Unnecessary complexity is an occupational disease in IT. Every time I've cleaned up an old system, what I've found underneath is a solution that could have been half the size, half the price and twice as clear. And yet the complex version is what got built.
It usually isn't malice. It's five things that are more human than we'd like to admit.
1. "We don't quite know what we're doing, but we can't say that out loud"
When nobody really knows how a problem should be solved, the safest move is to build something that looks like someone knew. Layered architecture. Microservices. An event bus. Layer upon layer, each one justifiable with its own diagram.
The end result is a system no one understands as a whole — but every piece of which is "best practice." A simple implementation would have exposed the fact that the builders didn't really know what problem they were solving. A complex implementation hides it.
Uncertainty gets dressed up in structure. It costs more in the long run than someone simply saying "we don't know yet — let's build something small and see."
2. Complexity is budget currency
When you want more headcount, more licenses or more consulting hours, you need a justification. A simple solution doesn't look like a justification. A complex one does.
A board presentation about installing two Postfix servers gets no one excited. A presentation about a "strategic email platform" with monitoring, high-availability redundancy, certificate management and "scalability for future needs" does. Both do the same thing. One costs ten times more.
This doesn't mean all budget justifications are dishonest. It just means the industry has noticed that complexity sells more easily than simplicity in budget meetings. It's an incentive, and people respond to incentives.
3. Complexity is job insurance
If you're the only person who understands how a system works, you can't be fired. It's an ugly truth that few say out loud — but the phenomenon is so common there's even a term for it: bus factor, meaning how many people can get hit by a bus before the project collapses.
Nobody sets out to design a system as job insurance. But when the choice is between a clear, documented solution and "my own special implementation," plenty of people half-consciously choose the latter. Documentation gets postponed. The code lives only in one person's head. "Ask me, I know how it works."
That's understandable at the individual level. At the company level it's a risk that gets paid for sooner or later.
4. Vendor math rewards complexity
If a vendor is paid by the hour, the longest path is also the most profitable. If a vendor is paid by license, the biggest license bundle is the most profitable. If a vendor is paid for maintenance, a complex system is a better revenue source than a simple one.
This doesn't mean vendors are dishonest. It means their incentives point in a different direction than the customer's interest. I wrote a concrete example of this earlier: IBM quoted 150 hours, a Postfix relay solved the same problem in 15. The difference wasn't expertise — it was the motivation to look for the shortest path.
When hours are the currency, the longest road has the most currency on it.
5. "Best practice" culture without context
Google, Netflix, Amazon and Meta publish their architectures. They're interesting. They're worth learning from. And they were built for problems that a ten-person Finnish SMB does not have.
I've still seen, more than once, a 20-person company running a Kubernetes cluster, a service mesh, three environments, and a CI/CD pipeline building 40 microservices. Underneath it is two PHP applications and one MySQL database that would have fit on a single virtual machine.
"Best practice" without context means "we copied someone else's solution to someone else's problem and applied it to a problem we don't have." It's cult behavior that costs money and time but feels safe, because "everyone does it that way."
Why this matters
Complexity isn't just expensive. It's a source of slow learning. The more moving parts a system has, the harder it is to figure out where something broke. The harder it is to onboard a new employee. The harder it is to change anything when the business changes.
A simple solution is overwhelmingly more valuable than a complex solution to the same problem. It just doesn't sell as well, because it doesn't look like "something was done." But it's the one that still works five years later without anyone having to re-explain it.
What to take away
When someone presents you with a complex solution, always ask: what's the simplest form of this that would still work? If the answer is "it wouldn't work, because..." then listen carefully and weigh the reasoning. If the reasons are theoretical — "future scalability," "possible new requirements," "flexibility for change" — you are probably looking at complexity that does not serve your actual problems.
Simplicity isn't laziness. It's tighter thinking. It's a decision not to build what isn't needed. It takes courage to say "we don't need this" even when someone is offering it to you.
And if, from the inside, nobody can or dares to make that call, an outside set of eyes is usually the best way to get started.
Is there something in your IT environment that feels more complex than it ought to be? Digital Renovation starts by looking at it again and taking apart what can be taken apart. Project Guardian is the same idea as a continuous service: an outside perspective that stops complexity from creeping back in.