There is a particular discomfort that comes with looking at something you built — something that worked, something that people praised, something that had your name on it — and deciding that it is time to let it go. Not because it failed. But because the world has moved, and you must move with it.
I have been sitting with that discomfort lately. And in sitting with it, I have come to believe that the ability to self-disrupt is not just a leadership virtue — it is, fundamentally, an act of intellectual honesty.
The problem with solving problems
Most organisations I have observed — and I include my own in this — operate from what I would call a solution-oriented mentality. A pain point emerges. A team mobilises. A solution is built. The loop closes. We move on.
This is not inherently wrong. But it is incomplete. Because embedded in that loop is an assumption we rarely examine: that the problem we identified at the beginning is the same problem that still exists at the end — and that the solution we built will remain the right answer tomorrow.
What I am increasingly convinced of is that we need a more rigorous, more humble discipline for how we define problems in the first place. Before any solution is conceived, five questions deserve serious, uncomfortable attention:
Is this actually a problem? Not a symptom. Not a preference dressed up as a need. An actual, validated problem.
Does the proposed solution genuinely address the requirement — or does it address what we assumed the requirement to be?
Who does this serve? A single person, a department, the whole organisation — or does it have the potential to scale to industry-wide relevance? Defining scope is not a bureaucratic exercise. It is a strategic one.
What is the solution's functional scope, and what does its deployment realistically look like?
Does it actually address the ask — not in theory, but in practice, at the ground level where real people interact with it?
A problem correctly defined is a problem half solved. A problem incorrectly defined is an infinite loop of activity mistaken for progress.
The dimension we almost always miss: time
Even when organisations ask these five questions well, there is a dimension that gets systematically underweighted: time. Problems are not static. They breathe. They evolve in response to internal shifts — new leadership, changing priorities, growing teams — and in response to the world outside — technology disruptions, regulatory changes, industry inflection points.
A solution built for a problem as it existed two years ago may be solving for a reality that no longer exists. And the danger is not just irrelevance. The danger is that we continue investing in the maintenance and defence of that solution, consuming resources and attention that could be pointed at what the problem has become today.
This is where agility must be understood not just as a process methodology, but as a cognitive discipline. The question is not only "how fast can we build?" It is "how honestly can we look at what we have built and ask whether it still deserves to exist?"
A personal example — and a reckoning
In 2022, I built and led the creation of an Automation Framework — a system of templatised, automated capabilities that represented, at the time, a meaningful step forward for our organisation. It was the first of its kind in our context. It was rigorously validated. It was a genuine innovation, and I say that not with pride but with the intention of being honest about what it was at the moment it was created.
It solved a real problem. It addressed a genuine requirement. It had meaningful scope. By every measure I would now use to evaluate whether something deserves to be built — it deserved to be built. In 2022.
Here is the reckoning: the world of 2024 and 2025 is not the world of 2022. The emergence and rapid maturation of Generative AI has fundamentally changed the landscape of what is possible — and more importantly, what is necessary. The templatised, scripted approach that the framework was built on has been disrupted not by a competitor, not by a market shift, but by a categorical change in technology capability.
Today, templates that once needed to be painstakingly constructed — whether automation scripts, infrastructure-as-code configurations like Terraform, or compliance-driven documentation — can be generated on-the-fly, contextually, with far greater flexibility and speed than any templatised framework allows.
Innovation is not always about building something new. Sometimes it is about having the courage to dismantle something you built — and building what the next era actually needs.
From solution orientation to serving orientation
What I am moving toward — and what I believe is the more mature operating model — is what I call a serving mentality. The distinction sounds subtle but is, in practice, profound.
A solution-oriented mindset asks: what can we build that solves this problem? A serving mentality asks: what does this person, this team, this organisation actually need — and what is the most honest, most current answer to that need?
In practice, for us, this means transitioning away from a framework built on predefined templates toward a system centred on a living, governed knowledge base. Core stakeholders — the domain experts who understand standards, compliance requirements, regulatory frameworks, and organisational best practices — become the stewards of a structured knowledge repository.
AI, rather than generating from templates, draws from that knowledge base to serve the real-time needs of the people interacting with it. The result is not a static solution. It is a responsive, adaptive service — one that improves as the knowledge it draws from improves, one that scales naturally as new domains are added, and one that does not require a framework rebuild every time the underlying technology evolves.
What self-disruption actually demands
I want to be clear that what I am describing is not easy, and it should not be made to sound easy. Self-disruption — the deliberate dismantling of something you built, in order to make space for something better — requires a specific kind of psychological and organisational maturity.
It requires the willingness to separate your identity from your output. The framework was something I built. It is not me. Its obsolescence is not my failure — it is, if anything, evidence that the context around it changed faster than anyone anticipated, which is precisely the kind of environment that demands adaptive thinking.
It requires a culture where the honest answer is valued over the comfortable answer. Real innovation includes the discipline to acknowledge when the previous innovation has served its purpose.
And it requires a willingness to ask the five questions I outlined at the beginning — not once, at the moment of inception, but continuously, as a living practice of organisational metacognition.
The invitation
I am sharing this because I suspect I am not alone in this position. Many leaders and builders are sitting with tools, frameworks, systems, and processes that were right when they were created — and are now quietly misaligned with the moment we are in.
The question worth sitting with is not "should I defend what I built?" The question is "does what I built still serve — and if not, what does serving actually look like now?"
That is a harder question. It is also a more honest one. And I believe it is the question that separates leaders who build for legacy from leaders who build for impact.