How to do “status meetings” right (aka avoiding “Death-by-Status”)

A truism in the start-ups v. “big” company battle is that start-ups have a big advantage because they don’t have to waste time in internal communication. Status meetings are quick and focused; not long-drawn out off-site affairs.

However, many startups ignore the underlying reason and value for status updates and many big companies can easily avoid status meetings with a little bit of effort.

There is a value to status meetings!? What are you nuts?

Nope! Not talking about status meetings – status updates is where it is at.

Status updates can and should be sent by email every day. By everyone. Including the CEO.

For a status update to have value, it must:

• Be explanatory as to the reasons work was done. If the reason can’t be articulated — why was it done? (“Did X so that Y feature could be turned on in the next release”)
• Be forward looking. The status update must be usable as a planning document. When will the new feature be completed (in man-hours)
• Enable bad process to be discovered. Is something impacting all 10 developers 30 minutes/day? Solving that annoyance will save 5 man-hours a week!

The status email should have:

• successes (include “in progress” work): Brag. Celebrate successes. Explicitly indicate if:
  • work is completed as far as the sender is concerned
  • work is at a good resting point/milestone. Many times a task does not need to be “completed”, because “completed” means completely done as opposed to “major roadblock removed”
  • work still needs to be done on the task.
• planned work for next work period, with best guess time estimates/completion date. Include next time available (very important for part-time people). Plan out tomorrow today.
• frustrations arose that caused time to be “wasted” – use this to help spot problems with processes. The sender is NOT asking for help, but rather is calling out process issues.
• roadblocks that help is needed to solve. The sender must provide enough detail to form an actionable question or request. All details that the sender has discovered about the roadblock must be written. Writing out the problem with all the known information:
  • anyone trying to help does not have to duplicate already done research
  • sometimes leads directly to an “obvious” next step
  • might enable someone else to immediately provide an answer with little to no additional questions.