Every few years, IEEE Spectrum publishes another autopsy of catastrophic IT failures1. The latest tallies $2+ trillion in annual US software failure costs alone. The case studies are grimly familiar.
Canada's Phoenix payroll system ballooned from CA$310M to $5.1B while leaving 70% of federal employees with pay errors. The UK Post Office's Horizon system sent innocent people to prison while leadership covered up bugs they knew existed.
I've worked in organisations that would've made the list if anyone had bothered to write them up.
Retrospectives that go nowhere
Projects go off the rails. There's a crunch. Then a retrospective asking "what can devs do differently?" — never management.
I've sat in those retrospectives. The ones where everyone knows what went wrong — the scope changed three times, the deadline was set before requirements existed, someone added a manager to "help coordinate" and suddenly you're spending more time in standups than writing code — but nobody says it because saying it means admitting the structure is the problem.
For how much power they have over team organisation and processes, middle management has nearly no accountability for outcomes. You'd save billions in spend and boost productivity massively if management were bare bones and held accountable like everyone else.
The management layer tax
Big projects don't fail because engineers can't code. They fail because every layer of management adds latency, diffuses accountability, and creates incentives misaligned with shipping working software.
The pattern is predictable:
Project gets budget. Budget justifies headcount. Headcount requires managers. Managers require process. Process requires meetings. Meetings require documentation. Documentation requires review cycles.
Somewhere in there, someone was supposed to be writing software.
Each layer exists to coordinate the layer below it. But coordination has costs: context gets lost in translation, decisions get delayed waiting for approval, and ownership dissolves into committee. When something breaks, there are enough people involved that no one is clearly responsible.
The Phoenix payroll system had 80,000 pay rules to implement. But the rules weren't the problem — the problem was an organisation where information flowed through so many layers that no one at the top understood what was actually happening at the bottom until it was too late.
Why small teams work
Small teams outperform large ones. Not because they have better engineers, but because they have:
- Short feedback loops. You ship something, you see the results.
- Clear ownership. When something breaks, everyone knows who's fixing it.
- Direct communication. No game of telephone through three layers of management.
Linear hit a $1.25B valuation with 100 employees and 2 PMs. No A/B tests. No growth dashboards. No sprint planning. No OKRs for ICs. Just small teams of designers and engineers who think like product people.
The product sells itself because it works. And it works because there's almost nothing between the people making decisions and the people writing code. Often they're the same people.
That's not an accident. That's the point.
The mistake isn't growing — it's how you grow
The lesson isn't that organisations should stay small forever. Some problems require scale.
The mistake is reaching for management layers before you need them. Adding a "director of engineering" when you have 8 engineers. Creating a "project management office" because two projects overlapped once. Hiring managers to manage managers before you've proven you even need the first layer.
Every layer you add is a bet that the coordination overhead is worth the coordination benefit. Most organisations lose that bet and don't even know it.
I wrote about this from a different angle in my post on workforce planning at Flowstate2. The problem most technology leaders face isn't that they don't know what's happening — it's that they've built systems where information has to travel through so many layers that knowing becomes impossible.
The answer isn't more managers. It's better visibility.
When you do need to scale beyond what a single team can do, the goal should be preserving small-team dynamics through tooling rather than managing complexity through hierarchy. Make information visible by default. Let teams own outcomes end-to-end. Empower engineering leaders to coordinate directly.
At Flowstate, that's what we're building — a way for organisations to maintain visibility without creating reporting hierarchies. To surface blockers without requiring status meetings. To keep leadership informed without making them bottlenecks.
The $2 trillion opportunity
Everyone knows what's wrong. Fixing it requires those with power to constrain themselves.
Middle management exists because it's the default. Because that's how it's always been done. Because big budgets feel like they need big teams and big teams feel like they need layers.
But the evidence is overwhelming. The organisations burning billions on failed projects have thousands of employees. The ones shipping products that work often have dozens.
The difference isn't talent. It's structure.
At some point we have to stop expecting different results.