Solved. Again.
What you're teaching your team every time you fix it for them
A CEO had asked his project lead for a simplified dashboard to track actions on an ongoing major change management project. It didn’t appear straight away, so he opened a blank spreadsheet and built it himself.
It took twenty minutes. It would have taken the project lead longer – he was juggling three other things, and there was a reasonable chance his first attempt wouldn’t have been exactly what the CEO wanted anyway. So he just did it.
Here’s the thing: that CEO wasn’t trying to be unkind, and he certainly wasn’t trying to undermine his project lead. If anything, the opposite – he didn’t want to pile more onto someone he knew was already stretched.
But here’s what actually happened. The project lead found out the dashboard existed when it was sent round, already built. He felt side-lined on a piece of work that had been his to own, and not quite trusted to get it right. So he went away and built his own version on his own time, largely to prove he could. The thing that was meant to save fifteen minutes ended up costing considerably more than that, in hours and in trust.
This is solution bias in action: the pull to jump straight to here’s what you need to do – or, more often, to I’ll just do it myself – without pausing long enough to ask whether that’s what was needed or what was helpful. Let’s explore.
The filter you didn’t know was on
We don’t usually make a conscious decision to take over; it happens subconsciously in how we listen. When someone starts to explain a problem, often we aren’t really hearing the whole of what they’re saying – we’re scanning for the bit where we can step in. We start listening for ‘How can I fix this?’ rather than listening for ‘How can I help them figure out a solution for themselves?’ Two entirely different filters, and most of us have no awareness over which one is switched on.
Once you’re listening for the fix, everything that follows is shaped by it. You stop tracking their reasoning and start building yours. You interrupt with “have you tried…” before they’ve reached their own point. The problem in front of you becomes something to solve rather than something to understand – and the person who brought it to you becomes, in that moment, slightly beside the point.
The dopamine hit of done
It’s worth being honest about why this filter is so hard to switch off, because it isn’t laziness or arrogance. It’s that fixing things yourself is, in almost every practical sense, the more rewarding option.
It’s faster – you already know what you want, so there’s no need to explain it, no risk that someone else’s first attempt falls short of what you had in mind. There’s also a slightly addictive satisfaction in finishing something. A solved problem is a closed loop, and closed loops feel good in a way that “I coached someone through their own thinking” rarely does, even when the second one may be the better use of your time.
And for a lot of senior leaders, fixing things is precisely what got you here. Earlier in your career, being the person who could sort the problem fast was the thing that got noticed, rewarded, promoted. That instinct doesn’t simply retire once you’re managing a large team with a strategic remit. It just finds alternative, less visible places to keep operating.
The fix isn’t free
The costs are real, even when the fix itself looks free.
There’s the time cost: you, doing work that wasn’t yours to do, at a level below where your time is most valuable. There’s the development cost: every problem you solve on someone’s behalf is a problem they didn’t get to practise solving, and capability doesn’t build itself in their absence.
Then there’s the relational cost, which is often the most expensive and the hardest to see. People who’ve had a problem taken off their hands without being asked don’t typically feel grateful – they feel overridden. It reads as a vote of no confidence, however well-intentioned. Do it often enough, and people stop bringing you problems early, or stop trying to solve anything themselves at all, because why would they? You’ll just do it anyway. That’s not a high-performing team; it’s a queue of people waiting to be told what to do.
And underneath all of it, there’s what you miss: their context, their reasoning, the option they’d already ruled out for a good reason you never heard. You may have got the dashboard, but you didn’t get any of that.
Take your hands off the wheel
If we can recognise that this is an unhelpful habit, the next question is how can we break it.
The single biggest shift is also the simplest to state and the hardest to do: slow down. Notice the pull towards fixing before you act on it – that half-second where you feel the urge to jump in is exactly where the choice still exists.
From there, ask more and assume less. Before you offer the solution, ask what’s actually being asked of you. Is this person handing you a problem to fix? Asking you to help them think it through? Or simply letting you know what they’re planning to do? Those are three entirely different requests, and most of us answer all of them the same way by default.
If your honest answer is that they don’t need you to fix it, hand it back – but stay present while you do. Ask how they’re planning to approach it. Offer to talk it through if they want that. Validate their thinking if it’s sound. The goal isn’t to lob the problem over the fence and walk off; it’s to make it clear you’re available, while making the choice and the ownership theirs.
Sometimes, just fix the damn thing
None of this means you should never step in. There are situations – genuine crises, compliance issues, moments where someone simply doesn’t yet have the skill or experience to handle what’s in front of them – where being directive is exactly the right call, and coaching them through it would be unhelpful and even unkind.
The problem isn’t fixing things. It’s fixing things by default, regardless of whether the situation calls for it. The skill is telling the difference, and that starts with the same pause: noticing what’s actually needed before you decide how to respond.
Capability or dependency. Your choice.
The dashboard got built either way. What changed was whether the project lead came out of it more capable and confident, or more cautious – and that outcome had very little to do with the dashboard and everything to do with the fifteen minutes either side of it.
Every time you fix something that wasn’t yours to fix, you’re making a choice, even if it doesn’t feel like one. You’re building either capability or dependency in the person standing in front of you. Only one of those is sustainable in the long run.
Hit reply or leave a comment – think about the last problem someone brought to you. Did you ask what they needed, or did you just decide?
Restack
This is an interesting overview of the cognitive neuroscience of learning, with implications for how we effectively grow capability within our teams, Well worth a read.
Meme of the week
To everyone sweltering through the current heatwave, this one is for you…🥵😂
Enjoyed this? Subscribe to receive more like this in your inbox each Friday. Or follow to ensure you see my posts in the Substack app. You can also read my full Substack archive here.
Want to read more from me? Read my book, Do Sweat the Small Stuff, or follow me on Linkedin for more regular content.
Please use this button to share this post with someone who you think would enjoy it!
Get in touch by email if you’d like to explore me speaking to your organisation or at your event, or are interested in working with me as a coach.
Thanks for reading. See you next week!
Sarah