Why distributed teams matter, and how to manage them well

It is hard to deny that many talent scouts still rely on an outdated set of assumptions and are not especially resourceful when it comes to building winning teams. Newer entrepreneurs, however, have spotted that gap and are choosing to invest in undervalued talent that later delivers them win after win.

The lesson is clear: whether you are a large company or a young startup, you have the option to adapt your tactics and tap into high-potential talent pools that used to go unexploited.

In this article we explain how building and managing remote teams can create a major competitive advantage in the talent market.

Companies are moving to a distributed operating model

In 2016, the recruitment company TinyPulse surveyed more than 500 remote employees and concluded that they were happier, felt more valued, and were more productive than their in-house colleagues. More than 43% of American workers did some remote work over the previous year, a substantial increase on the 9% who said the same in 1995.

Adapting your organisation to accommodate distributed teams is not easy. But in our view, sticking to the status quo is an even bigger risk.

Below we go through the most common objections to distributed teams and share our best practices for hiring, management, and tooling.

Common concerns about distributed teams

Experienced executives may carry a residual fear of distributed development teams that dates back to the early outsourcing era. Newer executives may be tempted to defer to conventional wisdom. Both groups tend to raise the following concerns.

Quality

Nearly twenty years ago, the first exposure to distributed teams happened in a traditional outsourcing context. Collaboration seemed impossible: the tools we use today, like Slack or GitHub, did not exist, email exchanges took days because of time zone issues, and everyone was surprised when software built by the cheapest developers on the market turned out badly.

Visibility

Project managers hate surprises. That is why a plant manager regularly inspects the production line. There are of course few cases where physical presence is required to inspect progress on a software product, but the concern remains significant for managers in every sector.

Agile orthodoxy

We see many companies considering or beginning an Agile transformation. As part of it, they tend to seek guidance from books and consulting firms. When it comes to forming teams, those experts tend to say the same thing: "Your teams must be co-located." That was sound advice fifteen years ago, when collaborating across long distances was impossible.

Thanks largely to improvements in collaboration and communication technology, the conditions that led to those concerns no longer exist. By applying the five best practices below, companies will be well equipped to build high-performing distributed teams.

The five best practices

1. Hire for remote

Not everyone is cut out for remote work. Think about the qualities you value in a good developer: engineering skill, technical excellence, the ability to work in a team, honest communication. It is hard to assess how soft skills will show up in a remote environment, so here are a few pointers.

Proactive: the best hires are self-directed people who do not need tasks assigned to them or constant guidance to get things done.

Uncompromising about prioritisation: good remote workers have an intuitive sense of what matters and what does not on a project. They stay focused on what is important.

Writing skills: communication within remote teams usually takes the form of a written report, which requires a good command of writing.

2. Create a clear set of rules

Many companies struggle to make sure their development teams respect coding standards and project management processes. Productive teams are empowered and autonomous, and they have wide latitude to set their own standards.

Working remotely does not change that, which is why you need clear management rules in place: sprint ceremonies, the tools and frameworks to use, expectations around code.

In other words, the framework and collaboration processes should be firmly defined, but software development is as much an art as a science, so it is important that employees have the freedom to be creative.

3. Focus on outcomes

Consciously or not, some managers measure productivity by hours spent at the office rather than by results. But a developer who produces thousands of lines of mediocre code should not be considered more productive than one who produces a few hundred lines of excellent code in the same window.

For remote teams in particular, it is essential that productivity metrics measure the quality of outcomes rather than raw output. How much good software did we ship last month? Is our development velocity stable, predictable, and accelerating over time? Is the team demonstrating continuous improvement?

4. Use the right tools

Tools are the main reason remote work is flourishing.

Today's communication applications let remote teams overcome the pitfalls of earlier eras. Here is our list of essential tools.

Real-time chat: essential for a remote team. Want to reproduce the immediate interaction and collaboration you have with in-house employees? It is critical that all team communication is centralised in one place.

Information radiators: without in-person interactions to carry information, you need an online wiki to spread information to the team. As a manager, you need a single source for every area of information the team and stakeholders rely on to know where things stand.

Video conferencing: in our experience, talking face to face is the best way to work through a topic. Daily video meetings are an excellent way to strengthen team culture and trust.

5. Team rituals

You probably have a number of habits around sprint planning and estimation, code review, and software demos. Schedule them so that every team member, wherever they are, can take part.

While it is natural to worry about time differences when building distributed teams, in our experience a plurality of people who choose a remote career in technical development prefer to work outside traditional hours, and are often far more productive when allowed to do so.

Conclusion

In the talent-driven world of software development and professional services, consider the constraints you place on your organisation by insisting it hire local talent only.

A cultural change of this magnitude is a significant decision, but you can start the transition now: let go of office orthodoxy, welcome distributed teams, and let them realise their potential by giving them the management, the tools, and the culture they need to do their work, wherever they happen to be.