Simplicity Is Not Simple
Few of us are born with it. For most of us, simplicity is not a trait — it’s a discipline we have to practise.
I see this most clearly in transformation programs. Everyone says they want simplicity. Almost no one is willing to do what simplicity actually requires.
Simplicity starts with hard questions, not clever answers. Why does this matter? Why should we bother? Why is more not what we actually want? Most transformation programs skip these questions entirely. They default to big, to more, to expansion — another module, another integration, another custom workflow built to protect an exception nobody can name — and call it progress.
That’s not simplicity. But the opposite isn’t simplicity either. Cutting scope to save budget, stripping features to hit a deadline, going cheap because the business case is under pressure — that’s contraction, not simplicity. Your board might approve it. It still isn’t the thing you’re claiming it is. I’ve watched programs “simplify” by cutting training, cutting testing, cutting the change management no one wanted to pay for — and call the resulting mess lean.
Real simplicity has to be earned. It’s earned by saying no — repeatedly, specifically, to things that don’t matter, so you can stay with the things that do. I’ve sat in enough steering committees to know how rare this is. Saying yes to the new requirement feels like progress. Saying no to it, and explaining why, feels like conflict. Most sponsors choose the feeling of progress and pay for it eighteen months later, in a system nobody can maintain.
Underneath the “no” is a discipline most transformation teams never build: understanding cause and effect. Simplicity is elimination over fixing. It’s asking why a process exists before automating it, rather than automating the workaround along with the process. It’s understanding what actually depends on the thing you’re about to remove — and honouring that dependency, instead of discovering it three months after go-live, when the report nobody remembered feeding suddenly comes up empty.
That last part is the one executives underestimate most. Every system, every process, every spreadsheet in your organisation has dependencies that were never documented, only inherited. Simplifying without understanding them isn’t simplicity — it’s risk wearing a better outfit.
And even done well, simplicity doesn’t produce something perfect. It produces something honest. Accepting imperfection — and continuing to refine the craft and the output rather than declaring it finished at go-live — is part of the discipline, not a failure of it. The programs I’ve watched hold up long-term aren’t the ones that got everything right on day one. They’re the ones where someone stayed accountable to the outcome after the deadline had already passed.
It’s one of the most complex and simple skills there is to learn. Complex, because it asks you to hold cause and effect, dependency, and discipline all at once. Simple, because at the centre of it is just one word most of us find very hard to say.
What’s the last “no” your transformation program needed — and didn’t get?
