Tips for engineering managers learning to lead remotely | GitLab

The transition from working in an office to working for an all-remote company isn’t always easy. Many engineers are used to whiteboarding a troublesome piece of code with their colleagues and being able to tap their manager on the shoulder when they get really stuck. In-office engineering managers are accustomed to reading body language and following verbal clues when interacting with the team members they supervise. For developers used to working in an office, it takes some time to adjust to working autonomously from home, instead of in a pod of desks with a team.

GitLab team members share how they managed the shift from in-person, colocated work to working and managing teams remotely at GitLab to help others make the transition to remote work more easily.

"My day-to-day role is very similar," says Max Woolf, senior backend engineer on the Manage:Compliance team at GitLab. "I work closely with product owners or product managers deciding, refining work, and then writing the code to make those things happen on a daily basis. The main difference was that I worked in an office with 10, 11 other people, and now I work on my own with about 1,200 other people."

Overall, engineering managers say the goals of leading the team are the same, but the way you achieve those goals differs while working in-person and working remotely.

When working in-person, some of the hallmarks of asynchronous communications (document everything, be sensitive to your colleagues' time) are often sacrificed in favor of the ease of informal, verbal exchanges.

The reality is, there are times when an engineer's question just requires a quick, 30-second answer, says Cheryl Li, backend engineering manager for Verify at GitLab. It's easier when working in an office to just answer the question immediately, even if the question might be frequently asked or otherwise merits a documented response.

Corine Tan, cofounder of Kona, interviewed 500 remote managers in tech and summarized 21 key findings in a blog post and on Twitter. She learned that a bias toward overcommunication and rigorous standards for documentation is key to successfully managing a remote team.

Craig Gomes, backend engineering manager for Memory and Database at GitLab, echoes Corine's findings: Defining communication channels and setting clear expectations around communication is essential for successfully managing a remote team.

"If your team has a deployment issue to fix, it is easier in an in-person environment to gather everyone to quickly resolve it," says Craig. "In an asynchronous/distributed environment it is important to provide as much information in an established communication channel as possible to resolve the issue in an efficient amount of time. The same goes for planning, goal setting, bug fixes, etc."

One of the key benefits to managing a team in person is the interpersonal aspect. It is easier to build a connection and maintain team engagement when everyone is in the same place and there are more opportunities for small talk and shared laughs. Both Cheryl and Rachel Nienaber, engineering manager: Scalability at GitLab, mentioned relying a lot of verbal cues and body language to decipher when a team member might be struggling with burnout or a personal challenge. Non-verbal cues are not easily replicated via Zoom, which means managers need to overcommunicate with their team members to learn about stress styles. The best way to do this? Ask.

"Just as teammates have preferences for feedback or learning, they also have different reactions to stress. Knowing whether to give space, lend an ear, or take action often starts with asking the person," writes Corine in her blog post.

It takes intentionality and effort to build postive interpersonal connections in an all-remote team. At GitLab, we encourage team members to set up coffee chats via Zoom, and when Zoom fatigue hits we also have informal Slack channels that allow people to share photos and chat about shared interests. We will be exploring in depth how engineers can collaborate remotely in an upcoming blog post, so keep an eye out!

"From personal experience, one of the biggest challenges of remote work is ensuring engagement at a team and individual level," says Craig. One of the ways that Craig maintains transparency is by documenting team processes and expectations in the GitLab handbook, and by holding routine team processes reviews to check that everyone on the team is operating from a shared context.

"This level of transparency helps to improve shared context across stakeholders as well," he adds "By shared context I mean that we have a shared communication platform, written and asynchronous, rather than having the context spread across multiple different channels (meetings, hallway conversations, emails, etc)."

Rachel says that it was easier for her to know what her team was working on during the day while working as an engineering manager in an office setting. She was able to walk around the room and get a good sense of who was busy with what projects. But by the same token, she had to be prepared to be interrupted at any time by some of the engineers she supervised.

"When team members need help, it felt helpful and effective to unblock them quickly," says Rachel, who currently works as an engineering manager at GitLab. "But this meant that if I needed time to focus and get a piece of work done, I would need to book out a meeting cubicle for myself."

If both parties are available, hopping on a video call to discuss the problem and share a screen in real-time is a good way for engineering managers like Rachel to help team members who are blocked on a particular piece of code. Video calls on an as-needed basis are far more effective than recurring meetings which people might feel obligated to fill, even if they don't have anything pressing to discuss. Speaking of which…

The three engineering managers we spoke with for this blog post agreed: Working as an engineering manager in an office setting meant a lot of time spent in meetings.

"When I worked in a co-located environment, I largely performed the same duties, but I had a lot of more meetings," says Cheryl. "Working asynchronously wasn't part of the culture, so every discussion or decision had to be vetted in a synchronous meeting, sometimes in a meeting with 20+ people. Meeting rooms became scarce due to the nature of how the company operated."

Rachel agreed, noting that she was devoting the majority of her time to different types of meetings, from standups, to 1-1s, project meetings, coordination meetings. Managing her calendar became a significant part of her role as engineering manager.

"Synchronous meetings were seen as a more effective way to get things done, but they took up a lot of time," says Rachel.

Instead of defaulting to synchronous meetings by video call, we prefer asynchronous communication at GitLab. The core of asynchronous communication is documentation, as opposed to verbal communication. Documenting questions, answers, and discussions in one preferred communication channel allows team members to work on the time table that is most efficient for them, and helps projects move forward across time zones. We explain in depth how asynchronous communication works at GitLab in our company handbook, but these tips in particular are useful for reducing the number of synchronous meetings for your team:

This video gives the full run-down to engineering companies or teams that are considering making the switch from colocated working to all-remote permanent.