.png)
Operational chaos in a startup has two possible sources, and they produce the same fires. One is a gap in the company's systems: work with no owner, or no agreed way of doing it. The other is a founder bottleneck, where work waits on one person or routes around the process that was meant to carry it.
Founders usually reach for the systems fix first. A new system can be bought, handed to someone else and finished within a month. None of them asks the founder to change. That's the appeal, and it's also why the fix so often stalls. When the founder is the constraint, a new system just gives the work a different place to wait.
This guide covers how to tell which source you're dealing with, why the founder side is so easy to miss, and what order the fixes should go in.
What does operational chaos look like in a startup?
Operational chaos is a pattern of fires rather than any single failure. Work falls between two people who each assumed the other had it. A decision arrives a week after the team needed it. The same problem gets solved twice in different ways, and the CEO hears about a customer issue after the customer has escalated it.
Every one of those fires has a source, and there are only two kinds. A system gap is missing structure: nobody owns the work, or nobody agreed how it gets done. A founder bottleneck is work that waits on one person, or goes around the process to reach them, even when the structure exists. From the outside the two look identical, and the fire is the same whichever source started it.
This guide stays with the fires themselves. The same question asked about leadership gaps, such as decisions, alignment and capability, belongs to the separate diagnosis of whether the bottleneck is the CEO or the system, one part of what breaks as a startup scales.
A rising count of fires can also be a symptom of growth outrunning the company. Meetings and initiatives multiplying faster than finished work is one of the early warning signs of scaling too fast, and fires are where it shows up day to day.
Why do founders fix the systems side first?
Because a systems fix is visible, can be bought, can be handed to someone else and doesn't ask the founder to change anything about how they work. A new project tool, a written process, an operations hire or a reorganization each produces a feeling of progress within weeks. Changing where decisions go produces discomfort first and progress later.
One study of founder-led companies shows why that bet often fails. In 2019, Bradley Hendricks, Travis Howell and Christopher Bingham studied over 2,000 firms that had gone public, roughly half of them led by their founders. Their paper appeared in the Strategic Management Journal. Consistent with earlier research, top-team structure significantly affected companies run by hired CEOs. In founder-led firms it had "little to no effect on the operating performance."
The authors' explanation is the uncomfortable part: "founder chief executive officers (CEOs) may exert too much control." In their managerial summary, they add that founder CEOs "are much less likely to listen to and benefit from their teams relative to nonfounder CEOs." These are public companies, not Seed-stage startups, so the size of the effect won't transfer directly. The direction still holds: when the founder keeps control, changing the structure around them changes little.
The table below shows how each common systems fix plays out when the real source is the founder.
How does a founder become the bottleneck without noticing?
A founder becomes the bottleneck by staying the default destination for decisions and information. Each individual routing choice is reasonable. It's faster to answer the question than to explain who should, and the founder usually does know best. The trouble is what those choices add up to once there are dozens of them a day.
Noah Shanok founded Stitcher in 2006, ran it as CEO for eight years and now coaches venture-backed CEOs through Startup CEO Coach. He puts the cost bluntly in his post on making faster decisions:
If every decision flows through you, your company will crawl.
He also describes a common way founders end up there:
One of the most common patterns I see in executive coaching for startup founders is a CEO who has become the bottleneck without realizing it, not because they're slow thinkers but because they haven't distributed decision authority clearly enough.
"Without realizing it" is the reason founders reach for systems. They can see the queue. They can't easily see that they're the cause of it, because from the founder's chair a queue looks like other people waiting on decisions.
Queueing theory explains why the queue grows so fast. In the simplest model, a single server with random arrivals, the average number of items waiting or in progress is ρ/(1−ρ), where ρ is how busy the server is. MIT's course notes on the M/M/1 queue derive it. At 50% busy, the queue averages one item. At 80% it's four. At 90% it's nine, and at 95% it's nineteen.
A founder isn't a textbook queue, and the exact numbers don't carry over. The shape does. A founder whose calendar is nearly full isn't slightly slower than one with room to spare. Waiting work grows much faster than their busyness, and the waiting is where the fires start.
How do you trace a fire back to its source?
Take the last ten fires, meaning missed deadlines, escalations, customer surprises and rework, and ask the same four questions about each. The answers sort every fire into one of four sources, two that point to missing systems and two that point to the founder.
- Where did it start?
- Who had the information that would have prevented it?
- Who was supposed to catch it?
- Did it wait on the founder, or go around a process to reach them?
The first two are genuine system gaps. No owner means the work fell between two people, each sure the other had it. No process means everyone did it differently, so the result depended on who picked it up. Both are fixed by building something: an owner, an agreed way of working, or both.
The other two are founder behavior. Process bypassed means a process existed, but the founder went around it or overrode what it produced, and the team learned the process didn't really decide anything. Only the founder had it means the information or the authority lived with one person. That fourth source is the one founders misread most often, because it looks exactly like a system gap. It's the pattern Shanok describes: decision authority that was never distributed clearly enough. It also fits the explanation the Hendricks study offers for its finding, that founder CEOs "may exert too much control."
Then count. The pattern is usually clear. If most of the ten fires land in the first two sources, the company needs systems, and building them will work. If most land in the third and fourth, the founder is the constraint, and new systems will stall until that changes. A mixed tally is normal. When it's mixed, start with the founder side.
Here is what a tally can look like. This example is illustrative, not drawn from a real company. A 30-person startup lists its last ten fires. Two were handoffs between sales and onboarding that nobody owned. One was a pricing exception that three account managers each handled differently. Three were product decisions where the team had a review process, and the founder changed the outcome after it ran. The remaining four waited for the founder to reply: two customer refunds, a vendor contract and a hiring approval.
Read naively, that list says the company needs better processes, a contract workflow and a hiring tool. Read through the trace, seven of the ten fires sat with the founder. A new workflow would have given the contract a tidier place to wait. Refunds are the most frequent founder-only fire on the list, so the useful first move is to hand over refunds. Product reviews come next, once the first handover holds.
When the system really is the problem
It often is, especially early. In 2006, Wesley Sine, Hitoshi Mitsuhashi and David Kirsch studied internet ventures between 1996 and 2001 in Revisiting Burns and Stalker, published in the Academy of Management Journal. Ventures whose founding teams were more formalized, specialized and administratively intensive outperformed the looser, organic ones.
That's a useful corrective to the idea that structure is something only large companies need. The authors draw on Arthur Stinchcombe's idea of the liability of newness: young organizations lack the established roles and routines that let older firms coordinate informally. When the fire trace shows mostly missing owners and missing processes, the chaos is telling the founder that the company has outgrown improvisation.
Structure only works if decisions are allowed to move through it, though. In 2012, Nicholas Bloom, Raffaella Sadun and John Van Reenen studied almost 4,000 firms across the US, Europe and Asia in The Organization of Firms Across Countries. Firms in high-trust regions, they found, "are significantly more likely to decentralize." Trust also helps more efficient firms grow, "as CEOs can decentralize more decisions." Decentralizing is partly a matter of structure and partly a matter of whether the person at the top lets go.
When the tally does point to system gaps, the work is to build the operating structure that takes recurring decisions off a founder's desk. A few fires turn out to be strategy problems in operational clothing, and those belong with strategic clarity during hypergrowth.
What order should the fixes go in?
Fix the constraint first, then build systems around it. The Theory of Constraints, which Eliyahu Goldratt introduced in his 1984 business novel The Goal, rests on the idea that the slowest link sets the pace for everything. As the Theory of Constraints Institute puts it, "A constraint limits the output of every system, whether we acknowledge it or not."
The same page makes the point founders tend to miss: "Strengthening the other links can never increase the overall strength of the chain, because they are not the weakest." Applied to a startup, a new tool or an operations hire strengthens a link that wasn't the weakest. The work still waits on the founder, so the company is no faster, and it's now paying for the tool as well.
The order that follows from this is editorial, and it has three steps:
- Take the founder off the path for one category of fire, starting with the most frequent source-four fire in the tally. Hand over the authority along with the task.
- Let whoever replaces the founder run without override for a set period, long enough to make a few mistakes and fix them.
- Only then add or buy the system that makes the new route scale: the tool, the process document or the hire.
The cost of this order is real. For a few weeks, quality dips and work takes longer, because the person now deciding is learning. That's also when the urge to step back in peaks. Founders who override in the second week teach the team that nothing has changed.
Shanok's answer to a related question points the same way. Asked to separate the people problems in his coaching work from the strategy problems, he answered in terms of the founders themselves:
"The speed of startup growth is almost always constrained by the speed of their development. It may look like a strategy issue or a people issue or some other kind of issue, but once you unpack it enough, it mostly comes down to the founder's evolution."
How do you know the founder bottleneck is easing?
Re-run the fire trace every month. The share of fires landing in the third and fourth sources should fall first, and repeat fires, the same fire twice, should disappear early. If the share hasn't moved after two or three monthly traces, an illustrative window, the founder hasn't actually let go of the decisions they handed over, whatever the org chart says.
The second measure is the founder's own calendar. The queue curve is the argument for deliberate slack: in the simple model, a founder who is 90% busy has nine items waiting or in progress on average, against one at 50%. A calendar that is close to fully committed every week means work is waiting somewhere, even if nobody is complaining yet.
The third measure is whether decisions made below the founder stay made. A decision that gets reopened when the founder hears about it was never really handed over, and the team will treat the next one the same way.
When the numbers don't move, look at what happens just after a handed-over decision goes wrong. That's the moment most founders take the authority back, often without announcing it, by asking to see the next one first. The team notices immediately. If the founder can't tolerate a few wrong calls in a category, the category hasn't really been handed over. Start with a lower-stakes one instead.
It also helps to ask the team directly. People below the founder usually know which decisions still need the founder's sign-off in practice, whatever the official version says. Ask which approvals they still wait for and which they now decide on their own. Their answer is a faster read than the founder's own sense of how much has been let go.
Frequently asked questions
Should a founder hire a COO to fix operational chaos?
Trace the fires first. If most come from missing owners or processes, an operations leader can build what's missing. If most route through the founder, a new COO inherits responsibility without authority. A study of more than 2,000 public companies found that top-team structure had little effect when the founder was CEO, and its authors suggest founders may keep too much control.
What should a founder stop doing first?
Start with the most frequent source in the fire tally. If it's founder-only fires, choose the single category that recurs most and let someone else own it completely for a set period before reviewing the results. If it's bypassed processes, the first change is simply to stop overriding one of them.
How much slack should a founder keep in the calendar?
Enough that new work doesn't have to wait for a gap. The queueing model shows waiting work rising sharply as a schedule approaches full. A calendar with deliberate open time will move work faster than one packed solid. The right amount varies; a full calendar is the warning.
How long does it take to stop being the founder bottleneck?
Usually a few weeks per category of decision, and progress isn't smooth. Quality often dips while a new owner learns, which is when founders are most tempted to take the work back. Measuring the share of fires that still route through the founder each month shows whether the change is holding.
Why don't founders notice they've become the bottleneck?
Because the habit that causes it was once the fastest way to work. Answering every question made sense with a handful of people. As volume grows, the same habit creates a queue, and the queue forms behind the founder, where it looks like other people waiting rather than one person causing the wait.
Can new software fix operational chaos?
Only the kind caused by missing processes. Software can make an agreed way of working easier to follow and easier to see. It can't decide who owns the work or stop a founder from going around it. Introduced before those questions are settled, a new tool tends to add another place for work to wait.
The chaos usually routes through one desk
Operational chaos looks like a systems problem because systems are where the fires show up. Tracing them back often leads to one desk, where decisions wait or processes get overridden. A new tool, a process or an ops hire will work well once that route is open, and stall while it isn't. If the trace is hard to read from inside the company, a conversation with a coach is one way to get an outside view.
Before buying the next fix, take the last ten fires and trace where each one started. The tally will say which problem the company has and what to fix first.
Sources
- How much do top management teams matter in founder-led firms?, Strategic Management Journal
- M/M/1 Queue, Introduction to Manufacturing Systems course notes, MIT OpenCourseWare
- Revisiting Burns and Stalker: Formal Structure and New Venture Performance in Emerging Economic Sectors, Academy of Management Journal
- The Organization of Firms Across Countries, The Quarterly Journal of Economics
- Theory of Constraints of Eliyahu M. Goldratt, Theory of Constraints Institute
- How do I make faster decisions as a CEO?, Startup CEO Coach
