Learn · Delivering across organisations

Assessing before proposing

The first deliverable of an implementation is not a change. It is an honest account of the current state, in numbers the customer recognises.

Start with the distribution, not the average

An eleven-minute average can mean most builds take eleven minutes. It can also mean a large population of two-minute builds and a smaller population of forty-minute ones, in which case eleven minutes describes no build that has ever run.

These two situations need completely different work. Optimising toward the mean in the second case improves nothing anyone experiences.

Look at p50 and p90, and look at what is actually in the p90 bucket.

Separate the constraints

Before proposing anything, sort what you find into three piles:

Platform — capacity, queue topology, agent configuration. Yours to fix.

Pipeline design — no fail-fast, unbalanced shards, a barrier where dependencies belong, artifacts uploaded that nobody downloads. The customer’s to fix, with your help.

Organisational — a required approval that sits overnight, a release process that batches. Not a CI problem at all, and proposing CI changes for it wastes everyone’s time.

The third pile is the one most often mislabelled as the first, because approval latency and queue wait are both “waiting” and are frequently measured together.

Say what you measured

Whatever you report, state where the number came from and over what window. An implementation is a commercial relationship, and the difference between “your p90 is 34 minutes” and “your p90 over the last 30 days of main-branch builds is 34 minutes, excluding cancelled builds” is the difference between a finding the customer can act on and one they can argue with.

This matters more on the partner track than anywhere else. You will not be there when the number is questioned.