Warning: include(/nfs/c01/h15/mnt/13896/domains/randsinrepose.com/html/wp-content/plugins/wp-super-cache/wp-cache-base.php) [function.include]: failed to open stream: No such file or directory in /nfs/c01/h06/mnt/13896/domains/randsinrepose.com/html/wp-content/plugins/wp-super-cache/wp-cache.php on line 65

Warning: include() [function.include]: Failed opening '/nfs/c01/h15/mnt/13896/domains/randsinrepose.com/html/wp-content/plugins/wp-super-cache/wp-cache-base.php' for inclusion (include_path='.:/usr/local/php-5.3.29/share/pear') in /nfs/c01/h06/mnt/13896/domains/randsinrepose.com/html/wp-content/plugins/wp-super-cache/wp-cache.php on line 65

Warning: include_once(/nfs/c01/h15/mnt/13896/domains/randsinrepose.com/html/wp-content/plugins/wp-super-cache/ossdl-cdn.php) [function.include-once]: failed to open stream: No such file or directory in /nfs/c01/h06/mnt/13896/domains/randsinrepose.com/html/wp-content/plugins/wp-super-cache/wp-cache.php on line 82

Warning: include_once() [function.include]: Failed opening '/nfs/c01/h15/mnt/13896/domains/randsinrepose.com/html/wp-content/plugins/wp-super-cache/ossdl-cdn.php' for inclusion (include_path='.:/usr/local/php-5.3.29/share/pear') in /nfs/c01/h06/mnt/13896/domains/randsinrepose.com/html/wp-content/plugins/wp-super-cache/wp-cache.php on line 82
Status Reports 2.0 – Rands in Repose
Management Why am I apologizing?

Status Reports 2.0

At a start-up, there are two organizational inflection points which drastically change communication within the organization. The first change occurs around fifty or so people — this is the moment when, if you’re an early employee, that you first see someone in he hallway that you do not recognize. This is troubling to you because, until that point, not only knew everyone on a first name basis, but you also knew what they were about… what they were responsible for… what floated their boat. Now, there’s an unknown quantity in the building.

This awkward, but necessary evolution of the organization, passes. You accept the fact the company is growing and you decide to focus your attention just on your group… who cares what those schmoes over in the support group are doing, anyhow? You’ve got an engineering organization to build.

The second organization inflection point happens somewhere around two hundred… two hundred and fifty. The problems identified during the first inflection point are serious problems now. Fiefdoms have been created in your organization and they’re not talking to each other. What made your organization great early on, great communication, is still going on.. it’s just going on inside of each of your organizations and not across them.

Executives in these larger organizations may be the first to recognize this when they’re meeting with these different organizations and get the impression these individuals teams don’t work for the same company.

So, the executives panic. They have an offsite where they talking about cross-functional communication and teamwork. They come back, promote some would-be-holistics to be Directors to improve communication, reorganize the company, and then… they do it… they curse the organization with busy work… busy work in the form of Status Reports.

I’ve managed a variety of different sized organizations. In the larger ones, inevitably, I’ve had a meeting with my managers where I’ve needed to explain what my Status Report policy is. I’ve always started this conversation with this same preface, “I’m sorry, but we’ve got to do Status Reports.”

Why am I apologizing? Clear communication is a good thing and status reports are just good, clean communication, right? No, they’re not. The reason I’m apologizing is because by instituting or supporting a Status Report policy, I’m admitting, “I do not have a better solution to facilitating good communication than busy work in the form of Status Reports. Sorry. I’m pathetic.”

The idea of Status Reports is not a bad one. Generally, I ask for the following information on a weekly basis. Highlight, low lights, and any open issues. Pretty simple. Think of it as a weekly litmus test. The first few weeks with a new group, I tend to get stellar Status Reports from the team. Lots of detail… lots of energy… lots of content. It’s clear the manager and the team spent time on the report.

Two months later, Dullsville. The very same people who were generating content rich Status Reports are now sending bullet lists that really don’t change on a weekly basis. I stop reading them, they stop writing them, and we’re back in the Land of Poor Communication where we perpetuate the fact that everyone hates Status Reports.

This needs to be fixed.

To me, their are two major consumers who need Status Reports. The first consumers are the executives/overseers/managers. This is your senior management crowd who want a high level overview of where all that money is going. You want to keep this group in the loop because they sign the checks, they can be very good at discerning warning signs from seemingly vanilla Status Reports, and they also usually are big influencers on strategy… this is key when you want them on board when you’re proposing that two month slip to improve quality.

Due to the fact these folks see a lot of Status Reports, there’s a requirement for the data to be somewhat normalized via a familiar template otherwise they’re going to get frustrated spending their time figuring out what information is being conveyed rather than acting on it.

The other major consumer for Status Reports is, well, everyone else in the company. Actually, let me rephrase, the other consumer is everyone else in the company who wants to read your status report. I’ll explain…

Right now, you probably send your status report to some group of people or a mailing list which goes “to the right people”. The definition of the “right people” is likely based on role in the organization… the managers… the leads… whoever is supposed to have cross-functional visibility.

Here’s the problem with this group you’ve selected.

Let’s say you’ve had an open issue on your status report for four weeks now. It’s gone on long enough that you manager is starting to bring the issue up at your 1:1 and she’s getting frustrated that your answer to “What progress has there been?” is SHRUG. The correct answer to your four week open issue is sitting in the head of JoeBlow Engineer who sits nowhere near you. He is completely outside of your management food chain and he can save your weeks of effort and possible executive embarrassment. How in the world are you going to get to this guy?

Sure, if you’ve got a solid list of recipients for your Status Report, there’s a good chance that someone might make the connection between your Open Issue and JoeBlow, but, chances are, that manager has grown jaded about Status Reports JUST LIKE YOU.

You’re waiting for the punch line here, you think I’ve got some solution and, well, I don’t. What I do have is a rough knowledge of many of the emerging information management tools and I know there is a solution which:

  • Makes it easy/attractive for larger organizations to share their information
  • Provides a facility to publish scheduled structured reports to executive-types

Let us first talk about two tools:

WIKIS

Wikis provide a solid, flexible backbone for information gathering and distribution, but they are geek. Average computer users will not find them accessible. This means that any solution based on Wiki technology will mostly benefit engineering. I’m ok with that.

Wikis intentially don’t provide structure which means chaos rules. That’s great for a random mix of evolving information, but, at the end of the week, someone has to generate a Status Report and that person’s life will be easier if they don’t have to do a damned thing.

My gut feeling is that while Wikis are a great tool for organic information evolution, they’re not going to play nice in the Status Report world. Not only because of their lack of structure, but I believe the content would be biased the moment those who provided content discovered the Wiki was being pruned for Status Report data.

WEBLOGS

I can see three possible implementations here:

  • Everyone on the team has a weblog
  • “Leaders” have weblogs
  • Project or aggregate weblogs

Weblogs don’t have the level of collobartion has a Wiki, but they can be more structured. Plus, a variety of linking technologies varying from simple links to TrackBack technology provide some of the interconnectiveness that Wiki’s do so well.

A big issue with the weblog is initiating that first conversation within it that doesn’t sound like, “Hey guys, we’ve got a team weblog now and, well, speak up so I have to do less work on status reports.”

There needs to be some creative incentive for individuals to write stuff down. For the Wiki, there is the promise that if you write it down, maybe you can avoid future lame redundant questions. For the weblog, the timely conversational style of the medium keeps the content focused on news of the moment and that’s really the question; is news of the moment interesting to an engineering organization?

What I’m curious about is if anyone has had any success using web-based collaboration tools as a means of augmenting or replacing status reports. I know Wikis have successfully emerged as semi-structured information repositories… have they evolved into anything? How in the world can I get out of writing Status Reports?

24 Responses

  1. One of the problems with status reports is when you genuinely don’t have anything significant to report – you get into a loop of sending "no change" reports, but your actual progress may have shifted quite a bit over the course of time. You could ask people to only submit progress reports when they’ve actually made progress (or are significantly held up), but then some people will take advantage of that to contribute the bare minumum data to not get fired.

    A company I’m associated with tried using a weblog for progress reports for a while. It sort of worked, but it mostly didn’t, largely because of the number one problem of progress reports: the time you spend updating the thing could potentially be better spent getting more items off your to-do list. This is particularly noticeable in IT departments where there’s a lot of small stuff going on simultaneously – create an account, fix a small but non-critical bug on the mailserver, etc.

  2. I’ve got (some perhaps optimistic) hopes that some of the future reporting features in tasks will make it possible for me to spit out status reports at will without doing more than just minor editing.

  3. Interesting.

    Being an active user of tasks, I hadn’t even thought of using that app for status. I can see how you’d use the multi-user version to report on “what changed this week”… Hmmm….

  4. Yes yes yes!

    So here’s what you are really after. Using the same tools adapted for business use, many of the tasks in the project can actually be accomplished using them (e.g document editng). Focus project communication within these tools as well. Still require status reports, but your team can draw upon workable text and link heavilly to form them more quickly and you can always dive into detail.

    Disclosure: my company, Socialtext, provides these tools, as Jim McGee mentioned http://www.mcgeesmusings.net/2003/11/20.html#a3844

  5. Pearls before swine..

    Rands, you may have just given me the “oh shit, why didn’t I think of this first?!”. I’m going to suggest weblog to my manager tomorrow on my weekly Status Report (argh!).

    It may not be perfect but it will fill a few gaps that I see right now:

    1) let my boss know what I’m doing

    2) let other people in my team know what I’m doing (our weekly team meetings don’t always happen)

    3) my bosses boss (etc) if they want to get granular or think my project is particularly interesting can check it

    4) anyone else in the company (I know, this probably won’t scale to 2000 people but we’re only 250 and I’m an incrementalist) can see what the heck I’m doing and decide if their project and mine are intersecting/antimatter.

    5) don’t know what 5 is but I probably will find out tomorrow.

    B-)

  6. Eli Sarver 13 years ago

    Our company uses Niku for task management. We still make time for verbal conversations on projects, and we still write ‘post mortem’ reviews of projects, but ‘statusing’ is now a thing of the past. We end up much more autonomous that way. Also, vacation time is tracked this way so we don’t have to worry about that mess either.

  7. Kindred 13 years ago

    Damn Rands, when are you going to write a management book??? Scott Adams be damned, you have some great ideas that people (other than us Jerk City fans) should read up on.

    [+2 ASS KISSING SKILL]

  8. Great Post! I’ve been advocating blogs as part of a “Team Brief” a well established practice. See http://www.henshall.com/blog/archives/000163.html Seeing it in the context of “Status Reports” just helped me with language! Thanks. Team briefs focus on Performance, Plans, People, and Policy.

    I don’t think you want to get out of writing status reports. The problems arise when they are not associated with achievements, progress, action, barriers, new questions or insights. Sales Reports are a great example for blogs, which well categorised really enhance communication. Similarly, marketers that aren’t using blogs to answer specific questions are wasting time. All these elements add to the status of what’s going on and creates a “real-time” flow.

    As you so correctly point out. Getting over that first hurdle is the most important.

  9. “Information” is (to some) “a difference that makes a difference”. There’s no context for a generic status report aimed at everybody/nobody.

    I’ll try to stop frothing/ranting and do a rewrite, but you can see my first thoughts at

    http://webseitz.fluxent.com/wiki/z2003-11-21-RandsOnStatusReports

  10. Great Post! I’ve been using a weblog for posting status information for about two months or so now. I am still harvesting the ‘what’ out of my blog to create official status reports, but that is mostly because I need to deliver it to customers as well as internal management.

    I think the really powerful part of this is that it allows others to look over your shoulder as you work. And the others can be peers as well. Status information goes sideways as well as up.

    Aggregation can also play a big part in getting refined information pushed up to senior management where it needs to be. I agree that this likely belongs in a structured blog of sorts …

    What I have thought about is creating a feedster style portal page that automatically aggregates status reports into a common view…

  11. hgulaghluaghubuuuhh

    Positive feedback for communication; or designate 1-2 people within a given fiefdom to communicate with the other divisions, or to management. Weak connections can often be the most important links.

    (See first sentence)

  12. Adrian Howard 13 years ago

    Blogs as status reports have worked very well for me for a year or so now. Especially when combined with a wiki where you can make your own “aggregate” pages – so you get public status reports that everybody can read.

    One payoff you get in a distributed team is that the team itself can spot internal issues more easily.

    One issue I’ve spotted a couple of times when I’ve introduced blogs as status reports / project journals is a lack of integration with existing systems. For example a programming team is probably already entering status information into their source control system when they commit changes. Don’t make them enter it again into a blogging tool, instead make an RSS feed from the source control system.

  13. actmodern 13 years ago

    The problem with blogs and wikis is that they are both not very good at keeping information categorized and sorted out neatly. Even a decent Wiki system is at the mercy of its users categorizing things properly.

    I’m a big fan of mailing lists. Subscribe your staff to a mailing list, keep a searchable archive somewhere, and maybe allow each one to maintain a blog.

    The boss should still make rounds every day or two and keep tabs on his staff. Talk to them one on one. Assign tasks, and ask for verbal reports by calling staff into your office.

    This should still scale.

    Maybe I’m old fashioned but I think Wikis and blogs are just too “webby” to be useful.

  14. pubegagger 13 years ago

    We just use a Request Tracker ticket for every project. (rt3 – http://bestpractical.com/). Subteams use connected child tickets. When we need reporting, we interrogate the ticket database directly via a bunch of postgresql views and queries. Later on, we can relate bugs, issues as separate tickets connecting directly back to their original project ticket.

    Managers can and do bookmark the tickets they care about, and can search and categorize by keywords and queues (a queue is a class of ticket). Appends are by simple web interface or by email, with adequate access control.

    RT supports more automated magick than our management have been able to so far demand. We have an ODBC bridge so that ticket-based reporting links directly into various Excel spreadsheets used for ERP.

    And it’s free. And neither I, nor my team(s), need to write status reports 🙂

    PG

  15. Harry Henshaw 13 years ago

    The second organizational inflection point might be somewhat less than two hundred. Robert Paterson discusses some work of Robin Dunbar suggesting the maximum number of people with whom a person can maintain a social relationship is 150.

    http://smartpei.typepad.com/robert_patersons_weblog/2003/11/magic_numbers.html

  16. Konrad 13 years ago

    Rands, you’ve hit on the core problem of management, software engineering and many related fields such a military logistics: information processing doesn’t scale well.

    A computer with two CPUs isn’t twice as fast as with one. A team of 5 engineers doesn’t work 5 times as fast as a single engineer. There’s always overhead. Eventually the overhead grows to the point where you spend more time dealing with it than with the problem itself. That’s management. That’s software engineering. That’s logistics.

    What’s software engineering about? Dealing with information processing. 99.99% of time spent on any software project is stuff *other than* typing in the code. It’s making sure one guy’s code will work with the other guy’s code and that the whole thing will do what the customer asked for in the first place.

    Software engineering is the answer to dealing with huge projects that are too complex for any one person to deal with. You don’t need design patterns, requirements specs, object-oriented design paradigms and all that crap to make a little program that plays tic-tac-toe. These are tools that try to tackle complexity. They’re not there to make coding easier but to make the organization of the coding easier.

    Likewise, management is what happens when you need to run a large organization. The managers are there to manage the complexity of figuring out what each employee should be doing. They break up the information processing work of this huge, complex thing into chunks that the tiny capacity of the human brain can deal with. At the end, you put those processed chunks together and hope for the best.

    Do I have an answer for you? Hell no! But if there’s any point to this is that no matter what solution you come up with it’s gonna suck. Not because you’re not a smart guy but because it’s an intractable problem. Once in a while you can get a good management solution for a particular company of a particular size at a particular time, but that’s maybe the best you can reasonably hope for. (And of course, that’s all you asked for to begin with.)

    Possibly the ultimate example of all this is politics. Democracy is horribly inefficient. You’d think that if everyone gets a vote, then the majority would get what they want. That only works some of the time and even then only for simple issues that have a yes or no answer. Sometimes the majority gets what only a minority wants and other times everybody gets what nobody wants!

    Like Churchill said, it’s a horrible system but the alternatives are even worse. Why? Cause we don’t have a good way to deal with decision making in complex systems.

  17. Tools, Practice and Adaptation

    One of the better parts of my talk at the Bay Area Futurist Salon was finally meeting Eric Eugene Kim of BlueOxen. He posted some well grounded reflections, but raised some issues, so I’ll continue the conversation here. Eric questioned…

  18. blogs for work?!

    I’m thinking about pitching MT + w.bloggar or something as a solution for communication and coordination with all the goonies at work. We’ve got a fairly large (~100) person department (DBAs, network techs, admins, pc ninj4s, etc), and about half…

  19. Status Reports

    A few weeks ago Rands posted a couple of articles (1 and

  20. Wikis and Weblogs

    The original post entitled Status Reports 2.0 at the Rands in Repose blog is more than half a year old, but I only encountered it today.

  21. My boss wants a daily email sent to him about what I did each day. I just recetly setup a weblog (wordpress) on a small web development server and will be setting up rss2email[1] to automaticly email him each post in a “daily status” category.

    Not only will he get the information he wants but I will have an archive of what I am doing that I can get comments on from other people.

    (Also this development server hosts a rogue wiki I setup to store my stuff on and now is accepted by all the managers.)

    [1]http://www.aaronsw.com/2002/rss2email/

  22. Keep working!

  23. David 9 years ago

    Can I suggest that you re-read before posting? You have some good ideas, but if your interest is clear communication, a quick once-over would remove about 20 grammatical mistakes, and help you come across as a professional. I know that, as a society, we’re trading away precision in favor of volume in our communication, but if each of us puts in a bit of effort, we can have both. Also, your use of the word ‘inflection’ is, shall we say, cutting edge?

  24. Vivek Varma 9 years ago

    Your article brings joy in developing a tool for Status report and my process towards starts !!