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, they 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 intentionally 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 collaboration of a Wiki, but they can be more structured. Plus, a variety of linking technologies varying from simple links to TrackBack technology provides some of the interconnectedness 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?