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?