Managing Remote Developer Teams: How Buffer Set the Gold Standard

Managing Remote Developer Teams: How Buffer Set the Gold Standard - Interview with Katie Womersley 

Working with a remote team has many upsides, but managing a remote developer team is one tough job to have. There are loads of challenges you wouldn’t have to worry about in an office, like possible time zone differences or making sure people feel part of the company. It requires a lot of attention to keep everything on track.

We sat down with Katie Womersley, the VP of Engineering at Buffer. She’s managing many remote engineering teams, and she shared a lot of invaluable experience she picked up over the years in dealing with all the obstacles of working with distributed teams.

Buffer set the gold standard for remote work over the last several years, working with 82 people from 15 countries all around the world. They paved the path as being one of the first tech companies working fully remotely, and they also became incredibly successful in the process, which clearly shows their way works. According to the State of Software Development report over 70% of companies allow some degree of remote work, so these are valuable lessons for anyone.

Interview by Tamas Torok in episode 1 of the Level-up Engineering podcast!

Let’s see what they had to share!

From this post, you will learn:

• The biggest challenges remote developer teams face
• Advantages and disadvantages of synchronous and asynchronous communication
• Key elements to make a remote team work
• DOs and DON’Ts of managing a remote developer team
• The dark side of managing a remote dev team
• How to handle big time zone differences
• How to on-board a developer with no previous experience with remote teams
• How to reward progress and celebrate small wins
• About Katie Womersley

Check out the slide version of the interview!

What are the biggest challenges to managing a remote developer team?

It’s always that balance between synchronous work and asynchronous work. When people work synchronously, they are online at the same time chatting back and forth, which is really great for being connected, bonding as a team, real-time collaboration, and being creative with ideas.

On the other side is being asynchronous, and letting people respond when it suits them, not having to be in a lot of meetings, and there’s no frantic chatting going all the time, so they can work with their heads down. It’s great for writing excellent code, productivity, having a more calm work environment, and being able to have manageable hours.

When your team is more synchronous, they’ll tend to feel like they are more energetic, more creative, and more connected to everyone else, and they’ll have more sense of what’s going on in the rest of the company. On the downside, they might feel like things move too quickly, there are too many remote meetings, they get left out of decisions, and they’re finding it difficult to get keep heads down.

When we're very asynchronous, everything’s happening over words and documents. Responses are a lot slower, and they are much more thoughtful, because people respond when it suits them. I’m often told people are getting a lot of great work done, they feel very productive and very balanced. At the same time, they often feel quite lonely, disconnected, and like things move slowly. They don't really know what’s going on with others. They’re all alone in their rooms, and it can get quite depressing.

Both asynchronous and synchronous communication has its advantages and disadvantages. In the following table below, we made a high-level comparison.

Balancing synchronous and asynchronous work

Managers always swing back and forth between synchronous and asynchronous, and I think at Buffer, we're starting to find a balance where the swings are not so extreme anymore. We're constantly trying to figure out how to mix the two in a healthier way—what should be synchronous and what can be asynchronous—and that’s probably the most difficult thing.

Knowledge silos

A problem we're always fighting at Buffer is knowledge silos when only one person knows about an area of the codebase. When they get sick or leave or something happens, then it’s the whole team’s problem. So, document your pull requests, write good commit messages, and leave status on JIRA cards. These practices make it less likely to develop these knowledge silos.

Challenges as a woman in the tech industry

I’m sure I have faced many challenges, some of them I probably didn’t even notice, because I don't know what it’s like to be a man in the tech industry.

I think the hardest thing is when you wonder, is this about my gender? Would they treat me like this if I was a (cisgender) man? Personally, I try to focus my energy on creating  a supportive environment for women on my team, where they can be “just an engineer” and not even think about issues like gender inequality. I try to support and uplift others where I can, and I encourage our whole team to be active allies for women and under-represented groups in tech  in every area: race, gender, mental health, disabilities and more. I am learning how to do this every day, and have a lot of things to improve, too.

Key elements in making a remote team work

Trust

It’s important to trust your teammates that they are doing their best work possible, that everybody has good intent, and that everyone’s trying to be productive. It's essential to build trust in virtual teams. It goes both ways: if you’re trusting your team, you’re also free to ask for help when you’re stuck or blocked, and you trust that they’re not going to judge you.

Clear communication

Clear communication skills are very important; otherwise, it’s very difficult for a team to stay in sync and to share context.

Work-life balance

We encourage our developer team to work really hard with their work-life balance, and not to overwork. People often ask me, how do you know the engineers are working hard? But the problem I really have is, how do I know they ever stop working? People tend to overcompensate whenever they're remote, since they know there’s a lot of freedom, they really want the job, and they really appreciate the privilege almost too much, so sometimes, they will try hard to prove that they are not slacking off. Managers need to be sure to keep the culture healthy and not encourage over-work and burnout.

What are the DOs and DON’Ts of managing a remote developer team?

DO make sure you invest into 1:1 meetings with your team.

DO make sure you’re really listening to your team and checking in on how they are doing, because you can’t just walk around the office and see the dynamic; you need people to tell you. This is the most important.

DON’T be that manager who constantly asks, hey, what’s happening with this feature? Hey, what happened with the status? This may be the most important don’t. Figure out a system where you are getting status updates asynchronously. There’s a ton of tools, so use them!

The dark side of managing a remote developer team

Remote developer teams often have mental health issues that people don't talk about. It could make your teammates less productive, less healthy, and more likely to quit and go work somewhere in an office where they feel better. Anxiety and depression correlate with feeling lonely or being isolated. Naturally, when working remotely, people often work from home most of the time.

Many but not all developers find themselves a bit more introverted, a bit more on the quiet side, so they’re not going out every day with a ton of friends. One thing we see is that the rate of anxiety and depression is higher with remote workers, so the most practical advice is to be very open in talking about mental health with people, because it really affects their work and their ability to be a successful  teammate on the job.

Remember, a manager is not a therapist; it's not your job to solve the issue, but it’s your job to be aware of it and to make sure your teammate gets proper help. Make sure they go see a doctor, go to a co-working space, get out and do some exercise, or get an actual therapist before it ends up becoming a real health problem.

What’s next for Buffer?

One thing we're doing, is getting everybody into a much better on-call schedule, and our ultimate goal is for people to be on-call for only one week in a quarter, and for them to be interrupted by an incident one day in a month. This is how we try to make it a very calm workplace for developers.

Another thing we will continue doing is using open source by default, building in the open, and contributing to the community. So right now, almost 90% of all our new code is totally open-source in public, so if you get our GitHub.com/Bufferapp, you can see a lot of our code. Of course, we use a lot of open source, so we don't want to be just a taker in the community; we are aiming to be active contributors.

Conclusion

The key takeaways are to provide the proper toolset, to put extreme emphasis on communication to make up for the lack of personal contact, to make sure people have a plan to be healthy and stay happy in the long run, and to get everyone on the same page about every possible issue.

Buffer is proving every day these processes work, so if you found anything you’re not doing yet, make sure to implement it. It will probably improve the day-to-day life of your remote developer team.

About Katie Womersley

Further reading 📗📘📙:

👉 Psychological Safety: The Foundation to Build Your Team’s Success - Interview with Dan Rummel (Sr. Director of Engineering, One Medical)

👉 Mentoring Developers: Best Practices From Uber - Interview With Gergely Orosz

👉 Scaling Developer Teams: Know-How From Amazon, Facebook and Intercom - Interview with Rich Archbold

👉 Managing Platform Teams: How to Structure and Run a Great Platform Team – Interview with Karen Cohen