When you first find yourself leading and mentoring a distributed development team, it can seem like an incredibly daunting task. You might ask yourself things like: “How am I suppose to lead people when I can’t even see what they’re doing?” or “How can I mentor someone through a chat box?”
The good news is that once you learn how to trust and empower proactive people, regardless of where they live, you will be amazed at the results you can achieve.
Don’t become a dependency.
Great leadership empowers by encouraging autonomy and distributing ownership. Poor leadership disempowers and creates a dependency on the leader.
Empowering a team involves a huge amount of trust, but this can be a scary thing for a leader because you feel you are judged by the quality of other people’s work! Unless you can master this fear it will drive you to trust your team less. Whether you observe this happening in your own situation or not, it’s safest just to assume you will become a dependency and take positive steps to address it.
As leaders what we really need is to be asking not only “how can I serve my team better?“, but also “how can I empower them and build up their leadership?“, so that we avoid making people dependent on ourselves.
Over the years of leading a particular team, I went on paternity leave twice. And both times the lead-up involved some pretty frantic preparations for me, because I was worried that perhaps, once I was out of the picture certain things would stop being done, or not done to the level I wanted. But I was fortunate that both times, on my return I saw other members of the team had stepped up and not only maintained the level of service I had hoped for, but in a lot of cases, improved on it.
If you woke up in hospital tomorrow and couldn’t remember your own name, how would that impact your project? Which parts of the project or customer experience would suffer the most? Stepping out of the project will expose any areas where you have become a dependency, but it’s also extremely risky. I did a lot of hard work to mitigate this risk, but I was also lucky to have the right people around. So don’t leave this too late, start preparing now.
A simple way to get started is to start empowering developers with responsibilities like helping with onboarding a new team member. Every ounce of responsibility you can give your team, the more they will feel part of it and will be more willing to support you when you need them.
When possible, delegate authority, not tasks.
Delegating tasks leads to micromanaging, but delegating authority creates more leadership. You are telling the person “I believe you are able to reach this goal and get a great result for the team“. So don’t do it unless you really do believe in the person. If they fail, it’s partly on you and you are responsible to fix it. For this reason, make sure that as well as handing out responsibilities you are also providing that person with as much support as you can from yourself and others.
Try to assign tasks based on each developers’ strengths and interests; if they prefer backend work, try to allocate as such where possible.
Critique yourself before others.
Be patient when critiquing your team mates’ work. Sometimes our first reaction is that something should be changed, yet on closer introspection you may realize that it’s your personal preference, and not so much a question of quality. When you do ask people to change the way they do things, give objective reasons why the change needs to be made. This helps them to understand the principles by which they can make better decisions next time.
Bonus tip from X-Team Senior Developer Jason Brumwell:
“Timezone differences can result in developers needing help when you are off the clock, so try to schedule yourself so you can overlap as much as required for the project.”