Writing

A finance lead once walked me through an approval chain that required two signatures on any contract above $50,000. I asked where the threshold came from. She said she'd inherited it. The person before her had inherited it too.

We eventually traced it to a deal that went badly four years earlier. Someone signed something that turned out to be expensive, and the response was a second signature above a dollar figure that felt roughly right at the time. Since then the company had built out a robust legal function, added contract review before signature, and moved average deal size well past $50,000. The condition that produced the rule was gone. The rule was still running on about 40% of their deals, adding nine days to each one.

Nobody in that chain was being careless. Everyone was doing exactly their job.

Companies preserve decisions and lose the reasoning behind them. The rule is easy to encode. It goes in a policy doc, a workflow, a required field in the CRM. The reasoning lives somewhere much less durable. In the head of whoever made the call. In a Slack thread from 2022. In a hallway conversation that never got written down anywhere.

So the rule travels forward and the reasoning doesn't. A few years later you have a company full of controls nobody can explain.

That gap shows up in two ways, and they look like opposites.

The first is accretion. Nothing gets removed, because nobody can prove it's safe to remove. Any given rule might be holding weight. So it all stays, the operating model gets heavier every year, and people quietly route around the parts that stopped fitting.

The second is the correction. A new leader arrives, sees obvious bloat, and clears it out. Some of what they remove is residue. Some of it was load-bearing. They find out which was which about six months later, usually during an incident.

Both come from the same missing information. If you don't know why something exists, you can't tell whether it still should.

The fix isn't more documentation. Most companies already have more documentation than anyone reads. It's a change in what gets written down.

"Two approvals required above $50,000" is a rule. No expiry, no conditions.

"Two approvals required above $50,000 because we have no legal review before signature, and the last unreviewed deal cost us $400,000" is the same rule carrying its own audit. The day legal review exists, the sentence stops holding together. Someone reading it will notice.

Write down the condition, not just the conclusion. Then the rule can tell you when it's finished.

Most of this gets lost in transitions. Someone leaves, someone new takes over the function, and the handover covers what to do without ever covering why any of it was decided. The rules survive the turnover fine. The reasoning walks out with the person who had it, and nobody thinks to ask them for it on the way out.

When execution starts breaking down, the instinct is almost always the same: Add a step. Add an approval. Add a checkpoint. Document it. Train people on it. Call it a new process.

Sometimes that's exactly right. If no process exists, building one is the obvious answer.

But in many companies I've worked with, the problem isn't that process doesn't exist. It's something else entirely. And adding more process on top of it doesn't fix anything. It just gives the original problem somewhere new to hide.

The three situations I see most often:

The Gap

The process actually doesn't exist. Someone needs to design it. This is the one case where adding process is the right call. But it's less common than people think. What looks like a missing process is often actually a process that exists informally in someone's head, in how a particular team does things, in the way work has always moved between two people who figured it out years ago. Before building something new, it's worth asking whether the process already exists somewhere and just hasn't been encoded. Because if it does, the work isn't design. It's documentation. And those are very different engagements.

The Workaround

The process exists but isn't being followed. This is where most companies stop asking the right question. The instinct is to reinforce the process: remind people, retrain, add oversight, add another approval. But people don't avoid process randomly. They avoid it when it doesn't match how work actually moves. Sometimes the process was designed by people who weren't close enough to the work to understand how it actually ran. Sometimes it made sense once and quietly stopped making sense as the business changed around it. The process didn't fail. It just stopped fitting. And when process stops fitting, people route around it. They find the path that actually works: the Slack message, the favour, the workaround that gets things done. The workaround becomes the real process. And the documented one becomes a compliance exercise that everyone performs and nobody believes in. Adding more process in this situation doesn't fix anything. It adds another layer on top of something that was already being avoided.

The Trap

The process exists, is being followed, and is still the problem. This is the hardest one to diagnose because nothing looks broken from the outside. Compliance is high. People are doing exactly what they're supposed to do. And yet deals are still stalling. Handoffs are still breaking. The same friction keeps showing up in the same places. Sometimes the process was designed for a version of the business that no longer exists and never got updated. Sometimes it was built to protect one function without anyone asking what it cost the rest of the system. Sometimes it just never worked as well as everyone assumed it did. Whatever the reason, the answer isn't more enforcement. The process itself is what needs to change. And that's a much harder conversation to have than telling people to follow the rules.

The mistake isn't caring about process. The mistake is treating all three situations the same way.

Before adding anything, the more useful questions are: does a process exist, is it being followed, and is it actually working?

If the answer to any of those is no, that's where the real work starts.

I've sat in enough leadership meetings to recognize a pattern: Three functions. One broken process. Three completely different explanations for why it's broken.

One team thinks the other is too slow. Another thinks nobody follows the process. A third thinks they're always the last to know. Each team is describing something real. Each team is also only describing what they can see from inside their own lane.

Nobody is looking at the space between them.

It's not lack of effort. It's not incompetence. It's not politics. It's the natural result of how organizations are built. Each function is trained to see the world through its own lens. Sales sees the deal. Risk sees the exposure. Finance sees the margin. Product sees the delivery. Everyone is paying attention. Just not to the same thing.

At scale, things rarely fall apart inside a function. They fall apart in the gap between them. The handoff that worked at fifty people doesn't hold at two hundred. The approval that used to be a quick conversation becomes a weeks-long bottleneck. The decision that's supposed to happen at one level quietly moves two levels up because nobody ever designed a process for when two functions disagree.

Ownership is only part of it. Sometimes the right people are involved but in the wrong order. A function that needs to weigh in early gets pulled in late, after decisions have already been made around them. Another gets engaged before the work is ready for them, creating rework instead of progress. The sequence was never designed. It just happened.

So what happens? Each team escalates. Leadership gets pulled in. Someone proposes a new process, a new tool, more headcount. The symptoms get treated. The gap stays open. A few months later, the same problem surfaces with a different name.

The most useful question I've learned to ask isn't who's right. It's: what is each team seeing that the others aren't?

That question changes where you look. Not inside the functions, but between them. The decision nobody has actually made yet, because everyone assumed someone else would. The moment where one team's responsibility ends and another's hasn't clearly begun. The decision everyone thought was settled. Nobody documented it.

When you start looking there, the real problem usually becomes visible. And it's almost never a reorg, more headcount, or a new tool.

None of this is a character flaw. It's structural. Every team is doing exactly what they were built to do. The problem is that nobody was ever asked to own the space between them.

That space is where execution goes to slow down. And in most organizations I've worked with, nobody owns it. Not because people don't care. Because nobody ever asked them to.