The $100,000 Status Report

A status report template to prevent middle management from costing your company millions

Did you see the memo?

The Process

Every Friday, my engineering manager writes a detailed status report. He even takes time to find a random “fun fact” to make them more interesting and encourage people to read to the bottom.

On Mondays, my job as Product Manager is to take that report and condense it down into our group’s preferred format and also make sure our roadmap, our project plan, and the project plan of several department-wide initiatives are up to date.

On Tuesdays, he and I sit in an hour-long meeting with our group’s leadership; 11 leaders across three teams review the summarized status report in detail. I’m reasonably certain that of the nine other attendees, at most three of them are paying attention at any given time. All the people who have any reason to care were emailed the original format from the engineering manager, but I’d bet money they didn’t read it. The presentations from the other three teams do not impact my work in any meaningful way, so I return the favor of their highly-divided attention and tune them out.

On Wednesdays, our VP summarizes our status report and those of the other groups in our department and sends a company-wide status update. I only understand about 25% of it because most of it is so far out of my domain I haven’t bothered to learn the lingo.

On Thursdays, I dream of clever ways to insert some way of determining whether other individual contributors actually read or understand any of these reports. I chicken out of trying any of them.

On Friday, we start the mind-numbing process all over again.

Quantifying the Waste

I work at a medium-sized tech company based in Silicon Valley. Everyone involved in writing these status reports is well-paid. For just my group of 11 leaders, I estimate we spend roughly 20 hours a week gathering these reports or sitting in meetings about them. Twenty hours a week is half of a full time employee — more than half if you consider vacation, sick time, etc. If each of these leaders makes about $200k, we’ve just spend $100k a year writing reports that provide little to no value to the organization, and that’s just one group. In my department, there are 12 other groups that follow this process. Twelve. This wasteful process is repeated a dozen times a week.

Want to know why scrappy start-ups are able to usurp established giants? They don’t waste time and money on status reports. Start-ups don’t have layers and layer of middle management who need to feel informed but don’t actually make decisions. In the start-ups I’ve had the pleasure of working with, middle management is there to remove roadblocks and solve problems, not just document them and run them up the chain.

Building a better status report

Believe it or not, there are better ways to report on a team’s status across the organization. Strategies that are not only informational, but motivational. Here’s a template loosely inspired by the Traction model that should serve you well, no matter what size of company you’re at:

• Top metrics — What are the top metrics your team is trying to move right now? Limit this to 3–5 distinct metrics tops, and assign each a green/yellow/red status. Keep the same metrics for at least a quarter. If possible, show historical trends.
• Headlines to celebrate — What wins did your team have this week that are worth calling out? Features launched, new customers won, lessons learned, work anniversaries, new hires, call out the good stuff — including failed experiments. Celebrating the lessons from failure breeds innovation. Always include a “what we learned” this week update to foster continuous learning and experimentation.
• Path(s) to green — what are you doing about your metrics this iteration to turn anything that’s yellow or red to green?
• Blockers/Risks — What challenges are keeping the team from green? Focus on what you need from the audience of the status report to support your efforts.

This format is superior to traditional status reports that focuses on whether or not you’re on track to hit a date for a variety of reasons, as outlined below.

Focus on business outcomes

The metrics your team is accountable for are and nearly always will be way more important than any deadline. Software delivery deadlines are rainbows, pixie dust, and lies. There is no scientific process for setting them. There’s no experiment you can run to get more reliable at predicting them because every project is unique. The estimation process for your last success may lead to your next biggest failure. Business outcomes, on the other hand, don’t lie. Did your team sign up to decrease infrastructure cost by 10% by end of quarter, but costs have gone up week over week instead of down? THAT’S a red flag that senior management needs to know about.

Reset what it means to be a great manager

A great manager has three jobs:

• Inspire your people to deliver the best possible outcomes for the company
• Leverage your connections and position of authority to remove as many roadblocks as possible
• Ensure your people get the recognition and promotions they deserve

Great managers don’t

• Micromanage deadlines
• Consider timelines more important than business objectives
• Shield their people from upper management, even if intentions are good

The best managers inspire the best results. Just because a team delivered a feature on time doesn’t mean it will drive any kind of meaningful business results. Middle managers need to stop fearing the wrath of upper management if a deadline slips and instead help reports tell the story about the value the company will receive from the investment. Sometimes, the value is a lesson learned instead of the revenue or engagement we had targeted, but it’s still a valuable experiment. Structuring as many quarterly objectives as experiments to learn from instead of deadlines to meet builds a culture of innovation and autonomy that brings the creative best out of every individual contributor. When the team is too afraid to speak up about a deadline not being hit because of the paperwork that’s sure to follow, we over-communicate empty promises instead of sparking meaningful conversations about the best way to drive business goals.

Motivate the team around common goals

Common business goals that directly support the organization’s mission and vision are inspiring. They help individual contributors connect the dots between the mundane work they’re doing every day and the big picture. They illustrate the impact that every engineer has on the bottom line. They inspire those aha! moments that drive innovation as team members think of other opportunities to drive the same outcomes with less investment.

Actionable Status Reports Unblock your Team

Imagine if your status report inspired action, instead of just more questions. Status reports should help your boss understand how to help you, not just provide them with fodder for the next level up to chew on and regurgitate into the next higher-level summary. Do you need to escalate a decision? List it here. Is the team waiting on communication from another department? Ask for a date to expect an answer by. Whatever it is that’s keeping your team from success, this is your time to ask for it. Raise these things early and often so that it is never a surprise when outcomes are missed come quarterly review.

Give your team back their time

Finally, evaluate if your team really needs the meeting to discuss the status report. In my experience, if you keep it succinct, publish it in a consistent, memorable, easily discoverable place (NOT JUST EMAIL), and provide the content in other skip level or cross-team initiative conversations, nothing will be a surprise and meetings can be avoided. That said, sometimes your team needs help brainstorming paths to green, and that’s where a cross-team meeting can help inspire some creative solutions. If half the team is ignoring half the meeting, that’s a good sign you didn’t need to meet.

Feedback welcome

I’m a firm believer that your processes are what make a team agile, not whether or not you adhere to a prescribed agile methodology. Every team needs to adapt processes to their own unique needs. Did you try this process out and it worked wonderfully? Amazing! Let me know in the comments. Was it a flop? Tell me about that, too. I’d love to learn from your experiences and/or advise where I can.