Go with the flow, part 1: the utilisation trap

Imagine you’re cruising down a leafy road at 60mph; sun shining, roof down, all is well.

Then you join a busy dual carriageway; there’s more traffic, but things are moving and your spirits remain high. It’s only when you hit the motorway that the journey gets really grim – before you know it, you’re at a complete standstill.

The motorway is 100% utilised, and now completely useless. What you need is a bit of flow.

Software development, particularly in corporate and enterprise environments, has been forever plagued by a focus on utilisation (or utilization – for our friends in the States). Utilisation is defined as the act of optimising the amount of work that a resource does. The usefulness of this definition depends heavily on how you define ‘amount of work’.

In our road analogy above, a static measure of cars per mile of road doesn’t reflect whether the road is doing a valuable job.

The failure of many utilisation targets is that they judge success by some intermediate measure of process (like the amount of hours logged against a project), rather than the outcome delivered (e.g. improvements that go live and result in an increase in sales conversion). In the first part of this article, I want to show exactly why an obsession with utilisation so often causes problems.

Utilisation of People

When talking about “good utilisation” of people, most organisations aim to maximise the allocation of people to projects. Historically, the way to achieve this has been via ‘matrix management’ – the idea that people sit in resource pools (consisting of a common discipline, and managed by a discipline lead) and are allocated to projects when a need is identified.

The typical outcome of this approach (illustrated here) is that management spends an escalating amount of its time on resourcing, and less time on initiatives that will bring the organisation success. An organisation’s most experienced people should be spending their time evangelising, coaching, problem-solving and removing impediments – not reduced to shuffling names on a spreadsheet.

The second problem comes as a result of people’s time being chopped into ever thinner slices (‘Bob is 7.5% on project X’). This practice presumes that the mere presence of an allocated discipline on a project plan guarantees the outcome. What it actually does is increase context-switching – and the damage this does to developer effectiveness is well known.

A key way that organisations fail to limit work-in-progress is to treat important initiatives as projects that can be started, stopped and resumed at will. This shows an inability for leadership to prioritise between problems to be solved – damning the delivery culture to be dominated by overheads of resourcing, timesheeting and context-switching (check the #NoProjects hashtag for resistance to this approach).

Going back to our hypothetical motorway, the pipeline becomes so busy that travel – the purpose of the endeavour, let’s not forget – becomes almost impossible.

Utilisation of Systems

In systems architecture, we regularly see an obsession with abstract (and speculative) centralisation, and prescribed sharing. In this context, the word ‘utilisation’ tends to be replaced with ‘re-use’, but it comes down to the same thing; a focus on optimising the use of materials. Either way, there’s no emphasis on value delivered.

The logic behind a company building something and prescribing that everyone else must use it is that the total cost of delivery is reduced. However, this attitude assumes the majority of the cost of delivery is in the building of components (e.g. writing lines of code). It ignores integration costs and dependency waits, which both impede flow:

• Integration costs include reading documentation for a component or library that may do much more than you need, as well as context switching between different metaphors, paradigms or idioms. The overhead of managing a feature across multiple processes (versioning, testing, deployment) can often be more than simply implementing the minimum capability required.
• Dependency waits are caused when a feature is “nearly right” for a team’s use, but getting it to actually work means going back to the component’s original authors. Without the right operational maturity and automated processes, this can cause scheduling problems – and consequent delays. This is something to bear in mind before pursuing a microservice architecture (though it can work very well in the right environment).

As you can see, focussing on utilisation can be problematic. Read part 2 of this piece to escape the gridlock, and see how a focus on flow can get the wind back in your hair…