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?”Distributed TeamIt’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.

pablo (6)

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.

pablo (4)

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.

Respond team syncing during the beta launch
Respond team syncing to catch up on the beta launch

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.

pablo (5)

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!

Free up your day with our Social Media Tools

Buffer can save you up to an hour a day and grow your traffic too.

Learn More
Written by Niel de la Rouviere

Niel is the Product Engineering Director @ Buffer. He spends time working on engineering culture, hiring, inclusivity & personal fulfilment within the engineering team.

  • This is such a fascinating post Niel! I live in Abu Dhabi, four hours ahead of my native England, and so whilst professionally I am usually in the same time zone, personally I struggle sometimes. I love the idea that distributed time zones can be beneficial. Thank you for sharing your thoughts.

  • I was wondering about how this worked myself, so thanks for sharing Niel! Right now I work with engineers locally, but we support some colleagues across the country. Having experienced some of the “gotchas” just a 3 hour offset can cause, I can certainly see the advantages of having engineering support spread out around the world & clock.

    When forming smaller teams for various projects, are overlapping working days considered much, or is it more treated as incidental and the team will make it work using all the tools at hand?

    One tool I found recently that I thought would be fun to share: http://www.worldchatclock.com
    It lets you set a bunch of different cities/timezones for a team and has a great visual representation of how standard working days overlap. This allows you to more easily figure out who is available and makes planning of group chats a little easier.

    Example with some cities configured: http://bit.ly/1QvCrWz

    Cheers,
    Brendan

    • Woah, that’s such a rad tool Brendan! We use a similar tool that Dan, one of our engineers built. Here’s our team: http://timezone.io/team/buffer. I’ll definitely share that with the team.

      As for smaller teams when they are formed, at the moment, we don’t quite take timezones into account. The main reason for that is that we want to give people the freedom to move around and fall into teams that also fit their motivation. Things change often too, especially when teammates travel. We rather aim for fluidity here and adjust as things change. 🙂

      A recent example of a more loosely formed team and how we adapt to timezones, Jim (Director of Product), Joel (CEO), Sunil (CTO), me (Product Engineering Director) and Dan (Engineering Lead in Buffer for Business) sync once a week to chat about team dynamics, product changes, new teammates, engineering needs and more. We changed the time for this sync this week as Joel flew down to Hawaii and will be staying there for month and half. 🙂

      If people can’t quite make syncs on some days, if they’re sick, or something comes up, then we aim to still write detailed notes to make sure everyone is up to speed. I think that’s why we try to see real-time communication and asynchronous communication as equal, even though some of have advantages over the other, we aim to make sure that someone isn’t excluded 🙂 Being fully remote has made us aware that communication & transparency is key to making this work.

      I hope that helps here Brendan! Happy to answer any more questions!

      Thanks for the cool comment.

  • Really touched something with parallelisation! It’s challenging to juggle with fast and slow-paced work dynamics but worth it as you shared!

    Wondering how effective do you think is your current communication setup? Slack + Discourse + Emails sounds a bit overwhelming to me. Curious to know how it feels to you guys.

  • @zayd_awadallah:disqus: Inside Buffer
    Working Remotely: How we develop Buffer over 10 different timezones