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:
Check out the slide version of the interview!
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.
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.
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.
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.
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.
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 skills are very important; otherwise, it’s very difficult for a team to stay in sync and to share context.
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.
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!
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.
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.
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!
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 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.
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.
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.
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.
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!
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.
We talk to them provide advice if necessary about where to work from, how to set up a workspace, how to set up their schedule, how to stay healthy and productive while clearing enough but not too much time to work. It’s key to talk to them openly and honestly about the advantages of working in a remote team and the challenges as well to make sure they consider every aspect.
Building a fully remote onboarding process is a challenge. We provide every developer with a 30-, 60-, and 90-day onboarding plan, which has clear goals.
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.
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.
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.
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.
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.
We also have a Slack channel dedicated to showing gratitude, and we often write there when we’re really grateful for somebody or something.
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.
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 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.