Leadership

Going Distributed

Choosing the Right Remote-Friendly Team Model
Published
December 9, 2019
Author
No items found.
Share
#
min read

This is part one in a “how-to” series for building effective distributed teams. We’ve compiled advice from CEOs and functional leaders to help you better understand how to structure a distributed team, best practices for hiring and managing distributed and blended teams, and what tools you’ll need to be successful.

A business lives or dies by the quality of its people — and increasingly, the best people are demanding more flexibility in where and how they work. Some cannot or prefer not to relocate to a major city such as San Francisco. Others simply find it distracting to work in an office or want to avoid hours stuck in traffic, which costs the U.S. alone billions each year in lost productivity. Today, 70% of employees list telecommuting options as an important factor in choosing their next job. Telecommuting is also a big factor in whether they stay in a job. In one recent study, 74% of respondents said the ability to work remotely would make them less likely to leave their employer.

In response to tight talent pools and evolving employee preference, more companies are embracing distributed workforces. In some cases, this means being open to hiring remote individuals from around the globe. In others, it means establishing a second headquarters or multiple non-HQ offices. And increasingly, this may mean spinning up a fully distributed team with no headquarters and no owned offices.

Through our work with companies like Stripe, Samsara, and Livongo that represent permutations of these distributed team models, we’ve seen that benefits go beyond attracting and retaining great workers. These benefits have been documented in a Stanford study that found a dramatic increase in productivity among remote employees — the equivalent of an additional full day’s work per week. And another study by Global Workplace Analytics found each full-time remote worker can save their employer up to $10,000 in real estate costs per year. As the trend toward distribution races forward, we believe a thoughtful approach to remote work will become an important differentiator for a company built to endure.

Even if you’re committed to “going remote,” the possibilities may seem overwhelming. Should you adopt a fully remote model? Open satellite offices? Establish multiple headquarters? Should a distributed work option be offered to everyone or just certain employees — and does it depend on their role? Their team? Their current office? When in your company’s development should you take the leap? Most importantly, how do you make sure distributed employees are supported — and successful?

To answer these questions, we talked to leaders and remote work leaders at Gusto, GitLab, and Stripe about their different approaches to distributed teams.

1. How and When to Go Remote
Making the Call: How and When to Go Remote

GitLab CEO Sid Sijbrandij at the Making Remote Work 2019 conference. (Photo credit: Slava Blazer Photography)

For CEO Sid Sijbrandij, GitLab’s all-remote model was less a decision and more a natural evolution. “After Y Combinator, we started out with nine of us in a house, but people just stopped showing up. There was no need to be in person, and it saved us commuting time.” Only a few years earlier, that may not have been true, but improvements in tools like Slack, Zoom, Google Docs, along with more reliable internet service, were making remote work easier than ever. Plus, hiring outside of San Francisco added valuable perspectives to the team. GitLab found that hiring remotely wasn’t just more affordable for the company, it also gave them greater opportunity for building a more diverse team.

As GitLab grew, some teams were initially co-located, but even in those cases, the employees would gradually transition to working from home. So somewhere between 100 and 200 employees, Sijbrandij and the team made it official: GitLab was a fully remote company.

Gusto was at a similar headcount when conversations began about hiring outside San Francisco. But for co-founder and Head of Engineering Eddie Kim, the timing was more about speed than size.

Gusto co-founder Eddie Kim. (Photo credit: Gusto)

“When you have multiple locations, it’s much easier to hire as many engineers as we need to every quarter,” he says. The company’s maturity was a factor, too. “We were large enough that we’d built the muscle of documenting things, which is critical with distributed teams.”

Though Gusto did have a few remote workers in various North American cities, they were primarily former on-site team members who’d moved but stayed on. Kim and his colleagues preferred to maximize co-location — especially for the fast-growing Customer Experience (CX) team, which works closely with Engineering. “There are a lot of benefits to actually sitting together, from the culture and camaraderie you can build, to how you navigate difficult conversations,” he says. So instead of a major remote expansion, they decided on a different approach: an HQ2.

Based on factors including time zone and cost of living, they identified several possible cities and sent teams to interview CX candidates in each. “From there, it was about which group was aligned with our culture and values. Denver was the obvious choice for us.” They formed a “landing team” of 10 current CX employees, who were also Gusto “culture keepers,” to spend three months setting up the new office. Some came back to San Francisco, but several ended up staying.

Like GitLab and Gusto, Stripe’s approach to remote work has evolved over time. In 2015, for example, with 30% of the team already distributed, Stripe decided to temporarily pause further remote growth. “At the time, we were scaling some operational groups that Engineering needed to collaborate with,” explains CTO David Singleton. “We wanted them to be co-located while we figured those things out.”

As workflows and relationships have developed — and as technologies have improved — Stripe has again begun to grow its remote team. Last year, it adopted a new “remote hub,” modeled after the company’s engineering hubs in San Francisco, Seattle, Dublin, and Singapore. “We thought a lot about what makes a new office successful — that we’re deliberate about connecting it with the rest of the company, that leaders travel there frequently, that we do events with the local community,” Singleton says. To support the remote team, they reasoned, they should create as many direct analogs as they could.

2. Best practices and pitfalls for distributed teams
Getting started: Best practices and pitfalls for distributed teams

For many companies with distributed teams, the biggest question is which roles should be remote — and which shouldn’t. At Stripe, most engineering teams are a mix of remote workers and those on-site. “We’ve found when our remote people are working directly with people at the physical offices, they’re not as likely to get sidelined on less-important projects,” Singleton says. The company is also thoughtful about the regions in which they can support remote work at scale. It’s already widely available in North America, where physical locations are established enough to support it — but just getting started in Europe as the Dublin office continues to grow. The company is also deliberate about when they allow remote work from new locations.

For Gusto, the launch of HQ2 offered an entirely different lesson: They preferred the members of a given team to be co-located whenever possible. After starting with CX in Denver, engineering hires had quickly followed. But at first, most Denver-based engineers were still contributors to San Francisco–based teams. Kim and his team decided instead to base four specific engineering teams in Denver (the ones that collaborate most with CX), so members — and leaders — could work side-by-side.

Gusto’s CEO, Josh Reeves, also insisted on hiring a C-level leader in Denver, to help represent the office. Finding CPO Danielle Brown took more than a year, but Gina Hinman-Trulli, the company’s former head of people partners, says it was worth the wait. “I give Josh a ton of kudos because that was a smart call. I was actually a little worried at first about the CPO not being in San Francisco with the rest of the leadership team. But Danielle’s been great at building relationships from Denver.”

Another challenge for nearly every distributed team? Time zones. Even with Gusto’s emphasis on co-location, the company will have to reschedule its mid-afternoon all-hands meetings as it prepares to open an HQ3 in New York. And for GitLab, with employees in 60 countries, scheduling is a next-level challenge.

GitLab’s entirely public company handbook.

So, too, is part of its solution: in addition to best practices like heavy reliance on asynchronous communication, and recording and sharing all meetings for those who can’t attend, GitLab maintains a 3,000-page publicly available online handbook that serves as a platform for proposing, discussing, and documenting decisions around nearly every aspect of the company. It’s also a valuable resource for other teams considering working remotely.

Documentation is something all companies should do, but because we’re all-remote, we’re always thinking about it,” explains Darren Murph, head of remote at GitLab. “It becomes less of a chore and more of a habit.”

The goal of the handbook is not to enforce dogma, but to answer questions as efficiently as possible. “GitLab gets great reviews in terms of being responsive to questions. Part of the reason for that is we have fewer questions to answer, and that’s thanks to the handbook,” Sijbrandij explains. When a question comes up that the handbook hasn’t addressed, the team takes the opportunity to create a new page — then answers the question with a link.

Gusto and Stripe have adopted similar tools, from team wikis to “email transparency” practices in which every decision gets written up and sent to a mailing list. Over time, employees have learned to default to asynchronous communication even when they’re in the same office. “It might feel weird to Slack someone who’s across the room,” Kim says. “But it really helps us be inclusive of the people in Denver.”

3. Supporting remote workers — and their teammates
The long haul: Supporting remote workers — and their teammates

Practices like documentation and asynchronous communication go a long way but supporting remote workers requires countless subtle but important cultural shifts. “You need to consistently pay attention to lots of little details,” says Aditya Mukerjee, a risk engineer and remote worker at Stripe who was recently named site lead for the company’s remote hub. “It’s about making sure the company culture respects remote workers as first-class citizens.”

In his site lead role, Mukerjee tracks the health of the remote hub across dimensions like hiring, training, and assignments; helps develop Stripe’s policies around distributed teams; and serves as a point of contact for issues remote workers face. The first step was simply understanding, via team surveys as well as one-on-one conversations, the common needs and pain points of his remote colleagues. Armed with that information, he’s now developing guides to help managers and employees navigate the transition to remote work. And because remote workers’ pain points are often shared by on-site workers in non-HQ offices, some of those solutions may have an even broader reach.

Among Mukerjee’s recommendations is that each team holds one meeting a week where everyone joins via their laptop — even members who work in the same office. “It’s a reminder for on-site people of what it’s like to be remote,” he says.

Gusto and GitLab, too, have developed norms to help ensure remote workers have a voice, such as defaulting to video rather than audio for remote calls, including video conference links in every event invite by default, and inviting remote employees to speak first during meetings.

Sijbrandij argues the so-called “collisions” often cited as support for co-location can be replaced and even improved upon via video — but notes those interactions won’t happen on their own. To encourage work-related “serendipity,” GitLab maintains Slack feeds and changelogs that team members can use to follow what their colleagues are working on — and the company carves out time for non-work chats, as well.

“You do want to be able to see the person behind the work, and it can be easy to lose that in a remote environment. There’s no waiting in the conference room or walking over to the meeting,” Sijbrandij says. To close that gap, GitLab teams hold hour-long “socials” each week to catch up, and individual employees regularly schedule virtual “coffee chats” with their colleagues.

“In the early days of remote teams, the thinking was you’d put your headphones on, code all day, and never talk to anyone. But that didn’t work. People were lonely!” Hinman-Trulli says.

“Employees do want the human connection. They just want it in a way that doesn’t require them to live in a particular city or have an hour-and-a-half commute.”

All three companies recognize the value of in-person face time, as well. Reeves travels to Denver for every other Gusto all-hands, and Kim does the same for Engineering all-hands. The company also has a generous travel policy for employees — simply shadowing another team is reason enough. GitLab, too, offers a travel stipend to help team members visit each other and work together in person, and hosts a weeklong company on-site each year that mixes group excursions with sessions on topics like preventing burnout.

“At a co-located company where people get to see each other every day, your first thought about that week of work travel might be, ‘How do I get out of this?’” says Murph. “Here, people can’t wait. They have it marked on their calendars months out.”

4. Distributed teams and the future of work
Looking forward: Distributed teams and the future of work

From workflows to cultural norms, “it’s definitely a lot more work to do remote right,” says Kim. “But in terms of employee engagement and ownership, it will pay for itself over and over again.” With the launch of HQ2, his team learned to tailor everything from training practices to internal messaging to the unique needs of each office — and will now expand that playbook, based in part on the team’s feedback, as they launch HQ3. “It’s really been a forcing function to get better at remote. Now we can put those learnings into practice in New York.”

At Stripe, too, Singleton, Mukerjee, and their colleagues are drawing on the experience of current remote workers to seed best practices that can help them grow the hub. The responses to the company’s biannual employee survey, which includes several questions on distributed work culture, will be important to inform their work — but what may be most important is that those questions are being asked in the first place.

“Just being aware of and actually caring about the remote experience is big,” Mukerjee says. “It’s something a lot of companies don’t do, but that’s how you establish remote as part of your team culture.”

And at GitLab, where distributed teams are already a way of life, Sijbrandij and Murph see an opportunity to lead the way toward an increasingly remote-friendly world. “I think we’re coming close to a tipping point with remote,” says Murph. “Instead of distributed teams having to justify why they do it, it’s going to be the other companies having to justify why they don’t.”

Going Distributed: Choosing the Right Remote-Friendly Team Model

Published
December 9, 2019
Author
No items found.
Share
#
min read

This is part one in a “how-to” series for building effective distributed teams. We’ve compiled advice from CEOs and functional leaders to help you better understand how to structure a distributed team, best practices for hiring and managing distributed and blended teams, and what tools you’ll need to be successful.

A business lives or dies by the quality of its people — and increasingly, the best people are demanding more flexibility in where and how they work. Some cannot or prefer not to relocate to a major city such as San Francisco. Others simply find it distracting to work in an office or want to avoid hours stuck in traffic, which costs the U.S. alone billions each year in lost productivity. Today, 70% of employees list telecommuting options as an important factor in choosing their next job. Telecommuting is also a big factor in whether they stay in a job. In one recent study, 74% of respondents said the ability to work remotely would make them less likely to leave their employer.

In response to tight talent pools and evolving employee preference, more companies are embracing distributed workforces. In some cases, this means being open to hiring remote individuals from around the globe. In others, it means establishing a second headquarters or multiple non-HQ offices. And increasingly, this may mean spinning up a fully distributed team with no headquarters and no owned offices.

Through our work with companies like Stripe, Samsara, and Livongo that represent permutations of these distributed team models, we’ve seen that benefits go beyond attracting and retaining great workers. These benefits have been documented in a Stanford study that found a dramatic increase in productivity among remote employees — the equivalent of an additional full day’s work per week. And another study by Global Workplace Analytics found each full-time remote worker can save their employer up to $10,000 in real estate costs per year. As the trend toward distribution races forward, we believe a thoughtful approach to remote work will become an important differentiator for a company built to endure.

Even if you’re committed to “going remote,” the possibilities may seem overwhelming. Should you adopt a fully remote model? Open satellite offices? Establish multiple headquarters? Should a distributed work option be offered to everyone or just certain employees — and does it depend on their role? Their team? Their current office? When in your company’s development should you take the leap? Most importantly, how do you make sure distributed employees are supported — and successful?

To answer these questions, we talked to leaders and remote work leaders at Gusto, GitLab, and Stripe about their different approaches to distributed teams.

1. How and When to Go Remote
Making the Call: How and When to Go Remote

GitLab CEO Sid Sijbrandij at the Making Remote Work 2019 conference. (Photo credit: Slava Blazer Photography)

For CEO Sid Sijbrandij, GitLab’s all-remote model was less a decision and more a natural evolution. “After Y Combinator, we started out with nine of us in a house, but people just stopped showing up. There was no need to be in person, and it saved us commuting time.” Only a few years earlier, that may not have been true, but improvements in tools like Slack, Zoom, Google Docs, along with more reliable internet service, were making remote work easier than ever. Plus, hiring outside of San Francisco added valuable perspectives to the team. GitLab found that hiring remotely wasn’t just more affordable for the company, it also gave them greater opportunity for building a more diverse team.

As GitLab grew, some teams were initially co-located, but even in those cases, the employees would gradually transition to working from home. So somewhere between 100 and 200 employees, Sijbrandij and the team made it official: GitLab was a fully remote company.

Gusto was at a similar headcount when conversations began about hiring outside San Francisco. But for co-founder and Head of Engineering Eddie Kim, the timing was more about speed than size.

Gusto co-founder Eddie Kim. (Photo credit: Gusto)

“When you have multiple locations, it’s much easier to hire as many engineers as we need to every quarter,” he says. The company’s maturity was a factor, too. “We were large enough that we’d built the muscle of documenting things, which is critical with distributed teams.”

Though Gusto did have a few remote workers in various North American cities, they were primarily former on-site team members who’d moved but stayed on. Kim and his colleagues preferred to maximize co-location — especially for the fast-growing Customer Experience (CX) team, which works closely with Engineering. “There are a lot of benefits to actually sitting together, from the culture and camaraderie you can build, to how you navigate difficult conversations,” he says. So instead of a major remote expansion, they decided on a different approach: an HQ2.

Based on factors including time zone and cost of living, they identified several possible cities and sent teams to interview CX candidates in each. “From there, it was about which group was aligned with our culture and values. Denver was the obvious choice for us.” They formed a “landing team” of 10 current CX employees, who were also Gusto “culture keepers,” to spend three months setting up the new office. Some came back to San Francisco, but several ended up staying.

Like GitLab and Gusto, Stripe’s approach to remote work has evolved over time. In 2015, for example, with 30% of the team already distributed, Stripe decided to temporarily pause further remote growth. “At the time, we were scaling some operational groups that Engineering needed to collaborate with,” explains CTO David Singleton. “We wanted them to be co-located while we figured those things out.”

As workflows and relationships have developed — and as technologies have improved — Stripe has again begun to grow its remote team. Last year, it adopted a new “remote hub,” modeled after the company’s engineering hubs in San Francisco, Seattle, Dublin, and Singapore. “We thought a lot about what makes a new office successful — that we’re deliberate about connecting it with the rest of the company, that leaders travel there frequently, that we do events with the local community,” Singleton says. To support the remote team, they reasoned, they should create as many direct analogs as they could.

2. Best practices and pitfalls for distributed teams
Getting started: Best practices and pitfalls for distributed teams

For many companies with distributed teams, the biggest question is which roles should be remote — and which shouldn’t. At Stripe, most engineering teams are a mix of remote workers and those on-site. “We’ve found when our remote people are working directly with people at the physical offices, they’re not as likely to get sidelined on less-important projects,” Singleton says. The company is also thoughtful about the regions in which they can support remote work at scale. It’s already widely available in North America, where physical locations are established enough to support it — but just getting started in Europe as the Dublin office continues to grow. The company is also deliberate about when they allow remote work from new locations.

For Gusto, the launch of HQ2 offered an entirely different lesson: They preferred the members of a given team to be co-located whenever possible. After starting with CX in Denver, engineering hires had quickly followed. But at first, most Denver-based engineers were still contributors to San Francisco–based teams. Kim and his team decided instead to base four specific engineering teams in Denver (the ones that collaborate most with CX), so members — and leaders — could work side-by-side.

Gusto’s CEO, Josh Reeves, also insisted on hiring a C-level leader in Denver, to help represent the office. Finding CPO Danielle Brown took more than a year, but Gina Hinman-Trulli, the company’s former head of people partners, says it was worth the wait. “I give Josh a ton of kudos because that was a smart call. I was actually a little worried at first about the CPO not being in San Francisco with the rest of the leadership team. But Danielle’s been great at building relationships from Denver.”

Another challenge for nearly every distributed team? Time zones. Even with Gusto’s emphasis on co-location, the company will have to reschedule its mid-afternoon all-hands meetings as it prepares to open an HQ3 in New York. And for GitLab, with employees in 60 countries, scheduling is a next-level challenge.

GitLab’s entirely public company handbook.

So, too, is part of its solution: in addition to best practices like heavy reliance on asynchronous communication, and recording and sharing all meetings for those who can’t attend, GitLab maintains a 3,000-page publicly available online handbook that serves as a platform for proposing, discussing, and documenting decisions around nearly every aspect of the company. It’s also a valuable resource for other teams considering working remotely.

Documentation is something all companies should do, but because we’re all-remote, we’re always thinking about it,” explains Darren Murph, head of remote at GitLab. “It becomes less of a chore and more of a habit.”

The goal of the handbook is not to enforce dogma, but to answer questions as efficiently as possible. “GitLab gets great reviews in terms of being responsive to questions. Part of the reason for that is we have fewer questions to answer, and that’s thanks to the handbook,” Sijbrandij explains. When a question comes up that the handbook hasn’t addressed, the team takes the opportunity to create a new page — then answers the question with a link.

Gusto and Stripe have adopted similar tools, from team wikis to “email transparency” practices in which every decision gets written up and sent to a mailing list. Over time, employees have learned to default to asynchronous communication even when they’re in the same office. “It might feel weird to Slack someone who’s across the room,” Kim says. “But it really helps us be inclusive of the people in Denver.”

3. Supporting remote workers — and their teammates
The long haul: Supporting remote workers — and their teammates

Practices like documentation and asynchronous communication go a long way but supporting remote workers requires countless subtle but important cultural shifts. “You need to consistently pay attention to lots of little details,” says Aditya Mukerjee, a risk engineer and remote worker at Stripe who was recently named site lead for the company’s remote hub. “It’s about making sure the company culture respects remote workers as first-class citizens.”

In his site lead role, Mukerjee tracks the health of the remote hub across dimensions like hiring, training, and assignments; helps develop Stripe’s policies around distributed teams; and serves as a point of contact for issues remote workers face. The first step was simply understanding, via team surveys as well as one-on-one conversations, the common needs and pain points of his remote colleagues. Armed with that information, he’s now developing guides to help managers and employees navigate the transition to remote work. And because remote workers’ pain points are often shared by on-site workers in non-HQ offices, some of those solutions may have an even broader reach.

Among Mukerjee’s recommendations is that each team holds one meeting a week where everyone joins via their laptop — even members who work in the same office. “It’s a reminder for on-site people of what it’s like to be remote,” he says.

Gusto and GitLab, too, have developed norms to help ensure remote workers have a voice, such as defaulting to video rather than audio for remote calls, including video conference links in every event invite by default, and inviting remote employees to speak first during meetings.

Sijbrandij argues the so-called “collisions” often cited as support for co-location can be replaced and even improved upon via video — but notes those interactions won’t happen on their own. To encourage work-related “serendipity,” GitLab maintains Slack feeds and changelogs that team members can use to follow what their colleagues are working on — and the company carves out time for non-work chats, as well.

“You do want to be able to see the person behind the work, and it can be easy to lose that in a remote environment. There’s no waiting in the conference room or walking over to the meeting,” Sijbrandij says. To close that gap, GitLab teams hold hour-long “socials” each week to catch up, and individual employees regularly schedule virtual “coffee chats” with their colleagues.

“In the early days of remote teams, the thinking was you’d put your headphones on, code all day, and never talk to anyone. But that didn’t work. People were lonely!” Hinman-Trulli says.

“Employees do want the human connection. They just want it in a way that doesn’t require them to live in a particular city or have an hour-and-a-half commute.”

All three companies recognize the value of in-person face time, as well. Reeves travels to Denver for every other Gusto all-hands, and Kim does the same for Engineering all-hands. The company also has a generous travel policy for employees — simply shadowing another team is reason enough. GitLab, too, offers a travel stipend to help team members visit each other and work together in person, and hosts a weeklong company on-site each year that mixes group excursions with sessions on topics like preventing burnout.

“At a co-located company where people get to see each other every day, your first thought about that week of work travel might be, ‘How do I get out of this?’” says Murph. “Here, people can’t wait. They have it marked on their calendars months out.”

4. Distributed teams and the future of work
Looking forward: Distributed teams and the future of work

From workflows to cultural norms, “it’s definitely a lot more work to do remote right,” says Kim. “But in terms of employee engagement and ownership, it will pay for itself over and over again.” With the launch of HQ2, his team learned to tailor everything from training practices to internal messaging to the unique needs of each office — and will now expand that playbook, based in part on the team’s feedback, as they launch HQ3. “It’s really been a forcing function to get better at remote. Now we can put those learnings into practice in New York.”

At Stripe, too, Singleton, Mukerjee, and their colleagues are drawing on the experience of current remote workers to seed best practices that can help them grow the hub. The responses to the company’s biannual employee survey, which includes several questions on distributed work culture, will be important to inform their work — but what may be most important is that those questions are being asked in the first place.

“Just being aware of and actually caring about the remote experience is big,” Mukerjee says. “It’s something a lot of companies don’t do, but that’s how you establish remote as part of your team culture.”

And at GitLab, where distributed teams are already a way of life, Sijbrandij and Murph see an opportunity to lead the way toward an increasingly remote-friendly world. “I think we’re coming close to a tipping point with remote,” says Murph. “Instead of distributed teams having to justify why they do it, it’s going to be the other companies having to justify why they don’t.”

Going Distributed: Choosing the Right Remote-Friendly Team Model