When Is Process Armor, and When Is It a Shackle?

At one corporate I worked for, there was a form you had to fill in before every release. Seven fields, three signatures, one mailing list. You filled it in, it went to the list, nobody ever replied; a day later the release shipped.

After a few months I couldn’t help myself and asked: “Who reads this form?” Nobody knew. When I pushed, the longest-serving person on the team shrugged: “Something happened once.” Nobody remembered what. The team that had lived through it had scattered, and the manager who asked for the form had left two companies ago. But the form was still there, and thirty people filled it in every month.

The genuinely funny part only hit me later: I studied the form, tried to reconstruct the “something,” and reached one conclusion — whatever incident this form was born from, it could not have prevented it. Nobody was reading it.

In the first post of this series I defined being institutional as “the decision can be separated from the person.” Process is the concrete instrument of that separation. This post is about its two faces: the same process can be, at the same moment, the armor that protects you and the shackle that slows you down. Telling which one you’re looking at takes less intuition and more accounting than you’d think.

One boundary before I start: I’m not going to argue Agile versus Waterfall here. I did that in the methodology decision matrix. The subject here isn’t which methodology you picked; it’s the process itself that accumulates on a team regardless of what you picked — why it’s born, why it never dies, when it protects and when it obstructs.

Process isn’t a virtue, it’s a line item

The most common mistake in any conversation about process is treating it like a character trait. “A disciplined team.” “A serious company.” “We don’t cut corners.” All of that is moral language, and that’s exactly what makes it dangerous: a moral thing can’t be debated, only defended.

But process is a budget line, and it has two sides.

What you pay: the coordination tax. Time (forms, meetings, waiting on approvals), attention (being pulled off the actual work), and the most expensive one, morale — because a person who repeats a step whose reason they don’t know loses a little faith in their own job. And because that tax is invisible, nobody books it.

What you get: repeatability and independence from any one person. The same work, at the same quality, done by someone else, for the third time. When one person goes on holiday, work doesn’t stop. A mistake doesn’t happen twice.

Process is the cost of a past incident, spread into the future in instalments. The moment the instalments add up to more than the incident cost, process stops being armor and turns into a shackle.

That isn’t a slogan, it’s a balance you can genuinely compute. A form that eats ten minutes a month from thirty people costs sixty hours a year. Is the incident that form prevents worth more than sixty hours a year? If the answer is “yes,” the form is armor. If the answer is “I don’t know” — which it usually is — what you have isn’t a process, it’s a habit.

When should process be added?

There’s a right time for process. There’s also a too-early and a too-late.

1. When the same mistake happens for the third time. Once is chance, twice is bad luck, three times is a pattern. Adding process the first two times means solving a problem that doesn’t exist yet — premature optimisation. By the third, you have proof that individual attentiveness isn’t solving it; the system has to.

2. When critical work depends on one person. “Only Ahmet knows how that works” isn’t a joke, it’s a risk report. Process here isn’t a vote of no confidence in Ahmet; it’s what lets Ahmet take leave, get ill, even resign. Dependence on a person is a weight on that person’s back before it’s a weight on the company’s.

3. When the team is too big to overhear itself. In a team of five, process is unnecessary because coordination is already happening at the table. In a team of twenty-five it isn’t. You’ll know you’ve crossed the threshold by how often you hear “nobody told me.”

Every process added before those three thresholds books more cost than it solves. Every process not added after them will, sooner or later, remind you it exists by way of a crisis.

The process graveyard

Now for the real fault. The corporate disease isn’t adding process — adding process is usually the right call. The disease is that there is no ritual for removing it.

Every process is a headstone for an incident. Year by year the company turns into a graveyard, and nobody tends it. The reason isn’t laziness. It’s a clean asymmetry of risk:

	Adding a process	Removing a process
Who carries the risk?	Nobody; it’s spread across the team	The person who removed it, alone
What if it’s wrong?	Nobody notices; slowness becomes a general complaint	”Who removed this?” now has an answer
Visibility of the decision	The owner of it is invisible	The owner of it is signed

The risk of adding is diffuse; the risk of removing is personal. Any rational person looks at that table and makes the same call: don’t touch it. And so the company accumulates a weight that nobody wants and everybody protects. Corporates slow down over time not out of bad faith, but because of this asymmetry.

I’d offer two concrete things against it, and both are cheap:

Write down the incident that gave birth to the process, alongside the process. One sentence is enough: “This check was added in 2024 because customer data was copied into the wrong environment.” That single line is what makes the process defensible — or removable — five years later. A process with no stated reason is, by definition, unremovable, because nobody can know what they’d be risking.

Once a year, run a “which processes still hold?” review. Everybody has a meeting for adding. Nobody has one for removing. The real function of that meeting isn’t even to remove process — it’s to make the removal decision institutional rather than personal. That’s what breaks the asymmetry.

Question: When should a process be removed? Answer: When the incident that created it can’t happen again; or when the process doesn’t actually prevent that incident anyway. The second case is far more common and far less noticed — because a process existing and a process working get conflated. The form I filled in was in the second group.

The owner-run company’s allergy to process

There’s the other side of the coin, and I have to be equally honest about it.

The sentence I hear most in owner-run companies: “We work agile.” Most of the time, that’s a polite way of saying “we don’t like writing things down.” Decisions get made out loud, the reasoning is never recorded, the same argument gets relitigated every six months, and nobody notices this is a cost — because the bill doesn’t arrive in one lump, it arrives a little each month.

But sometimes it really is agility. And when it is, that speed is a genuine competitive advantage: while your competitor waits on an approval chain, you’ve already shipped. In those companies, adding process means shaving down the one edge they have.

The test that separates the two is a single question: is the same mistake recurring? If it isn’t, that really is agility; don’t add process, leave it alone. If it is, what you’re calling “agile” is negligence, and it’s costing you something — you just haven’t seen the invoice yet.

Three desks

From the senior engineer’s desk. Process is two things to you at once: the armor that shields you from arbitrary blame, and the shackle that slows you down. Pay attention here — those aren’t two different things, they’re the same thing. The step that lets you say “I followed the procedure” when something blows up is precisely the step that eats ten minutes of your day. Your constraint: you usually didn’t witness the incident that created the process. So some of what looks unnecessary really is unnecessary, and some of it only looks unnecessary to you. If you object without separating the two, you’ll lose even where you’re right.

From the manager’s desk. Process is auditability, and it’s how you defend yourself. When something goes wrong, it’s the only thing you can show upward. Removing process, on the other hand, is direct personal risk for you: if the control you removed turns out to have been preventing something, the bill goes to you, not to the team. That asymmetry is your constraint. If you aren’t removing process, it isn’t laziness — it’s that the upside of removal belongs to the team and the risk belongs to you. The only way to change that is to take the removal decision out of the personal column and put it in the institutional one — that is, to turn the review I described above into a rule.

From the owner’s desk. To you, process means cost and slowness, and you’re largely right about that. What you can’t see is this: process is also the company becoming independent of you. It’s what makes the company delegable, manageable by someone you hire, survivable while you’re on holiday, and one day sellable. Your constraint hides right there: an owner with an allergy to process is, without realising it, building a company that cannot be sold. Because a buyer would have to purchase not the company but the contents of your head — and nobody buys that.

Closing

Process is neither good nor bad. It’s the invoice for an incident, and you pay it in instalments.

The question to ask isn’t “is there too much process here.” The question is this: does anyone remember the incident that created this process, and is that incident still possible? If both answers are yes, that process is armor; stop complaining and carry it. If either answer is no, what you have is a headstone — and tending graveyards is somebody’s job too.

Usually it’s nobody’s job. Which is why we spend years filling in forms.