Managing your team’s liquidity

Whenever I join a team there is a guy named Bob. Bob is great. He is the rock that the team is built around. Bob does most of the development and investigates/fixes most of the production bugs. Bob is great. Bob normally arrives a little late because he was working into the early hours the day before. He works late to get his development work done because he spends much of the day investigating bugs or attending design meetings. Bob is a roll your sleeves up kind of guy who gets things done. Bob is on the critical path for all the projects and anything he is not involved in struggles or fails. Bob never has time to adequately explain how the system works to anyone else. Bob is utilised at somewhere between 150% and 200% depending on his need for sleep.

Bob is a IT risk management nightmare.

• Every time a bug or request comes into the project, Bob is rightly involved. Unfortunately Bob is normally assigned the most critical aspects of development on the project. Bob normally sits right on top of the critical path. Every delay to Bob hits the critical path.
• Bob normally enjoys this situation even thought he may complain. He enjoys being the hero. He enjoys the daily praise of IT Management and the Business for saving the day yet again. Although popular, Bob normally does not have a partner demanding their time. The real risk is that Bob gets a partner who objects to the amount of time they spend at work.

The problem comes because of the way we traditionally allocate those staff with the most options to tasks. We normally look at the hardest tasks and allocate them to Bob, then Bobette, followed by Bobina and then the rest of the team pick up the easy stuff. This is because we attempt to optimise

Instead we should consider the liquidity of the project when we allocate staff to tasks. We should consider the time it takes to respond to change (Liquidity).

Staff should be allocated to tasks based on their ability to do a task with support rather than on their own. The developer with the most should options should NEVER be allocated to a development task. Instead they should pair with junior staff (in terms of the system) to transfer knowledge. This means they are instantly available to address any issues (bugs, business changes, design issues) that arise WITHOUT AFFECTING THE CRITICAL PATH.

When an issue arises, they should never address it on their own. Instead, they should pair with someone else with an aim of freeing themselves from being committed to the issue as soon as possible. Whilst they are focusing on an issue, they are not instantly available to address another problem. When the issue is de-risked, they are then free to work on anything else. They may choose to stay working on the issue or work on something else. The key is that they are not the bottleneck. They are not the only person who can address the issue.

An example of how this works.

Some years ago I was head of Business Analysis for a group. I received a call from the business manager. A client had refused to do another lucrative (think tens of millions) deal unless our company fixed a problem with our current process. I grabbed Tarquin, the BA in charge of that business area, and within two or three minutes we were both at the trading desk to discuss the problem with the business manager and trader. Within an hour, the two of us had mapped the entire process and identified the cause of the problem. We then suggest a spreadsheet reconciliation that would act as a control to prevent the problem from recurring. Tarquin and a desk developer worked on the solution for the next two or three weeks. The business were able to inform the client of the plan and I was able to go back to sleep at my desk waiting for the next crisis.