I remember the first time I had to write one of these puppies.
I had just been promoted to manager at Yahoo back in 2000, and was running a small team. I was told to “write a status email covering what your team has done that week, due friday.”
Well, you can easily imagine how I felt. I had to prove my team was getting things done! Not only to justify our existence, but to prove we needed more people. So I did what everyone does: I listed every single thing my reports did, and made a truly unreadable report. Then I started managing managers, and had them send me the same, which I collated into an even longer more horrible report. I sent this to my design manager, Irene Au and my GM, Jeff Weiner (who sensibly requested I put a summary at the top. Go Jeff!)
And so it went, as I moved from job to job, writing long tedious reports that at best got skimmed.
At one job, I stopped authoring them. I had my managers send them to my project manager, who collated them, sent it to me for review, and after checking for anything embarrassing, I forwarded it on to my boss. One week I forgot to read it, and didn’t hear anything about it. It was a waste of everybody’s time.
Then I got to Zynga in 2010. Now say what you want about Zynga (and much of it was true) but they were really good at some critical things that make an organization run well. One was the status report. All reports were sent to the entire management team, and I enjoyed reading them. Yes, you heard me right: I enjoyed reading them, even if when were 20 of them.
Because they laid out important information in a digestible format. I used them to understand what I needed to do, and learn from what was going right. Please recall that Zynga, in the early days, grew faster than any company I’ve seen. I suspect the efficiency of communication was a big part of that. When I left Zynga, I started to consult. I adapted the status mail to suit the various companies I worked with, throwing in some tricks from Agile. Now I have a simple, solid format that works across any org, big or small.
1. Lead with your team’s OKRs, and how much confidence you’ll hit them this quarter.
If you don’t use OKRs, use any goal you set quarterly. If you don’t set goals, you have more problems than your status report. You list OKR’s to remind everyone (and sometimes yourself) why you are doing the things you did. Your confidence is your guess of how likely you feel you will meet your key results, on a scale from 1 to 10. 1 is never going to happen and 10 is in the bag. Mark your confidence red when it falls below 5, green as it heads toward ten. Color makes it scannable, making your boss and teammates happy. Listing confidence helps you and your teammates track progress, and correct early if needed.
2. List last week’s prioritized tasks, and if they were achieved.
If they were not, a few words to explain why. The goal here is to learn what keeps the organization from accomplishing what it needs to accomplish. See below for format.
3. Next list next week’s priorities.
Only list three P1’s, and make them meaty accomplishments that encompass multiple steps. “Finalize spec for project xeno” is a good P1. It probably encompasses writing, reviews with multiple groups and sign off. It also gives a heads up to other teams and your boss that you’ll be coming by. “Talk to legal” is a bad P1. This priority takes about half hour, has no clear outcome, feels like a subtask and not only that, you didn’t even tell us what you were talking about! You can add a couple P2’s, but they should also be meaty, worthy of being next week’s P2’s. You want fewer, bigger items.
4. List any risks or blockers.
Just as in an Agile stand-up, note anything you could use help on that you can’t solve yourself. Do not play the blame game. Your manager does not want to play mom, listening to you and a fellow executive say “it’s his fault.” As well, list anything you know of that could keep you from accomplishing what you set out to do— a business partner playing hard-to-schedule, or a tricky bit of technology that might take longer than planned to sort out. Bosses do not like to be surprised. Don’t surprise them.
Finally, if you have anything that doesn’t fit in these categories, but you absolutely want to include, add a note. “Hired that fantastic guy from Amazon that Jim sent over. Thanks, Jim!” is a decent note, as is “Reminder: team out Friday for offsite to Giant’s game.” Make them short, timely and useful. Do not use notes for excuses, therapy or novel writing practice.
This format also fixes another key challenge large organizations face: coordination.
To write a status report the old way, I had to have team status in by Thursday night in order to collate, fact check and edit. But with this system, I know what my priorities are, and I use my reports’ status only as a way to making sure their priorities are mine. I send out my report Friday, as I receive my report’s. We stay committed to each other, honest and focused.
Work should not be a chore list, but collective push forward toward shared goals. The status email reminds everyone of this fact, and helps us avoid slipping into checkbox thinking. This system is so effective in helping me get things done, I’ve even adapted it for my personal life.
Coordinating organizational efforts critical to a company’s ability to compete and innovate. Giving up on the status email is a strategic error. It can be a task that wastes key resources, or it can be a way that teams connect and support each other. Change your status email today, and transform your teams.
On a related note, I have a new book out on goal setting and execution for product teams.
Originally posted on Elegant Hack.
Editor’s note: If you found this post useful, check out the free e-book Design Collaboration for Product Teams (Vol.1).