When the problem changes
Changing goal posts is something you’ve likely had to deal with (maybe even this week!). It’s not ideal and generally it’s an unwelcome development.
When the goal posts move, what’s often really happened is that the problem to be solved has shifted. Why? Well, take your pick:
A new boss arrives with a different priority or mark to make
A new and highly influential stakeholder enters the scene with their own view
Economic conditions shift, changing investment appetite
You discover that you never really had support for solving the original problem, even if you thought you did (ooof, that one really hurts)
Or, if you’re in government, a new minister or change of government brings a whole new set of policy positions and expectations.
I feel as though this happen so (so!) often that it’s been a struggle to isolate one specific example to share with you. But here’s a go from a project I did many years ago with a retail business.
The CEO engaged our team to answer a specific question:
“How can we best align our capabilities to deliver on our multi-channel strategy?”
If you think about this question and how it is framed, the wording implies that the the capability exists, but needs to be reorganised. Throughout the first few weeks, it became clear that success actually depended on investment in a different set of capabilities altogether.
Because iteration is a key part of problem-solving — as more information emerges, our understanding, framing and approach refines — the primary question was broadened to:
“What capability do we need to achieve our multi-channel strategy?”
How to best align that capability within the organisation became a sub-component of the broader challenge.
Towards the end of the project, a new Chief Transformation Officer was appointed, and the CEO tasked them with overseeing implementation of the outcomes of this work.
But with their arrival came shifts we hadn’t anticipated. Suddenly, the intent of the work pivoted from building capability to achieve the strategy, to achieving radical cost efficiency. Cost efficiency had always been a factor, but it wasn’t the whole story or the driving factor.
The incoming executive had a view of what a transformation program should look like — what I’d call a McKinsey-style cost-out program — and that was what they wanted to implement.
Unfortunately for us, we hadn’t been working on that.
If the primary question when we started had been “How can I redefine my operating model to reduce cost?” we would have arrvied at a very different answer.
So, what do we do here? The framing of this problem has now shifted so substantially that the solution doesn’t answer the new question.
Look, laying all this out like this I need to confront that this particular situation didn’t go well for me, or anyone else involved, and it wasn’t able to be resurrected.
It was one of those downright frustrating and deflating situations.
When misalignment like this surfaces suddenly and usually in uncomfortable ways, it first shows up through someone more senior than you saying things like:
“I don’t understand what problem we’re trying to solve”
“Remind me why I should spend money on this?”
“Where’s the data that supports this approach?”
“What have you been doing for the past X weeks/months/years?”
Even when you can see the problem changing right in front of you, there isn’t always an opportunity to pause and rediscover. Sometimes the shift happens so fast or so far above your pay grade that you just have to watch the bus change lanes and accept that you’re not the one driving it.
Even when you can see the problem changing right in front of you, there isn’t always an opportunity to pause and rediscover.
That’s hard. Because if you’re wired to work with integrity, clarity, and care, seeing good work lose its way can feel like a personal failure. It’s not. It’s just the system doing what systems do: reshaping itself around new intent, whether it makes sense or not.
When this happens, it’s tempting to double down. To defend your original framing or keep arguing for the version of the problem you know is right. But often the more useful thing is to step back and observe what’s really happening. Ask yourself:
What is this telling me about how this organisation defines success now?
What can I learn from this about how intent gets translated (or lost) along the way?
Rediscovery doesn’t always mean jumping back into a project to fix it. Sometimes it means rediscovering your own understanding of the system you’re in. Testing what’s shifted and being willing to create a new narrative.
Not every story ends neatly. But even when you can’t get a project back on course, you can still practise the discipline of rediscovering.
Shaping your next move with a little more awareness, and a little less attachment.
Thanks for reading. Let’s unsquiggle this, good people!
