Stop micromanaging - just set clear expectations

Prior to startup days I spent much of my time managing development teams - setting tasks, reviewing them, and all too often redoing them because the outcome wasn't what I'd expected. The problem wasn't so much that the task had been done poorly, but more that I had done a poor job of setting clear expectations.

I hate being micromanaged as much as the next person, so I prefer to clearly define the task up front and then get out of the way. The problem with this is that sometimes people have a very different picture in their head as to what a successful outcome looks like.

Didier tweeted this great HBR post on how to get involved without micromanaging last week and it reminded my of a checklist that I started using with my development team to improve the outcome from tasks I set - "CPQQRT". Despite it's clumsy name, quickly running through this in my head whenever I had to task my team really helped in aligning expectations.

• Context: what is the background?
• Purpose: what are you trying to achieve?
• Quality: what quality level is required?
• Quantity: how much is necessary?
• Resources: what resources are at your disposal?
• Time: how long have you got to get it done?

Here's an example task for a software developer to illustrate. The task: "Create a report of all outstanding software defects and an overview of our defect management process".

• Context: The customer is concerned with the amount of time we've been spending fixing defects so they'd like to better understand what's outstanding, and get an overview of our defect management approach.
  
• Purpose: We need to give the customer confidence that we are on top of the current defects and that our defect management approach is thorough without being over the top.
• Quality: Needs to be presentable to the customer and the data has to be accurate.
• Quantity: A couple of pages will do - e.g., a summary table of defects, and a process diagram with some explanation will be sufficient
• Resources: You can use tool xyz to draw up the process flow if you like, talk to Bob if you need help on how to drive it
  
• Time: Need the report by Friday, make it your top priority.

Our developer should have a clear idea on what is expected of him and the outcome is unlikely to result in any surprises.