You have 1 article left to read this month before you need to register a free LeadDev.com account.
Decentralization of engineering talent is important for so many reasons but two, in particular, stand out.
First, hiring strong engineering talent is the biggest challenge for any engineering team; instead of focusing on only one geographical region, hiring can be parallelized across geographies.
Secondly, decentralization brings a diverse perspective, representing your customers’ voices. At Twitter, approximately 19% of our active customer base is in the US. It makes sense to represent our product that is used globally, with global and diverse perspectives.
Twitter has been intentional about diversification and decentralization for many years, from being an early adopter of hybrid ‘work from both’ work environments before the pandemic to becoming the first major US company to announce permanent remote work plans in 2020.
Much thought has gone into decentralization, from understanding how engineers can most effectively communicate and collaborate, to developing best practices that create an even playing field that fosters personal and professional growth.
As an engineering manager who has been at the helm of establishing, staffing, and growing our Singapore site, there are several challenges and learnings I’ve encountered on our journey toward creating successful engineering teams in a decentralized environment.
I joined Twitter San Francisco in 2013, fresh out of college as a software engineer on the infrastructure team. After a great first year in the US, I ended up moving back to Singapore where I worked for a startup for two years. But my experience at Twitter felt incomplete and I remained curious about how Twitter could unlock its potential to grow internationally – both to diversify its talent pool and to grow the base of people who use the platform in untapped markets.
The opportunity to rejoin the company presented itself when my now-manager moved from San Francisco to Singapore in 2016, with the directive to spin up Twitter’s international data science team under the product data science umbrella. I jumped at the opportunity to help establish this team and grow the Singapore office. We built a small team of five data scientists that focused on understanding how the behavior of people who use our platform differs across geographies, which led to several product improvements (including bookmarks, sharing features, and multiple accounts).
Since 2018, we have been scaling data science teams and adding more decentralized engineering teams to Singapore, such as performance engineering, data engineering, and machine learning.
The journey has been tough but rewarding as we navigated (and continue to navigate) our way through three particular challenges: deciding which teams are best suited for distributed work; defining communication and collaboration best practices for global teams; and discovering opportunities for career growth while leveling the global playing field.
Here I’m going to walk you through each of these challenges, sharing our insights and workarounds in the hope that you can learn from our experiences.
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:
- Codebases are independent. 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.
- Teams can 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.
- Time zone differences offer 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 leveling 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.
Reflections
Building a distributed team or decentralized organization has been a challenge, but it has also presented countless exciting opportunities. For me personally, it has led to an accelerated learning path for my career. For Twitter, it has allowed us to hire strong talent and leverage a diverse range of voices that more accurately represent our customers. If you’re starting out on a similar journey, I hope our insights can help you on your way.
