When I've been working inside an organisation long enough to understand what they're actually trying to do — what problem they're solving, what value they're delivering to users — I often find myself with a specific, uncomfortable thought.
What are all these people doing?
Not cynically. Genuinely. If the system had been kept clean — architecture updated as requirements changed, processes stripped back to what they actually need — a third of the people could do the same work. The product would be better. The decisions faster. The code more coherent.
When I share this observation — and I usually do, eventually — and when I tell stories of high-performing teams I've worked with, where small groups built and maintained complex products efficiently, making decisions quickly and taking the consequences, refactoring constantly, keeping 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.
That reply is exactly what I'm talking about.
Large ≠ complex
There's a conflation running through almost every large organisation I've worked with: the belief that a large or complex product requires a large and complex organisation.
It doesn't.
A product can be genuinely complex — serving millions of users, spanning multiple platforms, handling sensitive data, integrating dozens of systems — and still be built and maintained by a lean, focused team with a clean architecture and clear ownership. I've seen it. I've worked in it.
What creates organisational complexity isn't the product. It's the accumulated weight of decisions — about structure, processes, tooling, governance — each locally sensible at the time, but collectively creating a system nobody designed and nobody would choose if they were starting from scratch.
The self-reinforcing trap
Large organisations don't become complex through a single bad decision. They become complex through many locally sensible decisions that collectively create a system nobody intended.
- Developers get rewarded for shipping features. This creates lots of functionality with declining quality. Poor quality requires more people to maintain. More people makes the work feel significant.
- Managers gain status from team size and budget. This drives systems that need armies to operate. Armies create coordination overhead. Overhead requires more managers.
- Architects earn recognition for sophisticated designs. Complex solutions need specialised teams. Specialisation makes the work feel advanced.
Conway's Law says organisations build systems that mirror their structure. The deeper trap is that these systems then reinforce the behaviours that created them. Complexity breeds more complexity. Everyone gets rewarded for making it worse.
"You don't understand our scale."
First principles
The way out isn't to manage the complexity better. It's to question whether it should exist at all.
Not "how can we do this better?" but "why does this exist?"
Start from what the product actually does for users. What problem does it solve? What does it need to do — and what does it not need to do? What would the simplest architecture look like that could do exactly that, and no more?
This is harder than it sounds. It requires making real choices: cutting features, restructuring teams, admitting that certain things were built for internal reasons rather than user value. It requires telling people that their work doesn't need to exist in its current form.
Most organisations don't do this — not because they can't see the complexity, but because the system that created it also makes it politically expensive to remove.
An exercise worth taking seriously
The question is simple: if you had to build a competitive version of your product from scratch — same market, same users — with a team one-tenth your current size, what would it look like?
But this isn't a one-hour meeting squeezed into a busy schedule. It's not a one-day workshop. To get real value from it, you need to take it seriously — get the right people off-site, undisturbed, for a few weeks, and let them actually work through it. The investment sounds significant. It is. It might also be the most valuable thing you do this year for the future of your product and your organisation.
Who you put in the room determines the quality of the answer. You need people who understand what users genuinely need — not the roadmap, but the actual problem being solved. You need engineers with strong technical judgment who aren't attached to the current architecture; people who can look at the existing system with honest eyes. And you need at least some of the people who have been there longest — not to defend the status quo, but because they carry the institutional memory of why things are the way they are. The edge cases. The decisions made under pressure a decade ago that are still embedded in the code. That knowledge is what tells you what genuinely needs to be kept, 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. Focus only on what users genuinely value.
Then ask: what does that exercise reveal about what you've built? And do you have the courage to act on it?
What actually threatens you
Your real competitors are often not other large enterprises with the same problems. They're smaller organisations that never created those problems — teams that built lean because they had to, discovered it was actually faster, and kept going.
They don't have coordination overhead because they don't need it. They don't have architectural complexity because they didn't let it accumulate. They can make a decision on Tuesday and ship it on Thursday.
The question isn't whether you can "do agile at your scale." The question is whether you can simplify your product, architecture, and organisation enough to move at a pace that doesn't require your complexity to be justified.
Organisations that thrive are those that can build simple solutions to complex problems, eliminate unnecessary work rather than optimise it, and make decisions quickly with small, empowered teams where technical and business understanding live in the same room.
That's not a technology problem. It's a leadership decision about what kind of organisation you want to be.