Tuesday, December 04, 2012

 

Why I despise status reports (and you should too)...

I wonder if I am somehow unique in that I almost NEVER ask my team to provide me with status? My mantra as a leader is to be savage in reducing the amount of administrivia that development teams work. While I can control it for others, I do suffer in controlling it for myself. It is important to acknowledge the reason why status reports exist in the first place. The root cause is simply attributable to human nature. We focus on meetings that are primarily designed for people to get answers to questions—not explore answers but get answers, so they’re looking for information, looking for status reports.



Most of our inbox is filled with status reports—when is this thing going to be ready, when is it going to ship, what happened and that sort of thing. Even when we are engaging with people, we tell stories about events. What happened, tell me the story. If you put all those things together, all of them are about the results of what’s going on. They however aren’t so much about the why.

As someone with an engineering mindset, I tend to learn not by the current status of any situation but the root cause. If you are building bridges and you have built hundreds of them successfully, what have you learned? Now ask yourself how much you can learn when a bridge falls down?

If you think about the reports that people have, just the first layer of that system for understanding current reality, if they’re good reports, they tell us whether we have a problem. If they don’t even tell us about a potential problem, I’m not even sure what the point of the report is.

Second, they should tell us where we have a problem, or at least help us figure that out. Many reports don’t do that, but if they’re really good and the problem is of a certain nature, reports should be able to tell us where we have a problem. Even so, they still really never tell us why we have a problem. For that, we have to go to the source – we have to go to how the work is done. Whether it’s direct observation, we go and actually see the problem, whether it’s process maps or value stream maps, or a mechanism to get into how the work is designed and managed and improved.

We sometimes wax poetically about finding root cause, but sometimes we simply need to understand cause and effect. Many leaders don’t really understand how the problems are being generated. We often have much more focus on the results than we do on why we’re getting the result that we get.






<< Home
| | View blog reactions


This page is powered by Blogger. Isn't yours?