{squeaky lean}

Beat the competition. Be a slave to your development team.

In a company that has managers responsible for the success of a product, and developers who produce that product, the company's hierarchy normally places the managers 'above' the developers.

'Above' implies that it is the managers who request things of the development team, and the development team who respond on demand. Not the other way around.

And that, in the main, is how things are.

Thing is, it is this situation that damages the quality of a product and reduces the speed at which it gets to market. 

To fix this, once a manager has handed a project over to the development team, he or she should be answerable to that team, on demand, until the completion of the project. They should expect to be interrogated as and when the team require answers, and should be quick with decisions as and when the team need direction.

Why? Well, a few reasons, but the one I want to talk about here is context switching.

What is Context Switching?
Imagine your mother has asked you to bake a chocolate cake for a party this evening. You've not baked a cake before, but you're pretty excited about it.

  1. You get started, and soon realise you don't know which type of flour to use. You call your mother. She's playing poker and says she'll call back in an hour.
  2. You mow the lawn in the meantime. CONTEXT SWITCH No 1
  3. An hour later, your mother calls and tells you about the flour. Great, back to the cake. CONTEXT SWITCH No 2
  4. You spend 15 minutes going back over what you'd done so far to get yourself back up to speed. Baking and gardening require different mindsets after all.
  5. 15 minutes later you're wondering if it's ok just to use the chocolate egg you got for Easter.
  6. You call your mother again.
  7. She's spending her poker winnings on a spa treatment and can't be disturbed for the afternoon.
  8. You sigh, and decide to go and varnish the garden fence. Not as pressing a task as the cake, but it needs doing, so why not. CONTEXT SWITCH No 3
  9. At about 5pm your mother calls back.
  10. She says you need to get special cooking chocolate.
  11. You violently smash up the Easter chocolate with a rolling-pin. CONTEXT SWITCH No 4
  12. You trudge to the shop and come back with the chocolate. CONTEXT SWITCH No 5
  13. You read the recipe and retrace your steps for a third time. CONTEXT SWITCH No 6
  14. Your excitement about the whole cake thing has diminished substantially and suddenly you're not interested in how it will taste anymore, just about getting it done.
  15. Later that evening as people eat dry chocolate cake, your mother tells you you shouldn't have cooked it so long.
  16. You love your mother, but you spike her coffee with laxatives all the same. CONTEXT SWITCH No 7

What went wrong?

The cake went off track because when you needed more information, your mother wasn't available to provide it, so you had to stop working on it.

Your only choice was to switch to a different task and a different context.

Different contexts require different mindsets, knowledge and skill sets. Putting one set away, taking out another and getting the hang of it again can be exhausting and confusing if you have to keep doing it.

Context switching like this also makes it very difficult to keep tuned-in enough to spot mistakes, or to find those extra improvements that make a product great.

Is overall productivity effected?

Yes, because the context switching itself takes time. People don't move seamlessly from one to the other without losing momentum. Losing momentum by switching often can slow down projects drastically.

So what would have made the cake better?

Your mother answering your questions the moment you needed them answering. That way you could have just got on with it, keeping your momentum along with your excitement and pride in the quality of the cake.

Stop beating yourself up. The bad cake was her fault.

Anyway… back to business now please?

Yeah, sorry. Enough about cake.

As I've said, when 'management' hand the development team a project, they should then be answerable to the development team until the project is finished.

They need to be available to answer questions and to make decisions. Not at the next meeting, but as and when questions need answering and decisions need making.

But 'management' have things to do as well. Aren't you just passing the context switching problem to them?

Yep. And that's how it should be.

What?! Why?!

Because protecting those who produce your product from context switching, by swallowing it yourself, is what good managers do. It's what good management IS.

Good managers tell their team that they can call them or go see them when they need to. If you don't have time for these calls or visits then either:

  • Delegate this authority to someone who will, and forego the right to complain about the end product
  • Acknowledge that if the project isn't important enough for you to make the time, then the team shouldn't be working on it in the first place
  • Make time

Like this?

By Kevin Heery.


Leave a Reply