I have been managing distributed teams for as long as I have been a manager. This has probably had a profound effect on how I manage overall. It is probably also why I have never minded managing remote workers. That just feels normal to me.
Still, I can appreciate that managing a distributed team feels harder to people who are not used to doing it. That doesn’t mean that distributed teams are a bad idea, though. It just means that we need to train people on how to run them effectively. You receive many benefits from distributed teams: You get to build a team that takes advantage of talented people without regard to where they live. You may find you have lower turnover, because people are better able to fit their work into the other parts of their lives. In some cases, a distributed team can also increase the diversity of viewpoints on your project, which can lead to a better result overall.
In short, if you find yourself arguing that your team must be 100% local because that makes for a better team, pause and consider that you may just be covering for your own weaknesses as a manager. Luckily, these weaknesses can be addressed. Here are the things I think are most important for effectively managing a distributed team:
Careful planning. Especially if your team is distributed across time zones, you cannot rely on last minute efforts to rescue you if you missed something in your planning. You must plan your team’s work ahead of time or risk delays because people in one location did not realize that people in another location were counting on them to finish some task. This does not mean giving up on agile methodologies, if those are what you prefer. All of the popular agile methodologies include some planning, even if they don’t call it that. (For instance, sprint transitions include significant planning time: when you’re selecting what stories go in the next sprint, you’re planning the team’s work.) If your methodology doesn’t provide for enough planning, modify it. A methodology is a guideline, not a strict recipe.
The most important part of planning is understanding which tasks depend on which other tasks, and making sure that the people know when to expect tasks to be completed. This allows everyone to organize their own work days efficiently and helps avoid last minute emergencies..
I recently wrote about why I always do a dependency analysis at the start of a project. Understanding your dependencies will lead to better plans, no matter what method you use to do your planning or where your team members sit. If you only realize that you can’t start Task B until Task A is finished when someone on the team goes to start Task B, you’ve made a mistake no matter where everyone is located. The effect of that mistake is exacerbated by the fact that the person who needs to complete Task A works in a different time zone than the person who wanted to work on Task B, but it is always a mistake, and it has an impact even when the Task A person is in the same location as the Task B person and able to drop her other work to accommodate your poor planning.
Foresight in communication. If your communication plan is limited to “people ask when they need information” you may need to upgrade it to work effectively with a remote team… unless you are so good at planning that people are able to see what information they’ll need ahead of time, so that they can ask before the lack of information blocks them. I consider myself good at planning, but I’ve never considered myself to be that good. Therefore, I always try to make sure that crucial information is shared ahead of time.
This may be the aspect of management most influenced by my early experiences. In my very first post-PhD job, I collaborated with a team in New Zealand. I was in New Jersey. If I had a question for my Kiwi counterparts at the beginning of my work day, the earliest I could hope to hear the answer was at the end of the day. They had it a little easier: sometimes they’d send a question in the morning and catch me before I logged off for the day. Still, that team learned to effectively document things, because that was how we got more done.
This was also before Skype and Google Hangouts made voice communication cheap, so we communicated by emails. We got very good at writing emails that minimized the space for misunderstanding. This had a predictable side benefit: we thought questions and proposals through more thoroughly before raising them, and I think this led to better discussions and ultimately better decisions.
Even if your time zone difference is not as profound as the New Jersey to New Zealand difference, you will benefit from learning to think about what your team mates might need to know, and making it available before they ask for it. And even if you’re in two different locations in the same time zone, you’ll benefit from learning how to communicate your ideas clearly, without relying so much on follow up questions to get your meaning across.
Sharing Priorities. If your team is distributed, they cannot need your input for every decision. You just cannot always be available. Therefore, you need to empower your team to make decisions on their own. They can only make good decisions if they understand the priorities on the various aspects of the work to be done. Should they drop their work on Task X because someone else has a problem on Task Y? Or should they ask the person working on Task Y to wait until Task X is finished? The answer depends on the relative priorities of the two tasks (and their downstream dependencies).
As a manager, you probably carry these priorities in your head, although you may not have thought about them explicitly. When confronted with a decision like the one outlined above, the answer will be obvious to you, because you know what is most important for the project or the team.
To work with a distributed team, you need to take these priorities out of your head and communicate them to the team. You can’t do that if you can’t articulate the priorities yourself. You’ll need to move this aspect of your management work from the implicit to the explicit. This can feel awkward at first, almost like you’re being asked to choose which child is your favorite. But you aren’t: you’re being asked to identify which “child” has the most urgent needs right now, and to share that determination with your team.
You will probably find that the process of explicitly identifying and sharing priorities improves your decision making, too. This is because you’re being forced to think about the reasons for your priorities, and because once you share them, your team is likely to have questions and suggestions that improve them.
Each of these skills will improve your effectiveness as you manage a distributed team. Each also has at least one bonus side effect that improves your management skills in general. Learning to effectively manage a distributed team will make you a better manager overall, and your entire team, both local and distributed, will benefit from your strengthened skills.
Be First to Comment