Challenge 1: Deciding which teams are best suited for distributed work
One of the biggest challenges we faced was figuring out which teams were best suited to be decentralized and would benefit from a distributed setup.
Not all teams, at various stages of maturity, can thrive in an asynchronous environment. Some teams can fail due to the high risk of being siloed and misaligned with the culture and priorities of the company.
For instance, we noticed that working on a shared codebase was inhibiting the success of the project as there were challenges with ensuring that both locations were aligned on the context and prioritization.
The following three principles were helpful to consider when picking and pitching for decentralized teams:
- Independent codebases reduce communication overhead. We recognized that we need more synchronous communication and context sharing when distributed teams work on tightly coupled modules of code, which is more difficult when overlapping working hours are only one to two hours. We mitigated this by offering internal transfer opportunities for senior engineers who help to build context. Additionally, our data science and data engineering teams operate on mostly independent codebases that require minimal overlap with other team repositories.
- Uninterrupted working blocks help teams achieve deep work. Certain teams work better when they have the opportunity of uninterrupted working blocks, with one to two hours of cross-timezone collaboration. Data science and machine learning teams specifically benefit from this as they want to avoid knee-jerk inferences.
- Make the most out of time zone differences for greater coverage. Certain 24/7 coverage teams such as site reliability engineering and quality engineering operate on a ‘follow-the-sun’ model with eight-hour shifts in each time zone. These teams benefit immensely from being globally distributed with defined handover agreements. Additionally, for some engineering teams, productivity is multiplied when code is written in the day and reviewed and approved by the sister team during the night.
Challenge 2: Defining communication and collaboration best practices for globally distributed teams
When dealing with decentralized teams, it’s important to address the challenges of effective communication and collaboration and establish best practices for folks working in different locations.
In 2019, the data science team in Singapore took on a project to understand the impact of a new feature launch in collaboration with another data science team located on the west coast of the US. This was the first cross-time zone collaboration on this feature, with tighter deadlines that left little room to build a working agreement and set up the right expectations of communication. This led to a breakdown of collaboration and provided a host of best practices for the team and the site:
- Set expectations via ways of working agreements. Formalized and templated working agreements that can be reviewed and generally agreed at the beginning of the project prove extremely effective in the long run. Working agreements address the topics of communication frequency, density, shared documents, and collaboration channels. It also helps to align on clear boundaries of ownership, brings empathy to the time zone challenge between the teams, and asserts focus on multiplying the gains from decentralization.
- Overcommunicate as a habit. This is a muscle that develops over time and needs to be instilled in each new hire of a decentralized team. Most engineers, new to decentralization, have worked primarily in local teams. It is imperative to provide resources and training on communication that is dense yet complete and requires minimal back-and-forth to save precious time.
- Encourage empowerment and autonomy. Decentralized teams need to feel autonomous to deliver their best work. This can be done through various methods by ensuring a level playing field in terms of team staffing, with a well-balanced team of senior and junior members. Additionally, staffing key functions alongside engineering teams such as product management or technical program management, for example, helps teams function effectively.
Challenge 3: Discovering opportunities for career growth and levelling the global playing field
Finally, the challenge that is closest to my personal journey is that of career growth. I was hesitant to start as the first hire in Singapore at an early stage in my career as I felt that it would not give me the benefits of learning from others around me, and I might not grow as fast as my peers in other well-staffed sites.
During the first few months, I realized that if I did not make a proactive effort in overcommunicating, I would lose context and alignment with my partner teams. But these concerns were resolved through conversations with senior leaders as they formalized decentralization as a company initiative and actively helped to build a career path for me.
Here are a couple of specific career challenges we faced and how we worked to resolve them:
- Removing silos. A major challenge for folks working in a decentralized model is the risk of operating in a silo. This can be especially damaging in the early stages of a career. Silos happen when information is not shared, usually unintentionally. After emerging from communication breakdowns, we were able to iterate through working agreements, which instituted learnings for communication.
- Creating teams with diverse skill sets. Finally, new decentralized sites often don’t have teams with diverse skill sets such as design or product management. I was apprehensive of myself and the engineers in Singapore not having enough collaboration with diverse functions. This is hard to fix and takes time as teams grow slowly in new geographies while functions are added based on the need. We partially mitigated this by carving out more intentional cross-functional collaborations with available functions like user research.
Final Reflections
