The hard problem lands on your desk, and you can see an answer before the person finishes explaining it. You take it, fix it, and get back to the rest of your day.
Except the rest of your day is more of the same.
If this is your standing role across the company, the problem may be bigger than a crowded calendar. The solving habit never retired. It got rewarded. Your team gets relief; you get the satisfaction of being useful. Meanwhile, setting direction and developing an executive team get whatever time is left.
I wouldn't start by telling you to solve less. I'd make you justify the takeover: what does this situation need from you that its owner can't provide?
Why being useful can keep you stuck
I've written before about how routinely supplying answers can teach people to bring you the next problem. The harder part is what that arrangement teaches you.
A visible save gives you a result now, often with appreciation attached. Helping someone develop judgment takes longer, and the benefit may show up in a decision you never hear about. If your sense of contribution rests on having the answer, that can feel like a demotion.
That's why a successful intervention is a poor test of whether it was necessary. You solved the problem. You haven't established that you needed to be the solver.
A better calendar can protect time. It won't, by itself, change what you do when someone brings a problem you enjoy solving.
Some problems do need you
Early in a business, hands-on solving may be essential. Even in a large company, a new venture or an important technical problem may deserve your close attention. A well-led, established area may need much less.
Some decisions stay yours by design. When someone needs a clear standard or a decision only you can make, give it. Coaching isn't a way to avoid either.
An escalation can also be sensible when the decision affects another function, exceeds someone's authority or requires information they can't access. Supply what's missing rather than automatically taking over the whole problem.
And if nobody has time to own the work, willingness to let go won't create capacity. Reduce commitments, change staffing or keep an explicit temporary role yourself.
Replace the percentage with a standard
The 80 percent rule says to let someone proceed when their solution gets most of the way to the goal and won't cause a catastrophe. I like the permission to accept a different approach. I wouldn't use the percentage as the decision threshold.
Eighty percent of what? Your preferred method isn't the business requirement. And avoiding catastrophe is too low a bar.
Instead, agree on the outcome, deadline and quality the work must meet. Check that the owner has the skill, authority and time to make the call. Then decide what downside is acceptable and how you'll detect trouble while there's still time to act.
Suppose your head of support wants to clear a backlog by grouping cases differently than you would. If the plan fits the available staffing and meets the required customer response times, your preference alone isn't a reason to replace it. If it puts a service commitment at risk, name that gap and work through it.
Don't relax safety or legal requirements for a learning opportunity. Narrow the decision or add review before an irreversible step.
Look at the moments you take over
Try a short Solver Log. It's a practical exercise, not a validated diagnostic.
Reconstruct one recent week from your calendar and messages. For each problem you personally fixed, record what it was, who owned it, what they needed from you and what you actually did. Include the work you took over without being asked.
Then add the part worth examining: why did you intervene? A missing approval? A real risk? A gap in their knowledge? Or an answer that wasn't the one you would have given?
Check a few entries with the people involved. Your memory of a rescue may leave out the authority or information they had been asking you for.
An empty owner column doesn't prove understaffing. It may reflect an unassigned responsibility, unclear authority or a genuine capacity shortage. The log gives you questions to investigate, not a diagnosis of anyone's character.
Pick one recurring category where a capable owner has room to act. Agree on the decisions they'll make, the standard they'll meet and when you'll review the work. Be explicit about what should bring you in sooner, and tell the affected team who owns the call.
On the next few cases, ask for the person's recommendation and the help they need before offering your answer. When you feel the urge to take over, write down the specific requirement or risk that justifies it. If you intervene, record what you changed.
Keep bad news welcome. Asking for help shouldn't automatically cost someone ownership.
Give the time you're trying to recover a job, too. Name one upcoming demand the company needs you to prepare for, such as a financing or launch, and check whether your week actually makes room for it.
At the agreed review, look at the work and your interventions. Did the owner meet the standard? Did your involvement address a material problem, or mostly change the method? If results fell short, examine the support, workload and capability before deciding what to change. If the owner keeps missing an explicit standard despite adequate support, address that performance problem directly.
Under pressure, you may want to take everything back. That urge isn't proof that delegation is working or failing. Use the work to judge.
If the work meets the agreed standard and your main complaint is that you would have done it differently, leave it alone.
Still the one solving everything?