Managing Distributed Teams

Many books have been written about leadership, management, and project management. Of these, many are committed to the agile project management methodologies like those used by my team in building software products. However, none of these books prepared the business world for the implications of managing teams through a crisis when their teams could no longer share a physical space.

The evidence of the disaster is made clear by the number of articles written in the past year advocating for teams to “return to the office”, usually with some ham-fisted attempt to denounce remote work as “bad”. The remote work of the 2020’s is not bad, any more than the globalization of the 2000’s was bad. It simply requires new tools and management techniques. It’s time that we prepare our managers and teams properly instead of wringing our hands like those in condemnation of Galileo, claiming that the world should revolve around us in complete opposition to the facts.

If the first step is to acknowledge that there is a problem, the second step is to determine its nature. We can begin by noting that there is nothing new about distributed teams, nor are they going away. In the past three decades I’ve worked with over 100 companies and the thing that nearly all of these projects had in common is that not everyone on the project was in the same room all the time. In fact, the larger the project or the company, the more likely that was to be true. While working in the midwest on federal government projects, I often had to work closely with people on the east coast. While working on state government projects, people were often working out of different offices in the same city. Working for insurance companies I had to collaborate with teams in Ireland and India. All of this was before 2015, and I’m sure you’ve had similar experiences, so how do we make this work well?

Some of the top areas I recommend focusing on include:

• Minimize synchronous touch-points
• Focus on text-based communication
• Prioritize documentation
• Audit your software and tools

Communication

When I say minimize synchronous touch-points that means a lot more than simply reducing the number of meetings, although that’s an important start. When your team spans 12 time zones like mine does there may be members of your team who are never on a call at the same time. Rather than leaning on meetings, real-time chat, and phone calls as the primary mode of communication it’s necessary to change the goal of meetings to:

• removing barriers
• clearing up confusion
• and making decisions

Meetings should never be the primary mechanism for distributing team objectives or project details.

Those things are best via text-based communication. Whether you use Slack, Teams, or email, or a collaboration tool like Asana or SharePoint, committing communication to text means that it is persistent, and can be shared asynchronously. In addition to helping across time zones this helps us keep teammates in the loop when they’re out sick or on vacation.

If we commit to organizing these details and making them searchable, we’re really building documentation. Now instead of having multiple in-person meetings with subsets of our project team, making decisions that work for that group, then reconvening in a different meeting only to discover that things don’t work correctly anymore … we can disseminate information once, collect feedback in public, make revisions, and publish documentation in a single cohesive process that produces useful and long-term documentation. Because of the natural delay in distributed teams, this process will often feel slower initially, but with the reduction in back-and-forth, changes in direction, and false-starts due to incomplete understanding of the actual project direction the overall pace of progress can be dramatically improved.

It will take time and practice to learn how to collaborate asynchronously in public, and knowing exactly how to organize the documentation and when to move a conversation into a knowledge base, but building practices around this sort of asynchronous text-first collaboration will pay dividends. Your teams will become more efficient, reduce errors, build trust both with each other and with management.

This overall approach works extremely well alongside values-based leadership, where your top-down communication focuses much more on the values and goals of decisions (the why) rather than on how to make decisions, or what decisions to make. This generates empowerment because when those at every level of the organization understand the big picture they can move in the right direction without constantly waiting around for confirmation.

Tools

You’ve probably noticed already, but this communication process is contingent upon something very important – your software tools. Without the right tools, building collaborative documentation or having public asynchronous discussions is never going to happen. My team uses Slack for discussions, Confluence for our knowledge base, and Jira for our project management, but the important thing isn’t the specific software you use but how well it supports your mission and your team.

Some specific criteria I suggest includes:

• When possible, software shouldn’t require VPN to access
• Every person on the team should have (appropriate) edit access
• Tools should integrate together for streamlined workflows
• The software is either supported by your company’s IT department or is available as a maintenance-free cloud platform
• At least one tool should support the creation of visualizations (flowcharts, diagrams, mockups) without needing design experience
• Provides good support for accessibility

Work with your management team to put together agreements on how to select software. Review your existing tools and make sure they work well with these agreements and also for your plans for documentation and collaboration. If any current software doesn’t pass, make a plan to replace it and communicate this with the team. And while everyone should be empowered to (and requested to) contribute to documentation, ideally every team should have at least one technical writer who is responsible for maintaining documentation. If this isn’t possible, your business analysts and project managers can take ownership of their own areas. Regardless, make sure that there is a specific person responsible for reviewing the documentation to ensure it remains accurate and relevant over time.

Summary

We’ve acknowledged that distributed teams have been around for a long time, and that whether we’re working from home or sitting in offices around the world, we need effective ways of collaborating and producing business value. Shifting from synchronous methods of communication to asynchronous ones is an important way to successfully manage teams in this reality.

And there are amazing benefits:

• we can better support a wider variety of communication styles
• our projects become much more crisis-resistant
• our teams can be more inclusive of a wide range of people including parents, caregivers, and those with disabilities
• and our communication can be much more effective not only across time zones but also between languages

As managers, let’s focus more on getting our teams into the same head space and less on getting them into the same physical space.