The help that makes teams helpless

A team hits a blocker. A dependency on another team hasn't moved, an environment is down, a decision is stuck two levels up. Someone raises it, and the same person picks it up: the coach, the Delivery Manager, the one who knows who to call. It gets resolved by afternoon. Everyone moves on.

Do that a hundred times and you have built something specific: a system where every obstacle has exactly one path out of it, and that path runs through one person. The team stops learning the route because the route is always walked for them. When that person is on holiday, in a workshop, or covering two other teams, the blockers don't get smaller. They queue.

This is the quiet failure mode of being useful. It comes not from neglect but from its opposite. The help is real, fast, and competent. It is also the constraint.

Why the reflex is so hard to resist

Solving the blocker yourself is the responsible-looking move in almost every frame that matters in the moment. It's faster than watching someone else work it out. It protects the sprint. It feels kind. You're sparing the team a frustrating call with a vendor or an awkward escalation. And it's legible to your own managers: a Delivery Manager who clears obstacles is visibly working.

None of that is wrong on any single occasion. The problem is that the thing you optimize for in the moment (this blocker, gone, now) is different from the thing the team needs over a quarter: the capability to clear the next one without you. Every time those two goals compete, the immediate one wins, because it's the one with a deadline attached. The cost of the other choice is deferred and diffuse, so it never shows up on this week's board.

The result is a support relationship that transfers outcomes but not ability. The blocker is removed. The knowledge of how to remove it is not.

What the research actually says about role transfer

There's a cleaner way to describe the goal than "step back," and it comes out of a study worth reading carefully.

Spiegler, Heinecke and Wagner (2021) ran a grounded-theory study across 11 Bosch divisions, 75 practitioners, looking at how leadership behaves in agile teams as they mature (Empirical Software Engineering). Their finding is concrete: they identify nine distinct Scrum Master leadership roles, and as a team matures, those roles transfer to the team itself. Facilitation, impediment removal, coaching on method, the interface to the outside: these don't stay welded to one job title. They migrate.

The part that should change how you work is the condition for that transfer. The authors describe it needing a leadership gap (space the team can move into) along with trust and freedom, and a supportive internal team climate. Role conflicts, where it's unclear who owns what, tend to diminish the transfer.

Read the "leadership gap" idea back against the helpful-person pattern and the mechanism is plain. A coach who fills every gap the moment it opens removes the exact opening through which team members would have learned to lead. You can't hand over a role the team never had to reach for. The generous instinct, never let a gap sit, is the thing that keeps the gap from ever being filled by anyone but you.

A note on what this evidence does and doesn't support. Spiegler et al. describe how roles transfer and what conditions help; it's a theory-building study, not a controlled measurement. There is no clean flow-metric dataset showing that a dependency on the coach raises a team's cycle time. The direct evidence on that specific causal link is thin. What the research gives you is a credible mechanism, not a proven number. Treat it that way.

Ownership is bounded, not romantic

It would be easy to turn this into a case for maximum autonomy, and that would be a mistake, especially at scale.

Moe, Smite, Paasivaara and Lassenius (2021) studied two large telecom software organizations with partly self-managing teams, looking for where organizational control and team autonomy actually balance (Empirical Software Engineering). Their teams were self-managing in some respects and constrained in others, and that mix was the point. Alignment can run top-down or bottom-up; they describe bottom-up communities as one way to preserve autonomy while still meeting real alignment needs. Centralized decisions and mandatory processes, unsurprisingly, cut into autonomy. But the paper doesn't treat that as a simple evil to be removed. Coordinated work needs alignment.

So the target isn't the absence of control. It's explicit decision rights and working alignment loops, so the team knows which decisions are genuinely theirs, which are shared, and which sit elsewhere on purpose. A team that "owns" its work but can't tell which category a given decision falls into will escalate everything anyway, not out of helplessness but out of reasonable caution. Vague autonomy produces the same queue as too much help.

Why you can't just leave

The other failure mode is the overcorrection: read all this, decide the team should stand on its own, and withdraw. That's not autonomy. Without capability behind it, it's abandonment.

Doblinger (2022) reviewed 84 studies on the individual competencies behind self-managing team performance (Small Group Research). The common thread: self-managing teams perform when their members actually have the competence to operate in a self-managing system. The structure alone doesn't carry the load. Remove the support before the competence is there and you get worse outcomes with a nicer name on them.

Hoda and Murugesan (2016) sharpen what that competence has to cover (Journal of Systems and Software). Their grounded-theory work with 21 practitioners across six companies shows self-organizing teams still hitting management challenges at several levels at once: project, team, individual, and task. Calling a team self-organizing doesn't make those challenges disappear; it just changes who's supposed to handle them. If the team is now meant to manage dependencies, sequencing, and risk, those problems have to be made visible to it and learnable by it. That is work. It's the work the help was quietly doing all along.

And there's a reason to bother beyond delivery mechanics. Buvik and Tkalich (2022) surveyed 236 members across 43 Norwegian software teams and found autonomy associated with psychological safety, which in turn was associated with reflexivity and performance (Hawaii International Conference on System Sciences). The study is cross-sectional, so read it as correlation, not proof of direction. But it points at something the delivery view alone misses: autonomy isn't decoration. It plugs into how a team learns and reflects. A team that never handles its own obstacles has fewer occasions to reflect on how it handles them.

One more reason not to hoard the role. Gren and Ralph (2022), interviewing 13 professionals across 10 companies, describe effective agile leadership as dynamically shared among team members rather than owned by a single person (ICSE). Over-identifying leadership with one role, yours, cuts against how it seems to work in practice.

A support model that spends itself down

If the goal is capability transfer with the guardrails above, it helps to name where you are with a given task, because "helping" hides four very different things:

1. Do it for the team. You handle the blocker, the decision, the facilitation. Right when the team genuinely can't yet, and when the stakes or the deadline don't allow a slower path. The honest question here isn't "did I fix it." It's "does anyone but me now know how."
2. Do it with the team. You still lead, but someone works it alongside you and sees the moves: who you call, what you say, which levers exist. This is the stage most people skip, because it's slower than stage 1 and less finished-looking than stage 3.
3. Watch the team do it. They lead; you're present but quiet, catching things before they become expensive and debriefing after. This is the leadership gap in practice: you're deliberately not filling it, while staying close enough that a mistake stays recoverable.
4. Remove yourself from the path. The team handles this class of problem without routing it through you. You're no longer the queue for it.

The point of naming the stages is to notice when you've been sitting at stage 1 for a class of problem that should have moved months ago. And, equally, when you've jumped to stage 4 on something the team was never brought through stages 2 and 3 on. Both are common. The first is the queue. The second is the abandonment. The stages aren't a ladder you climb once; you'll be at different stages for different kinds of work at the same time, and that's correct.

A flow audit you can run this week

Intuition about how dependent a team is tends to be flattering. A cheap way to check it is to stop reasoning about the team in general and look at the actual recent record. Pull the last ten of each and mark who drove the resolution, you or the team:

• Last 10 escalations. Who did they route to, and did the same name recur?
• Last 10 blockers. Who removed them? How many were things the team could have removed with information it didn't have?
• Last 10 meetings. Who facilitated? What happens to those meetings when you're away?
• Last 10 improvement actions. Who proposed them, and who owned the follow-through?
• Last 10 cross-team dependencies. Who managed the interface, you or the team directly?

Read across the five lists. If your name is on most of the lines, that isn't a verdict on your competence; it's a map of where capability hasn't transferred yet, and a shortlist of the exact classes of problem to move from stage 1 or 2 toward stage 3. If the team's name is on most lines but the same problems keep recurring, you may have withdrawn ahead of the competence: the Doblinger and Hoda/Murugesan side of the risk.

Treat these as a signal, not a metric. Ten items won't survive statistical scrutiny, and they're not meant to. They're meant to interrupt the story you tell yourself about how self-sufficient the team is.

There's a version of this concern circulating among practitioners right now. Recent commentary in the agile community has taken up almost exactly this phrasing, that teams can be helped into helplessness, alongside broader unease about the future of agile roles. That's a mood, not evidence, and I'm not leaning on it for the argument. But it suggests the pattern is being felt in more than one place.

The instinct in all of this is to hear it as an argument for helping less, and it isn't. A team that's over-helped and a team that's under-supported fail in different directions, and both are worse than the middle. The distinction that matters isn't the amount of support. It's the direction: support that leaves capability behind versus support that only leaves an outcome behind. The first kind is the point of the role. The second kind, done often enough, quietly becomes the thing the team can't deliver without.

The goal is not less support. It's support that works to make itself less necessary.

Sources

• Buvik, M. P., & Tkalich, A. (2022). Psychological safety in agile software development teams: Work design antecedents and performance consequences. In Proceedings of the 55th Hawaii International Conference on System Sciences (pp. 7330–7339). doi.org/10.24251/HICSS.2022.880
• Doblinger, M. (2022). Individual competencies for self-managing team performance: A systematic literature review. Small Group Research, 53(1), 128–180. doi.org/10.1177/10464964211041114
• Gren, L., & Ralph, P. (2022). What makes effective leadership in agile software development teams? In Proceedings of the 44th International Conference on Software Engineering (ICSE '22) (pp. 2402–2414). ACM. doi.org/10.1145/3510003.3510100
• Hoda, R., & Murugesan, L. K. (2016). Multi-level agile project management challenges: A self-organizing team perspective. Journal of Systems and Software, 117, 245–257. doi.org/10.1016/j.jss.2016.02.049
• Moe, N. B., Šmite, D., Paasivaara, M., & Lassenius, C. (2021). Finding the sweet spot for organizational control and team autonomy in large-scale agile software development. Empirical Software Engineering, 26(5), Article 101. doi.org/10.1007/s10664-021-09967-3
• Spiegler, S. V., Heinecke, C., & Wagner, S. (2021). An empirical study on changing leadership in agile teams. Empirical Software Engineering, 26(3), Article 41. doi.org/10.1007/s10664-021-09949-5