Why Distributed Teams Matter, and How to Build One

“Assume you’re by yourself in a startup, and you want a partner. You’d take a lot of time finding the partner, right? He would be half of your company. Why should you take any less time finding a third of your company or a fourth of your company or a fifth of your company? When you’re in a startup, the first ten people will determine whether the company succeeds or not. Each is 10% of the company. So why wouldn’t you take as much time as necessary to find all the A-players? If three were not so great, why would you want a company where 30% of your people are not so great?” — Steve Jobs

In 2003, the author Michael Lewis published a book called Moneyball: The Art of Winning an Unfair Game. On its face, the book is a classic underdog story: a struggling baseball team realizes that talent scouts who rely on decades-old wisdom are missing opportunities to build winning teams. By evolving their scouting tactics to incorporate modern tools and practices, the team identifies and hires a roster of underestimated players, achieving a winning record against opponents with far larger payrolls.

The real lesson of Moneyball is clear: whether you’re a major corporation or a scrappy upstart looking for an edge over an incumbent that can outspend you, you have an opportunity to adapt your tactics and hire untapped reservoirs of high-quality talent by recognizing when the conventional wisdom on building teams no longer reflects reality.

Companies Play Moneyball By Using Distributed Teams

In our view, there is a clear opportunity for organizations to play “moneyball” in their search for high-ROI talent: empower your team to hire remote employees.

Over 43% of U.S. workers telecommuted in the past year, a substantial increase from the 9% who said the same in 1995.

In 2016, the employee engagement firm TinyPulse conducted a survey of over 500 remote employees and found that they were happier, felt more valued, and were overwhelmingly more productive than their on-location peers. Over 43% of U.S. workers telecommuted in the past year, a substantial increase from the 9% who said the same in 1995. In the aggregate, companies that allow remote work have demonstrated lower stress, greater efficiency and lower turnover in their workforce.

Adapting your organization to accommodate distributed teams is no easy feat. But in our view, sticking with the status quo presents an even bigger risk. We believe companies that resist the move to remote are like old-school talent scouts: they’re doing an excellent job following sound advice from twenty years ago. On the other hand, organizations that embrace remote work are playing moneyball: everyone will follow their lead in the near future, but for the time being they’re rewarded with a substantial competitive advantage.

In this article, we lay out the common objections to distributed teams, and share our experience in addressing these pitfalls with five recommendations that cover best practices in hiring, measuring the right metrics, management, tools and culture.

Common Concerns With Distributed Teams

Seasoned executives might have a residual fear of distributed development teams that stems from experience in the early outsourcing era. Newer executives may be tempted to rely on conventional wisdom to dismiss remote teams out of hand. Both groups tend to cite the following concerns:

• Quality: Nearly twenty years ago, the first exposure to distributed teams occurred in the context of a traditional outsourcing model, driven entirely by cost savings. Collaboration felt impossible: tools we take for granted today like Slack or GitHub didn’t exist, e-mail exchanges took days because of time zone issues, bandwidth was costly—and for some reason, everyone was surprised when the software built by the cheapest developers we could find turned out to be lousy.
• Visibility: Project managers hate surprises. This is the reason why a factory manager inspects the production line regularly, or a construction foreman sits at a desk in a trailer at the job site. Of course, there aren’t many cases when you need physical proximity to inspect progress in a software product or professional service engagement—other than proximity to a good Wi-Fi connection or mobile tower—but presence has retained its importance among managers of all kinds.
• Agile Orthodoxy: We see many companies considering or actively implementing an Agile transformation. As part of that transformation, they tend to seek guidance for their executives from Agile books, coaches and consulting firms. When it comes to building teams, these experts tend to say the same thing: “Your teams should be co-located.” This was sound advice fifteen years ago—in many ways, Agile was a reaction to the conditions above that made collaboration next to impossible across distances, and made rigid waterfall project management practices necessary.

Thanks in large part to improved technology for collaboration and communication, the conditions that led to these concerns no longer exist. By employing the five best practices outlined below, organizations will be well equipped to build high-performing distributed teams and maximize the transformative potential of remote work.

1. Hire For Remote Compatibility

Not everyone is made for remote work. Think about the traits you value in a top developer: engineering and technical excellence, the ability to work well in a team setting, open and honest communication. Assessing how soft skills in particular will translate in a remote setting is challenging, so here are some characteristics to look for:

• Proactive: Physical proximity makes it easier to have frequent check-ins; barring that resource, the best hires are self-starters who don’t need tasks assigned or constant guidance to get things done.
• Ruthless at prioritizing: Good remote workers have an intuitive sense for what’s important and what isn’t on a given project, narrowing in on what matters.
• Proficient writing skills: Communication on remote teams usually takes a written form, which makes writing skills especially crucial for remote teams.

Where do you find these remote superstars? People with the attributes above typically have startup backgrounds or previous freelance engagements that enable them to build a track record of achievement in unstructured environments.

2. To Manage Distributed Teams, Create a Sandbox

A frequent concern we hear about distributed development teams is the difficulty of enforcing team norms, coding standards and practices, and project management processes. In our experience, productive teams are empowered and self-governing, with a good deal of latitude around establishing standards on their own.

Remote teams are no exception, but management must take special care to ensure that controls are in place. As a general principle for managing distributed teams, we like to use the analogy of a sandbox. The edges of the box represent boundaries for the team: agreed-upon constraints like sprint ceremonies, tools and frameworks to be used, code coverage expectations, etc.

In other words, the framework and processes for collaboration should be firmly defined, but software development is just as much art as science, so it’s important that remote employees have the latitude to be creative within the sandbox.

3. Train Managers to Track Outcomes, Not Output

Consciously or not, some managers measure productivity by the number of hours spent at a desk as opposed to the results of that work. But a developer generating thousands of lines of sub-par code should not be considered more productive than one who generates a few hundred lines of excellent code in the same period of time.

For remote teams in particular, it is crucial that productivity metrics measure quality of outcomes instead of mere 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? Remote teams must be assessed against the right metrics, since managers have less visibility into the process of doing the work itself and no way to give partial credit by observing their employees “showing the work.”

4. Use The Right Tools

Tools are the main reason that remote work is thriving today. Modern communication and collaboration apps are the scaffold that supports distributed teams in addressing the pitfalls of earlier eras. We like to say that when people are on Slack, they’re in the office—here’s our list of essential tools:

• Real-time chat: Real-time chat is a vital tool for a remote team. You want to be able to replicate the immediate interaction and collaboration that you would have in a collocated team. Not only is real-time chat essential for communication, but it’s also helpful for building a remote culture. For this to succeed, it is vital that all team communication is centralized in single place—remember, the sandbox needs walls. At Toptal, we use Slack, but alternatives include HipChat, Flowdock, and Skype.
• Information radiators: Without in-person interactions to socialize information, you’ll need an online wiki and story wall to radiate information to the team. In Agile or Kanban development, the entire team and all associated stakeholders should have access to immediate information about the status of development—stories in flight, waiting for testing, defects, etc. The team should also have access to dashboards for the build pipeline and status, code coverage, and other key data. As a remote manager, you want a single source of truth for each area of information the team and stakeholders are relying on for status.
• Video conferencing: Real-time video chat is an essential complement to instant messaging—in our experience, there’s nothing like actually talking to another human being. At Toptal, we use Zoom, Slack calls and occasionally Skype for one-on-ones, status meetings and code showcases. Daily scrum stand-ups via video conferencing are a great way to build team culture and trust.

5. Embrace Ceremonies

You probably have a number of team ceremonies occurring at fixed points in each sprint—planning and estimation meetings, code review, software demos. Schedule these in such a way that all team members, regardless of location, can participate. Ideally, the team will have several hours a day where they are all online and working.

While it is natural to be concerned about time zones when building distributed teams, in our experience a plurality of people who have chosen careers in remote software development prefer working outside of the traditional 9-5 work day—and are often far more productive when allowed to do so. To the greatest extent possible, allow the team to define the times that work best for them.

Conclusion: You Might Already Rely On Distributed Teams

Even if your organization hasn’t directly utilized a distributed development model, you’re probably leveraging its benefits to a significant degree: the odds are that you’re using open-source software.

By its very nature, open-source development has been distributed from the beginning. Innovation in the open-source world occurs at a staggering pace, and evolving engineering practices help drive that pace: one of the first challenges that early open-source projects resolved was online collaboration and transparency of process for distributed teams.

Whether you’re following the lead of the open source world, or taking a cue from Michael Lewis to play “moneyball” in the talent-driven world of software development and professional services, consider the constraints you impose on your organization by insisting that they can only hire from local talent pools.

A cultural shift of this magnitude is a significant undertaking, but you can kick start the transition right away: let go of the in-office orthodoxy, welcome distributed teams, and enable them to reach their potential by providing team members with the metrics, management, tools and culture to get the job done wherever they may be working from.