How These Programmes Fail

Developer productivity programmes fail in recognisable ways. Diagnosis matters more than any implementation guide.

Measuring without acting

The symptom: a dashboard, a monthly report, and a toolchain that is exactly as slow.

The cause: scoped as reporting, with no owner able to change anything.

The correction: one finding, one owner, one date, re-measured. Report the change, not the analysis.

Buying before measuring

The symptom: a platform configured to answer questions nobody had, while the actual bottleneck is untouched.

The correction: configure what you own, measure what remains, then procure against the gap.

Starting with a migration

The symptom: eighteen months in, two build systems, neither finished.

The correction: cheap configuration wins first; migrations after the credibility is earned and with a stated cutoff date.

Optimising the wrong loop

The symptom: the pipeline is twice as fast and developers report no difference.

The cause: the local loop dominates their day and was never measured.

The correction: instrument the local loop, with the telemetry boundary stated first.

Ignoring reliability

The symptom: everything is fast and nobody trusts the result.

The cause: flake rate untracked, retries invisible.

The correction: flake rate as a reported metric alongside duration. Reliability is worth more than speed at the margin.

Individual metrics

The symptom: cooperation drops, telemetry gets disabled, survey answers become diplomatic.

The correction: stop, say so publicly, and answer the underlying question with system data. This one is not recoverable quickly.

Averages

The symptom: the reported median is fine and everyone complains.

The cause: bimodal distribution. Warm-cache runs are fast, cold ones are terrible, the mean describes neither.

The correction: median and ninetieth percentile, always, and investigate the second mode.

Adoption assumed

The symptom: a faster path exists and the numbers have not moved.

The correction: measure adoption, ask the people who have not switched, fix the uncovered case.

No owner

The symptom: the project ended, the improvements decayed, the build is slower than before it started.

The correction: allocated time, permanently, and a trend report that makes decay visible while it is still small.

The common thread

Each of these is measuring the project rather than the experience.

Tools deployed, dashboards built, migrations completed — all move while time-to-signal, flake rate and local build duration stay exactly where they were.

Reporting the experience measures from week one is the single most effective preventive step, because it makes the gap visible while there is still time to correct it.

The recovery move

For a programme that has produced dashboards and no change.

Publish the baseline: time to signal, flake rate, queue split, local build duration.

Pick the largest cheap finding and fix it, with the developers affected involved from the start.

Re-measure and report, including if nothing moved.

Start the weekly one-page report in an existing forum.

One quarter of work, and it converts a reporting exercise into a programme with a mandate.

Diagnosing before adding tooling

A platform bought to restart a stalled programme usually stalls with it.

Work through the list above and name which failure you have.

No owner, no action, wrong loop, ignored reliability, individual metrics, averages, assumed adoption.

Each has a specific correction and none of them is a purchase.

Where the honest answer is that the programme was never given time, say that rather than proposing a tool, because the tool will not be given time either.