In this Perspectives in Engineering interview series, engineering leaders talk about how to build, coach, and scale world-class technology teams.

Leading remote engineering teams comes with a suite of challenges. How should teams that are spread across time zones coordinate their schedules? How do teams ensure that everyone’s involved in making decisions? How should remote engineers support themselves, since they lack the interpersonal support of a co-located office?

Nassim Kammah, who recently joined Elastic as a Senior Engineering Manager, believes that leading a distributed team is really not so different than leading a co-located one. The difference is that remote work will exacerbate any friction in team communication—issues that we’d often accept as “the way things work” when we’re all working in the same office.

“I see the friction of remote work mostly as an inclusion problem,” Kammah says.

Before joining Elastic, Kammah lead a coast-to-coast remote team as a remote Senior Engineering Manager at MailChimp. And before that, he served as a remote engineering manager at Etsy, following a decade as an IC trained as an industrial engineer. He’s focused his managerial efforts on addressing how to solve those inclusion problems and develop more inclusive practices.

In this exclusive interview, Kammah starts by tackling the problems of most caucus-format meetings—problems which are only highlighted by holding them with remote employees—and how to offer everyone an equal and equitable experience within a meeting. He then ventures into how distributed teams can make strong use of asynchronous communication to also ensure deep focus time, and he stresses ways that leaders can ensure necessary self-care for the benefit of the engineers and the team as a whole.

 

 

Practices for inclusive remote meetings

Many of the perceived drawbacks with having remote team members have underlying causes, Kammah says. There are existing problems in how teams communicate, and having remote team members will simply make those existing problems more visible. The real issues are beneath the surface.

For instance, the technicalities of meeting with team members who aren’t in the same office can feel like a hassle. Video feeds freeze, microphones will drop sound, and you miss a lot of that unspoken communication that happens when you’re in person. “But the problem is not about being remote,” Kammah says. “It’s about the format of the meeting.”

 

The default caucus format is problematic

Typical meetings follow the caucus format, where whoever speaks first gets the floor. Some team members possess an ability to speak easily, to speak as they think, and to jump in when others are talking. They tend to have a much more engaging experience than the team members who have to take the time to process what they hear before answering, or who defer to the people already speaking.

Kammah also notes that his thinking around remote team meetings has been heavily influenced by Chelsea Troy. He points to her post Why Do Remote Meetings Suck? as an especially useful resource for others facing similar challenges.

“That format affects every meeting,” Kammah says. “Being remote simply exacerbates it. Some lag, some AV issue, and people are pushed aside from participating in the conversation. By the end of the meeting, they can be completely tuned out.”

Partially remote teams have their own inclusion problems during meetings, as well. It’s simple for people physically in a room together to have side conversations that exclude anyone dialed in remotely. The remote engineers aren’t always able to contribute as easily.

There’s two main problems here: not everyone in this scenario is having a comparable experience, and the meeting format itself is flawed. Kammah suggests solutions to both of these concerns.

 

Give everyone the same experience

“Everyone in a meeting should have the same experience regardless of the location,” Kammah says. “If some people can see body language, everyone should be able to. Seeing people’s reactions relates to your assessment of their understanding and reaction.”

In an all-too-frequent setup, where some people are physically co-located in a room and others are dialed in or videoed in, not everyone is having an equal experience. The screen is too far for some people to see, or the lone camera in the meeting room doesn’t capture everyone the same.

"Everyone in a meeting should have the same experience regardless of the location."

So Kammah recommends giving everyone the same view of the meeting: in this case, everyone, whether in the meeting room or working remotely, dials in with their laptops for video support. “That way, everybody has the same view of who they’re talking to. I can read your body language and your facial reactions the same as you can see mine,” he says. “It’s very powerful.”

(Our strategy at GitPrime is similar: for every meeting, everyone logs in to Zoom, even if many of us are in the same building. Kammah recommends using a gallery view for whatever program you use for communication so you can see everyone at once and give everyone the same experience.)

 

Moderators keep everyone aware of the norms

Those strategies level the playing field for remote and co-located employees—fixing the above-water part of the iceberg. But they don’t address the issue of the caucus format. Caucuses have no rules about who talks, how long they talk, or in what order. It’s a bit of a free-for-all, which can be exacerbated when social dynamics or the slightest technological delay can be the difference between engineers speaking up and sitting out.

"Making meetings more accessible to remote employees doesn’t just make meetings more accessible to remote employees; it makes meetings more accessible to everyone."

Chelsea Troy Why Do Remote Meetings Suck?

“You need a moderator to control the flow and safeguard people’s ability to listen and to speak,” he stresses. “You establish ground rules on how your team is going to collaborate in this meeting, and then you have someone who monitors and makes sure it happens that way.”

The moderator can be anyone on the team, and in fact, it can be a rotating responsibility. If the idea of implementing moderation seems intimidating, Kammah points out that many teams already use some moderated meetings. Sprint planning, for example, usually has a specific order of speakers, who each have a set amount of time to cover a set amount of information.

An agenda can certainly aid a moderator, but he stresses that a human being is needed in the role to keep others from hijacking the conversation, even with the best intentions.

“As much as they are moderating norms, they are monitoring the dynamics in the room, making sure everybody has a voice, and encouraging participation from some people while tempering others,” Kammah says.

 

 

How to get asynchronous communication right

Meetings certainly warrant attention to be made more inclusive. But most communication on remote teams happens outside of meetings—it takes place in Slack and other similar channels on a day-by-day, minute-by-minute basis.

“When you have a group of folks in an office, it is easy to have interactions in person and think that the remote members will catch up,” Kammah notes. “But for them to truly catch up, you have to relay every conversation, every relevant technical detail, anything that happens, through the same method for everyone.”

Just like with meeting environments, he says, everyone should have the same experience. In-person conversations can still happen, and their contents can be written up in Slack. But remote teams are well served by favoring asynchronous communication over synchronous communication.

“That's a big shift,” Kammah says. “That is not easy for everyone, but that's the more inclusive practice, especially when you cover different time zones.”

 

Asynchronous communication alone isn’t fully inclusive

Asynchronous communication is a standard best practice for distributed teams, particularly those where work hours don’t overlap 100%. But going async isn’t itself enough. It doesn’t keep some engineers from missing out on real-time conversations just because they’re not working at the right moment.

“Slack is very powerful, and we can use it really well or really poorly,” Kammah says. “By default, it’s easy to use it poorly—as in, use it as a synchronous tool. Ask a question, have a debate, settle it, move on. Once that conversation happens, it's too late. It's done. That's really how Slack works if you decide to treat it that way.”

For example, at Mailchimp, Kammah’s team was based three hours apart in Atlanta, Brooklyn, and Oakland. The Oakland folks would sit down at eight or nine o’clock in the morning, and the first thing they had to do was catch up on previous three hours of team discussion. Sometimes, people had already made decisions about the project they were working on.

The folks in earlier time zones didn’t have bad intentions, they just wanted to make progress. Yet it didn’t seem fair to others who were being left out of those conversations.

 

Quiet hours give permission for heads-down time

“That’s how we came up with the idea for quiet hours,” he says. “The idea behind quiet hours is to reset expectations. Don't look at Slack from this time to this time. It’s safe for you to turn it off.”

Kammah’s team had quiet hours until noon Eastern/nine Pacific, when everyone was at work (this was not a set expectation, but rather a consequence of the timezones people were in). Quiet hours would resume at 2:00 Oakland time, when everyone in Atlanta had left for the day. That way, everyone starts every day with an empty Slack channel. No conversations happen that exclude whole segments of the team.

Quiet hours have other benefits beyond inclusivity, too. “It avoids the tendency of always having an eye on Slack,” Kammah says. “It’s impossible to also have an eye on your code. Nowadays, we spend more time communicating about work than doing the work. Quiet hours allows us to get back to having deep focus on the work.”

"Nowadays, we spend more time communicating about work than doing the work."

Cal Newport author of Deep Work

His team at MailChimp also used those quiet hours for self-care (a topic he will touch on below), which he stresses is critical for supporting healthy remote workers.

How quiet hours were formatted was specific to the team. Some teams chose specific times of day, based upon team members’ time zones, schedules, or preferences. Others had no-meeting days, which leads to similar results. The quiet hours themselves were not what’s most important, but rather the expectation and acceptance of dedicated time free from interruption and chatter.

“If I were to distill this idea, it’s about being explicit and giving people the authorization to tune out from group communication,” he says. “You are empowered to do that.”

 

Set expectations for communication—and stick with them

Getting team members to tune out for quiet hours sounds simple in theory. The managers making that call are safe to do it. They’re in charge. But not everyone may feel truly safe with the idea of shutting down Slack for whole blocks of time.

“A junior engineer just joining the team might feel obligated to be available,” Kammah points out. “Especially if they see everyone else always responding. They may think that responding right away is the expectation. You can’t let people assume the way to communicate on the team. You need to really set the expectations clearly.”

Many of us are so accustomed to giving our time and focus to communication channels, whether or not it’s warranted. So Kammah makes his expectations around quiet hours explicit, as well as his expectations around how his team uses its communication tools. Behavior establishes norms, so he makes certain his team knows when to jump on their shared channels—and when not to.

“I set guidelines and expectations for how we communicate and how we use Slack,” he says. “This is when you can turn it off, and you should not expect responses during these times. It’s especially critical when you have remote employees.”

 

 

Highlight the importance of self-care

Team members can’t sustain quality engineering work if they’re not taking care of themselves and maintaining a sustainable workflow. That’s why a lot of companies emphasize relaxation or recreation—pool tables in the break room, yoga classes, or mandatory time off.

Kammah takes another tact. He makes sure that self-care isn’t just an option, but that it’s a necessary part of being on the team.

“As a remote manager, I need to be very conscientious about self-care and the toll that not having breaks or time to socialize, or reboot, can take on people,” he says. “I've been remote for about five years and I still have a long way to go on this—there are many days where I don’t take breaks. I get hyper-focused, and can often get so much more work done than if I were in an office. Sure, it can be exhilarating, but come the end of the day and you realize you’ve stepped out three times to go to the restroom and those were your only breaks. You have to proactively work to find a healthy balance, or you’ll burn out really fast. Knowing how easy that can be, as a manager, I have to proactively encourage team members to take care of themselves.”

Kammah offers some self-care suggestions for how to encourage it among the engineers on a team, as well as for the managers leading those teams.

• Celebrate breaks as a team. Beyond encouraging his team to take breaks throughout the day, Kammah actually celebrates them. “On our team, we celebrate best practices and encourage best behaviors by using emojis,” he says. “So someone taking a break, for example, is met with lots of emojis and people saying, ‘Yay! Go for it!’ and so on. By openly supporting all types of best practices as a team, we can reinforce those values.”
• Make an effort to reach out on a personal level and ensure team members are taking time to reboot. It can be as simple as sending a quick message asking when an engineer’s last break was, for example, or asking in a 1:1 how they’re feeling with workload and whether it’d be helpful to take some time off (even if everything is going really well). Or it can be automated—a timer that reminds you how long you’ve been sitting at your computer. However these reminders look, “It’s up to me as a manager to repeat the importance of self-care and check in with my team about it,” Kammah says.
• Take it outside. This is one of Kammah’s favorite strategies for remote managers in particular—though any manager could implement it: take a walking 1:1. Because who says all meetings have to have video? He takes his phone for a walk while calling his direct report, whom he encourages to talk a walk as well. “That's been powerful, because you think differently when you walk, when you're outside and moving,” he says. “There's a different flow to the conversations. Sure, you don't have the video, but you can get a lot more ideas and interpersonal signal from the other end.”

 

 

Conclusion

Kammah understands most of the friction experienced by remote teams is, ultimately, related to inclusion and the unequal experience different team members have. Treating a distributed team as first-class citizens requires conscious action from a remote manager, and Kammah offers these insights for how leaders can make a more inclusive experience for all the engineers on a team:

• Offer everyone the same experience during meetings. The default caucus format of many meetings, where the person who speaks first or loudest holds the floor, has implicit problems that are exacerbated with remote communication. Moderators can mitigate these problems, while ensuring everyone experiences the meeting the same way (such as everyone signing in to a video call on their own laptops) smooths out the inequalities for remote engineers.
• Develop more inclusive asynchronous communication. Async isn’t automatically more inclusive for remote engineers, because we still tend to treat those mediums (such as Slack) as synchronous. Kammah institutes quiet hours so engineers can get focus time without keeping an eye on chatter. But however a team organizes its communication to reinforce deep work time, its manager can make the expectations around it explicit.
• Prioritize self-care. By making self-care something that the team recognizes and celebrates, managers enable the mental and emotional health of their engineers. And self-care doesn’t always have to be distinct from an engineer’s work life; Kammah has instituted “walking 1:1s” as a way to implement self-care as part of the company culture.

“Being a remote manager is possible,” Kammah offers in conclusion. “It’s all about setting explicit expectations, having good intent, and trusting your remote employees to deliver. Then, be there to support them.”