The Solution Looked Simple. The Landscape Got Harder.
Are you simplifying or complicating?
Someone presents you a solution. It solves the problem in front of you. The demo is clean, the logic sounds reasonable, and the timeline seems manageable. You approve it.
Six months later, the problem is technically gone. But something else has shifted. There are more handoffs. More exceptions. More places where the system breaks down quietly instead of loudly. The landscape is harder to navigate than it was before.
This happens more often than people admit. And it usually isn’t because the solution was bad. It’s because no one asked the right question before approving it.
The question is not: does this solve the problem? The question is: does this simplify or complicate the overall landscape?
Those are not the same thing.
A simplifying solution eliminates. It removes steps, removes dependencies, removes the need for workarounds that accumulated over time. A complicating solution substitutes — it replaces one problem with a new process designed to manage that problem.
The classic example is a train system struggling with long journey times. One response is to invest in faster trains — you address the root cause, the journey gets shorter, the problem is gone. Another response is to install entertainment screens in every carriage — the journey time doesn’t change, but passengers are distracted from noticing. Both solutions get approved. Only one simplifies the landscape. The other adds infrastructure to manage a problem that still exists.
Most technology solutions in organisations work the same way. A new approval workflow gets built because the old one was unreliable — but no one asks why the old one was unreliable, or whether approval at that point is even necessary. A reporting tool gets added because the ERP isn’t surfacing the right data — but no one asks why the ERP isn’t configured to surface it. The original problem becomes the reason for a new layer. The new layer becomes part of the landscape. The landscape gets harder.
A simplifying solution is principle-based, not preference-based. This is harder to see in the moment, but it matters. Preferences produce solutions that work for the person proposing them — for their team, their current workaround, their comfort with a particular tool. Principles produce solutions that would work regardless of who was in the room. When you find yourself approving something because it suits the people presenting it rather than because it structurally makes sense, that’s worth pausing on.
A simplifying solution is end-to-end, not point-fix. Point-fixes feel satisfying because they close a ticket. But a fix that resolves one node in a process while leaving the surrounding process untouched often creates pressure elsewhere. The pain moves rather than disappears. A solution that genuinely simplifies traces the problem back to its origin and addresses it there — which means the change is visible across the whole process, not just at the place where the symptom surfaced.
A simplifying solution is architecturally coherent. This doesn’t mean it requires a full architecture review before anything gets done. It means the solution fits logically into the structure that already exists — or deliberately changes that structure in a way that’s acknowledged and planned for. When a solution requires carving out an exception, building a bridge to something that wasn’t designed to connect, or adding a manual step to compensate for a gap — those are signals that the solution is complicating, not simplifying, even if the immediate problem disappears.
A simplifying solution is natural to operate. Solutions that require people to change their behaviour dramatically, remember new sequences, or work against their instincts tend to be abandoned or worked around. Not because people are resistant, but because the solution was designed around a system’s logic rather than a human’s. A simpler landscape is one where people do less to achieve more — where the obvious path is also the correct path.
None of this means every solution needs to be elegant. Some problems are genuinely complex and the solutions will carry that complexity. But there’s a difference between necessary complexity and accumulated complexity. One is the cost of the problem. The other is the cost of not asking the right question before you approved the last ten solutions.
The question is worth asking every time: are we simplifying the landscape, or are we adding another layer to manage what’s already there?
