Process debt

Every rule in your company was added by a reasonable person, after something went wrong.

That's what makes process debt harder to remove than technical debt.

Bad code has no defenders. A rule has an author, a founding story, and usually an incident behind it that people still remember, which means removing it looks like inviting the incident back through the door.

So it stays. The next one gets added on top.

Five years later a change carrying no risk at all passes through four checkpoints built for three different failures, none of which have occurred since.

Where it comes from

Almost always one bad incident.

Followed by an entirely understandable response.

Something breaks. It's visible, somebody senior is embarrassed, and the question gets asked.

How do we make sure this never happens again.

A rule is proposed and nobody objects, partly because objecting in that moment sounds like arguing in favour of the outage.

Then the rule gets applied to every future change, forever, whether or not that change resembles the original failure in any way.

That's the actual cost. Invisible, because it's spread thinly across thousands of changes, where the incident was concentrated and vivid.

This is the case for the rule of two or three, which shows up in every part of how I run things.

Wait until the same failure has happened twice before building structure around it.

One occurrence tells you almost nothing about whether it's structural. Two tells you a great deal, and the rule you write on the second occurrence describes the actual pattern rather than the memorable instance.

Note what that means in the moment after the first incident.

The correct answer is often "we're not going to change anything, and here's why."

Hard sentence to say. It's most of the discipline.

Every rule names its failure

What makes process removable later is a requirement at creation time.

Each rule gets written down with the failure it prevents, when that failure last happened, who owns it, and when it will be reviewed.

Four lines. Any rule that can't produce them doesn't go in.

Costs almost nothing at creation, and it changes everything about the removal conversation two years later.

Instead of arguing about whether a rule is valuable in the abstract, which is an argument nobody can win, you're checking whether a named failure is still plausible. That's a factual question, and factual questions have answers.

There's a filtering effect at proposal time too.

A surprising number of proposed rules evaporate the moment somebody has to write down the specific failure and its date, because the honest answer turns out to be "it hasn't happened, but it could."

The annual deletion pass

Once a year, half a day.

List every recurring rule, approval, gate, ceremony and required document in the engineering organisation.

For each one: what failure does this prevent, when did it last happen, and what would we notice if we removed it.

Three categories emerge, reliably.

Rules that are load-bearing and stay. Rules whose failure hasn't occurred in years, where the underlying cause was quietly fixed by better tooling long ago. And rules nobody can trace at all, which turn out to be more common than you'd think, particularly in organisations that have hired experienced people from much larger companies.

Delete the second and third categories.

Not gradually. Not by exception process. Delete them, and say what you're doing and why, in writing, so it reads as a decision rather than a drift.

What makes this survivable is deleting with a trial period.

"We're removing this for a quarter. If the failure it prevented recurs, we'll put it back, and then we'll know it was real."

Almost nothing comes back. And framing it as an experiment means nobody has to be wrong in public.

Scar tissue versus judgment

The hard distinction, and the one that requires actual thought rather than a rule.

Scar tissue is a rule that encodes a past failure and then applies indiscriminately.

Every database change needs the DBA's approval, because in 2021 somebody dropped a table.

Cheap to state. Expensive to run. And it can't tell a dangerous change from a trivial one.

Judgment is that same knowledge, held by people, applied in proportion.

Engineers know which changes are dangerous, and they get a second pair of eyes on those ones.

Scar tissue scales to people who weren't there and can't tell the difference. That's its genuine advantage and it's why it exists. Judgment is faster and better and requires that the people have the context.

Which suggests the real question when you're deciding whether to keep something: do the people doing the work have enough context to make this call themselves. If yes, the rule is costing you and teaching them nothing. If no, the better investment is usually in the context rather than in the rule, though that takes longer and can't be done in the week after an incident.

The version I'd keep as a hard rule regardless: anything where the failure crosses into other people's systems or customers' data. Blast radius is the tiebreaker.

The tells

Three signs that process debt has accumulated past the useful point.

Nobody can explain why a step exists, and the person who could has left. This is the clearest one, and it's usually the oldest step in the chain.

There's a routine workaround. When "just ask Dave to approve it, he does it in five minutes" is standard practice, the gate isn't providing control, it's providing delay plus a social workaround that only works for people who know Dave.

And exceptions outnumber applications. If most changes go through the exception path, the exception path is the real process and the official one is a fiction that costs everyone a form.

The thing to protect

An organisation with no process at fifty people is chaos, and this lesson isn't an argument for that.

It's an argument for a specific ratio: the amount of process that is currently justified by a repeated, named failure, and not one increment more. That number is not zero and it grows as you grow.

What makes it hard is that the growth is automatic and the pruning isn't. Nobody's job is to remove rules, nobody gets credit for it, and every deletion carries a small personal risk if the failure recurs. Which is exactly why it has to be scheduled, done in public, and owned by whoever is senior enough to absorb that risk.