There are moments in life that don’t mean very much when they happen.

Words people say in passing.
Stories half told.
Places you leave behind without really understanding what they meant to you.

And then one day, decades later, those same moments return carrying an entirely different weight.

For me, one of those moments happened around thirty years ago when I was leaving the UK for Australia.

Our family friends said to me:

“Never forget where you came from.”

At the time, I smiled politely, probably nodded, and carried on packing my bags.

I don’t think I understood those words at all.

I do now.

I was born in England, but when I was seven years old my family moved to a small village in North Wales, near Snowdonia, to be closer to my maternal grandmother.

It was beautiful. Rugged hillsides, slate-grey skies, winding roads, old stone buildings and a sense of history that seemed embedded in the landscape itself.

But it was also a culture shock.

I didn’t speak a word of Welsh when we arrived and, in that region, Welsh wasn’t just a language — it was identity, history, resistance and belonging. In some shops and among older members of the community, Welsh was spoken almost exclusively. At school, some lessons were taught in Welsh and, as a child arriving from England, I became very aware very quickly that I was “other”.

At seven years old, you don’t have the language to explain exclusion or cultural tension. You just know how it feels.

You know what it’s like to walk into a room and not understand what’s being said.
You know what it’s like to stand out.
You know what it’s like to desperately want to fit in.

Over time, I learned the language. By high school, I could understand and speak Welsh reasonably well. But high school introduced an entirely different layer of complexity.

This was during a period where Welsh nationalism felt particularly heightened in parts of North Wales. There were tensions around identity, language, land ownership and the growing number of “holiday cottages” owned by people outside the local community. Some extremist factions responded aggressively and, in nearby areas, holiday homes were being targeted and burned.

As a teenager, it was frightening.

At school, the divisions often felt visible and tangible. I remember playgrounds that felt split down invisible lines — Welsh on one side, English on the other. There were fights, insults and hostility that no teenager really has the emotional tools to process properly.

“English go home” was something we heard often.

The irony was that many of us hadn’t chosen to be there in the first place. Our parents had made those decisions for us. We were just trying to survive adolescence while carrying labels we didn’t fully understand.

Oddly enough, my closest friendship during that time crossed those invisible boundaries entirely.

She was Welsh first-language.
I was English first-language.

Both of us already sat slightly outside the social structures of the school for different reasons and somehow that created common ground. While other kids seemed determined to pick sides, we mostly just tried to stay invisible.

That feeling — of existing between worlds without fully belonging to either — followed me for a very long time.

When I moved to Australia in my twenties, the feeling returned all over again.

Not because of language this time, but because of culture.

Australians, broadly speaking, didn’t seem particularly concerned with where you came from. At least not in the overt ways I’d experienced growing up. But beneath the surface, it was impossible not to notice undertones of racial tension and intolerance, particularly directed towards Aboriginal and Torres Strait Islander peoples.

Coming from a country with its own deeply complicated history around migration, identity and racism, I recognised some familiar patterns.

And it saddened me.

Earlier in my career, I had the opportunity to spend significant time living and working in the Northern Territory. It remains one of the most culturally rich and fascinating parts of Australia I’ve experienced.

What surprised me most was not the landscape or the remoteness.

It was the feeling.

For reasons I couldn’t properly explain at the time, I felt something there that I hadn’t felt in many other places in my life:

Connection.

Not ownership.
Not entitlement.
Just connection.

A sense of place.
A sense of history.
A sense that culture mattered.

I didn’t fully understand why it resonated with me so deeply.

Not then, anyway.

Years later, mostly out of curiosity and for a bit of fun, I completed an Ancestry DNA test.

The results came back overwhelmingly Welsh and Celtic.

Not vaguely.
Not partially.

Deeply and unmistakably tied to the very region around Snowdonia where I had spent much of my childhood feeling like I didn’t belong.

I remember staring at the results with a strange sense of disbelief.

All those years of feeling disconnected from the place… and my family history had roots there all along.

Nobody had ever really spoken about it in any meaningful way.

And yet, in hindsight, there had been fragments.

My mum once told me stories about my great-grandfather working in the Clogau gold mine — the same mine famous for supplying gold to the Royal Family. I remembered attending my Uncle Elwyn’s funeral in a tiny family-owned church nestled into the hillside. I remembered names, stories and places that suddenly carried more significance than they ever had before.

It felt like discovering pieces of myself long after I’d already become an adult.

And strangely, it also came with grief.

Not dramatic grief.
Not catastrophic grief.

Just the quiet sadness of wondering how life might have felt differently if I had understood those connections earlier.

If somebody had helped me see culture not as division, but as inheritance.
As belonging.
As continuity.

These days, I think differently about identity than I once did.

I think about language preservation.
About local communities trying to hold onto culture.
About the deep emotional connection people have to place and history.

Welsh is considered a vulnerable language. Communities in parts of Wales continue fighting to keep younger generations in local areas as housing affordability and outside ownership reshape entire regions.

And perhaps because of my own experiences — both in Wales and later in Australia — I find myself feeling increasingly passionate about protecting culture, language and Indigenous identity wherever it exists.

Not because I believe cultures should isolate themselves from others.

But because once culture disappears, something irreplaceable disappears with it.

A world view.
A memory.
A connection between generations.

Gone.

Australia is home now.

My roots, my life and my future are here.

But for the first time in my life, I also understand that where we come from matters — even when we don’t yet understand why.

Maybe especially then.

And perhaps that’s why those words from thirty years ago finally make sense.

“Never forget where you came from.”

I won’t.

Discover → Diagnose → Frame → Mobilise → Enable → Stabilise & Learn

Phase 1: Discover

Step 1: Rapid Landscape Scan

Actions:

• Build an immediate, imperfect view of the environment

• Avoid waiting for complete artefacts

Inputs & Prompts:

• Conversations

• Existing boards/tools (if any)

• Observations

Outputs:

• Initial mental model of work and pressure points

Success Measures:

• You can describe ‘what’s happening’ without needing validation from reports

Step 2: Structured Leadership Conversations

Actions:

• Meet 1:1 with managers and delivery leads

• Use consistent questioning

Inputs & Prompts:

• Now / Next / Later

• Why it matters

• Timeframes

• Dependencies

• Risks

• Needs from leadership

Outputs:

• Pattern recognition across teams

Success Measures:

• Repeated themes and inconsistencies become visible

Phase 2: Diagnose

Step 3: Identify Weak Signals

Actions:

Look for:

• ‘Everyone knows’ issues

• Cross-team dependencies

• Time-bound risks

• Low ownership areas

Outputs:

• Candidate risks

Success Measures:

• You can articulate the issue clearly and confidently

Step 4: Validate and Deepen Understanding

Actions:

• Test assumptions

• Confirm scope and impact

• Identify affected systems, teams, and processes

Outputs:

• Defined problem statement

Success Measures:

• The issue moves from vague → specific

Phase 3: Frame

Step 5: Translate to Business Risk

Actions:
Reframe into:

• Continuity risk

• Customer impact

• Financial exposure

• Strategic misalignment

Outputs:

• Executive-ready narrative

Success Measures:

• Non-technical stakeholders immediately understand urgency

Step 6: Secure Sponsorship

Actions:

Present:

• Risk

• Timeline

• Options

• Consequences

Outputs:

• Priority endorsement

• Decision rights

• Organisational backing

Success Measures:

• Work is officially recognised and supported

Phase 4: Mobilise

Step 7: Decompose into Workstreams

Actions:

• Break problem into outcome-based streams

Outputs:

• Clear work packages

Success Measures:

• Work can be parallelised and assigned

Step 8: Reduce Scope Where Possible

Actions:

Identify:

• Workarounds

• Alternatives

• Redundant effort

Outputs:

• Reduced or simplified scope

Success Measures:

• Less work required without compromising outcomes

Step 9: Assign Ownership

Actions:

• Allocate a clear owner per stream

Outputs:

• Named accountability

Success Measures:

• No workstream is “floating”

Step 10: Establish Visibility

Actions:

• Create shared view (e.g. Now/Next/Later, program board)

Outputs:

• Transparent priorities and progress

Success Measures:

• Anyone can understand what matters quickly

Phase 5: Enable

Step 11: Tailor Delivery Approach

Actions:

Match method to work type:

• Agile

• Operational

• Project-based

• Hybrid

Outputs:

• Fit-for-purpose delivery model

Success Measures:

• Teams are not constrained by mismatched process

Step 12: Coach Leaders

Actions:

Support delivery leads in:

• Planning

• Decision-making

• Team enablement

• Escalation

Outputs:

• Improved leadership capability

Success Measures:

• Leaders adapt their style to suit the situation

Step 13: Enable Team Ownership

Actions:

Shift from:

• Task assignment → Problem ownership

Encourage:

• Self-organisation

• Collaboration

• Initiative

Outputs:

• Increased engagement and speed

Success Measures:

• Teams step forward without prompting

Step 14: Monitor Flow

Actions:

Track:

• Wait states

• Bottlenecks

• Handoffs

• Lag time

Outputs:

• Realistic delivery insights

Success Measures:

• Risks are identified early, not after delay

Phase 6 — Stabilise & Learn

Step 15: Adapt Scope

Actions:

• Shift to MVP where required

• Reprioritise based on constraints

Outputs:

• Achievable delivery plan

Success Measures:

• Outcomes delivered despite disruption

Step 16: Embed Learning

Actions:

• Capture:

  • Leadership shifts

  • Team behaviours

  • Delivery improvements

Outputs:

• Reusable capability

Success Measures:

• Organisation performs better next time

Subscribe now

When we got to the last phase of the program, the work looked very different from where we started. What had started as:

• An undefined risk

• With no clear ownership

• And no coordinated response

Had become:

• A structured program

• With aligned leadership

• And teams actively engaged in delivery.

But this is often when delivery feels most vulnerable. As momentum grows, so does the pressure. The real test then is: can you keep making progress when constraints begin to tighten?

Project 2: Where Structure Faced Reality

The second main focus, improving the legacy product, needed a different approach.

While Project 1 improved thanks to changes in team dynamics and self-organisation, this stream needed:

• Tighter coordination

• Clearer sequencing

• And more deliberate tracking

So we set up a focused delivery team. It was a small, dedicated group supported by:

• A Scrum Master who took on a project coordination role

• Close collaboration with the architecture

• And clear insight into both delivery tools and timeline planning. That wasn’t welcome.

We also supplemented Jira with MS Project to help everyone see the timeline more clearly. They immediately embraced. Many felt that adding more tools, especially MS Project, just meant extra work without much benefit. It was initially seen as:

• Extra work

• Duplicate effort

• Something was removed from the ‘real’ delivery.

But then things started to change.

What Became Visible

As the plan came together, we noticed a gap in effort. Not in capability. But in flow.

The team had estimated the work well but what hadn’t been fully accounted for were the delays between steps:

• A developer completes work… and it waits for testing

• Testing completes… and it waits for review

• Review completes… and it waits for deployment

Individually, these delays seemed minor. Collectively, they were significant.

Just as importantly, we didn’t see these delays until we started looking for them.

Why This Mattered

Without that visibility, we would have continued to:

• Track effort

• Monitor completion

• And assume progress

All while losing time in the spaces between. MS Project didn’t just show us a timeline, it revealed a pattern we hadn’t seen before: systemic delay that could have pushed delivery beyond the deadline.

Once we could see the problem, we could manage it. People’s view of the tool changed quickly after that. From overhead… to insight.

Adapting Under Pressure

Halfway through delivery, we faced another challenge. An unexpected period of extended leave within a small, specialised team. No immediate backfill. Limited alternatives.

This is the moment when delivery plans really get tested. But in real life.

And at that point, there are only a few options:

• Push harder

• Add pressure

• Or make adjustments

We chose to adapt.

Reframing Success

Instead of sticking to the original plan, we redefined success. Not in terms of features, but in terms of outcomes.

What was essential to maintain business continuity? What could be deferred? What constituted a viable, stable solution within the timeframe? This led to a clear decision:

Deliver a true MVP

Not as a compromise, but as a careful, intentional choice.

What This Made Possible

By narrowing focus:

• The team maintained momentum.

• The critical path remained intact, and our delivery stayed focused on what mattered mosted most.

At the same time, we worked closely with the business to:

• Reset expectations

• Agree on a phased continuation.

• And ensure ongoing development beyond the deadline.

This wasn’t about lowering standards. It was about making sure we achieved the right outcome.

The Outcome

By the time the license expired, the organisation was prepared.

• Critical dependencies had been addressed.

• Business continuity was maintained.

• Three streams were fully delivered.

• One continued with an agreed extension.

And perhaps most significantly, the organisation avoided having to renew an expensive license that offered little value.

But Delivery Was Only Part of the Story

It would be easy to judge success only by what we delivered. But that would miss the real changes that happened. Because, alongside delivery, our capabilities grew in the Teams

Across the program, we saw:

• Leaders are evolving their approach to managing and enabling teams.

• Teams stepping into ownership, rather than waiting for direction.

• Individuals found chances to lead, no matter their title.

• Increased collaboration across roles and disciplines

And importantly, people became more confident in the organisation’s ability to handle complex delivery.

What Changed in the Environment

The conditions we created, both on purpose and in response to needs, made a difference:

• Flexibility in how people worked

• Space for teams to self-organise

• Support for those willing to contribute more

• Early experimentation with new practices and approaches

These changes weren’t official transformations, but they were meaningful changes. Shifts.

What Changed for Me

Taking on the Acting CIO role in these circumstances could have turned out in many ways. Without visibility, without context, without a defined starting point.

But through experience, structured thinking, and by applying Agile principles in a practical way, we were able to surface risk early, align the organisation quickly, and deliver under pressure.

But what mattered most wasn’t just the outcome. It was the trust we built along the way. From peers, from teams, from leadership.

Returning to the Basics

Looking back, this wasn’t about following a specific framework.The alignment is clear:

• Visibility over assumption

• Outcomes over activity

• Flow over effort

• Ownership over awareness

• Adaptation over rigidity

None of these ideas is new, but when things get tough, they make the difference between movement… and progress, activity… and delivery

A Final Thought

Leadership is often tested when the way forward isn’t clear. No handover, no roadmap, no certainty, just a situation that needs clarity, decisions, and action.

In those moments, it’s easy to look for answers. But the real work is something different.

It’s about creating the conditions where the right answers can come up
quickly enough to matter.

Series Close

Leading Without a Map has been a reflection on a real experience, not a perfect one, but a practical example of what happens when:

• Ambiguity meets urgency

• Risk meets accountability

• And teams are given the space to step forward.

Subscribe now

At some stage in every project, structure alone just isn’t enough. You can have:

• Clear workstreams

• Defined ownership

• Executive alignment

• Visible progress

Yet, it can still feel like something is missing. That’s because delivery isn’t only about what gets done. It’s also about how the work gets done and who takes the initiative to make it happen. It started to show as the program moved from planning into execution.

Where the Real Work Lived

At this point, two streams became the main focus:

• The replacement of intranet content and functionality

• The uplift of a legacy product constrained by outdated technology

Both were time-bound. Both were complex. Both required more than straightforward execution. They needed coordination, decision-making, and a kind of adaptability that process alone can’t provide.

When One Problem Becomes Two.

At first, the intranet work seemed like a single stream. But it wasn’t. Very quickly, it revealed two distinct challenges:

• Content that could be migrated relatively cleanly

• Functionality tightly coupled to the legacy licence

Each required a different approach. So, we decided to do this without formal processes or extra bureaucracy, but with clear intention.

• Content migration became a structured, business-supported effort.

• Functional components required deeper technical delivery and coordination.

This empowered and enabled both streams move forward quickly, without one holding back the other.

There’s a simple but important lesson here: when the nature of the work changes, the way you deliver should change too.

Constraint That Became the Opportunity

Within the technical stream, there was an established way of working. It had changed over time, shaped by what worked in practice. Work was typically assigned, decisions about who did what sat largely with the delivery lead. With the pressure of this program, that approach would be limiting.

This wasn’t a situation where one leader could or should make all the decisions.

Shifting the Dynamic

Rather than bringing in a new framework or forcing a process change, we chose a more practical approach. Changed how problems were presented.

Instead of assigning tasks to individuals, we began presenting problems to the team, and then we paused.

That pause matters.

That pause gives space for something different to happen.

What Happened Next

At first, there’s always a moment of hesitation.

People are used to being directed, used to waiting, used to being told where to focus.

But when people had space and clear goals, something shifted:

People started stepping forward.

Not all at once and not in a perfectly coordinated way, but enough.

And then more.

From Task Ownership to Shared Ownership

What happened next wasn’t just a change in how work was assigned. It was a change in how the team saw the work itself.

• Problems became shared challenges, not assigned tasks.

• Work progressed in parallel, not in sequence.

• Individuals began to take ownership of outcomes, not just activities.

And with that, something else happened: Momentum.

The Emergence of Micro-Leadership

One of the most interesting outcomes was what I’d call micro-leadership.

Individuals who weren’t in formal leadership roles began to:

• Step into coordination

• Guide small pieces of work.

• Support others

• And make decisions within their domain.

Not because they were asked, but because the environment made it possible. it.

These moments are easy to miss unless you’re paying attention. But they matter.

Because they’re often where capability grows the fastest.

Watching these moments emerge has been, and will continue to be, one of the most rewarding highlights of my leadership career.

A Different Kind of Coaching

During this phase, my role wasn’t to direct; it was to enable it.

That meant working closely with managers to support how they approached the work.

This included:

• Coaching on project structure and flow

• Supporting decision-making under pressure

• And, just as importantly, I challenged old patterns when they no longer served the outcome.

Evolving Leadership Styles

For the Software Delivery leader, this was a time to reflect.

The usual approach, which was more structured and directive, had worked before.

But in this situation, it was causing a bottleneck. We explored an alternative:

• Shifting from assigning work

• To help the team organise itself around the work wasn’t a theoretical conversation.

We put this into practice right away, and it had real effects. And the results spoke for themselves.

What Changed on the Ground

You could really feel the change.

• Work began moving faster.

• Multiple threads progressed simultaneously.

• Knowledge sharing increased naturally.

• And individuals gained exposure to areas they hadn’t worked in before. But maybe the biggest change was in the atmosphere.

There was energy. It was that feeling you get when a team isn’t just working,
but engaged.

Conversations were happening, problems were being solved collaboratively, people were leaning in. The team had something many aim for but rarely keep:

The buzz of a team performing at pace.

Supporting the Momentum

With that shift underway, the focus became:

How can we keep this going?

Two practical productivity-boosting decisions helped:

• Providing flexibility in how and where people work

• Offering paid overtime for those who wanted to and could contribute more, endorsed at an executive level, recognising the time-bound nature of the work.

But even more importantly, they sent a clear message:

We trust you to do what’s needed, and we’ll support you along the way.

Learning in Motion

While the team delivered, something else was happening too. The team was learning.

• New technologies

• Different parts of the system

• Alternative ways of working

They weren’t learning through formal training, they learned by doing.

And because the environment supported collaboration, that learning spread quickly.

More Than a Delivery Shift

It might be easy to call this phase a successful change in how we delivered. But that would miss the real point. The real change wasn’t just in how the work got done. It was:

• How people saw their role in it

• How leaders engaged with their teams

• And how ownership was distributed across the group

A Thought to Leave You With

There’s a common belief that structure creates high-performing teams. But it’s not enough.

Performance doesn’t come from control. It comes from:

• Clarity

• Trust

• And giving people the space to step forward. When teams are given problems to solve, not just tasks, they don’t just deliver. They grow.

Subscribe now

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

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

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

Subscribe now

There’s a moment in most complex environments where something shifts: not visibly. not dramatically, but just enough that, if you’re paying attention, you feel it.

It’s the point where patterns stop being abstract… and start pointing to something real. That moment came not through a single conversation, but through several:

• Different managers

• Different contexts

• Different pieces of work.

And yet, the same thing kept coming up quietly, almost as an aside.

‘Yes, we’re aware of that…’

It wasn’t raised as a risk. It wasn’t escalated as a concern. It surfaced more as background noise: ‘Yes, we know about that…’, ‘That’s coming up…’, ‘We’ll need to deal with it…’

Individually, these comments didn’t stand out. Collectively, they told a very different story: There was a licence due for renewal/expiry in three months.

At one point, it had been essential because it supported a core product used throughout the business. But that product had since been transformed. Rebuilt. Replaced. On the surface, it looked like the organisation had moved on.

In reality, it hadn’t.

What Gets Left Behind

Transformation often focuses on what’s new:

• New platforms

• New capabilities

• New ways of working

So, when you consider transformation, remember: what’s left behind - these unaddressed dependencies - can create operational risks as significant as any new system or process. Because rarely does everything move at the same pace.

In this case, several systems - and some important operational capabilities - still depended on that licence. Because over time, dependencies had become:

• Embedded

• Assumed

• And eventually, invisible

Until something forced them back into view.

The Gap Between Knowing and Acting

By this point, it was clear that multiple people knew about the licence but no one had fully stepped up to resolve it.

This is where organisations can get caught in a very specific gap: not a gap in knowledge…

A gap in ownership.

Because when something spans teams and touches multiple systems, products, and priorities, it can quietly become everyone’s problem.

And in doing so, it becomes no one’s responsibility.

Why This Happens (More Often Than We Admit)

There are a few patterns that tend to show up in situations like this:

• The original context is no longer current

• The ownership model hasn’t evolved with the architecture

• The work required cuts across multiple teams

• And the effort to resolve it feels… inconvenient

Not impossible, just complex enough to delay.

It’s acknowledged. It’s remembered. But unless someone mobilises action, this important issue remains unresolved - and the risk of inaction grows closer.

And time continues to move.

Reframing the Conversation

At this point, there were two possible ways to approach the situation:

Treat it as a technical clean-up or recognise it for what it actually was:

A time-bound business continuity risk

The distinction matters because technical problems can be deprioritised but business risks can’t. So the conversation shifted.

Not:

• ‘We have a licence expiring’

But:

• ‘In three months, parts of the business will lose access to capabilities they still rely on’

And:

• ‘We have a limited window to either remove that dependency - or accept a significant cost increase for questionable value’.

That reframing ensured the issue was treated as a business-critical risk, leading to clear prioritisation and action.

The Decision Landscape

Once surfaced clearly, the options became more explicit:

Renew the licence

• At a significantly increased cost

• With a cost-to-value ratio that no longer made sense

Detangle the dependencies

• Across multiple systems

• Within a fixed timeframe

• With no pre-existing coordinated plan

Neither option was trivial.

Only one option matched the organisation’s strategic direction, highlighting the importance of aligning technical choices with business goals.

From Awareness to Accountability

At this point, the role of leadership isn’t to solve the problem immediately, it’s to create clarity and secure alignment. So the next step was to bring this into the right forum:

• Executive leadership

• Not with technical detail

• Not with a fully formed solution

But with a clear articulation of:

• The risk

• The timeframe

• The decision required

• And the consequences of inaction

What followed was exactly what was needed:

• Sponsorship

• Priority

• Urgency

And just as importantly:

Permission to act decisively.

The Moment Ownership Becomes Real

There’s a subtle but important shift that happens when something moves from:

‘Something we know about’ to ‘Something we are now responsible for delivering’.

You can feel it. The conversations change, the focus sharpens, the edges of the problem become clearer. Because now, it’s not theoretical, It’s real work with a real deadline.

But Clarity Isn’t the Same as Simplicity. At this stage, we had:

• Visibility of the issue

• Executive alignment

• A clear direction of intent

What we didn’t yet have was:

• A defined path forward

• A structured plan

• Or a clear understanding of how deeply embedded the problem actually was

Because the next step wasn’t just to act, it was to understand what we were truly dealing with.

This deliberate assessment of the problem laid the foundation for a solution optimised for business continuity, not just technical completion.

A Thought to Leave You With

In many organisations, the biggest risks aren’t hidden. They’re known, discussed, even accepted. But without clear ownership, they sit in a kind of operational limbo: visible, but unmoved. Until time runs out.

Awareness creates comfort.
Ownership creates action.

In summary: leaders identify risks, assign clear ownership, and transform organisational awareness into decisive action. That is when knowledge becomes results.

Subscribe now

There’s a particular kind of leadership moment that doesn’t come with a briefing pack.

• No handover

• No documentation

• No tidy list of priorities waiting to be picked up and progressed

All I had was a role, some expectations, and a real sense of urgency to get up to speed quickly.

That was the situation I stepped into when I took on one of my leadership roles.

Moments like this reveal more about an organisation’s strengths and weaknesses than any formal strategy document. So, if you don’t start with information at your fingertips, what do you do next?

The Illusion of ‘No Information’

On the surface, there was no visibility.

• No single view of work in progress

• No shared roadmap

• No clear articulation of priorities across teams

But over time, I’ve learned something important: organisations rarely lack information - what they really lack is connected information. With that in mind, I considered where to begin building that connection.

The knowledge was there. It just wasn’t in one place.
It lived in conversations, in individual team backlogs, in half-formed plans, and in people’s heads.

When information is scattered like this, leading becomes a guessing game. So it’s critical to choose your starting point carefully.

Where You Start Matters

There’s a natural instinct in these situations to go hunting for artefacts: plans and reports, dashboards, anything that gives a sense of control.

But artefacts without context can mislead just as easily as they can inform.

So I started with something far more reliable: people; and this shifted the entire approach.

I met with each manager individually. These weren’t formal interviews or status checks, but conversations meant to build a clear picture.

I asked three simple questions:

• What is your team working on now?

• What’s coming next?

• What’s on the horizon for later?

And then I asked the question that tends to unlock everything else:

Why do these things matter?

From there, the conversation naturally expanded:

• What are your timeframes?

• What’s getting in your way?

• What are you worried about?

• What do you need from me?

What came out of these talks wasn’t just a list of tasks. It was context. It was intent. It was pressure points.

And importantly, it was the beginning of alignment.

This alignment would prove crucial to navigating uncertainty and driving organisational progress. But what made these conversations more valuable was their impact beyond discovery.

More Than Discovery

At face value, this might look like a simple discovery, but it’s more than that.

This is where real leadership begins to take shape.

Because in asking those questions, a few things happen simultaneously:

• Teams begin to clarify their own thinking.

• Priorities become visible beyond Leaders, and Leaders also notice where work overlaps, where conflicts arise, or where gaps exist or are left.

It’s not a workshop, it’s not a framework rollout.

It’s actually much more practical:

A shared understanding forming in real time.

If you compare this to formal practices, it’s similar to Agile portfolio thinking:

• Surfacing work

• Understanding value

• Spotting dependencies

But in reality, it doesn’t start with tools, it starts with a conversation.

The First Signals of Risk

As these conversations progressed, patterns began to emerge.

Some were expected:

• Teams focused on their own domains.

• Limited visibility of cross-team dependencies

• Competing priorities without a clear mechanism for alignment

But there was something, the kind that never appears in a report but sits just below the surface. just beneath the surface.

There was an issue that multiple people were aware of.

Not urgently discussing, not actively progressing. Just… aware.

And in complex environments, that’s often where the real risk lives. Moving from shared awareness to real ownership became essential.

Shared Awareness Isn’t Ownership

One of the more subtle challenges in leadership is recognising the difference between:

• Something that is known, and

• Something that is owned

Because those are not the same thing. In fact, they can sit dangerously far apart.

What I was beginning to see was a pattern of distributed awareness without coordinated action.

No one was ignoring the issue, nut no one had fully stepped up to resolve it either.

And without making that shift from awareness to ownership, time quietly slips away. This made me realise the need for visibility before seeking solutions.

Creating Visibility (Before Creating Solutions)

Before jumping into solutions, I needed a way to make the emerging picture visible. Not just for me, but for everyone. So I created a simple, physical representation of what I was hearing:

A Now / Next / Later view of work across the function.

Nothing complicated, no tooling, no formatting perfection. Just clarity. Making this visible invited feedback and sparked collaboration.

I put it on the wall in my office and invited people in:

“Come and have a look. This is what I’m seeing - tell me what’s missing” and something interesting happened:

• People engaged

• They challenged it

• They added to it

• They connected dots

What started as a personal sense-making tool became a shared artefact of alignment.

It didn’t stay physical for long. As it became clear that more people needed access, especially hybrid team members, we moved to a digital version using our existing tools, but the principle stayed the same:

Make the work visible, and conversations improve.

Before the Problem Fully Reveals Itself

At this point, I had something I didn’t have before:

• A cross-functional view of work

• A growing sense of priorities

• Early signals of risk

But the full shape of the problem hadn’t revealed itself yet. That came next, and it came quickly.

A Thought to Leave You With

Stepping into a leadership role without context can feel like starting from zero. But it rarely is.

• The information is there

• The signals are there

• The risks are already in motion

The essential question is: how quickly can you turn scattered knowledge into shared understanding?

Because that shift, from scattered to shared understanding, is when leadership moves from being reactive to intentional.

Subscribe now