Clarity creates momentum, but only if you do something with it.
By this point, the situation had shifted. What began as a vaguely understood issue, something people noticed but did not address, was now clearly defined:
A time-bound risk
Executive-backed priority
A non-negotiable outcome
We were no longer asking whether to act. We were asking:
How do we deliver this properly within the time we have?
The First Realisation: This Isn’t One Problem
‘Leadership is the capacity to translate vision into reality’ - Warren Bennis
There’s a tendency, when faced with something urgent, to treat it as a single piece of work: One issue, one solution, one plan. But that only works when the problem is simple. This wasn’t.
As we began to look more closely at the licence dependency, it became clear that we were not dealing with just one risk.
Instead, there was a network of dependencies spread across different systems, products, and operational processes.
Solving this took more than just effort, it required structure. This was about making the invisible visible.
The first step was to break the problem down into something we could actually work with. Not tasks, not technical components, but outcome-focused areas of work.
What emerged were five distinct streams:
Data access and retention
A customer-facing service relying on legacy functionality
A legacy product constrained by outdated technology.
A legacy intranet
Remote access to critical files
Each of these represented something slightly different:
Different stakeholders
Different levels of complexity
Different levels of risk
And importantly: Different paths to resolution.
Why This Step Matters More Than It Seems
At face value, this is a straightforward decomposition. But in practice, it does something much more important: it changes the nature of the work.
Instead of a single, overwhelming problem, we now had:
Clearly defined areas
Potential ownership points
And the ability to move multiple streams forward in parallel
This is where delivery shifts from reactive… to intentional.
From Workstreams to a Program
With the work broken down, the next step wasn’t to start delivering immediately, it was to properly frame the work.
Because how you frame work determines how it gets prioritised, resourced, and supported.
So this wasn’t positioned as:
A set of urgent fixes
Or a collection of technical tasks
It became a program of work.
That distinction matters.
Programs:
Create visibility at the right level.
Enable coordinated delivery across teams.
And signal importance to the organisation.
Most importantly, they create alignment of effort.
Gaining Momentum Through Sponsorship
Executive alignment had already been established. But alignment alone doesn’t drive delivery; momentum does. So the focus shifted quickly to:
Confirming sponsorship
Reinforcing urgency
And ensuring that this work was seen for what it was:
critical to maintaining business continuity
With that clarity, we had permission to move decisively.
Early Progress: Reducing the Problem Space
Before mobilising all five streams, we took a step back and asked:
Do all of these need to be solved in the same way?
Through collaboration between product and business teams, one of the streams was reassessed on its value to the business. Its dependency on the legacy environment wasn’t as fixed as initially assumed. There was an alternative. A workaround.
Not perfect, but viable, and … importantly, fast and endorsed by the users impacted.
That single decision reduced the program from five streams to four.
Why This Was More Than a Tactical Win
This wasn’t just about reducing workload. It demonstrated something critical:
Not every problem needs to be solved through engineering.
Sometimes, the fastest and most effective path comes through:
Reframing the requirement
Engaging the business differently
And being open to solutions that sit outside the original system.
It’s easy to default to ‘build’ or ‘fix’. It’s harder, but often more valuable, to ask: Is there another way to achieve the outcome?
Establishing Ownership
‘Good leaders organize and align people around what the team needs to do. Great leaders motivate and inspire people with why they’re doing it’ - Marillyn Hewson
With the program now defined and slightly reduced in scope, the next step was clear:
Ownership needed to be explicit.
Each stream required:
A delivery lead
A clear outcome
And a shared understanding of urgency
This wasn’t about assigning accountability in a top-down way, it was about ensuring that every part of the program had someone:
Thinking about it
Driving it forward
And surfacing risks early.
Because without that, even well-structured programs drift.
Creating Visibility (Again, But Differently)
As delivery began to take shape, visibility needed to evolve. The earlier “Now, Next, Later” view had helped establish understanding. Now, we needed something that supported execution.
So we introduced:
Regular check-ins with delivery leads
Structured reporting on progress, plans, and blockers
Clear visibility of how each stream was tracking against time
And importantly:
We made the work highly visible across the organisation, not hidden in delivery tools, not confined to status reports. Visible.
Because visibility does two things:
It drives accountability
And it invites support where it’s needed.
Resisting the Urge to Over-Engineer
At this point, it would have been easy to introduce heavier governance.
More reporting
More structure
More control
But that wasn’t what the situation needed. The timeline was tight, the work was complex, and the teams needed space to move.
So the approach stayed deliberately balanced:
Enough structure to provide clarity
Enough flexibility to allow delivery to adapt
If you are familiar with Agile practices, you know that effective delivery happens in the space between governance and autonomy.
Where Leadership Starts to Shift Again
With the program in motion, something subtle began to change. The problem was no longer abstract, the work was no longer theoretical, it had become:
Real
Visible
And shared
And that’s the point where leadership shifts again: from defining the problem… to enabling the people who will solve it.
A Thought to Leave You With
Breaking a complex problem into parts is a familiar concept, but doing it well, especially under time pressure and with real consequences, takes more than just technique. It requires judgment.
How you define the work shapes everything that follows:
Who owns it
How it’s delivered
And whether it succeeds
Structure doesn’t slow delivery, the right structure makes it possible