Most Process Is Just Scar Tissue: How to Tell Good Process from Bureaucratic Buildup

Most of the process inside a growing company is scar tissue. It is the rule somebody wrote after something went wrong once, to make sure that exact thing never happened again, and then it calcified and nobody ever removed it. Good process makes work faster, clearer, or possible where it was not before. Scar tissue makes work slower while protecting against a problem that may not even exist anymore. The test for which is which is simple: does this make the work better, or does it just make everyone behave differently than common sense would tell them to?

This breaks down where scar tissue comes from, how to tell it apart from process that earns its keep, and how to cut the dead weight without throwing out the structure that is actually holding things together.

Where scar tissue comes from

Nobody sets out to build a bureaucracy. It gets created one reasonable decision at a time.

The pattern is always the same. Someone makes a mistake. Somebody overpays for a flight, a release breaks something, a customer gets mishandled. The team meets, everyone feels the sting, and a new rule gets born to prevent that specific thing from recurring. The rule is reasonable in the moment. The problem is that the rule never leaves, even after the conditions that created it are long gone, and over years you end up with a thick layer of rules each written for a problem nobody can quite remember.

This is how a company that overpaid for one hotel ends up with a multi-tier travel-approval matrix. It is how one bad hire becomes six rounds of interviews for every role. It is how a single missed bug becomes four mandatory sign-offs on a one-line change. Each rule made sense as a response to one event. Together they form a body so stiff it can barely move.

The deeper trap is that scar tissue feels responsible. Adding a rule after a mistake looks like learning. It looks like maturity, like a company growing up. That is exactly why it goes unchallenged, because removing a rule feels like inviting the old problem back, and nobody wants to be the person who took down the guardrail right before someone drove off the road.

The test for good process

Good process passes one of two bars, and the framing I have stolen and never given back comes from Shopify's founder. Good process either makes something possible that was impossible before, or it makes something that was already possible significantly simpler. Everything else is the third category, which is just telling people to behave differently than common sense would.

Here is how I run that test in practice when I walk into a company drowning in its own procedures.

Does it speed the work up or slow it down? Good process removes friction. It takes a thing that used to require five confused Slack threads and makes it one clear path. If a procedure adds steps without removing confusion, it is probably scar tissue.

Does it serve the people doing the work, or does it serve someone's anxiety? A lot of process exists so a manager can feel in control, or so nobody can be blamed if something breaks. That is not process serving the work. That is process serving fear, and fear is not a business requirement.

Could anyone explain why it exists? If you ask the team why a step happens and the best answer is "that is how we have always done it" or "I think someone set that up a while ago," you have found scar tissue. Process that earns its keep has a living reason. Scar tissue has a dead one.

Does it assume people are capable or assume they are not? Process built to enable good people is light, because it trusts them to use judgment. Process built to prevent bad behavior is heavy, because it tries to remove judgment entirely. The heavy kind tells your best people that you do not trust them, and your best people notice, and your best people leave.

How to cut it without bleeding

The reason most leaders do not clean out their scar tissue is the fear I mentioned: pull the wrong rule and the old disaster returns. That fear is worth respecting, but it is not a reason to keep everything. It is a reason to cut carefully.

The approach that works is to put the burden of proof on the process, not on the person questioning it. The default in most companies is that a rule stays unless someone can prove it is useless, which means everything stays forever. Flip it. A rule should have to justify its continued existence. If nobody can explain what it currently protects against and why that protection is still worth its cost, it goes.

When I rebuilt engineering process at a company that had none, then watched a consultant try to bury the team in by-the-book ceremony, the thing that worked was relentlessly asking what each piece of process was actually for, rather than reaching for a framework. Two-week sprints inside six-week iterations stayed, because they gave the team fast feedback loops. The elaborate Jira-tagging rituals went, because they served the methodology and not the work. The team that came out of that became the highest-performing product and engineering org in the company's history, and it ran on less process, not more.

Cut the rule, watch what happens, and put it back only if the problem it guarded against actually returns. Most of the time it does not, because the conditions that created it are gone. You will be surprised how much of the body's stiffness was protecting against ghosts.

What to keep

None of this is an argument against process. A company with no structure is just chaos with good intentions, and chaos does not scale any better than bureaucracy does. The goal is the lightest structure that makes the work predictable, which is a necessary thing.

Keep the process that makes the previously impossible possible. Keep the process that makes hard things meaningfully simpler. Keep the decision rights that let people act without waiting, the cadences that give work a rhythm, and the shared definitions that stop people from arguing about what "done" means. That structure is load-bearing. Cut everything that is only there because someone, sometime, got scared.

Frequently asked questions

What is organizational scar tissue?

Organizational scar tissue is process that was created reactively to prevent a specific past problem and then never removed, even after the conditions that justified it disappeared. It accumulates one reasonable rule at a time until a company is stiff with procedures nobody can quite explain.

How do I know if a process is worth keeping?

Ask whether it makes the work faster, clearer, or possible where it was not before. If it does, keep it. If its main effect is to add steps, remove judgment, or make people behave against common sense, it is probably scar tissue. A process that earns its keep has a living reason someone can articulate.

Isn't all process bureaucracy?

No. Process and bureaucracy are different things. Good process removes friction and enables people to do good work. Bureaucracy adds friction and tries to prevent bad work by removing judgment. The same company needs the first and should keep cutting the second.

How do I remove process without causing the old problems to return?

Shift the burden of proof onto the process itself. Instead of keeping every rule unless someone proves it useless, require each rule to justify why it still earns its cost. Cut the ones that cannot, watch for the problem to actually return, and reinstate only if it does. Most of the time the original conditions are long gone.

Why do startups accumulate bureaucracy as they grow?

Because adding a rule after a mistake feels like maturity and learning, while removing one feels like inviting disaster back. That asymmetry means rules only ever get added, never subtracted, so structure piles up reactively unless someone deliberately works against the drift.

If your company has gotten slower as it has grown and nobody can say exactly why, the answer is often a buildup of process nobody has questioned in years, and cutting it back is a large part of what I do.