No. 01
The reflex when execution breaks is to add process — and the research says that reflex is usually what slows a scaling team down, not what fixes it. What actually works.
When a scaling company’s execution breaks down, the reflex is almost always the same. Add process. Write the doc. Stand up the committee. Institute the review. It feels like control, and it is the wrong instinct more often than not.
BCG’s Yves Morieux has spent a career measuring why. By the BCG Institute for Organization’s index, business complexity has grown sixfold since the 1950s: companies that once tracked four to seven performance requirements now track between twenty-five and forty, and as many as half of them contradict each other. The internal complicatedness companies add to cope with it — the procedures, layers, coordinating bodies, approval steps — has grown thirty-five-fold over the same period. The machinery built to manage the complexity outgrew the complexity itself. The result is an organization that spends its energy managing itself instead of serving the customer. More process, more meetings, more alignment, and somehow less shipped.
This is where a lot of founders draw the wrong lesson and swear off process entirely. Move fast, stay lean, trust the team. That works right up until it does not, and the point where it stops working is predictable. A company of fifteen runs on hallway conversations, and it should. The same operating style at a hundred and fifty is not lean, it is chaos, because the informal coordination that carried the early team quietly stopped scaling somewhere around Dunbar’s number and nobody noticed.
So the question was never process or no process. It is whether the operating layer you have is built to distribute liability or to increase throughput. Most process is defensive — designed so that no single person is blamed when something goes wrong — and defensive process is exactly the kind that slows teams down. It adds steps without adding judgment. The operating discipline that actually works is generative: it puts the right decision in front of the right people with the right information earlier, so that fewer wrong things get built at all.
Software engineering already ran this experiment and settled it. For years, moving fast and not breaking things were treated as opposites, and every release was a risk you managed with more sign-offs. Then DevOps inverted the premise. Continuous integration, automated testing, deployment pipelines — an infrastructure layer that made shipping faster and safer at the same time. The teams that adopted it did not slow down to buy quality. They got quality by building the system that made speed sustainable. Product operations is the same move applied one level up: to how a company decides what to build, not only how it ships what it decided.
McKinsey’s operating-model and agile research lands in the same place. The organizations that scale execution are not the ones that add governance. They are the ones that redesign how decisions flow. The Startup Genome study of 3,200 high-growth startups found the single most common cause of failure was not moving too slowly. It was premature scaling — expanding faster than the underlying systems could support, with founders holding on to too many decisions — which accounted for 74 percent of failures. The dysfunction reads as a speed problem. Underneath, it is a systems problem.
You can tell which kind of process you have by what it produces. Defensive process generates documents that get written and never read, reviews where the outcome was decided beforehand, and a roadmap that changes without anyone able to say why. Generative operating discipline produces fewer things in flight, clearer ownership, and a visible drop in the work that has to be unwound after the fact. If your last three process improvements made the team feel more managed and less effective, you did not have too little process. You had the wrong kind.
The fix is not to strip it all out and hope the chaos resolves. It is to replace defensive scaffolding with an operating model matched to the company’s stage, one that raises the odds of building the right thing before the team spends a quarter building the wrong one. That design work is specific to the company, and it is the difference between an operating layer that compounds and one that calcifies. Most teams have never seen the good version, which is why they assume all process is the enemy. It is not the process. It is the design.
When execution breaks, the instinct is to add process, and BCG's research shows that instinct usually backfires: companies answer complexity with complicatedness that grows far faster than the problem. The distinction that matters is not process versus no process. It is whether the operating layer is built to distribute liability or to increase throughput. Software settled the same question years ago with DevOps.