Chapter 6: Cultivate team agility
6.5 When should I step in, and when should I step back?
In self-organizing teams, even ones that have nominal leaders, it’s everyone’s responsibility to participate in leading the team: this is the essence of shared leadership. It is not the exclusive duty of the formal ATL or the coach. Moreover, it is not the manager’s role to fix all the problems. Many problems belong to the team. When teams willfully own their problems and solve them, they grow stronger. That is your motivation for stepping back.
If you’re a parent, you have seen this. If you regularly intervene on your kids’ behalf, they either come to you with issues before trying to solve them on their own, or they resist your help and resent you for it. However, if you allow them room to resolve their issues with your optional guidance, they will develop personal responsibility and healthy learning habits. Your team is not a bunch of kids, and you are not their parent, but they are human beings. As such, they like to have a safe framework with understood (or understandable) rules of engagement.
As their leader, set the framework — the envelope for their work — and let them get on with it. Make sure everybody knows that you’re there for them if they need you but that you won’t tell them what to do. That designates you as their servant leader.
You need to monitor the goings-on and pay particular attention to their decisions. If you think you must intervene, ask for permission to make a suggestion or act on their behalf. Some teams will welcome a lot of help when figuring out how to move forward, whether due to technical disagreement, process immaturity, or team dynamics.
If the situation turns bad, you might fly in and save the day. Before you do that, pause. Ask yourself two questions:
- “Is winning the battle worth possibly losing the war?”
- “Am I worried that their results mean bad leadership or performance on my part?”
If you feel confident about your team and trust them to do their work, they will sense that and respect you for it. If they understand that you step back deliberately in order to help them grow, they will respect you more than if you just solved their problems. However, if your confidence and trust are not genuine and you swoop in at the first sign of trouble, you will lose their respect, and they will lose the chance to learn and grow.
Many issues are not truly urgent or critical. A mistake may result in learning that improves long-term results. Both teams and individuals grow stronger and more resilient as they work their way through problems. If they sailed smoothly through the first few months of a project, they would probably be less prepared to respond well to later disasters or upheavals.
Many years ago I was leading an in-house development team. One afternoon, I was checking a data migration script, and accidentally ran it on the production database instead of the test database. I spent the evening cleaning up my mistake. The next day, I got the team together, and we made a rule: “If you’re going to touch any database, someone from the team will pair up with you.” (Notice how this rule obliges a second person to act in the team’s interest.) It was our process and our decision; no external manager told us how to mitigate our risk.
If the team experiences a problem and you let them work it out, take these three actions:
- If they (or others) perceive a failure, help them reframe failure as an opportunity for feedback.
- If they are taking corrective action and appear to learn from the problem, play up their response. If necessary, make sure they are forgiven.
- Follow up on their responses and learning.
As an Agile team leader (or any type of manager) who is serving the team while being beholden to higher-ups, expect to feel uneasy stepping back. That’s how it is for servant leaders. If you do step in, do so gently. Do not immediately fix the problem for them. Coach them by asking questions that ignite discovery and creativity. Give caring feedback and avoid judgment or evaluation.