Shipping without supervision

Somewhere on most teams there is a line, rarely written down, between the people whose changes wait for someone else’s yes and the people whose changes go out when they are ready. Crossing it is usually described as being trusted, which makes it sound like a judgement about character. It is not. It is a judgement about how expensive you are to be wrong about, and that is something you can change deliberately.

The question underneath this is almost never “am I good enough yet”. It is that someone senior ships on a Friday afternoon without asking anybody, and you cannot work out what they have that you do not, because their code does not look categorically better than yours.

What the trust is actually measuring#

The DORA research programme measures delivery performance with four metrics, and the way they split in half is the whole point. Two are about speed: change lead time, the time from a change being committed to version control to it being deployed in production, and deployment frequency. The other two are about what happens when a change is bad — change fail rate, the proportion of deployments needing immediate intervention, and the time it takes to recover from one that does.

Nobody grants shipping rights on the strength of the first pair. A person who deploys often and quickly, with no answer for the second pair, is the person a team most wants a gate in front of. The permission tracks the recovery half: how bad it is when you are wrong, and how quickly the badness stops.

This is also why the request is not the imposition it can feel like. DORA’s own finding is that speed and stability are not tradeoffs, and it states the real choice as being between better software faster and worse software slower. The properties that make you safe to leave alone are the same properties that make the team quick. You are not asking to be exempted from care; you are asking for the gate to be replaced by something cheaper that does the same job.

The three properties that earn it#

Small enough to undo. Not small in lines — small in what has to be true for the change to be reversible. A change that only adds a code path behind a flag can be turned off by one person in one minute. The same feature, shipped with a migration that drops a column, cannot be undone at all; it can only be repaired forwards, by someone writing new code under pressure. The second one needs supervision no matter how well it is written, and the difference between them was settled before a line was typed.

Loud enough to notice. A change that fails silently is indistinguishable from one that worked, and a person who cannot tell those two apart is a person who has to be watched. This is the part most people under-build, because the check that matters is not the test suite — it is the specific signal, after the deploy, that says this particular change did the thing it was for. Knowing what to look at once the change is live, and for how long is the difference between finding out in four minutes and finding out from a customer in four days.

Reported by you. The third one costs nothing to build and is the one people skip. Google’s SRE book describes a postmortem as a written record of an incident, its impact, what was done about it and the follow-up actions — written blamelessly, which it defines as looking for the systematic reasons an individual or team had incomplete or incorrect information rather than for who did it. Its summary of the culture is direct: writing a postmortem is not punishment, it is a learning opportunity. A team that works this way is not waiting for you to be flawless. It is waiting to find out what you do at the moment you are not.

What it costs you#

The first cost is arithmetic. Splitting one change into four reversible ones is four deploys, four sets of release notes and four moments of watching a dashboard, for the same feature. Per unit of work the ceremony goes up, not down. What you buy is that no single step is frightening — but on the afternoon you are doing it, it feels like being slower on purpose.

The second cost is one people notice only afterwards: you lose somebody to have been wrong with. A reviewer’s approval feels like shared liability, and giving it up is uncomfortable in a way worth naming rather than talking yourself out of. It is also worth knowing what that approval was ever worth. Google’s own review standard asks reviewers to approve a change once it definitely improves the overall code health of the system, even if it is not perfect, on the stated grounds that there is no such thing as perfect code — only better code. An approval was never a proof of correctness. It was a second reader saying the direction was sound, which is a much smaller thing than the safety most people feel on receiving one.

The third cost is that the pager becomes personal. When your change is the last one out and something turns red, there is no queue of approvers to spread the question across. This is the real content of the permission, and the reason it is given rather than taken: the team is handing you a class of interruption it used to absorb on your behalf.

Where it goes wrong#

The failure is not the dramatic one. It is the quiet fix, and it looks like the ideal outcome while it is happening.

A change goes out. Something goes wrong — a rate of errors that was not there an hour ago, a job that stops finishing. The person who shipped it sees it first, understands it immediately, and has it repaired within a few minutes, before anybody else has looked. Nothing is said afterwards, because by the time there was anything to say, there was nothing left to fix. Every instinct says this is what being trusted is for.

It costs three things at once. The evidence disappears: the only demonstration that the team’s safeguards work end to end is the one that gets narrated, and an unnarrated recovery is indistinguishable from nothing having happened. The cause goes unrecorded, so the same gap waits for the next person, who is unlikely to be as quick because they will meet it cold. And the reporting habit quietly inverts — once small breaks are handled in silence, the threshold for what is worth mentioning drifts upward, until the first thing anyone hears about is the one that could not be fixed in four minutes.

The version of this that costs a career rather than an afternoon is its cousin: earning the permission by only ever shipping things that cannot fail. It works, for a while. It also means that when the risky change finally has to be made, nobody — including you — has any evidence about how you behave when something breaks, which is the exact question the permission was about. The same reasoning puts what an incident actually produces, and where it goes afterwards on the other side of the same coin: an incident that changes nothing in the backlog was survived rather than used.

The next step past this one is what happens when a change is too large to be reversible at all — the point where the argument has to happen before the code exists, in a document that gets read and commented on rather than skimmed and forgotten.