Staff Liquidity is about managing the number of options in your system. You want to maintain as many options so that you can respond to changes in demand. Once we realise that we want to create/maintain as many options as possible in our system, it affects the way we make decisions. (Author’s note: When I say “you”, I’m referring to the team as a whole).
In the past I’ve seen many development teams that have one or more Bob’s on the team. Bob is the one who knows (some part of) the system inside out. Whenever you allocate work, Bobs is the only person who can do certain things and as a result, he is always fully loaded at two hundred percent utilisation. Bob spends his entire time on the constraint for the project. Whenever a problem/issue/production issue/etc. occurs, Bob is the only one who can work on it. Whenever Bob is working on a production issue, etc. the projects slips behind a day at a time. Some Bob’s enjoy the attention, some don’t and they leave. Allocating Bob to work first is the most effective way of destroying options on a project. On a skills matrix, Bob would be the only “3” for one or more task. The rest of the team are only along for the ride as only Bob(s) can do the real work.
Every time you allocate someone to an item of work, you effectively remove them from the skills matrix. Once you see it like that, you realise the best way to allocate work is to start with the people with the fewest options first. You give them work they can do with the support of an expert. You then do the same for the rest of the team until you get to Bob. Ideally, you do not allocate Bob to anything. Bob becomes the expert who pairs with other team members. Bob coaches others in his part of the system. Bob is instantly available in the event of a crisis without impacting the time to value.
When Bob investigates a production issue, he should do so with another member of the team. As soon as they work out what needs to be done and the other team member is able to finish it alone, Bob becomes available again thus ensuring the team has the maximum number of options to address the next crisis.
Sadly its not too uncommon to discover an entire team of Bobs. Everyone on the team is the only person with a “3” for a part of the system. Once they understand what they are doing, the team should self organise to become Not(Bob)
November 25th, 2013 at 7:27 am
November 28th, 2013 at 3:51 am
Thanks for writing this up. This is perfectly timed as I am working with a team right now that has one, if not several, Bobs. This post is a great way to explain the problem they may have and suggest a possible solution.