At Plato — we interview senior engineering leaders all the time, and this story comes from Skyscanner’s Engineering Manager, Ardy Dedase.
Let me set the context…
The concept of distributed teams is prevalent nowadays in high-growth tech companies. It’s inevitable that in the span of your tech career, you’ll have the opportunity to work with or lead multiple teams across multiple time zones. There was a point in my career where I needed to work closely with people and teams from across different office locations: Edinburgh, London, San Francisco, Shenzhen, and Singapore. This situation led to me being spread thin across my responsibilities as an engineering lead and manager. It also caused some of our teams to stay late at the office, delayed deliverables, miscommunication across teams, and misalignment in our collective goals which caused further delays.
We came up with the following guidelines and shared them across our organization.
- Separate work streams for different locations. Collocated teams can have similar work streams whilst minimizing dependencies of these work streams between different locations. We are all for collaboration, but for distributed teams we’d like to have as much autonomy as possible for each collocated team or group of teams and reduce dependencies between locations.
- Get to know your remote colleagues and build personal relationships. Spending time in person is not always possible but it’s the best way to build rapport. At least make an effort to spend one to one conference calls with your remote colleague especially if you’ll be working closely together. Start by having an introduction conference call to break the ice and kickstart the relationship-building.
- Negotiation and compromise should come from all teams regardless of location or office size. Different sides of the world will need to give while others will need to take. For example, there are times when our U.K. based teams will need to wake up early while our APAC based teams will need to stay late at the office.
- No last minute changes or requests. People have adjusted their schedule either to wake up very early to jump in the call or to skip their dinner appointment so they can join the synced-up conference call. If you really need to change or cancel the meeting give at least 24 hours notice. Your colleagues will thank you for giving them their time back.
- Treat your documentation as part of your product. When your team in Singapore is sleeping, the source of truth of how your products or how to use your API will be its documentation.
- There will be cases where it will be impossible to compromise without taking a toll on people’s personal lives. One example is the dynamics between teams that are in timezones without reasonable time overlaps like San Francisco and Singapore. For such cases it’s best to structure your teams and meetings in such a way that there is no need for overlap between locations that are in the opposite sides of the globe. For example, schedule meetings and set work streams that are meant to optimise between Singapore and London, then London and San Francisco.
- Default to asynchronous communication through usage of tools like Slack and Confluence. Reserve only necessary occasions to jump in a conference call for a meeting. Examples:
- Leave your questions in your Slack channel before you go home. Then, best case is you’ll have an answer the next morning when you come back. Not so good case is someone saw your question but didn’t know the answer and will hopefully tag someone else who can help.
- Write a Confluence document of your plans with a breakdown of tasks. Share that to your remote colleagues before you go home and ask them to leave their comments on the document.
- Revisit and revise your working guidelines regularly. What worked yesterday might not work today.
—Skyscanner’s Engineering Manager, Ardy Dedase.