Working Remotely: How we develop Buffer over 10 different timezones

At Buffer, we’re a fully distributed team. We recently closed our office in San Francisco and now have a team in 12 different timezones. One of the frequent questions we receive is, “How do you work as a remote developer with so many timezones?”

It’s such a great question and helps me reflect on some the unique aspects of working as a full-time developer at Buffer. It’s been such a fun journey working remotely for over two years now, so I’d love to dig into some of the challenges & advantages of working across timezones.

Momentum: Timezones mean we can work around the clock

Early on at Buffer, when the team was quite small, I was in Asia, Colin was in the UK, and Brian was in the US. Here is where the momentum of timezones really shined. I was working on the front-end, Colin on the back-end and Brian was doing design. We’d sync up with each other at the start/end of our days and pass the baton. Then the next day you’d wake up and back-end/designs would be ready and you can keep going. This chain of consistent productivity was amazing. Bottlenecks were seldom. That’s the amazing advantage of working across timezones: things never stop.

Presently, we have lot more people on the engineering team. So things have gotten bit more complex as teams change and people move around. For example, at the moment I work on the Awesome plan team with people in the US & Europe. So we have some overlap. However, the other engineer on the team, Federico, currently in Milan, Italy, is planning to travel with his family around the Asia/Australia timezones a few months from now. This will change our momentum & rhythm a little, and as the example above in the early days, sometimes even if team members are distributed across timezones, sometimes somethings comes up and the momentum hits a snag.

So where, I’d wake up and expect a few things to be ready for me to keep going, things aren’t quite there yet. This happens regularly as well, which leads me to the next point.

When bottlenecks occur new workflows arise: independence & parallelisation

We aim to foster & hire for people who have a lot of independence & self-motivation in the team. Team dynamics always change at Buffer, some people might have something come up in their day, some might travel to different timezones, some might catch a flu bug, or even take a few days off. Where we have little overlap with some team members, when team dynamics change like this, it could be quite disruptive for the momentum I mentioned above. However, this presents a different workflow & opportunity: to work more independently on different tasks in parallel.

Velocity of the development team is key things we focus on at Buffer. We always strive for codings things in a lean way and validating MVPs and ideas along the process. So when we are faced with possible bottlenecks and disruptions, we look for other opportunities: fix bugs, start researching different implementations for an upcoming feature, refactor small pieces of code, dig into customer feedback and more.

These initiatives aren’t always part of the plan, so developers need to have some ability to actively seek out these tasks.

I liken it to callbacks, when one part of the plan is waiting for something else, we can go ahead and see through some other executions & when the callback returns, that part of the program can resume.

On the product engineering side, this has helped us quite well in moving fast & slow at the same time. When we’re building new features, we move fast, and when we face bottlenecks, in the engineering team or outside of the engineering team, such as waiting for customer development feedback or designs, we can also take some time to reflect on the more slower tasks, such as refactoring & planning.

This parallelisation I feel has become a key part of our engineering culture.

Staying in touch with video syncs & asynchronous communication

At the moment our teams are separated into smaller product & engineering teams, such as Buffer for Business, or Respond and the iOS team for example. These smaller teams, usually up to 5-6 people at the moment, mostly 1 or 2 engineers, aim for daily syncs to catch up on what people have been working on. The video chats have different meanings for different timezones. For example, in the Europe/Africa, because of our overlap with the US, these calls usually tend to be at the end of our days, and for the US at the start of their days. So each person on the team might have a different routine depending on which timezone they are in.

For me, being at UTC+2, having most of my calls towards the end of the day makes it great for me to focus on more deeper focus-based tasks earlier in the day & morning. Similar engineers in my timezone whom I have 1:1s with also aim to focus during this time. So we’ve changed our calls to take place in the afternoon.

With that being said, one interesting challenge that arises for my timezone is that my overlap with the US makes it so that most of my video calls ends being in a 2-3 hour window at the end of my day. We aim to respect people in their timezones and don’t expect people to jump on calls late in their evenings if they don’t wish to. So this small window for me can get quite full sometimes, which causes me to choose between certain video chats and missing others, or postponing them to different days.

This has been a challenge as the team grew, however this presents another great opportunity, to increase our dependence on asynchronous communication. In the same way, that the momentum sometimes changes, so do our communication styles. We rely on many different kinds of communication and sometimes one method is better than others, and developing great asynchronous communication is just as important as having real-time communication, such as video syncs.

We’re so grateful to have many tools to help us with this: Slack, Paper, Discourse, Github & Email.

Preference for similar timezones during high communication periods

One thing we have noticed that there are times when we choose to prefer similar timezones. When someone joins the bootcamp, a lot of care has to be taken to help ramp up the new team member in the best way we can and help ensure their success at Buffer. We take this responsibility very seriously, so having more communication overlap helps a lot in this regard. For example, in our current team onboarding process we have a three buddy system: the role buddy, culture buddy & leader buddy. The role buddy’s emphasis is on being there for the new team member to help with any role-based questions & walkthroughs. Like answering questions on code, helping brainstorm tasks, and guiding them along their journey to become a more independent developer.

Therefore we aim to place role buddies in similar or close timezones with lots of overlap. We’re lucky that the team has grown so much that we can now mostly find role buddies in many timezones.

Having engineers on call

Another awesome advantage with having so many developers across timezones is that we usually have at least one engineer available to jump on any alerts, critical bugs or downtime. Having a no-ego doer value on our team also helps promote shared responsibility for our code and team. It’s happened quite often where I’ve deployed something, and it’s created a bug, then when I jump online again the next day, it’s already been found by our happiness hero team, reported & then fixed by another engineer. This is incredible for me.

I’ve also extended this gratitude to other team members many times. The unintentional effect of this is that I get to learn about areas of the code that I don’t usually touch often, or get skilled in my dev ops skills too. This helps the independence that I mentioned earlier, which is key to becoming a great developer at Buffer.

In fact, funny story, the time where I had to learn the most was when something went wonky with our DNS resolution for our buff.ly url, which we use as a default shortener for posts. All posts going out couldn’t resolve the links. The timing however was really curious, as it was when the whole team was flying down to Cape Town for our third Buffer retreat.

Everyone else was in transit and I was the only engineer around. I learned a lot, but there were still some snags that I couldn’t figure out. The irony is that the time when we needed a distributed team the most, in different times & different places to help with DNS resolution & testing, was when everyone was coming together to a central location. ?

Having a distributed team of engineers around the world has made our system accidentally more anti-fragile!

Summary

Working remotely is a lot fun and when you start mixing in timezones it creates whole new way of working. At Buffer this has become quite natural for us. There are some challenges sometimes, but we use those as a opportunity to reflect & change our workflow. The advantages are also a great plus: ongoing momentum, around the clock support & parallelised workflows. I’m sure we’ll be learning a lot as the team keeps growing. It’s a great journey.

Have you had any experience in working across timezones? Is there any tips you can share? Would love to hear!