Transformation gets a lot of attention – new systems, new platforms, new initiatives — it all creates a sense of progress. It’s visible, easy to explain, and gives people something concrete to point to.
Simplification doesn’t work like that.
From what I have seen, simplification is usually the harder problem — and the one that matters more.
Transformation is about adding. There’s momentum behind it, and it’s relatively straightforward to get buy-in because it feels like forward movement.
Simplification is the opposite. You’re taking things away. And that’s where it becomes uncomfortable.
You’re not just dealing with systems — you’re dealing with history. Every layer was put there for a reason at some point in the past. Every system has an owner. Every process has context. So even when something no longer makes sense, removing it is rarely straightforward.
What looks simple on paper usually isn’t. You start pulling at something and quickly realise how much sits behind it.
My view on this is that most complexity isn’t designed — it’s accumulated. And once it’s there, removing it is far harder than adding something new on top.
Another thing I’ve seen is that less experienced teams naturally default to adding rather than removing. They focus on what’s in front of them and what needs to be delivered next. The instinct is to build.
What takes time is learning to step back and ask a different question — what doesn’t need to be here at all?
That shift in thinking is where simplification actually starts.
From a CTO perspective, this is where most of the real work sits. Not in introducing something new, but in reducing what has built up and making the environment easier to operate.
Transformation adds.
Simplification removes.
Both are necessary. But from what I have seen, only one of them really determines whether things work in the long run.