Management Why you do what you do

Context Reports

I’ve been hating on status reports for a long time and it comes from my first knee-jerk reaction when my manager asked for one. My unspoken thought was, “Why, wait, what?” I didn’t understand big companies, I didn’t understand politics and bureaucracy, all I understood was that it felt like a waste of time to document the things I’d already done. I didn’t understand why.

After a couple of decades of preaching status report hate, they are still around. Leads are giving them clever new names, they are asking for them on wikis instead of email, but the core concept is there. Leaders at a distance are trying to measure what is going on and rather than figuring out why communications in their teams are breaking down, they flex their managerial muscle and dictate their terms: Each week, every week at the same time, please document what you’ve done, please explain what you’ll do next week, and if you want please note any concerns.

I would like to note a concern. Yes, I understand that humans don’t instinctively communicate well at scale, but as I noted elsewhere I believe email-based status reports are the clearest and best signs of managerial incompetence and laziness. I am concerned that in two decades of leadership, status reports are still around. We’ve invented innumerable new mediums of communication, but crap managers are still asking the team for information a good lead should be able to acquire via other productive and respectful means.

This morning I realized I might have a productive way to twist status reports into a useful exercise. Let’s call them context reports. A status report documents actions both completed and planned. A context report documents the reason why (and to a lesser extent how) you’re completing these actions and I suspect this information is far more useful to everyone involved. Let’s try it out by transforming common status report items into context report bullets.

Status: Interviewed Bob for the engineering positioning.
Context: Continued to interview candidates because our front-end engineering team is currently 1/3rd the size of our platform team which means we can’t put a well-designed face on most of the functionality we’re building.

Status: Closed and verified 23 bug reports.
Context: 70% of the 23 bugs I fixed this week were P0 and we’re two weeks from shipping which means there is no way we’re shipping.

Status: Met with the product management team.
Context: Twice a year meeting with product management team where they ask for what they can’t have, we say no, they promise resources they don’t have, and everyone gets frustrated.

My example statuses are deliberately bland and my example context is also deliberately snarky, but my point is the same: which gives everyone involved more value?

Context describes “the circumstances that form the setting for an event, statement, or idea, and in terms of which it be fully understood and assessed.” It’s more for you, the person saddled with capturing status, but if you’re required to build these reports, why not make an exercise where you are taking the time to understand why you do what you do?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

10 Responses

  1. I love this post! Mostly because I have and do deal with a lot of people who think status reports are important. They (the reports, not the people) make me feel like moments of my life I’ll never get back.

    I once said “if you’ve got a time machine in your back pocket so we go back and change anything we need to I’d be glad to have a status meeting.” That didn’t go over too well. :-) I also said to someone once that I’d rather have progress updates and they accused me of playing with semantics. :-) Some compliance came my way when I explained what I was looking for but old habits are really hard to break for some people. Sometimes though it feels like quite the struggle so thanks for writing this post!

  2. My $.02 – just stfu and just write the status report ( call it a context report if it makes you happy). It only takes a few minutes.

  3. Barry Williams 9 months ago

    While I completely agree that a weekly report of tasks performed is pointless I do think that a retrospection of what happened and why each week is a valueble process for managers. Spending an hour or two listing all of the detailed tasks and states into a report that nobody will ever read is the wasteful portion.

    I like the idea of summarized contextual reporting because it still forces the retrospection without meandering into tediousness for the author and recipients of the “status report”

  4. Context reports sound great and all but isn’t the end result the same? An emailed status report with more words in it?

  5. I know on my end, even when I am using “valuable” status reports (IE, providing something for mass digestion/to be used by a PM for mass alignment), a lot of the value gets lost. It becomes about confirming items being completed, and a consolidated tool (your Asana, or even a shared project plan with some amount of change tracking) would be just as good.

    I like that this is providing better content because it is capturing Need/Reason, as well as any obstacles. I think I am going to try it!

  6. Really like the idea, particularly because of the value of this exercise to the writer.

    My snarky example…

    Status: Met with the dev team.
    Context: Bi-weekly meeting with our engineers to review component effort forecasts and prioritize enhancements. Immediately discounted forecasts by 20% to account for 40% “we’re making this sound harder than it is” cushion.

  7. In my experience, status reports are a cover up for incompetent management. It may sound harsh, but making engineers writing status reports, is a waste of time that could have easily been spent otherwise (and yes, I consider surfing web more productive as writing status reports). Not to mention that the whole point of making engineers writing status reports is the fact that your own manager does not know what his subordinates do. Which is sad in it’s own right.
    What is sadder is that a manager could easily obtain data from any half-decent issue tracker and SCM, but they are either too lazy or to inept to do so.

  8. Allen 9 months ago

    I love your context report in place of a status report. There is always a but with this kind of thing, the but in this case is that most workers just don’t write that well.

    Part of the manager’s job is to design reporting processes that their employees can actually use without investing so much time that it impacts their regular job. For most team leads and first line managers writing the kind of descriptive text you do is beyond their experience and training.

    Your context based tracking will only work effectively if the senior manager is willing to invest the time and effort to train his direct reports in what is important and how to report it. The burden is always on the senior manager to clearly define and explain what she/he wants and to allow the subordinate time to get it done.

  9. Philip Derbeko 6 months ago

    You have a great point that status reports lack context. However, there is a deeper problem: people don’t like to write especially about what they did. Some think that they might spend those 5 minutes doing something more productive, which is wrong. Some feel that they are being micro-managed and some say: “look at the code changes”.
    All of them are wrong, but I’ve been trying to deal with information distribution problem for years in different organizations but without a good solution. Even daily/weekly meetings are not solving the problem (I let the people talk and then I write a summary). People talk too little and prefer not to listen.
    In summary, the best solution I had is to have group managers to write a weekly reports of the group progress and send it company-wide. They can be made to invest the time, they still know what is done in their groups and can summarize it. Those reports also limit the amount of flowing information in the organization.