Understanding the differences in delivery management between the kick-off phase and the ramp-up phase will be helpful to maximize the value of distributed delivery. In this two-part series, I will share the best six lessons I learnt from scaling up distributed delivery centres with my clients over the last few years. For the sake of simplicity, I’ll refer to ‘offshore distributed delivery centre’ as ‘delivery centre’, and ‘onshore site’ as ‘client site’.
Set up key roles of delivery center manager and technical principal
There are two roles in a middle or large size delivery team that are helpful to dealing with the challenge of ramping up. One is a delivery center manager and the other is a delivery center technical principal.
The delivery center manager acts as a leader who works on the remote site and focuses on delivery assurance, people development and site operations. They are the bridge between the client site and the delivery centre. From the client’s perspective, they represent and are accountable for the delivery of the whole remote team. From the remote team’s perspective, they have the responsibility of sharing the high-level context from the client - the mission of the engagement and the value offshore teams are expected to bring.
The other key role is the delivery center technical principal. This role is more than a tech lead. With clients, they drive the technical direction or engineering baseline conversation. With remote teams, they take care of the technology and engineering during delivery, including sharing technical context, providing high-level strategy and architecture guidance, building security awareness within the remote teams and driving the skillsets development plan.
Usually, we select these candidates by considering both their tenure in this account, as well as their previous experiences of growing teams.
Foster Cultural alignment
When it comes to scaling teams, there are two common cultural challenges teams will face.
Firstly, when you have more stakeholders from the client-side join the team, not all of them may have the same level of empathy for their remote peers who may be located thousands of miles away, which may lead to less effective cooperation. Therefore, helping improve understanding and empathy is key to the success of scaling distributed delivery.
Some examples include holding joint celebrations of national holidays and local festivals such as Lunar New Year and sharing how working in a remote site looks.
Below is a screenshot from a video sent to our clients. The video was made for a project that kicked off during 2020 when travel was not possible. During the Covid-19 pandemic, the teams offshore realized that the small thumbnails of team members on Zoom calls weren’t enough to build relationships. This three-minute video illustrates a typical working day for Thoughtworkers in the remote site, including how teams get to work and how they follow Covid-19 protocols in the office. It was highly recognized by the client as it gave great insight into how their remote peers work.
A screenshot of a typical working day in Thoughtworks Xi’an,
provided by Jia Xie
The second challenge is building awareness of the positive impact a distributed delivery centre can have in the client organization. When client teams start to work with offshore teams from a different organization, client teams may get worried about whether the engagement will damage their own organization’s culture or change their ways of working.
In one of our recent engagements, we presented at a client’s internal town hall together with our client stakeholders to talk about the plans of building a distributed delivery centre, including the purpose, and what things will or will not change. In addition to this, the client executive stakeholders answered all of the questions related to these concerns in a transparent manner. This is helpful to drive further cooperation and support from the client and the wider organization. Another example of the benefits is that it helped the client IT team to prioritize setting up infrastructure for the offshore team among their own backlogs.
Promote Cross-team sharing
There’s a common misconception that if something has been shared with the remote site team, then everyone on that site will know about this. It may be true when there are just five or six consultants involved, but things will be dramatically different at scale because the level of complexity increases. Several anti-patterns might be found if no extra effort is taken:
Eyes only on your own work: When large numbers of teams are spread across different domains or functions, each team may focus on their own business and know little about others, leading to siloed context and not aligned engineering practice.
Unbalanced teams: If there are a few teams with obviously smaller sizes compared with others, team members may have less opportunity to share what they are doing.
One of the key ways to avoid these anti-patterns is to build a ‘one-team spirit’ across different teams. This involves having a common understanding of the goal, which is usually related to the client’s business vision and a strong motivation and commitment to work together to achieve this. Having both clients and team members communicate their update via a town hall, send out quarterly site update emails with different team updates to make sure they all have more visibility, are all helpful.
In the next part, we’ll look at talent development, risk management and workspaces in scaling teams in distributed delivery.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
