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 (not to management), and when teams understand that they can truly own their problems and solve them, they grow stronger. That is your motivation for stepping back.
If you’re a parent, consider the results you get when you intervene in your kids’ actions and what results you get when you step back. 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 run 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 need to intervene, ask for permission to make a suggestion or act on their behalf. Some teams will welcome a lot of help 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 risking 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 a project had no hiccups at all and the team just sailed through it, they would be less likely to respond well to disasters or upheavals.
10 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 two people to act in the team’s interest.) It was our process and our decision; no external manager told us how to mitigate our risk.
When the team experiences a problem, you need to decide whether to step in or not. If you choose to let the team 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) serving the team while being beholden to higher-ups, expect to feel uneasy stepping back. That’s how it is for servant leaders. But 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.