The Process That Fits Nobody

Every standard process arrives the same way, and I have been on both ends of it. Somebody identifies a team that is visibly working - shipping steadily, calm during incidents - and writes down what that team does. The description becomes a document, the document becomes policy, and the policy goes to everyone. The reasoning is not stupid. Here is a thing that works, here are teams that would like to work, connect the two.

Six months later the picture is remarkably consistent. The team it was copied from is still performing, which everybody reads as confirmation. Two teams have quietly gone on doing what they did before and file the paperwork afterward. The rest run the ceremonies exactly as written and get nothing out of them, which nobody says out loud, because the ceremonies are visible and the value is not.

The usual explanation is that the other teams lack discipline, or maturity, or buy-in, and I have made that argument myself with a straight face. I no longer believe it. A process is a compression of one team's context into a set of rules, and it works because the context is still sitting underneath, implied, doing most of the actual work. Move the rules elsewhere and you have moved the artifact without the thing that made it mean anything.

Start with what it costs when you are wrong. A team whose users sit two floors up and will tell you directly can deploy on a Friday afternoon and fix it Monday. A team whose failure is measured in money per minute, or whose customer has a regulator, cannot, and the release policy that is correct for the first is negligence for the second. Release cadence is a function of blast radius. It gets read as a measure of engineering maturity, and it is not one.

Then there is how much is already in people's heads. A team that has sat together for four years needs little written down, because the coordination already happened and the design conversation is a two-minute exchange rather than a document. Impose heavy process on them and you tax them for a problem they do not have. A team assembled last quarter needs the opposite, and reads the identical rules as scaffolding rather than bureaucracy. Same document, opposite effect, and neither team is misreading its own experience.

And the price of the steps is moving. Generated code has moved the expensive part of a change from writing it to reading it, and that shift does not land evenly. A team whose bottleneck was authorship gets faster. A team whose bottleneck was already the review queue gets slower, because the queue now takes more changes, larger ones, and ones whose author is a little less sure why each line is there. Documentation becomes cheap to produce and no cheaper to trust. Any review policy calibrated before that is now mispriced, by a different amount on every team.

A written process encodes decisions already made. What we treat as risky, what we have been burned by, who needs to hear about a change before it lands. The rules stay short because the context carries the meaning. To the team it came from, a two-approval rule on a directory means "that is the module we broke last year". To a team that never broke it, the identical sentence is an obstacle between them and a merge button. They are not being cynical; they are reading it accurately, because that is all it is.

Ceremony is what a rule turns into when the reason is not available locally. Nobody decides to perform. It happens because the rule still has to be satisfied and the only part anyone can see is the observable one, so that is what gets satisfied. The standup becomes a status report to a manager. The definition of done becomes a checkbox beside a ticket. Compliance and value produce identical artifacts from outside, which is the whole difficulty: reporting cannot tell them apart, and reporting is what leadership sees.

So here is the argument in one sentence. A process is the answer one team reached to a question it was actually asked, and rolling it out to a team that was asked a different question hands over the answer without the question.

Nobody can name the failure the rule prevents. The best question available, and it takes ten seconds. Ask what goes wrong if we skip this step. A team using a rule answers immediately and specifically, usually with a date attached, because they remember the incident that produced it. A team performing the rule answers with the rule's own name, or with the word compliance, or by looking at whoever imposed it. That is not evasion. They genuinely do not know, because the reason never traveled.

The exception path carries a serious share of the work. Every process has an emergency route, and the honest measure of whether the main route fits is how much traffic the emergency route takes. When a large share of changes go through the expedited path and everyone including the approver finds that unremarkable, the organization has already voted on its process. It has simply not counted the votes, and the exception does the real work while the policy takes the credit.

In October 2012, Henrik Kniberg and Anders Ivarsson published a fourteen-page paper called "Scaling Agile @ Spotify" describing squads, tribes, chapters and guilds. It spread further than almost anything else written about how software teams organize, and produced a decade of reorganizations at companies with nothing else in common with a music streaming service. The authors put a disclaimer on page one: the article "is only a snapshot of our current way of working - a journey in progress, not a journey completed. By the time you read this, things have already changed."

The part that traveled least is the part that mattered most. The same paper says squads "decide their own way of working - some use Scrum sprints, some use Kanban, some use a mix of these approaches." A document whose central mechanism is each team choosing its own process was adopted, repeatedly, as a standard process. That is less irony than physics. What is easy to copy in it is an org chart and a vocabulary, and those travel effortlessly. Nothing else in it does.

Standardize the outcome and never the mechanism. "Changes are reviewed by somebody other than the author before they reach production" is an outcome. "Two approvals in this tool, using this template, with these three checkboxes" is a mechanism, and a mechanism is one team's route to that outcome. The first is auditable anywhere and means the same thing everywhere. The second is a guess wearing the authority of a policy. Write down the outcomes and let each team show you how it meets them.

The set of outcomes is smaller than it feels. The rules that genuinely have to be uniform serve three purposes: what an auditor or regulator must be able to see, what security requires and cannot delegate, and what lets a person move between teams without relearning the job. Short list, and a usable test. A rule serving none of the three is a preference with an organization-wide distribution list, and should have to say so out loud.

"Our team is different" is the most reliable way to end a conversation about measurement. I have said it. Sometimes it was true. Sometimes it meant I did not want anyone looking at how often we broke things, and the argument is perfectly shaped for that job: unfalsifiable from outside, and flattering to whoever makes it. A manager should notice how often the loudest version comes from the team with least to show, and ask which property of the work the rule misprices. A team that has one answers in a sentence.

The cost of full local autonomy is also worse than people arguing my side tend to admit. When every team has its own release policy, review norms, on-call handoff and definition of an incident, nobody moves between teams without relearning the job, and the organization loses the main lever it has when priorities change. It cannot describe its own risk either, with no common account of last quarter. That bill arrives as fifty small frictions rather than one line item, which is why nobody attributes it to autonomy.

Then the argument I find hardest. A uniform rule is nearly pure tax on the strongest team, which would have done it anyway, and it is the only protection the weakest team has. Google requires review for almost every change to its codebase, no matter how small, which its engineers call one of the few blanket processes everyone there must take part in.

A change there needs three approvals: a correctness read, an owner of that part of the tree, and somebody certified in the language's readability. That is heavier than anything I have argued against, and at that size it is right, because the alternative is a codebase whose quality varies by whoever happened to write each directory.

So let me make the claim smaller, because it should be. I am not arguing that each team should pick its own process. I am arguing about which layer the choice lives at, and I have moved on the default: uniform unless a team can state the specific property of its work that the rule misprices. Making that case should be possible and should cost something. What I would stop doing is what I used to do: grant the exemption to whichever team argued hardest, and privately call that judgment.

What I would keep is the question rather than any of the answers. A process is a set of decisions somebody already made, compressed small enough to hand to a stranger, and the reasons did not fit in the envelope. Before handing it over, ask which of those reasons the receiving team also has. If the honest answer is none of them, you have not given anybody a process. You have given them a costume, and they will wear it, because you asked.