Too Good in a Crisis: Why Going Faster Is Making Your Startup Slower

The purchasing decision that set everything off was not reckless. That is the part worth sitting with before you do anything else.

Renata runs purchasing at a tech company we’ll call Kestrel. One morning she got a note from a sharp, well-meaning technical lead — call him Tom — suggesting a different supplier for a structural component. Lighter alloy. Better price. Shorter lead time. On every number Renata could put her hands on, it was the better choice. So she made it. Quickly, the way everyone at Kestrel has learned they are supposed to move.

What no one in that exchange thought to do was bring in Maya, the engineer who had designed the part. She had specified the heavier material for a reason that had nothing to do with weight or cost: it was about how the part holds up under sustained vibration, a failure mode she had chased down across two prototypes. The new alloy was lighter, cheaper, faster to source, and wrong.

Nobody lied. Nobody was lazy. Three competent people moved quickly and made a sound call with what each of them knew. The trouble is that the one person who knew the thing that mattered was never in the conversation.

Nobody asked Maya.

---

Daniel founded Kestrel, and Daniel reads this story as a competence problem. He has been finding decisions like this for months — small holes in someone’s reasoning, a missing assumption, a step skipped under pressure — and each one confirms what he already feels in his chest: that things go sideways when he is not there to catch them.

Here is what makes it harder to see than it sounds. Daniel is not a micromanager. He does not sit in every meeting or sign off on every decision. He has a COO who runs operations, a CFO who runs the numbers, capable managers who own the day-to-day. On paper, the company is built exactly the way a growing company should be.

What actually happens is quieter. The structure looks complete, but it does not hold. Under the daily pressure of a company moving fast, handoffs get dropped between teams, tasks stall with no one owning the follow-through, and decisions like Renata’s get made by whoever is closest. None of it is dramatic on the day it happens. It accumulates — until it becomes a crisis.

And when it becomes a crisis, it goes to Daniel. Fast. Because Daniel is genuinely good in a crisis: he can walk into a burning situation, cut through the noise, and have it sorted by the end of the day. Everyone has learned this, so they escalate early and often, because escalating to Daniel works. The phone rings, and it is always Daniel’s phone.

The trouble is what he carries in when it rings. He arrives without the background — he was not there when the thing was set in motion — and more and more, he arrives already certain: a fast, confident read on a situation he has only just heard about, sure he can see what everyone closer to the problem has missed. He pushes. He sorts the immediate fire. And then, watching the people he just steamrolled, he wonders why they don’t move faster.

There is something else feeding the pattern. Daniel has fallen a little in love with speed itself. He thinks fast and decides fast, and he has come to expect the same tempo from everyone around him. Why, he reasons, should the rest of the company not move like that? Hire faster. Prototype faster. Decide faster. Momentum is everything.

I want to be careful here, because the instinct underneath all of this is not foolish. In Kestrel’s early days, Daniel being in the middle of everything was the company’s advantage. He held the product, the customer, the numbers, and the engineering in one head, and that closeness let Kestrel move faster than companies ten times its size. The speed was real. The frustration he feels now is also real, and it is not the frustration of a bad leader. It is the frustration of a smart person who can feel that something is wrong and has misnamed it.

Because this was never a competence problem. The material story is not the story of three people who weren’t good enough. It is the story of a company with no defined way of deciding — nothing that says a change to a designed part has to include the person who designed it. The right people are not required to be in the room, so sometimes they are not.

And documenting it would not have saved them. You could write Maya’s every reason into every spec sheet at Kestrel and still make this exact mistake, because the failure was never that her reasoning went unwritten. It was that the decision was structurally allowed to happen without her. A broken way of deciding does not get fixed by better notes — it gets fixed by deciding, on purpose, who each decision needs. That is a structural fact, not a personal one. You cannot hire your way out of it, and you cannot push your way around it. You can only build your way out of it.

What is missing at Kestrel is not effort, and it is not talent. It is organizational viability.

The org chart is complete — the wiring isn’t

There is a precise idea behind that word. A system is viable when it can sense its environment, make decisions, correct its own errors, and hold its identity — in many places at once, without everything routing back through a single mind (a brief primer on the Viable System Model unpacks the whole idea). Your body does this every second. It coordinates thousands of simultaneous processes, keeps itself stable, watches for threats, and pursues a future, all without a central command post approving each heartbeat. Stafford Beer drew a model of organizations from exactly this, and its first lesson for a CEO is uncomfortable: the functions that keep a company alive all have to exist — and they have to be wired together tightly enough to run without you in the middle of them.

At Kestrel, the boxes exist. The wiring between them does not.

Daniel has operations, finance, the teams that build — the functions a growing company is supposed to have. What he does not have is the connective tissue that lets those functions regulate themselves: the coordination that keeps a handoff from being dropped, the monitoring that surfaces a problem while it is still small, the defined decision rights that put the right people in the room before a call is made. Without that tissue, each function does its own job well enough and the gaps between them go ungoverned. Ungoverned gaps are where crises are born.

There is a precise name for what happens next. Every viable system has an emergency channel — Beer called it the algedonic signal, the organizational equivalent of pain, the alert that bypasses the normal chain and goes straight to the top when something is badly wrong. It is meant to be rare. At Kestrel it has become the main channel. Because the ordinary structure is too thin to absorb the day-to-day variety, the company keeps converting its problems into emergencies and routing them to the one part that always answers: Daniel. He is not in every decision. He is in every crisis. And a company that runs on crises has quietly made its CEO its load-bearing wall.

This is also why his interventions land harder than they help. To actually regulate a complex situation, your response needs as much variety as the situation itself — Ashby called it requisite variety. That is exactly what Daniel does not have when he drops into a fire he has no background on. A confident, generic answer feels like requisite variety. It is the opposite: the same small response applied to every problem, missing the local context the people in the room already hold. So Daniel intervenes with less variety than the crisis demands, overrides the people who have more, and the fix he leaves behind is shallower than it looks.

And every fire he puts out teaches him the same false lesson: see, nothing moves unless I move it. The rescue is real. The conclusion is backwards. Daniel is not the cure for the crises — he is the reason the company never had to build the structure that would prevent them. Every time that structure should have been tested, he stepped in and relieved the pressure before anyone else had to feel it.

Why faster is making it slower

Now watch the loop close, because this is where the speed obsession turns on itself.

Daniel wants speed. But look at what the speed actually runs on. The structure is too thin to absorb the daily load, so things slip — a dropped handoff, a decision made without the right people, a task no one carried through. Each slip grows into a crisis. The crisis escalates to Daniel. Daniel storms in without the context, pushes hard, and sorts the immediate problem — which means the structural gap underneath it never gets built, because his rescue removed the very pain that would have forced the company to build it. So the next slip is just as likely, and the next crisis just as certain. Meanwhile the pushing leaves a residue: the people who actually had the context feel overridden, trust thins, and next time they escalate even faster rather than risk owning a call that Daniel might reverse. The firefighting deepens the conditions for fire.

Faster is making Kestrel slower. Not as a paradox or a clever line, but mechanically, as a feedback loop doing exactly what feedback loops do. Push on a system that lacks the structure to absorb the push, and the push comes back at you as friction. Momentum feels invisible not because people are lazy but because the company’s entire capacity to make progress is throttled through one overloaded valve.

There is an intuition Daniel has backwards about his own company. A single mind answers fast because everything it needs is already in one place at the moment it decides. An organization is the opposite shape. Its judgment is distributed — in Maya’s head, in Renata’s spreadsheet, in Tom’s instinct — and the only thing that makes a distributed system both fast and sound is whether its decisions reliably reach the people who hold the missing piece. Speed in an organization is not a function of how hard you press the accelerator. It is a function of whether the right minds are in a decision before it is made, instead of arriving after it has gone wrong.

You can’t hire the structure

When the overload gets bad enough, the instinct is to hire your way out of it — to bring in a senior, capable right hand to take the weight off your shoulders. It is a sensible instinct, and the right person genuinely can carry a great deal. But there is a way this goes wrong that I have watched play out more than once, and it is worth naming before it happens.

If that person is brought in to be a second Daniel — another sharp mind that everything routes through, another set of hands catching what falls, another shock absorber for the company’s missing structure — then the hire will not make Kestrel viable. It will feel viable for a quarter or two, while the new person quietly becomes a second bottleneck. Two regulators are better than one. Two regulators are still not a system.

The version that works is the one where their job is not to be the missing structure but to build it: to stand up the coordination that would have pulled Maya into the decision before Renata ever made it, to put in place the monitoring that surfaces problems as small signals through real channels instead of letting them reach the top as late-stage fires, to protect the strategic attention that the urgent present keeps eating. That is a real and senior job. It is also a different job than the one most founders think they are hiring for, and the difference between the two is the difference between relief that lasts and relief that evaporates.

What viable actually looks like here

None of this requires turning Kestrel into a bureaucracy. The cure for a startup that moves too chaotically is never to make it slow and procedural — that just trades one failure for another. It is to grow the five functions a living organization needs, distribute them, and keep them lean.

It means giving the teams who do the work real autonomy inside clear boundaries, so customer and engineering decisions stop routing back through Daniel by default. It means a genuine coordination layer — not process for its own sake, but the simple discipline that defines who a given decision actually needs, so that changing a designed part automatically pulls in the person who designed it, and the right people are in the room by default rather than by luck. It means an internal eye that reads how the operation is actually doing, in near real time, so problems show up as small signals to be handled in the open rather than as emergencies that detonate on the CEO’s desk. It means protecting the outward-looking attention that keeps a tech company relevant in a field that reshapes itself every few months. And it means making explicit the thing Daniel currently carries only in his gut — what Kestrel is, and what it will and won’t become — so that ten thousand small decisions have something to align to without him in the room.

Build that, and the material change does not happen, because changing Maya’s part brings in Maya. Build that, and Daniel stops being the part every crisis has to route through. The company gains the one thing every resilient system has and no amount of speed can substitute for: the ability to sense, decide, and correct in many places at once.

What to carry forward

The error is the signal, not the crime. When the same kind of mistake keeps surfacing — a decision made without the people it needed — the lesson is almost never “I have to watch more closely.” It is “we have no defined way of deciding who belongs in this decision.” Fix the process, not the person. And don’t reach for documentation as the cure: the right people have to be in the decision, not merely informed of it afterward.

Speed is an output, not an input. You do not get a fast company by demanding faster. You get it by building a structure where the right people land in the right decisions without you having to convene them. Press harder on a system that can’t absorb it, and the pressure returns to you as friction and rework.

Context is not optional, even for the CEO. The fastest person in the company is still wrong if they arrive without the background. Jumping into a crisis cold makes you a regulator without requisite variety — and a fast, confident answer is not the same as knowing what the people closest to the problem already know. Get the context before you push.

A company that runs on rescues isn’t fast — it’s fragile. When problems only get solved once they reach the top as a crisis, you don’t have a quick company. You have a single point of failure and a permanent shortage of the structure that would prevent the next fire. Every rescue quietly removes the pressure that would have built it. Scaling is building that structure on purpose, so the emergency channel can go back to being rare.

A great hire is not a structure. A strong right hand can carry the load or build the thing that carries the load. Only one of those survives their next vacation. Decide which you are hiring for.

---

If you have read this far and felt a flicker of recognition — the firefighting, the pushing, the strange sense that more effort is buying less progress — that flicker is worth trusting. It usually means the organization has outgrown the structure that built it, and that what feels like a people problem is a design problem wearing a people problem’s clothes.

That design problem is a knowable thing. It can be mapped, named, and rebuilt, function by function, without losing the speed that made the company worth building in the first place. That is the work I do — sitting with a founder and their team, finding where the structure stops holding: the dropped handoffs, the crises that should never have been crises, the decisions made without the people who should be in them. And then helping the organization become something that can finally run, adapt, and correct itself without the CEO as its load-bearing wall.

The fastest thing you can do for a company moving too fast is to make it viable.