Skip to content
Time to Signal

All notes  /  Programme

Who Owns the Toolchain

Nobody, one person, or a team. Each arrangement fails differently, and the failure modes are predictable enough to plan around.

Analysis

Toolchain performance is everyone's problem, which in practice means it is nobody's work.

Nobody owns it

The default in most organisations.

It degrades continuously, because every change adds a little and nobody removes any.

Improvements happen when someone is annoyed enough, which means they are unplanned and unmeasured.

Knowledge is scattered. Three people understand different parts of the build and none understands it all.

Nothing survives a departure.

Works at small scale and fails predictably as the codebase grows.

One person owns it

Fast, because there is no coordination.

Fragile. The bus factor is one, and the person becomes a bottleneck for every question.

They get pulled into support and stop doing the improvement work.

It is a career risk for them: invisible work, no feature delivery, and the thanks arrive only when something breaks.

Viable as a starting point, and it needs a plan to become something else.

A platform team

Sustainable and slower.

Can take on structural work that an individual cannot.

Becomes a service organisation if not managed carefully, spending its time on requests rather than on the systemic problems.

Can drift from its users, building what is interesting rather than what is needed.

Needs a product mindset: the toolchain has users, and their experience is the measure.

Embedded ownership

A person in each team owning their part, with a coordinating group.

Local knowledge, and changes that fit how each team actually works.

Duplication and drift, where twelve teams solve the same problem differently.

Works best combined with a small central team that owns the shared infrastructure and the standards, while teams own their own configuration.

The failure modes, named

The service desk. The platform team spends its week on tickets. Fix by publishing what is self-service and defending time for systemic work.

The ivory tower. Building what is interesting. Fix by measuring the experience and by embedding.

The bottleneck. Everything requires the platform team. Fix by making the common paths self-service.

The invisible team. Doing good work nobody sees, then losing budget. Fix by reporting, weekly, in a forum where people who fund things are present.

The heroes. One person holding it together. Fix before they leave, not after.

What ownership needs

Allocated time, protected. Toolchain work loses every unstructured priority contest against feature work.

Access to the data without asking.

Authority over the shared configuration, or the standards are suggestions.

A route to the teams whose code determines the graph, since structural work needs their agreement.

A standing report, which is what keeps the work visible enough to survive a budget cycle.

The measure of whether it works

Is the toolchain getting faster or slower, over quarters?

That is the whole question. A team that reports activity while the median build time drifts upward is not doing the job, and reporting the trend is what makes that visible before someone else notices it.

Defending time for systemic work

The failure that turns a platform team into a service desk, and the specific countermeasures.

Publish what is self-service, so the common requests do not arrive as tickets.

A rota for support, so one person absorbs interruptions and the rest work.

A stated proportion of time for systemic work, agreed with whoever sets priorities.

Measure the split between reactive and systemic, and report it.

Escalate when it drifts, with the number, before the team has spent a quarter on tickets and has nothing to show for it.

The measure of the team

One question, asked over quarters, that says whether the arrangement works.

Is the toolchain getting faster or slower?

Not tools shipped, tickets closed, or migrations completed — all of which can rise while the median build time drifts upward.

Report the trend on the headline measure in every forum where the team's work is discussed.

If it is going the wrong way, say so before someone else notices, along with why and what would change it.