Remote and distributed work provides the advantage of drawing from a broad, diverse talent pool, but it can also exacerbate coordination and communication problems—especially at scale.

Leaders of distributed engineering teams shouldn’t have to work up solutions to these problems from scratch. So we held a panel discussion with three of today’s top engineering leaders to discuss approaches and lessons learned in building, growing, and maintaining remote and distributed teams.

The three panelists for this discussion were:

• Eric Muntz, SVP of Technology at Mailchimp. Mailchimp’s engineering team is about 350 people, both distributed and remote, across the United States.
• Katie Womersley, VP of Engineering at Buffer. Buffer has a fully distributed engineering team—no home base, no hub, no offices. The engineering org is 35 people worldwide, covering nearly every time zone.
• Tim Armandpour, SVP of Engineering at PagerDuty. PagerDuty’s engineering org is about 150 people, with ten percent of those working full-time remote across North America.

You can view the entire panel discussion on Leading Remote and Distributed Teams here (or listen to it on Soundcloud), or read on for the top takeaways from the panel discussion. These include how to counter isolation and silos by keeping teams in the loop, how to handle time zone differences, what to look for in the hiring process, and onboarding strategies for remote engineers.

 

How do you keep remote and distributed teams in the loop and prevent the feeling that people are siloed and isolated?

Keeping all these people, who are working in different buildings and time zones and countries, connected to each other and the organization is one of the great obstacles of leading remote and distributed teams. A team, after all, is more about unity than it is about having a bunch of people doing disparate jobs.

“In our most recent engagement survey, our team is telling us that they don’t know what’s going on in other teams, despite that being one of our major focuses,” Womersley says. “So yes, that is a real challenge.”

These are strategies that these three tech leaders have used in their organizations to improve connectivity and reduce isolation:

DOCUMENT EVERYTHING

And they mean everything. Every decision, every goal, and the conversations and information that lead to those outcomes.

“Documentation is key,” Armandpour says. “We work with the presumption across the board that when your water cooler conversation turns into a decision, you must document it.”

When a team has employees in other locations, they are by default going to be left out of in-office conversations, as well as the video calls and emails between individual team members. Womersley suggests a first step of moving a team’s discussions into an internet-based tool or platform to level the playing field for your own workforce. By starting the conversations there, you eliminate the need to document conversations that happen elsewhere.

“I feel the most important thing that we've done at Buffer to keep folks in the loop is to very intentionally document our decisions,” she says. “Get everything you’re deciding online.”

MAKE BIG DECISIONS IN MEETINGS, RATHER THAN IN ASYNCHRONOUS CHATS

All that said, Womersley’s next piece of advice is this: Don’t make decisions in Slack.

“I know that's the default for a lot of us remote teams because it's where work happens,” she says. But what she found at Buffer is that making decisions in an asynchronous chat forced her teams to choose between watching that conveyor belt of messages—instead of doing deep work—or getting their work done at the expense of being left out of important conversations.

So while Slack and its counterparts are great for chatter and asynchronous chats, Buffer now schedules synchronous meetings for making the big decisions. Furthermore, her teams use online document tools to issue RFCs and to develop structured, written decision-making that can happen asynchronously.

BE INTENTIONAL ABOUT COMMUNICATION FLOWS

This idea umbrellas the previous two pieces of advice, but goes beyond them as well. Leaders of distributed teams can develop communication strategies that ease the delivery of critical information, as well as regularly moderating communication between teams and projects.

“When decisions are made, you make sure that they flow through the right channels and the right people in the right direction,” Muntz advises. “Making sure that leadership teams are in the loop and aligned and ready to answer questions before the rest of the individual contributors get the information has been super helpful for us.”

Armandpour has also found an asynchronous, global, weekly stand-up helpful for keeping everyone’s finger on the pulse of the organization. These info-sharing sessions have their own guidelines that keep communication open.

“We don’t use siloed acronyms that only one team knows, and we actually spell things out,” he says. “People start threading and asking questions, clarifying. A lot of that has helped bridge the gaps. Everyone only reads so much email. You can only say so many things at all-hands. We’re still trying to figure out the secret sauce, but every year it gets better. We’re figuring out creative ways to use the various tools at our disposal.”

 

How do you deal with time zone differences?

Of course, communication strategies within a distributed team are shaped largely by time zones. There’s no center of the world, and no escaping the fact that lunchtime in one city is midnight in another. Armandpour stresses the importance of empathy in handling time zone differences—the recognition, understanding, and acceptance that no one person’s time zone is the center of the world.

“If you can build up the right amount of empathy for each other, you can make mountains move,” he says. “Without that, trust breaks down, communications break down. We all have to move at this rapid, frenetic, maniacal pace, and if you can be rooted in empathy, you have a fighting chance. Engineering is still a human sport at the end of the day.”

These approaches to handling time zone differences are each rooted in that idea of empathy for everyone within the team.

CONSIDER WHICH TIME ZONES TO HIRE IN AND BUILD AROUND

Perhaps the most straightforward way to facilitate time-centric empathy between teammates is to build a team within just a few hours of each other.

“We’ve got plus or minus three hours,” Armandpour says. “It works fairly well. It’s not terribly hard. People can offset their days. Some days the West Coast folks are up earlier, and vice versa. People are very accommodating.”

Womersley’s teams, on the other hand, are distributed around the globe, from the United States to London and Beijing and just about every time zone in between. “In general, we don’t set up our teams quite that distributed,” she says. Teams are focused around overlapping time zones, even though the organization as a whole draws from a worldwide talent pool.

REMOTE IS NATURALLY FLEXIBLE FOR EMPLOYEES; ASK FOR FLEXIBILITY IN RETURN

Womersley’s teams, on the other hand, are distributed around the globe, from the United States to London and Beijing. No one is expected to attend a 7:00 PM meeting every night simply because they’re in a different time zone. Even so, Womersley says to new hires, “You're going to be given a lot of flexibility, but Buffer is going to ask flexibility from you as well."

She offers an example of hypothetical West Coast hires who will be working with European teammates. They already have an eight- or nine-hour difference, so those hires may not have the flexibility to start work at ten o’clock in the morning every day. They’ll need to be available more often at eight to enable some overlap. In return, they will have more flexibility later in the day, when their colleagues are home for the night.

“We're quite happy for people to jump out in the middle of the day, do whatever they need to do, spend time with their kids, but maybe there's going to be a later meeting happening at 6:30 PM their time,” she adds. “It is a balance. We need to be respectful of people's lives.”

STRIKE A BALANCE BETWEEN SYNC AND ASYNC

Working with remote teams is not an either/or choice between synchronous and asynchronous. Rather, it doesn’t have to be. For many teams, the truest balance lies somewhere in the middle.

Womersley’s teams at Buffer have tried out both extremes.

“We've leaned into almost fully asynchronous, really discouraged meetings, and it was great for a very short period of time,” she says. “Decisions were slow. People complained about isolation, disconnection, lack of context. It took forever to get what they needed.”

They then spun the organization the other way to fully synchronous, and distributed team members struggled with the set hours they needed to be online. They felt like they couldn’t keep up and had little chance to get their deep work done. Neither extreme allowed her teams to perform consistently or efficiently.

“I feel like this is pendular,” Womersley says, “and we’re slowly learning to keep ourselves in the green zone there between sync and async.”

DON'T PRETEND TIME ZONES AREN'T A THING

For teams contemplating going distributed, Muntz sees a danger in trying to make it so time zones don’t exist. Rather, he suggests encouraging everyone to be hyper-aware of the team’s time zone differences.

“We can’t just all pretend that we’re in one time zone,” he says. “We have to be cognizant of the fact that we’re not. People have families and obligations. They need to sleep.”

He sees a serious need for empathy in scheduling. Most of the people at Mailchimp are in the Eastern time zone, and so people in the Pacific time zone often get 6:00 AM invites. “We have to train our teams to set their calendars to automatically decline meetings outside of your working times so that people see it happen the instant they try to set up the meeting,” he says.

Scheduling meetings and other synchronous communication to be inclusive of people in different time zones can foster a willingness to be flexible when it’s necessary, as well as going a long way toward keeping teams working together without resentment or classism.

 

What do you look for in the hiring process to determine if engineers will succeed with remote work?

The simple truth is that not every engineer is in ideal circumstances for remote work. For instance, distributed team members tend to work in more solitary settings, so highly extroverted people who value the social aspects of working with a team may not be the best fits for those positions.

Armandpour, Womersley, and Muntz all stress the importance of having frank conversations with candidates about what their reality is going to be like. They offer these three pieces of advice for hiring new remote engineers, as well, to maximize a distributed team’s success.

HIRE PEOPLE WHO'VE DONE REMOTE WORK BEFORE

In order to assess if a remote candidate is going to succeed in a professional capacity, in addition to if they’ll be happy, these leaders err on the side of hiring engineers who have worked remotely before. Distributed teammates have responsibility over their schedules, their workspaces, and their discipline to a different degree than co-located ones, and dialing those in requires time and experience.

“Most of the folks we have hired on to be full-time remote have done it before, so they can say, ‘This worked for me,’ and, ‘This is what I need to be good at this,’” Muntz says.

And the same goes for distributed managers, as well—particularly when an organization is starting to go remote.

“Finding someone with good experience was super helpful for us,” Muntz says. “We have an engineering manager in Colorado, who was a remote manager before, who helped us understand remote strategies. That expertise, and listening to it, is huge.”

LOOK FOR PEOPLE WITH EXPERIENCE IN LESS-STRUCTURED, SELF-DRIVEN ENVIRONMENTS

Of course, every remote engineer has to start sometime. Engineers new to a distributed team can still find success—and there are other traits that can predicate it.

“If they’ve not worked remotely, that’s not a problem, but we’ll look for whether they’ve had a situation where they had a lot of flexibility and freedom, where they had to take initiative, where they had to be a self-starter,” Womersley says. “That can look different for many people. Work in agencies and contract work often translates really well, because those communication skills are really well-honed.”

She notes that self-taught folks tend to do really well in Buffer’s remote organization. That initiative, the growth mindset, and the drive to overcome obstacles all indicate an ability to succeed remotely.

“People who come from environments with a little less structure, with more flexibility and responsibility and ownership of their goals—those can be helpful markers of success,” Womersley says.

NOT EVERYONE WILL BE HAPPY WITH REMOTE WORK, AND THAT'S OKAY 

Muntz recalls a period when he was a full-time remote employee for another company. “I thought it was going to be great,” he says, “and I was pretty miserable. So, I have empathy with the fact that it may not work out so well.”

At Mailchimp, he makes sure to acknowledge that full-time remote work is not necessarily easy for everyone, and he relies on many of the approaches discussed above to make the process smoother for his teams. Yet, he and the other leaders acknowledge that remote work isn’t a one-size-fits-all model.

“Not everyone's going to be happy working remotely,” Womersley says, “and that's okay.”

 

How do you introduce remote teammates into the organization so they have a strong chance of being successful?

Hiring candidates with a proclivity for remote work is one thing—onboarding them in a way that sets them up for meaningful gains is another. Here are three strategies that the panel participants find beneficial in their organizations.

BRING PEOPLE TOGETHER FOR THEIR INITIAL ONBOARDING IN PERSON 

The remote members of a team will mostly be working… well, remotely. But Armandpour insists on bringing all of PagerDuty’s new hires (whether they’re remote or not) to one of the main hubs in Toronto or San Francisco for an onboarding program.

“They'll go through a two-and-a-half-day general onboarding program around PagerDuty, what we're all about, and what our philosophies are,” he says. “Then someone on their team will walk them through getting their environment up and running, and we have a checklist that is specific to the team, detailing what they need to ramp up on quickest.”

The goal is to have engineers’ first pull request in production within a few days, and by doing so while physically located in a major office, new hires get an intensive experience that can shape their remote time from then on out.

ONBOARD FOR CULTURE

Muntz details a similar in-person onboarding process at MailChimp. The first week of every onboarding class is at headquarters in Atlanta, and it’s run by the organization’s culture team.

“My joke is the chip implant doesn't hurt too bad,” he says. “It's a full, solid week of understanding what Mailchimp's culture is, what our history is, what it's all about.”

The company’s two founders do a chat with every single new hire orientation group, which takes place every two weeks. Muntz and another VP in Engineering do a monthly VP storytelling chat with all the new hires to talk through engineering culture—how they came to the organization, what’s been important to the company’s growth, and other anecdotes that shape the company culture.

“The technical aspects of onboarding are going to happen with their teams, where leadership is really about the cultural onboarding,” Muntz says.

PAIR NEW HIRES WITH TENURED PEERS

Womersley points to another strategy that is useful both during the initial orientation phase of onboarding, as well as for a full 90-day process (and beyond): Buffer gives each new hire two buddies in addition to their manager, who is actually overseeing the 30/60/90-day onboarding plan.

The first buddy is usually another engineer on the same team, who is there to help them out with any kinks in their dev environment or whatever technical and procedural things they're struggling with.

“Then they'll have a dedicated culture buddy who's often from a different team,” she says. “We try to choose someone who's been around for quite a while, who we feel is a really great ambassador for our culture. This culture buddy takes them through a program with a series of discussions, reflections, asks them to do certain reading and homework and writing assignments and teaches them about, not only remote work, how we communicate, where to find things, but also what our core values are, how we work. They have this intentional relationship for about ninety days, and often, that buddy will go on to be a close friend to the new hire going forward.

Womersley has seen many strong relationships emerge from the buddy system. This model has helped prevent new hires clubbing together for emotional support distinct from more tenured engineers, which can lead to cultural fragmentation. Having two veteran buddies to each new hire brings them into the existing fold and helps establish them within the wider organization.

 

Conclusion

In this panel discussion, Kate Womersley of Buffer, Tim Armandpour of PagerDuty, and Eric Muntz of Mailchimp discussed four aspects of leading remote and distributed engineering teams:

• Keeping teams in the loop by documenting all decisions and rationale online, making decisions in synchronous meetings, and considering the most useful flow of communication through team leaders to team members.
• Dealing with time zone differences by considering which time zones to hire or build teams from, asking for flexibility in return for the flexible nature of remote work, and striking a balance between synchronous and asynchronous communication.
• Focusing the hiring process around people who have done remote work before and people who have experience with self-driven work that translates well to remote work—and acknowledging that remote work isn’t for everyone.
• Introducing new hires to the organization with in-person onboarding, onboarding for culture, and pairing them with tenured peers in a buddy system.

Many thanks to all of our panel participants. Remember, you can watch or listen to the full panel discussion, as well as sign up to hear about our other upcoming panel discussions.