 |
 |
 |
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 2019 survey over 70% of companies allow some degree of remote work, so these are valuable lessons for anyone.
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
Check out the slide version of the interview!
About Katie Womersley
I joined Buffer as a software engineer, and I became our first ever engineering manager. Since then, the team has grown and evolved, so I moved from being an engineering manager to managing managers as a director, then eventually managing a larger team of managers as VP of engineering.
My role now is much further away from where I started, as I don't get to code anymore. Right now, my main focus is to support and empower the team by supporting a really strong engineering management structure and by making sure that our technical leaders have the tools, training, and the support they need to do a great job.
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 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. I think trust is really important for a developer team. 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.
Learn the ins and outs of Monzo's renowned engineering culture! [Podcast + Blog post]
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.
How to keep decisions fast and the team productive over different time zones
Use comments and questions
We try really hard to leave a lot of comments on everything we work on asynchronously. For most teams, this is on JIRA, and we try to make sure we have really clear specs with a design, a brief and maybe a mock-up, so when developers are working on it, they will be very clear with their status. They put in there any questions, so they get unblocked as fast as possible by a product manager, a designer, or another teammate.
Be proactive
We try to move into very thorough, detailed asynchronous communication, so people know what’s going on with the rest of the team, and they're getting their questions answered as soon as possible. We also encourage our team to be proactive and to make most decisions themselves. For instance, if you get stuck on something, don't wait around for help; just go do something else, figure out what else is valuable, or even better, make the decision yourself!
Decide if necessary
Something we really encourage is for people to make a decision and inform the team. Say, “I wasn’t sure about A or B; B made more sense to me, so I went ahead and I did it. If it’s a problem, let me know and I’ll fix it.” Nine times out of ten, the developer makes a great decision, and everyone’s happy. Only one time out of ten do they say we actually needed to do A, but it still saves a lot more time compared to waiting around, being stuck.
We have a saying on our team: If you can reverse it, do it!
We very much encourage our engineers to adopt this mindset, that if you can reverse the decision, just make the decision. Of course, if you can’t reverse the decision, then it’s better to wait for others.
Learn how Camille Fournier, Managing Director at Two Sigma manages engineering productivity!
Do you have any specific requirements for time zones when hiring?
We have no hard requirements. We try to hire the best person for the role and then make the time zone work. Remote work basically goes along the same guidelines as offshore software outsourcing.
It should be considered for collaborative roles
We do consider it when it comes to a highly collaborative role, like a product manager. For instance, if all of the engineers and designers were in Europe and the United States, and the product manager is in Australia, then we might consider how that is going to work and have a conversation with that person, since they may end up having some meetings at weird times. We try to avoid this and make it so all the time zones can work. We have people all around the world, but it is something to consider.
Flexibility is a must
We usually explain how people are distributed on some very difficult time zones, so they all need to be flexible. Buffer allows a lot of flexibility, but in exchange, we ask for some accommodations. If everybody insists they’re only going to work from 9:00AM to 5:00PM, and they’re not available at any other time with teammates in Europe, the United States and Australia, you can’t ever have a meeting.
It’s certainly manageable
We actually do have some very distributed teams, and it works well. For example, the infrastructure team has members in Beijing, China; Colombo, Sri Lanka; Cambridge, England; New York on the East Coast; and San Francisco on the West Coast. So, they’re almost perfectly seven hours away from another teammate. It’s a great infrastructure team of five people, and they keep an engineering organization of thirty-five running, with smooth releases. It also makes our emergency on-call schedule very easy!
How to onboard a developer with no previous experience with remote teams
We put a lot of effort into onboarding for anybody, even if they have worked remotely before, and if they haven’t, we note that in the onboarding document to give extra support. Previous remote experience is not a requirement for people joining Buffer.
Discuss everything up-front
We'll talk to them about where they are going to work from, how they will set up their workspace, how they are going to set up their schedule, how they are going to stay healthy and productive at the same time, and how they will have enough work time and also not too much work time. We believe it’s key to talk to them very openly and very honestly about the lovely advantages of a remote team, and the hard part of it as well, to make sure they consider every aspect.
Create clear goals
Every developer gets a 30-, 60-, and 90-day onboarding plan, which has really clear goals.
Assign a role buddy
They will also have a role buddy who’s another developer who will help them out with getting their tasks done, showing them how everything works. We know this person is going to be spending a lot of time helping the new person, so they’re going to be less productive, but we expect this.
Assign a culture buddy
They’ll also get a culture buddy, whose job is to talk to this person once a week, advise on their challenges, and how to work better remotely, how to communicate with their team, how to stay healthy and how to stay productive.
How do you reward progress and celebrate small wins?
We have an exuberant culture, so we really like to celebrate things. We use a lot of gifts and a lot of emojis, and we try to be very encouraging of each other.
HeyTaco! for rewarding each other
A new tool we really enjoy using is the HeyTaco! application in Slack. People can give their teammates a little taco for a win, progress, or anything they feel like. Tacos can be redeemed for actual rewards.
Threads as an achievement board
We also have a special tool called Threads. It’s somewhere between an e-mail and an announcement board, and we have a special category that is solely for praise and recognition. Often, teammates post about people when it's a bigger achievement. It’s not a simple taco; this is more special.
Dedicated channel for gratitude
We also have a Slack channel dedicated to showing gratitude, and we often write there when we’re really grateful for somebody or something.
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.
Further reading 📗📘📙:
👉 This Is How We Went Fully Remote In One Day - COVID-19 Case Study by Coding Sans
👉 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
About the author:
Tamas Torok is a marketer, helping tech companies to grow. He currently leads the marketing operations at Coding Sans and focuses on crafting high-quality, research-based content for engineering leaders. He started publishing the State of Software Development report and supports the growth of the Level-up Engineering podcast, dedicated to engineering leaders.