Demystifying Productivity of Remote Teams

Katie Womersley is the VP of Engineering at Buffer where she manages a fully distributed team of 82 people living across 15 countries. She is a champion of remote work and actively voices her thoughts about the mental health aspect of work. She is also the author of "Atomic Migration Strategy for Web Teams", which is a practical guide to rewriting a frontend client without delaying the product roadmap.

Here is a transcript of the interview with her, edited for clarity.

What drew you from a background of philosophy and  economics to software engineering?

I was always interested in solving problems, and philosophy seemed to be a very natural place to start. I wanted to understand how our world works in a more practical sense and felt economics made sense as we are in a capitalist society. It wasn’t only about the subjects; it was also about solving problems in the real world.

I had a lot of friends, along with my husband, who studied computer science, so I attended many lectures and sort of got hooked on it. I started to do common website development on the side just because it’s fun.

When I finished my master’s and realized that I had been trained for a management consulting sort of job, I didn’t want to do that, so I tried my hand at freelancing in the software field, and I never looked back.

Initially, I started to build an online booking system for a family friend who is a dentist. Eventually, when I started to get serious, clients were like companies, and I made a company for myself.  Later I became a full-time team member of the South African startup TravelGround.

The thing I love about this industry is that it has a low barrier to entry. You don’t need a fancy master’s degree to be a VP of engineering. I am sure it helps a lot, and they know a lot of interesting things. It is kind of interesting; this industry values learning, values people being self-starters, and values people that can solve problems by themselves. That’s what I appreciate about our industry.

Hypothetically if you had a chance to start over again, would you go distributed from the get-go or not and why?

If you are going to build a distributed team, it would be easier to start distributed because you will need to build up communication patterns that work for people that are not in the same place. So, if you first start co-located and then go distributed, your organization has to build two sets of habits. You will first build co-located habits, and then you will have to break these rules and build up the distributed habits. If you had a choice and you want a distributed team someday and think, “Should I start co-located first, maybe to get the culture a bit or something?” My advice would be no, just go distributed, because you will need to build a strong distributed culture and strong distributed communication. The sooner you start building those habits, the better, and the less stuff there is to unlearn.

Most of us don’t get a chance; we end up building companies that are co-located, and then we struggle to hire, especially if we are in SF. Then we realize that remote work is going to be helpful and end up going distributed.

What are one or two unfair advantages distributed teams have?

The first would be to hire the best person for the job who is aligned with the culture of the team because you are not forced to think, “Who can I hire who are within four miles of our office?” If you are thinking, “I can hire someone who is more than 1000 miles from our office,” then you are more likely to find the right person for the job who is a culture fit and who is going to bring a perspective that makes your team more diverse. That is the reason people always start with a distributed team; hiring is always the thing, especially in tech, because there are more tech jobs than there are developers today.

We are distributed across time zones, so this provides us a big operational advantage. We are available 24/7, so on-call is very easy. Serving our customers is also very easy; we always have somebody online to be able to do things. We can make progress around the clock when we need to release a new feature quickly, and it matters to beat the competition. We can essentially work 24/7 for that week without anybody overworking. When Instagram released its ability to do direct posting, Buffer was the second team to deliver that functionality despite being quite small in the competitive landscape.

If you are a distributed team but only in one time zone, I would say the biggest operational advantage you are going to have is that you are going to have much more documentation around how you work and operate; since you are not in the same place, onboarding and scaling are going to be much easier because you are not relying on somebody to tell the process.

What are a few disadvantages of a distributed team and how to mitigate them?

A big challenge is in collaboration, creativity challenges that people have in distributed teams. People are very productive and are very good at executing ideas when they have few interruptions. The main problem is coming up with what to execute because if you are very efficient with building the wrong thing, you are just going to do the wrong thing faster. So, the biggest challenge would be staying aligned, coming up with a strategy, and knowing what each other is doing, and for this, I think that getting together in person is important. At Buffer, we get together every six months, and I feel like that is a minimum amount of occasions. Getting together in person and doing brainstorming is very helpful, so I would say that a big chunk of money that you save on hiring and office space will be spent on a travel budget. Of course, you can also do a lot of brainstorming sessions while being remote with the help of tools like MIRO, Trello, etc.

Another big disadvantage for remote workers concerns their mental health, which has a huge impact on a company’s productivity and engagement. If half of your team ends up with depression, you’re just not going to have a very productive team, and of course, the human cost is huge.  It is something that does happen when you have people being socially isolated because they’re often working at home by themselves. At first, it’s great and, of course, over time, they might not see other people and might lose their social support network. Gallup has some research that suggests that people who have a best friend at work are seven times more likely to be engaged employees than people who don’t, and remote workers usually struggle with that social interaction. It can be so easy just about the work, and you just look like an abstract person doing this work; the impacts of it are people get depression, they get anxious, and they lose the social bond, which keeps people trying hard and keeps them interested in work. Often, people like to go to work because they’re going to see that friend or friends at work.

So, at Buffer, what we do with that is we pair people up into something called mastermind buddies where once a week, people have a one-hour call with somebody else from the company. It’s a purely social support relationship call. It’s not about work. Usually, they’ll be in a different area of the company, and we also do quite a lot of social activities like book clubs. We also have quite a lot of special interest channels, like pets, where people can talk about their lives and interests with colleagues to build that social connection. We also do color check-ins before meetings. Are you feeling red, yellow, or green? The person doesn’t have to explain, but it helps to humanize the coworkers and give them a bit more support.

How do you maintain the culture as new people are onboarded?

It is a natural thing for culture to evolve. So, the first thing to know is that your culture will change; it will evolve and it should evolve. The question is: in which direction? Is it evolving in a way that makes the leadership team happy, or is it evolving into something unproductive or toxic that people may start leaving your organization? The first thing to do is to have some written agreement concerning company values. What does your company value? That is going to form the basis of the culture that you are trying to build. Think of something that is not generic but specific to your company. Buffer has a “default to transparency” that influences our culture on a day-to-day basis. Amazon’s culture is all about cutting costs for the consumer, and that is why they have that famous story where the desks are all like doors put on trestle tables because that is their stated value. Remember: There is no such thing as good or bad culture; it is all about the culture that you are trying to build and what the impact of that culture would be. The leadership team should know what the business purpose is and what you are optimizing for. Why are you building this engineering team? Try to get that written down. There might be a question about whether you want to value these things. Maybe think about it a bit, but write those things down and then be ruthless in enforcing those values. Don’t hire people who aren’t going to be aligned with those values, because either you will try to change them and fail or they’ll try to change you—and you don’t want that, right? And if people are constantly not aligned with the culture, let them go. You know, it is okay to do that if somebody is maybe a really good developer but struggles with your cultural norms. Enforce the culture and don’t promote the brilliant developer who doesn’t align with your values because they are doing a good job, because you are going to get the behavior that you reward as a leader.

How do you ensure that your remote workers are productive?

This is the single most common question I get about remote work, and the answer is very non-intuitive. Usually, what we see with remote workers is that they work much harder than in-office workers because they’re trying to prove to their managers that they are not slacking off. There is a very famous study by Nicholas Bloom, who is at Stanford, on the Chinese company Ctrip. The company changed its whole call center to be working from home as an experiment, and they were very worried that people just wouldn’t do the work. The people worked a full extra day per week: they got six days’ worth of work done in five days. I see this very commonly with remote workers, while people get a lot more time. Firstly, they are more productive because they’re not interrupted. Secondly, they tend to work longer hours because everybody is worrying, “What does everyone think of me?” Because you can't prove that you were trying, if you go to the office, what you need to do is sit behind a computer screen, and no one is going to say you were not working because you were at work right. Whereas if you work from home and get stuck on a hard bug, suddenly there is a question of "Were you even working?". So I have seen developers, you know, spend like a full eight hour day debugging something difficult feel like they haven't even started cause they don't have output to show for it and then work through the night to get the thing done. It's almost the opposite. So the thing to worry about the most is not about are the people working but are the people working for a reasonable time, are they not overworking.

The second thing is the way you measure their productivity. You should use metrics such as the number of commits, how many story points did they ship? As an engineering leader, we have access to a lot of information that is very quantifiable. If you notice that somebody just really isn't coding much, you can have a conversation with them. There might be valid reasons: maybe they have been doing infrastructure work for five days, which might not be reflected in the number of commitments.

What is the best recruiting advice you would give to an Engineering Leader who is looking to hire their first remote/distributed team?

The first thing I would look for is any kind of evidence that they like to ship code to users because that’s what the company values. So, in their cover letter, I would look for independent initiative: Do they like to work in a more unstructured free environment where they are the ones driving what they are doing? A lot of successful remote workers actually are freelancers or have agency experience, or they have other qualities of being a self-starter and taking that initiative, or maybe they are self-taught or have a less traditional background. I like to hire people with good problem-solving skills, it makes them great remote workers.

---