In partnership with
One of the hardest habits to break as a manager is stepping in too quickly when work isn't moving. It feels helpful, and sometimes it actually is. Your team is stuck, the deadline is getting closer, the customer impact is real, or the same issue has been sitting there long enough that someone needs to make it move.
So you jump in. You write the doc, chase the dependency, make the decision, investigate the alert, clarify the plan, or apply the pressure the team needed. The work moves, which feels good. The harder question is whether the work moved because you helped unblock a real issue, or because you became the workaround for something the team should have been able to handle. The fact that your intervention worked doesn’t automatically mean your intervention was the right long-term answer. Sometimes you removed a legitimate blocker. Other times, you accidentally taught the team that when work gets hard, unclear, or uncomfortable, the manager will eventually step in and carry it over the line.
I get why this happens, especially for newer managers. You're still building trust with the team, you want to be seen as helpful, and you probably have enough context to solve the problem faster than it would take to coach someone else through it. If you were recently an IC, the pull is even stronger because jumping in may feel like returning to a version of work where you knew exactly how to be useful.
And to be clear, sometimes jumping in is the right call. I don’t believe in letting important work sit just to make a leadership point, and I don’t think managers should stay artificially hands-off when there is customer impact, an urgent reliability issue, or a team genuinely blocked on something they can’t resolve on their own.
But if the same kind of work keeps needing your intervention, that’s usually a smell.
A thank you from this week’s sponsor:
An engineering fellowship to land your next job
Many engineers feel stalled because the role itself has not evolved. The work looks the same, but the market has moved.
Senior engineering in 2026 demands ownership, faster judgment, and comfort with ambiguity. If your role is not pushing you there, it may be holding you back.
Last cohort, 15 hiring partners sent 31 representatives to evaluate challengers through 246 live interviews. Gauntlet offers a reset. Apply now.
Must be a US citizen to qualify.
I've seen it in my own line of work: a service alert sitting uninvestigated longer than it should, an SLO issue getting acknowledged but not actually driven to resolution, or a cross-team dependency where everyone knows the problem exists, but nobody is clearly owning the next step. A request is made more than once, maybe more than twice, and is still not moving until a manager or senior leader applies pressure.
None of those are red flags on their own, which is why they're easy to rationalize. Teams get busy, ownership gets fuzzy during a reorg, and things slip. Naming this nuance is important, but the part I don’t want to lose is that the work still has to get done while everyone is figuring it out. There’s only so much mileage you can get out of “ownership is unclear” before unclear ownership turns into work not moving, reliability issues lingering longer than they should, customers being impacted, or managers relying on escalation to create pressure that should have existed closer to the team.
When I step in, I try to ask myself whether I’m handling a one-off issue I can quickly resolve to unblock the team, or whether I’m looking at something that shouldn't have required my intervention in the first place. The work moving again is good, obviously, but if the only reason it moved is because you stepped in, you need to understand what was missing before you got involved.
Maybe the team genuinely didn’t understand the owner, the priority, the expected outcome, or the timeline. Perhaps the EM knew the issue was stuck but wasn’t applying enough pressure or creating enough clarity for the team to act. This is where you need to dig in.
This is also where managers can accidentally make things harder for themselves. If every stuck piece of work turns into you doing the work, chasing the work, or personally creating the urgency around the work, you may solve the immediate issue while making it harder to see whether the team is actually capable of owning it. You likely have your own work you need to get done, and instead you're spending time doing the work your team should be doing.
Sometimes the right sequence is to help unblock the immediate issue first, then come back and inspect the pattern once the urgent thing is no longer urgent. In these scenarios, the work shouldn't be considered done just because the deliverable is complete. The mistake I see EMs make is stepping in, feeling good that the work moved, and never asking why your intervention was necessary.
That’s especially true when the real issue may be an IC performance issue. And when managers don't follow up on these types of issues, the issue compounds: you now have an IC and EM performance issue on your hands.
I don’t think managers always want to name that possibility because it feels harsh, or because they want to believe the problem is clarity, process, prioritization, or anything other than someone not meeting the bar. Sometimes it is one of those things. Sometimes the team really was missing context. Sometimes ownership really was fuzzy. Sometimes the timeline really was unrealistic.
But sometimes expectations are clear enough, the priority is real enough, the work is within the team’s scope, and it still isn't happening at the pace or quality required.
If you keep stepping in at that point, you can end up insulating the team from the feedback they actually need. The work gets done because you made sure it got done, but the person who should have owned it doesn’t have to fully reckon with the gap between what was expected and what happened. The team gets the benefit of your intervention, while you absorb the cost of the pattern.
That cost adds up in several ways. It shows up in your time, because you're now carrying work the team should be carrying. It shows up in the team’s operating habits, because people learn which things only become urgent when you ask about them. It shows up in your ability to evaluate performance, because you're too close to the rescue to see the pattern clearly. And eventually, it shows up in trust, because teams that need repeated manager intervention to follow through start to feel unreliable, even if everyone involved has good intentions.
As managers, we should unblock teams, create clarity, make decisions, and help work move when it’s stuck for a legitimate reason. But being useful is not the same thing as becoming the team’s backup execution engine. The difference is whether your involvement helps the team move forward, or whether your involvement becomes the reason the team can move forward at all.
This is easy to miss in the moment because the fix is often within reach, and getting the work moving feels more responsible than letting it sit. But a pattern of repeated intervention becomes data. If you keep having to create movement, there's something worth inspecting underneath the stalled work, whether it’s a performance issue, a knowledge gap, or a prioritization problem. The answer matters because each one requires a different response.
I don't want you to take away from this that you should be less helpful. Step in when you need to, and don’t let important work sit just because someone else should theoretically be handling it. But once the immediate issue is moving, go back and ask the harder question: did this need me because the team was genuinely blocked, or did this need me because the team has learned, intentionally or not, that I will eventually step in and make it happen?