When I moved to Visa Europe I was leading technology for the region inside the innovation group, and being in innovation came with genuine privileges. We had dispensation to skip steps other teams couldn't skip, we had budget that didn't have to crawl through the usual gates, and there was an explicit organisational position that innovation should be allowed to run. With all of that, it was still slow. Not slow against some imaginary startup benchmark, slow in the sense that decisions I'd expected to take a week took two months, and a good chunk of my time went on working out who was going to make them rather than on the decision itself.

Nobody was doing anything wrong. That's the part that took me a while to accept. Every individual behaviour I could point at was locally sensible, and the slowness was emergent, which meant it wasn't anybody's fault and therefore nobody was responsible for fixing it.

The matrix structure was doing most of the damage. Big projects had five or six functions with a stake, each function reported up its own line, and there was never a single person who owned the outcome. Risk aversion follows from that automatically, because if you can't be certain you'll own the upside, you can be fairly certain you'll be handed a share of the downside. The flip side gets discussed less often and bothered me more. When nothing has an owner, credit is available to anyone who wants to claim it, and I watched work get attributed to people who'd been in two meetings about it. There was no way to contest it because there was genuinely no owner of record, and the same ambiguity that diffused blame diffused credit.

I've spent a lot of time since then working out why this happens, and the conclusion I've landed on is uncomfortable. Slowness isn't a disease that infects healthy organisations. It's the equilibrium state. Speed is the unstable state, and it only persists while something is actively spending energy to hold it there.

What efficiency actually means

Before you can talk about why an organisation is slow you need to say what you're optimising, and most organisational discussion skips this and goes straight to the org chart, which is why most reorganisations achieve nothing.

The formulation I've settled on is that you're maximising the compounding rate of value creation, roughly decision quality multiplied by decision velocity multiplied by learning rate, per unit of resource consumed, subject to a constraint on catastrophic failure. Each of those terms is doing something specific.

Velocity means latency, not throughput. Large organisations usually have perfectly acceptable throughput, and plenty ships eventually. What destroys them is the time between information arriving and a decision being executed on it, and that latency compounds through dependency chains, so a two-week decision cycle across five chained teams costs you a quarter for a single end-to-end change.

Learning rate is the term that compounds, and it's the one people underweight. SpaceX's advantage isn't that any individual decision is faster, it's that iteration speed sets how quickly the organisation learns, and learning feeds the next cycle. An organisation that decides twice as fast doesn't produce twice the output, it produces exponentially divergent output over a decade, because each cycle improves the one after it.

Ruin sits in the model as a constraint rather than as the objective, and this is where slow organisations go wrong at a structural level. Fast organisations treat catastrophic error avoidance as a constraint to satisfy. Slow organisations promote it to the objective they're maximising. Once that promotion happens, every additional checkpoint, sign-off and steering committee is locally rational, and there's no natural stopping point.

The slow ones do have a real cost function underneath. When you run critical payment rails, one catastrophic mistake genuinely does outweigh a thousand missed opportunities, and matrix structures, committees and sign-off chains are blame diffusion technology, which is a rational response to that. The pathology isn't the cost function, it's keeping it long after it stops applying, and applying it uniformly when only a small fraction of decisions are actually irreversible.

Two things follow from stating the objective properly. The first is that it has to decompose, so each team's local objective sums to the global one, and this is where matrix organisations fail mathematically rather than culturally. Two bosses means two local objective functions that conflict, and the global objective becomes incoherent by construction.

The second is the diagnostic I've found most useful, and it's the one I'd start with if I walked into an unfamiliar organisation tomorrow. Count the decisions. Not the meetings, not the tickets, not the deployments, the actual decisions being made per week and the level at which each one was made. It's a crude number and it's remarkably hard to fudge, and an organisation making four decisions a week at director level and above is telling you exactly what it is. Then look at the promotion criteria, because an organisation's real objective function is revealed by who gets promoted rather than by anything on the wall. If people advance for having no failures attached to their name, error avoidance is the objective, whatever the values poster says.

Six mechanisms, all of them ratchets

There are six failure modes I keep seeing, and the thing that unifies them is that each one is a ratchet. Adding a rule, a layer or a sign-off is personally safe and often personally rewarded. Removing one carries personal risk and no reward. So each mechanism only ever accumulates, and nothing self-repairs.

Coordination tax. Communication paths grow with the square of headcount while output grows linearly, so past a certain size most of the work in the system is coordination about the work. This one is physics rather than culture, and you can't incentivise your way out of it, you can only contain it structurally.

Accountability diffusion. With two bosses or a committee, no individual's model of the world is ever tested against reality, so nobody's judgement improves. Consensus decisions are systematically worse than owned ones because consensus optimises for what nobody objects to, which is a different thing from what's right.

Information degradation. Every hop up the chain filters and compresses, and the distortion is directional rather than random, because bad news attenuates on the way up and good news doesn't. Leadership ends up making confident decisions on a sanitised model of reality, and the confidence is the dangerous part.

Incentive inversion. Outcomes are noisy and process compliance is legible, so rational careerists optimise the legible thing, and over time the promotion system selects blame avoiders over decision makers. Nobody designs this, it just falls out of measuring what's easy to measure.

Process scar tissue. Every incident spawns a permanent rule, the author of the rule gets credit, and nobody has ever been promoted for deleting one. Twenty years later the organisation is executing the accumulated fear of every mistake it has ever made, and most of those mistakes are no longer possible.

Headcount as status. When pay and prestige scale with team size, every manager has a direct incentive to inflate the resource cost of their own function. Work expands to justify the org chart, which makes the coordination tax worse, which justifies more headcount.

The taxonomy matters as much as the list. The coordination tax is structural, accountability diffusion and information degradation are architectural, and the last three are incentive design. The fixes live in different places, which is why you can't solve an incentive problem with a reorganisation, and a reorganisation is exactly what most companies attempt.

What I saw at Visa was the first four running at once, which is why the innovation dispensation didn't help much. We'd been given relief on process, and process wasn't the binding constraint.

Principles, and what each one costs

The test for a real principle is that it costs something to follow. If following it is free, it's a poster rather than a principle, so each of these is stated with its price attached.

Small units with hard interfaces. You can't reduce the square in the coordination tax, you can only shrink what you're squaring. Two-pizza teams work not because small teams are magic but because the coordination cost gets paid inside a boundary where communication is cheap and high bandwidth, and between boundaries you use defined interfaces, written contracts and APIs rather than meetings. The cost is duplication, and Amazon accepts teams rebuilding what other teams already built because duplication is cheaper than coordination.

One owner per decision, and the owner decides. Exactly one name against each decision, with real authority attached rather than accountability for other people's choices. Advice is welcome, votes are not. The cost is that the owner will occasionally be visibly wrong in front of everyone, and you must not respond by adding a committee.

Shortest path for information, chain of command only for decisions. Anyone can talk to anyone, and escalation exists for conflicts rather than for data. Leaders have to touch raw reality routinely, because the org chart is a lossy compression algorithm pointed directly at them. The cost is that middle managers lose the information broker role that justified a lot of their existence, and they will resist accordingly.

Reward outcomes and judged decision quality, never process compliance. Promote people who made owned calls that turned out right, and also people who made good calls that failed on luck, and never promote for tenure, headcount or a clean record. A clean record usually means no decisions were made. The cost is that this requires leaders to exercise judgement rather than point at a rubric, which is precisely the work that legible metrics exist to avoid.

Every rule has an owner and an expiry. Any process must name the person who can waive it, and rules should sunset unless actively renewed. Musk's version is that if you're not occasionally forced to add back some of what you deleted, you're not deleting enough, and the institutional version needs symmetry of credit, so deletions get celebrated like launches. The cost is that an old mistake will occasionally recur and you have to hold your nerve when it does.

Decouple status from headcount. Pay and prestige track scope and impact rather than team size, and "I did it with fewer people" has to become a brag rather than an admission. The cost is that you lose the managers whose actual skill was accumulation, which is the point but is painful mid-flight.

Sort decisions by reversibility and route them differently. Reversible decisions get made by the owner, fast, at the lowest sensible level, and irreversible ones go slow and senior. Slow organisations run everything through the irreversible process and fast startups run everything through the reversible one, and the sorting itself is the actual senior leadership skill. Most of what gets escalated as a big decision is reversible and got escalated because stakeholders wanted a senior name attached to it, which is blame diffusion operating on you from outside.

Delegation only holds if you back the owner publicly when they're wrong. The first time you relitigate a delegated call in front of stakeholders, the delegation collapses and everything routes back through you, and it takes months to rebuild.

Working out which mechanism is actually binding in a given organisation is harder than it looks, and it's the reason I built Sonde, which walks through a structured diagnostic rather than letting you jump to a fix. Most of the time the fix people reach for addresses a symptom of a different mechanism entirely.

Structure is downstream of everything else

Structure is the implementation, not the design. An org chart is the output of a set of choices about what you're optimising for, and copying someone else's chart imports their answer without their question.

The variable that actually determines shape is how coupled the thing you're building is. Amazon and SpaceX are both fast and have close to opposite structures, which should be enough to kill the idea that there's one correct shape.

Amazon is divisional because it runs many loosely coupled products, so it shards into autonomous units that each own a service or a P&L end to end and communicate through hard interfaces. AWS is an org chart rendered as APIs.

SpaceX is functional because a rocket is one deeply integrated artefact, and you cannot two-pizza your way to orbit. Autonomous component teams would optimise components at the expense of the vehicle. The integration problem gets solved instead by the chief engineer model, one person holding the whole design in their head with authority across every function, which is the same shape Apple ran under Jobs.

The rule I'd draw from that is loosely coupled portfolio means divisional autonomy, and single integrated product means functional depth plus one integrating owner. It's Conway's Law applied deliberately, designing the organisation to mirror the architecture you actually want rather than discovering afterwards that your product looks like your org chart.

The matrix is what you get when you refuse to choose. You want functional excellence and product ownership simultaneously, so you give people two bosses, and you get accountability diffusion as a permanent structural feature rather than an occasional failure. The honest alternative is to pick a primary axis and make the other one a service with no authority, so either functions own people and products are lightweight integrating teams, or products own people and functions are standards-setting guilds.

Vertically, run as few layers as the arithmetic allows, because every layer is an information hop and a latency stage. The lever is span of control, and wide spans don't just save money, they force delegation, since a manager with ten reports physically cannot micromanage them. Managers should have real work of their own, and a manager whose entire job is routing information is a bug that the structure should make impossible.

Between units, the coordination medium wants to be written and asynchronous rather than synchronous. Six pagers, written interfaces, decision memos. Writing forces precision, scales to any number of readers at no additional cost, and leaves a decision record you can learn from later, which feeds the learning rate term directly. Meetings are the interface of last resort for genuine conflict.

Two things I'd change first in most organisations follow from this. Split status from decisions in steering committees, so status goes out as a written pre-read and the meeting shrinks to irreversible decisions and real cross-functional conflict, with the rule that a steering committee with no decision on the agenda doesn't meet. Expect roughly half of them to evaporate. Then move to decision memos for anything that would otherwise need your attendance, one page covering context, options and a recommendation, approved, vetoed or questioned in writing the same day. Ten minutes replaces two hours, the record accumulates, and people's judgement becomes visible and therefore improvable.

The other structural mistake I'd flag is treating individual workstreams as the unit of ownership at leadership level. Forty things cannot interface with one person and five can, so cluster them into domains and give each domain a single owner who holds the whole cluster including the reversible decisions and the committee seat. The decision surface drops from forty interfaces to five, and only genuinely irreversible things escalate. Related to that, "I don't have people who can do that" is usually a seniority gap rather than a capacity gap, and hiring more mid-level people adds throughput to a system whose constraint is decision latency through one individual, which doesn't move the constraint at all.

AI summarisation is synthetic middle management

Most organisational writing predates people running AI pipelines over their own organisations, so this mechanism doesn't appear in it, and it's the one I've hit most directly myself.

I've built one of these, and I wrote up the mechanics in AI without a system of record is just chat. Raw Slack and meeting transcripts get summarised, summaries become tasks, tasks roll into project state, project state reaches me. It works, and I'd build it again.

It's also synthetic middle management, and it inherits information degradation exactly. Every stage is a compression step, and I noticed the felt signal loss before I understood what it was, and my first instinct was to fix the prompt. The prompt wasn't the problem. A compression chain does what compression chains do, and the fact that the compressor is a model rather than a person changes nothing structurally.

The distortion is directional too, which is the bit that took longer to see. Summarisers smooth. Smoothing attenuates anomalies, and anomalies are disproportionately bad news, so an automated pipeline understates risk in the same direction that a chain of human managers does, for entirely different reasons and with the same result. The organisation looks calmer than it is.

Two countermeasures have held up. The first is shortest-path sampling, where I routinely bypass the whole stack and read one stream's raw threads end to end, rotating which one. I'm not checking the work, I'm calibrating the compressor, and the value is in noticing what got smoothed rather than in the content itself. The second is changing what I ask for. Asking a pipeline for status gets you smoothed status. Asking it for anomalies, contradictions between sources, and what would embarrass us in two weeks gets you something closer to useful, and any synthesised claim needs to link back to its raw source or you can't validate it at all.

If you're deploying AI summarisation across an organisation and you don't account for this, you've automated the middle management layer you were trying to remove, at higher speed and with more confident output.

Someone has to own deletion

Every mechanism in this piece regenerates. Rules accumulate, layers reappear, committees reconstitute, and the principles decay by default. Which means somewhere in the structure there has to be standing authority to remove things, layers, rules, processes and headcount, that doesn't have to justify each individual deletion as a special event requiring a business case.

Almost nobody builds this. At founder-led companies the organ is the founder, which is why the playbook survives at founder-led companies and dies roughly one management generation after the founder leaves. Amazon's attempt to institutionalise it is ideology plus mechanism, Day 1 as a stated belief alongside bar raisers and memo culture, which is an attempt to make the founder's immune system outlive the founder. The jury is still out on whether that works over a generation.

The strongest version of the argument is that the hard problem in organisational design isn't design at all, it's maintenance. Designing a fast organisation is a weekend of thinking. Keeping one fast is a permanent job that nobody's title says they have.

Where this argument is weak

An article that only celebrates the fast companies reads as hagiography, so the honest tensions are worth stating.

Survivorship bias is the obvious one. Amazon and SpaceX are the survivors of a large cohort that ran the same playbook, and we don't get to interview the fast companies that broke themselves. The playbook might be necessary without being sufficient, or it might be correlated with something else entirely.

The human cost is real. Both organisations burn people at a rate most companies can't sustain and arguably shouldn't try to.

Founder legitimacy is the hidden variable and the most interesting open question in the whole argument. How much of this is load-bearing principle, and how much is simply a founder having enough legitimacy to override the blame-avoidance instinct that would sink a hired executive doing exactly the same thing? A CEO who owns forty percent of the company can absorb a visible failure in a way that a divisional VP cannot, and the principles might be downstream of that rather than independent of it.

Some slowness is correct, and I'd rather say that plainly than pretend otherwise. A nuclear regulator optimising for decision velocity is a horror story, and I've written before about the genuine constraints in regulated industries, which don't disappear because they're inconvenient. The ruin constraint in the model is real. The argument is about where it binds, not whether it exists, and the failure at Visa wasn't that controls existed, it was that the control regime designed for the payment rails was applied uniformly to everything including work that couldn't have broken anything.

Consensus has a defence too. It buys commitment, and commitment affects execution speed even when it costs decision speed, so a fast decision that nobody implements isn't fast. The counter I'd offer is that commitment obtained by dilution isn't commitment, it's the absence of objection, and those behave very differently under pressure.

What I'd do first

If you're inside a slow organisation and you have some latitude, the sequencing matters more than the ambition.

Count the decisions for a month and note the level each one was made at, because you can't argue with the number and it will tell you where latency is accumulating. Read the promotion criteria and the last two years of actual promotions, since that's the real objective function and any change that contradicts it will be quietly undone.

Run a kill review before you hire anyone. Rank every workstream and every system honestly and ask whether the bottom fifth should exist at all, because workstreams get opened and almost never get closed, and consolidating systems is a form of deletion. Hiring into an unpruned portfolio just raises the coordination cost of work that shouldn't be happening.

Then take one steering committee, move its status reporting into a written pre-read, and see whether the meeting still has a reason to exist. That's a small enough change that nobody will fight you over it, and it's a fair test of whether the rest of this is going to be possible where you are.