Choosing What to Fix

Any first measurement produces more findings than capacity. The ranking matters more than the analysis that produced them.

The ranking

Time returned per unit of effort, which is frequency times duration divided by cost to fix.

Frequency dominates. A one-second fix on a loop that runs two hundred times a day beats a two-minute fix on one that runs twice.

Cost to fix varies by orders of magnitude. A configuration change is hours; splitting a god module is a quarter.

So: fast, frequent, cheap first. Almost always configuration.

The categories, by typical return

Configuration. Cache keys, exclusions, memory limits, parallelism settings, cancelling superseded runs. Hours of work, immediate effect, no coordination.

Reliability. Flaky tests. Higher cost, and it multiplies the value of everything else because retries stop consuming the gains.

Selection. Running only what is affected. Days to weeks, large return, needs a safety net.

Capacity. Runners, machines. Costs money, works immediately, does not fix the underlying waste.

Structure. Module boundaries, repository layout. Quarters of work, largest ceiling, hardest to justify without the earlier wins.

Work down this list, not up.

The trap

The interesting problem is rarely the valuable one.

Migrating the build tool is more engaging than fixing an editor exclusion list. The exclusion list returns more, sooner, to more people.

A programme that starts with the interesting problem spends its credibility before earning any, and if the migration overruns — which it will — there is nothing to show.

Sizing a finding

Before committing, four numbers.

How often does this occur? Per developer per day.

How long does it cost each time?

How many people?

What would it take to fix, honestly, including coordination.

The first three multiply into time returned; the fourth is the price. A finding without all four is an opinion about what is annoying.

What to defer deliberately

Anything requiring another team's roadmap, until you have something to trade.

Anything requiring architecture change, until the cheap wins are exhausted and the case is built on measurement.

Anything that only helps one team, unless that team is blocked.

Anything you cannot measure afterwards, because you will not know if it worked and you will be asked.

Recording the ones you are not doing

Keep the list, with the sizing.

Review it quarterly. Costs change: a fix that was impossible becomes trivial when a tool is upgraded.

Report the deferred list alongside the completed work. It is the evidence for the next headcount conversation, and it prevents the same finding being rediscovered every six months.

When the ranking says something unwelcome

Occasionally the largest return is a structural change nobody wants to start.

Say so plainly, with the arithmetic.

Continue with the cheap wins in parallel, which is not a substitute and buys time.

Re-present the structural case each time the cheap wins run out, which they will, and each time with more evidence than the last.

The sizing template

Four numbers per finding, which turns a list of annoyances into a ranking.

Occurrences per developer per day.

Cost per occurrence, in seconds.

People affected.

Effort to fix, in days, honestly, including coordination.

The first three multiply into time returned; the fourth is the price.

Fill it in for the top ten findings. The ranking that falls out is frequently different from the one people expected, and it is defensible in a way that a list of complaints is not.

Reviewing the deferred list

Costs change, and a finding that was impossible becomes trivial.

Keep every deferred finding with its sizing.

Review quarterly, which takes twenty minutes.

A tool upgrade, a platform change or a new capability frequently moves something from months to hours.

Report the deferred list alongside the completed work, because it is the evidence for the next resourcing conversation and it stops the same finding being rediscovered by someone else every six months.