Starting a Programme

Programmes in this field fail by starting with a tool purchase or with a strategy document. The order that works starts with measurement you already have.

The sequence

One: measure the loops. Build duration, test duration, queue time, flake rate. Most of it already exists in your CI system, unreported.

Two: ask people. Six questions, one free text field. Compare against the numbers.

Three: find the gap. Where perception and telemetry disagree is where the instrumentation is missing.

Four: fix one visible thing, cheaply, and report it.

Five: instrument the local loop, with the telemetry boundary stated before collection begins.

Six: establish the reporting habit — one page, weekly, in an existing forum.

Seven: then take on something structural, with the credibility the first six bought.

The first ninety days

Weeks one to three: extract CI data. Split queue from execution. Compute medians and ninetieth percentiles by repository. Compute flake rate from retry data.

Weeks four to six: survey. Talk to a sample of developers. Build the list of complaints and compare with the data.

Weeks seven to nine: pick the largest cheap win and do it. Cache key fix, superseded run cancellation, editor exclusions, a slow test file split.

Weeks ten to twelve: report — what was found, what changed, what it measured afterwards. Propose the next thing.

No purchase required for any of it.

Choosing the first fix

Hours of work, not weeks.

Visible to developers, so the programme is noticed.

Inside your control, not another team's roadmap.

Not about how anyone works, which would define the programme wrongly at the outset.

Measurable before and after on a number you already collect.

What to avoid early

Buying a platform before knowing where the time goes.

A migration — build tool, repository layout, CI system — as a first act. These are correct sometimes and they are never the first thing.

Individual metrics, at any point.

A maturity model, which produces a document rather than a faster build.

Announcing a strategy before delivering anything.

Getting the mandate

Frame it as a system problem, because it is, and because that framing keeps developers on the same side.

Lead with the pipeline compute bill if you need a financial argument — it is a real invoice and caching reduces it.

Lead with trust in the signal if you need a risk argument — a pipeline whose red is ignored has stopped being a control.

Lead with onboarding time if you need a management argument.

Not with developer happiness, which is the actual point and the least persuasive framing to the people approving budget.

Who does it

One person with allocated time is enough to start, and is the minimum.

Embedded in a team that owns the toolchain, not a separate function reporting elsewhere.

With access to the CI data without asking each time.

And a standing slot where findings are heard by people who can act.

Getting the CI data out

The first practical step, and it is usually a day's work.

Find the API. Every CI platform has one, and the run history is available through it.

Pull runs, stages and results for the last quarter.

Check whether queue time is separately available. It usually is and is usually not surfaced in the interface.

Pull test results if the platform stores them, which is what makes flake detection possible.

Load it somewhere queryable — a small database is enough.

Then compute the four numbers, which is an afternoon and which is the entire evidence base for everything that follows.

What to report at ninety days

The output that decides whether there is a second quarter.

The baseline, with the four numbers and how they were measured.

What was found, ranked and sized.

What was changed, with the before and after on the same measure.

What was not done and why.

What is proposed next, with the expected effect stated as a checkable claim.

One page. A strategy document at ninety days is a sign that nothing was fixed.