Bo Frese
Once I've worked inside an organisation long enough to understand what it's trying to do, what problem it solves and what value it delivers to its users, I often catch myself thinking an uncomfortable thought.
What are all these people doing?
I don't mean that cynically. Everyone is busy, and most of them work hard. But if the system had been kept clean, with the architecture updated as the requirements changed and the processes kept to what they really need, my honest guess is that a third of the people could do the same work. The product would be better, the decisions faster and the code more coherent.
Sooner or later I usually share that observation, together with stories of high-performing teams I've worked with, where small groups built and maintained complex products, made decisions quickly, took the consequences, refactored all the time and kept things lean. The reply is almost always the same:
"That only works for small products. We're different. We're a large organisation with a complex product."
It's said with conviction, sometimes with pride, as if scale itself were the explanation. To me, that reply is the problem.
Complexity is what kills
Fred Brooks made a distinction in No Silver Bullet that I find more useful every year. Essential complexity is in the problem itself. Accidental complexity is everything we add on top of it. Your domain may well be complex, and payments, healthcare, logistics and telecom really are hard. I'm not arguing with that. But in my experience most of the complexity in a large organisation is the accidental kind, and that is what slowly kills both the organisation and its products.
It rarely stays in one place. A complex organisation finds it hard to move and hard to make good decisions. It tends to produce complex products, or a complex portfolio of products, and it tends to build them in ways that are complex and hard to maintain. Each layer feeds the next. The code mirrors the architecture, the architecture mirrors the organisation, and the organisation grows to handle the complexity of the code.
Large doesn't have to mean complex
When Facebook bought Instagram for a billion dollars, Instagram had 13 employees. When it bought WhatsApp for 19 billion, WhatsApp had around 55, serving roughly 450 million users. Neither product was simple. They were built by small teams that kept fighting accidental complexity, and that is why they could stay small.
John Gall put it like this in Systemantics: "A complex system that works is invariably found to have evolved from a simple system that worked." Large organisations and systems that work have grown from small ones that worked. They grew that way because the people involved kept fighting complexity at every level, in the product, the architecture, the code and the organisation. When that fight stops, the complexity starts to win.
The self-reinforcing trap
No single bad decision makes a large organisation complex. Many sensible local decisions do, and then the system starts reinforcing itself.
- Developers are rewarded for shipping features. That creates lots of functionality with declining quality, poor quality takes more people to maintain, and more people make the work feel important.
- Managers are often measured by the size of their team and budget. That favours systems that need many people to run, many people need coordination, and coordination needs more managers.
- Architects are recognised for sophisticated designs. Complex solutions need specialised teams, and specialisation makes the work feel advanced.
None of this is bad intent. Everyone is responding sensibly to how they're measured. Conway's Law says organisations build systems that mirror their structure. The deeper trap is that those systems then reinforce the behaviour that created them, so complexity breeds more complexity, and the people inside are rewarded for making it worse.
Why it's so hard to get out
Once you're caught in the trap, getting out can seem almost impossible. There's a line usually attributed to Einstein: you can't solve a problem with the same level of thinking that created it. Improvement programmes are designed by the same organisation, with the same structure, incentives and assumptions that created the complexity in the first place, so the fixes tend to add a layer instead of removing one.
That's why we keep seeing the same pattern. A large, complex organisation slowly loses ground, until a startup does the same thing with a tenth of the resources. The startup isn't smarter. It just never built up the complexity.
Step one: imagine the startup that beats you
The cheapest way to start thinking differently is a thought experiment:
If you had to build a competitive version of your product from scratch, for the same market and the same users, with a tenth of your current team, what would it look like?
This isn't a one-hour meeting squeezed into a busy schedule, or a one-day workshop. To get real value from it, get the right people off-site, undisturbed, for a few weeks, and let them work it through. That costs very little compared to what's at stake. And even if you never build anything afterwards, it brings new thinking, ideas and energy into the organisation. People get to look at the existing system with fresh eyes, often for the first time in years.
Who you put in the room decides the quality of the answer. You need people who understand what users need, the real problem and not just the roadmap. You need engineers with strong technical judgement who aren't attached to the current architecture. And you need some of the people who have been there longest. Not to defend the status quo, but because they carry the memory of why things are the way they are: the edge cases, and the decisions made under pressure ten years ago that are still in the code. That knowledge tells you what really needs to stay and what can safely go.
Set the constraints: start from first principles, ignore existing technical decisions, challenge every assumption about what the system needs to do, and focus only on what users value.
Then look at what the exercise reveals about what you've built.
Step two: build it yourself
If the exercise shows that a much simpler version is possible, the next question is uncomfortable. Why wait for someone else to build it? You can be that startup yourself, inside your own organisation.
It needs a small team with its own decision rights, permission to compete with your existing product, and protection from the rest of the organisation. Without that protection, the existing organisation will, with the best intentions, pull it back into the same structures, processes and priorities, and it stops being a startup. It also needs to start small. Gall's Law works in both directions: a complex replacement designed from scratch rarely works either, so start with a simple system that works and let it grow.
The hardest part: keeping the engine running
The hardest problem isn't designing the simpler system. It's moving from the complex setup you have today to a simpler one, while the engine keeps running and your users stay happy. You can't stop the business for two years while you rebuild, and big-bang replacements have a poor track record. I think this is the hardest problem any organisation faces, and it's why so few of them even try.
There is no easy answer, but there is a direction. Let the new thing start with a few users or one part of the business, and grow it while the old system keeps running. Martin Fowler calls this the strangler fig pattern: the new system grows around the old one and takes over piece by piece, until one day the old one can be switched off. It works for organisations as well as for code. It's slow, it takes patience from leadership, and it means running two worlds side by side for a while. But it keeps the users happy along the way, and that's what makes it possible at all.
Somewhere, a small team is probably already working on a simpler version of what you do. Would you rather it was yours?