Is This Actually Ours to Solve?

For a while, every week felt like firefighting.

A stakeholder would raise an issue, we'd fix it, and another problem would appear somewhere else. The backlog kept growing, everyone seemed to have a genuinely important request, and despite working hard it often felt like we weren't making much progress.

Looking back, the problem wasn't a lack of effort. It was that we were moving too quickly into solutions before fully understanding what was happening.

I noticed this most clearly while leading the Learning Management System (LMS) work behind the Humankind programme.

The platform was already live in a small way. We were experimenting with different learning pathways, user numbers were growing and the product was attracting increasing attention across the organisation. Alongside that came a growing backlog of requests from Product Managers, frontline teams, business support colleagues, analysts and senior stakeholders. Everyone had a valid perspective.

The challenge was that everything felt urgent.

Like many teams, our first instinct was to solve problems. If something wasn't working, we'd try to fix it. If a request was escalated, we'd try to respond quickly.

The result was a lot of reactive work.

We would solve a problem in one area only to discover it had created issues somewhere else. Different stakeholders were often describing symptoms of the same underlying problem, and the loudest request wasn't always the most important one. The more we reacted, the harder it became to understand what was really going on.

Around this time, I took ownership of the LMS work and was onboarding a new Digital Product Specialist. I realised that continuing to work this way wasn't going to help either of us succeed. Instead, I deliberately created space for understanding.

We ran listening sessions with different stakeholder groups and asked people to walk us through what they were trying to achieve, what wasn't working and why it mattered. I focused on understanding stakeholder needs and organisational pressures, while the Digital Product Specialist investigated technical constraints, options and opportunities.

We weren't looking for solutions.

We were looking for understanding.

As we listened and investigated, patterns began to emerge.

Some issues were technology problems. Others were process issues, capability gaps or organisational constraints outside our control. What looked like dozens of separate requests often turned out to be a handful of common themes.

That helped us ask a more useful question:

Is this actually ours to solve?

Not every problem needed a feature. Not every request needed immediate action. Not every frustration belonged with our team.

Instead of moving straight from problem to delivery, we created space to investigate. We explored options, tested assumptions, gathered evidence and considered who else might be affected.

Many of our playback conversations followed a similar pattern:

You told us this.
We investigated it.
Here's what we learned.
Here are the options.
Here's what we recommend.

Sometimes that led to action, sometimes it led to further investigation, sometimes it led to a conscious decision not to do anything at all. What surprised me was that stakeholders were usually comfortable with any of those outcomes when they understood how the decision had been reached.

The transition wasn't always comfortable. At times stakeholders became louder before they became quieter. There were moments when I took that criticism personally. What I eventually realised was that people weren't really asking for immediate solutions. They wanted progress, clarity and confidence that their concerns were being taken seriously. Over time, trust grew. Prioritisation became easier. Conversations became more productive. We moved away from reacting and towards understanding.

Looking back, I don't think the biggest thing that changed was the LMS. It was my approach.

I stopped feeling responsible for having all the answers and became more comfortable creating space for understanding. Ironically, that is when the quality of the decisions started to improve.

I've since realised this applies far beyond systems work.

Whether I'm onboarding someone new, responding to stakeholder requests or exploring a new opportunity, listening, investigating and understanding are not things that happen before the work starts. They are part of the work. Sometimes the most valuable outcome isn't a solution. It's the clarity that helps everyone understand what is actually worth solving in the first place.