Bottleneck Ninja!

In the previous post in this management series we examined how we can improve the accuracy of our estimation, how it can be best tailored to service the needs of the business, and how we can automate it towards our goal of a self-managing team.

Before we get ahead of ourselves we must return to our current position on the team evolutionary scale and examine other time-consuming elements of the business process; team-management guru Roy Osherove has a wonderful phrase for this – “bottleneck ninja”.

Team Evolution, Roy Who?

I should interject at this point to mention that much of the foundation from which I speak originates from Roy’s teachings on team management; his approach to team evolution and dynamics was quite an epiphany for me.

Identifying where our team is on the team evolutionary scale will help you understand the role you must adopt and focus your attention on important tasks.

For the purposes of this post I am going to assume you are somewhere between the ‘chaotic’ and ‘assisted’ stages, as probably are most teams. Roy identifies the chaotic stage with many common traits, including:

  • Continually trying to come up for air from day-to-day tasks, you just keep putting out fires!
  • Nothing important can get done
  • Requirements coming in from multiple stakeholders and never knowing how to prioritise them
  • There is no team support, they want to fix the problems but they don’t know how and have no time to learn
  • Team members don’t possess adequate skills to fully utilise source control and tooling

At this stage you need to take control and start over, we must “reboot the team”. During this phase everything must go through you, from requirements to code reviews, you must become a bottleneck ninja.

Taking control

Taking control does require a level of authority and support from the business, and importantly your team. Do not underestimate the impact of constantly inquiring into everyday activities (and even taking them over) in your efforts to better understand them; it can hurt morale!

We must first identify where our teams’ time is spent and for-each validate it against some steps.

Step 1 – Is it our responsibility?

This can prove difficult as it is often precedence that dictates your team’s ownership (and therefore responsibility) for a given task – but are they? If not then you must tread carefully as any proposed change will most likely infer another part of the business adopt it. Make efforts to build bridges with those areas of the business before jumping straight in; often you will learn things that will help shape your own business process and earn their respect.

Step 2 – Does this really need to happen?

Once ownership is established you can undertake the task gaining insight and understanding to the benefits it brings (if any); this will also allow you to speak from a position of confidence when proposing an alternative.

Step 3 – Is it visible?

Ask yourself if this task is visible to the business; if not then it’s unlikely they will have an appreciation for the time spent and benefits it brings – be transparent.

Step 4 – Can I automate it?

Your team’s motivation and job satisfaction is in creating great software, they do not (for example) want to be filling in time-sheets all day long. If you can automate any task or provide tooling to ease the pain, then do it!

Step 5 – Does the team support it?

Consult your team at every stage along this journey, they will have some fantastic ideas and feedback that not only ensure it’s success but gain their support in implementing it. I always say to my team that they own the process, I do not.

Doing this not only provides opportunity to steal back time through optimisation and automation, but also identify ‘leakage’ often associated with those quick jobs that are often anything but.


When you have recouped time it is important that this is reinvested into your team in areas such as personal growth, learning, pair-programming, TDD, etc. At this stage you may well come under pressure from the business to use it for greater throughput and utilisation – you must resist – remember why you did this!

I confess that in all my presentations to business I have purposely neglected to sell this aspect, instead choosing only to share these wins with the team. It is very easy to shout “look how much time we could save” in order to get their support, but doing so may well come at the cost of success and respect of your team.

Summing up

Already in this management series I have touched on the subject of team morale several times – often with emphasis on it’s importance. In my next post I will be tackling common challenges in managing motivation and team morale.

Next time: Manging Motivation
Coming soon: The Holy Grail of Management