Status Reports Suck and Everybody Hates Them

with 4 comments

This post is part of my series on Managing Developers – How not to suck

When I worked at Compaq, we had an executive that just loved status reports. They were executive crack. His idea of managing was making sure everyone did their status reports on time. He was ultimately fired in a very public and very satisfying way. We had a party – really.

Every week he had the whole team stop what they were doing and write status reports. We had a very well defined status report format. Each team member would send their report to their manager, who would then combine them into a team status report. He would then send them on up the chain, they would be summarized again, and eventually they would all get to the executive.

Here comes the hilarious part; a few days later we’d be in a meeting with various folks – and the executive – and someone would ask a question. The reply was invariably “well, that was in my status report…”. This theme occurred with great regularity. Even though we had status reports, managers would ask questions as if we had no status reports. The executive was the worst.

Awesome. We spent a whole bunch of time, effort and energy running a process that caused us to write stuff nobody read.

It was really even worse: a pretty significant number of people didn’t get their status reports to their manager on time. Why? Because they were busy doing real work. This resulted in nag mail. Nobody likes nag mail. Relatively often people wouldn’t get their report in at all. Missing a status report got you on the execs radar – always a bad thing.

Why do status reports suck? Two reasons:

  1. Because status reports are always required to be short summaries – often bulleted lists with brief descriptions. The idea of course is people will read them if they are short.
  2. They are always done on a weekly deadline. This is a massive team wide synchronizing event.

Software development work is complicated. There are rarely simple issues. Simple bullets just lead to questions that need to be answered in detail. Proponents will point out that the status report let managers “drill into” interesting things and “manage by exception”.

That’s not managing by exception – it’s managing by being random. In this system, developers just get jerked around. They have no way to know what is interesting or exceptional because it always changes from week to week and is different for different managers.

People are not mind readers – unless you tell them ahead of time, they will not know what you think is important. So, people go in two directions; blowing of the status report off, putting the absolute minimum work into them they can get away with; They know they will get ask the same questions either way. Or, they will put too much work into it, wanting to be prepared for questions with detailed answers.

Status reports are disruptive: There is always a weekly deadline. This means that once a week, everyone stops what they are doing and writes their status report; all at the same time, no matter what else is going on. Each week – this makes status reports the single most important thing everyone is doing. This is just dumb.

Status reports also add latency: at best it takes two or three days for all the status reports to be written, rolled up and sent up the chain. It takes more time if there is something controversial or problematic happening; then the status reports are vetted and often sent back for revision, or edited heavily so they “express status in a measured manner” (e.g. spun). So, by the time the people that want them need them, the information is already old and things have changed.

If those reasons were not enough to avoid status reports, carefully note that developers hate them. Why? Because they are something that you (Mr. Manager) are making them do that doesn’t help them get work done; status reports are intended to help someone up the management chain they rarely talk to or hear from. You don’t need a status report because you talk to your team every day – right?

There are many ways to avoid status reports, all of them are better than having status reports. Here are four:

  • Have a system that sends “check in mail” to the right people. Check in comments should have useful information in them. Such as: “Initial check-in of the XML manifest schema checker”. Look ma! No status report needed.
  • Use your bug tracking system to keep track of the state of bugs and work items. All good bug tracking systems do this. Then, have a system (often included with said bug tracking system) that can automatically generate reports of progress and status. Bonus points for doing this with a web page. This is really easy to do. If you don’t have one of these for your team or organization then write one – you are all software developers… you can do it.
  • Use a project tracking system (like Microsoft project, Team Foundation, FogBugz, or one of many others, and let people update progress and task completion as they work. This goes into a database that managers can query when they choose.
  • Create an effective and light weight process for managing exceptions, problems, and blocking issues. Problems (say a newly discovered bad bug) need to be communicated right away, and not wait for a status report. The most important thing about this system is that problems shouldn’t be treated like fire drills. If you find that problems regularly put your organization into fire-drill mode then your managers have something they need to fix.

There are probably many others examples. Good management systems share three important characteristics

  • They are all asynchronous and timely. Developers can update the information at appropriate times such as when they complete tasks, or they are at natural stopping points.
  • Its easy to use – for everyone. Developers can easily update information – anytime. Managers can easily get reports any time. Anybody, not just managers, can query the system at any time to see where things are – they don’t have to wait on anybody.
  • Its automatic. Nobody has to do any manual work. Dashboards simply show the current status People are notified of problems right away.

Believe me – this kind of system works really, really well. Developers like it, managers like it. Everyone is happy. It’s also really efficient.

You invest in good computer systems for your developers, version control, and a bug tracking system. You should also invest in an effective work tracking systems and processes. It will make everyone’s lives easier – really

So, don’t suck. Don’t make your people write weekly status reports.



Written by foredecker

March 5, 2011 at 1:51 pm

Posted in Managing Developers, Uncategorized

Tagged with

4 Responses

Subscribe to comments with RSS.

  1. 🙂 Great post.


    April 4, 2011 at 3:26 am

  2. Ugh, I know this feeling, however, I feel like many companies are starting to steer away from these type of status reports (at least weekly ones). The company I am with now recently got rid of them after years of outcry. For our development management, we use OnTime (, to allow for our project managers to clearly see what everyone is working on and what is left to do. It has been working well for bug tracking too. When we were deciding what system to go with, someone did bring up Fog, and Jira, but, I never got a chance to fiddle around with either of them.

    Great post, look forward to catching up on the rest of them.



    April 15, 2011 at 12:08 pm

  3. I totally agree. Great post!!!!!!!!!!! This is awesome!


    July 31, 2012 at 10:33 am

  4. U agree…but I found a blog entry that links to a program that automates weekly report writing – I think it is worth a look:

    I think this is the kind of system you mentioned in your post?


    February 14, 2013 at 4:58 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: