The Process Trap

McDonald's solved one of the hardest problems in business history.

How do you serve the same burger to a million people, across thousands of locations, staffed by people who have never met each other, and have it taste exactly the same every single time?

The answer was process. Specific, documented, non-negotiable process. Every patty the same weight. Every fry cooked at the same temperature for the same number of seconds. Every wrapper folded the same way. You don't need to be a good cook to work at McDonald's. You need to follow the process. That's the point.

It works brilliantly. It might be the most successful operational system ever built for food.

But take that same system and try to run a kitchen where the goal is excellence rather than consistency, and something quietly breaks. The cook who stops tasting and starts timing. The chef who follows the recipe instead of reading the dish. The kitchen that produces the same thing every time, reliably, competently, and never once produces anything worth going out of your way for.

The same process that creates consistency at McDonald's would kill a good restaurant within a year.

I've watched a version of this play out in product teams more times than I can count. And the part that makes it hard to fix is that the people who bring it in almost always mean well.

Most product teams don't fail loudly.

They slow down. Gradually, the team that used to ship things that surprised people starts shipping things that are fine. Solid. Nothing embarrassing. Nothing remarkable either.

When you ask what changed, the answer is rarely a bad hire or a wrong strategy. It's usually a good hire. Someone brought in to bring order to the chaos, who had done it before at a company with a name people recognise, and who arrived with a system that made complete sense on paper.

Better prioritisation. Clearer documentation. Stakeholder sign-off baked into the process early rather than causing fires at the end. Every piece of it reasonable.

The chaos clears. And something else clears with it.

Process people have good intentions. That's what makes them dangerous.

I worked with a product leader once, brought into a mid-sized software company after a period of what the board called "productive chaos." The team had been shipping fast but inconsistently. Some things landed brilliantly. Others were half-baked and had to be quietly walked back. The board wanted steadiness.

He delivered it. Within six months the team was running like a machine. Every two-week work cycle planned in advance. Every feature backed by a document that had cleared four approvals before anyone wrote a line of code. Every decision written down with a reason attached.

The chaos was gone.

So was most of the thinking.

What I noticed, spending time with the team about eight months in, was that the designers and product managers had stopped having the kind of conversations that produce good products. The hallway debates about whether they were solving the right problem. The "what if we tried this instead" moments that usually got dismissed but occasionally changed everything. Those conversations had nowhere to go in the new system. They didn't fit any of the boxes.

The team wasn't unhappy. They were busy. Visibly, measurably busy. Hitting their deadlines. Closing their tasks. Moving work from one stage to the next.

But nobody was asking whether the stages were pointing in the right direction.

The thing process replaces is the thing you actually hired people for.

Steve Jobs talked about this once, in an interview most people haven't seen. He called them process people. His point wasn't that they were lazy or incompetent. It was more unsettling than that. They genuinely believe the process is the work. They've been in enough places where good process and good results happened at the same time that they've confused one for the other.

The McDonald's cook doesn't need to understand why the fry temperature matters. They need to set the timer. That's correct for McDonald's. But a product designer needs to understand why a design decision matters. If they're just following steps, you haven't scaled thinking. You've replaced it.

Product craft is the ability to hold a problem in your head from multiple angles at once and make judgment calls that can't be written down. You can write down the output of that judgment. You can't write down the judgment itself.

When a process-driven leader comes in and builds a system around the written outputs, it looks like structure. It is structure. But the thinking that produced those outputs is no longer required. The system runs on its shadow.

The tell is usually invisible until it's obvious.

At a business software company I spent time with a few years back, the head of product had inherited a team that had grown fast and badly. No clear ownership of who was responsible for what, roadmaps that overlapped, features being built by two teams who didn't know about each other. Real problems.

She fixed them. She was genuinely good at fixing them. Clear ownership, a single consolidated roadmap, a prioritisation system the whole team understood and actually used.

About a year later, the CEO asked me what I thought about the product direction. I told him what I'd observed: the team was well-run, the process was clean, and the last year of output had been, without exception, the most predictable and the least interesting in the company's history.

He went quiet for a moment. "I thought that was just a coincidence," he said.

It wasn't a coincidence. Predictability and originality aren't opposites, but the process that creates one can quietly starve the other if nobody notices it happening.

The tell is almost always the same. When a process-driven leader has been in place for a while, the team stops bringing problems to them. They bring fully-formed solutions instead. Pre-packaged, already justified, ready to slot into the approval process. Because the system rewards things that fit, not things that challenge.

And the leader reads those proposals, approves the ones that meet the bar, pushes back on the ones that don't, and feels, reasonably, that they are doing their job.

They are doing their job. That's the trap.

The other kind of operator exists, and they're extraordinary.

Not every leader who's good at scaling a team is a process person. This is the part that gets missed.

The best product leaders I've worked with, the ones who could take a struggling team and turn it into something that shipped great work consistently, weren't building systems around written outputs. They were building conditions for good thinking.

That's a different problem to solve entirely.

A leader who scales through coaching doesn't ask "what process stops us shipping bad work?" They ask "what does this designer need to think more clearly? What is this product manager not seeing yet? What conversation is this team avoiding that they need to have?"

The results look similar from outside. Clearer ownership. Better prioritisation. Fewer things built and quietly shelved. But the mechanism underneath is completely different. One scales compliance. The other scales judgment.

The franchise kitchen and the restaurant kitchen can look identical from the car park. You find out which one you're in when you taste the food.

Craft isn't one leadership style among three. It's the floor.

There's a framework that gets discussed in product circles where product leaders are sorted into three types: craftspeople who care about the product, operators who care about scale, and visionaries who care about the future. It's a useful map.

But it has a flaw. It treats craft as a personality preference, something some leaders have and others compensate for with systems or vision.

That's the wrong way to think about it.

A leader who understands product craft deeply can build a system that makes their team sharper. One who doesn't can only build a system that makes their team more compliant. A visionary who understands craft can push the team toward ambitious ideas that are also real. One who doesn't produces a roadmap that sounds exciting in a meeting and ships as a mess six months later.

Craft is not one option. It's what everything else either builds on or doesn't.

The companies that treat it as optional make a quiet decision that usually surfaces about two years later, in the form of a product that nobody can explain why it stopped being interesting. By that point the connection is hard to see.

I've seen it traced back. It's an unglamorous conversation. Usually someone goes back through old notes and finds the exact point where the team stopped asking the hard questions.

Almost always, there's a hire that happened about six months before that point.

A McDonald's kitchen running perfectly is genuinely impressive. Hundreds of people, millions of orders, zero variation.

But nobody drives across town for a McDonald's. They stop in because it's there and they know what they'll get.

The product teams worth working on, and the products worth building, are the ones people go out of their way for.

Process gets you consistency. It doesn't get you that.

Book series note: This article sits in the Product Teams and Leadership pillar and contributes to "The Product Lifecycle" at the Scale and Sustain stages. It could also be a central chapter in "How Markets Work," specifically on why well-run teams stop producing work that the market cares about.