← Home

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.


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?

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.


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

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:

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):

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:

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:

You MUST read widely

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