A manifesto for a team that never was
Three years ago, in a moment of confidence while I was Special Projects Editor, I privately wrote down a set of rules that explained how I approached project management, and how I thought a team of project managers ought to operate when trying to establish a beachhead in a traditional newsroom.
I was not so confident as to proclaim it from the rooftops and invite discussion and difficult conversations around it.
Perhaps because of that, three years later, that team of project managers never materialised. But today I rediscovered the document while starting up a different team — one focussed more on making structural and systemic improvements rather than managing editorial projects.
Many of the rules I wrote about back then do not apply to my new team. We’re busy writing our own manifesto (to start with, we’re calling it a charter rather than a manifesto), which we might make public in due course. But I did find it instructive to revisit what I believed in back then to see how my thinking has evolved.
While I would still stand by most of these proclamations, I now think a more inclusive, trusting and less confrontational approach towards reporters is the better way to go. I was also a lot more strident and prescriptive back then, and despite not yet having read any Tom Peters three years ago, I apparently already adopted some of his writing style and thinking.
What can I say? WTTMSASTMSUTFW
Who we are
We manage special projects.
We are going to be completely transparent about our schedule. Everyone in the newsroom will be able to see what times we have blocked off for what projects / reasons.
Once every three months you must clear a week where you are not working on any projects: this week is for reading/thinking.
We are entirely PROJECT based. We are always concerned only with how best to tell THIS story - if there are subsequently lessons to be learnt about how techniques can be used to tell an entire class of stories better, great. But the starting point is ALWAYS the specific story in front of us.
We get our project ideas from editors and reporters. If you generate an idea on your own that you want to do (and that involves others) you need to find a way convince a reporter/editor that it’s THEIR idea.
However - we are NEVER their servants. We must never be put into a position where we HAVE to do any particular project. We MUST always be seen as doing the reporter/editor a favour by taking on their project.
Working with our team must be seen as an opportunity - to do something different, something creative, and something to be proud of at the end of the day.
We do not work with unpleasant people.
We are the business of generating envy
How do we do this?
-
Quality
-
Exclusivity: By executing projects that can’t otherwise be done. Our projects are always conceived as multimedia, digital (and sometimes social).
-
Firepower: We are the only ones who can bring an entire (digital) production team to your project
-
One-stop-shop: We take care of every step of the way. You as a reporter only need to deal with me, the project manager.
-
Metrics: not that every project will be a viral hit, but that we are the only one who can afterwards show you exactly how it did and how we can improve in the future.
We want reporters to be desperate to work with us. This is important because we (as project managers) MUST run the show. So until they are familiar with how we work (i.e. until they’ve done at least one project with us) We MUST be able to dictate the terms on which they engage with us.
Projects
Each project must have a concrete start date and an end date. The pitch process, including research, background reading, and refining the pitch, can be outside of these dates. But during these dates, you are working on just that one project.
Choosing the right project is of utmost importance - once you are locked in, you’re locked in.
Questions we ask when choosing projects / criteria for our projects:
These are not all NECESSARY requirements, but the more it deviates from this list, the lower the chance of success
-
Am I, the project manager, excited about this idea?
-
Would I like to work with you?
-
Is there enough time to do this properly?
-
Can I innovate with this? How?
-
Are you (i.e. the reporter/video producer etc) committed to this project or do you just want me to do work for you? Can you take time off diary and make this project, for the duration necessary, your main focus?
-
Am I free to plan the project, even if this means scrapping whatever story plan has already been drawn up before and starting afresh?
Every project MUST have a planning document and a final review.
If you do your job right, you will be busiest before and after the actual project.
Measures of success that apply to ALL projects:
-
Did we learn something? What?
-
Do the people in the team want to work with us again?
-
Internally, did people not involved in the project think it was a success?
When the project is over, the planning document should be closed and (a copy of it) converted to a full description of the project.
You will need to write two reviews afterwards: one for external consumption and one for just the project team. The external document needs to be as short, and as polished, as possible.
When the project is over, you will need to start evangelising and teaching. You DID learn something from doing the project, right?
Dealing with people
If you are going to criticise or suggest how something could be done better, you MUST first point out one thing you particularly liked about it
If you are ever saying no to someone, you MUST always give them an alternative and point them to somewhere else. NEVER close the (metaphorical) door in their faces.
What people will respond/pay attention to (ordered from most to least):
-
Face-to-face
-
Phone
-
Instant message when they are online
-
The first time you share a doc, accompanied by a message addressed to them
-
Email directly addressed to them
-
Mass/group email not directly addressed to them
-
Changes/updates to something that’s already persistently there: an existing Google doc, Asana, etc
Every time you are asking someone to do something for you, especially as a favour, use face-to-face or phone. Every time you want to send an email to someone in the building, ask yourself: can I go see them instead?
I follow up every single important email I send by going directly to talk to the person. I often will email just a link to the person knowing that I’ll be at their desk before they’ve even opened up the email. [ed: in retrospect this is bad advice as it can be really annoying if overdone or if what you have to say is only important to you and not to them]
The times you DEFINITELY should use email/written communication:
-
When you need a definitive record on something in the future.
-
Links/forwarding someone else’s email, anything that makes no sense to try convey in person/on phone
-
Group communication: when you need to make sure everyone is referring to the same thing and are all on the same page (use shared docs/asana in these cases)
If someone comes to your desk you MUST turn away from your screen/computer and face them directly and give your full attention to them.
NEVER assume anyone has to do anything for you, even if it’s part of their job. You need to find a reason why they should/would help you. This could either be because:
- They’re nice
- You’re nice and so they like you
- They owe you
- You are giving them an opportunity to do meaningful work and to express themselves
- You help make their lives easier
- They get to claim part of the glory / your projects help boost their profile
Ideas are worth nothing until executed upon
Corollary: You can get great ideas, for free, from so many places.
Corollary: You can be generous with your own ideas. There’s always more.
What to read next: Why editors ≆ project managers