“The best companies outsource to win, not to shrink. They outsource to innovate faster….”
– Thomas Friedman (The world is flat)
I am pained by negative perceptions and comments on distributed development, even though the teams are not at fault. I would like to dispel any misconceived notions, and emphatically state that distributed development is a viable model, and very often the lack of success is a consequence of improper onboarding.
In this blog, I will share some of the strategies and best practices that we adopted to make distributed development live up to its true potential in delivering the desired business outcomes.
I cannot emphasize more the importance of a well-structured and executed onboarding phase. This is perhaps the most critical aspect that will set the tone, and can dictate the success or failure of the endeavor. I typically insist on the involvement of senior executive leadership from the customer’s native teams in this phase, to ensure that the key decision makers understand and appreciate the following:
- There is no silver bullet to solve all your challenges
- This is a journey and not an end
- This is a marathon and not a sprint
In my experience, setting the right expectations will go a long way in ensuring a proper buy-in, and support from all key stakeholders for the extended organization, without burdening it with unrealistic goals for immediate ramp up and delivery. Often, I advise my customers that, they should treat the distributed teams just like their native counterparts, and give them the same time and bandwidth to understand, assimilate, and deliver at the same level. When I ask them, how much time will they give a new employee to become productive in their native environment, I get a response ranging anywhere from 3-6 months. Now, this is without the complexities of culture, geography, and workflow that one has to factor in for distributed teams. Structured onboarding must lead to a well-thought out project plan encompassing all aspects ranging from recruitment, employee onboarding, training (knowledge transfer), team building, communication, common work flow/process, etc.
Align with customer goals
Alignment phase must be used to gain an understanding of the customer’s native organizational setup, their product/technology roadmap, workflow process and business goals. This will enable the service provider or distributed development partner to reach an agreement on the composition, roles, and functional responsibilities of the distributed team. This phase will also help gain understanding of the customer’s current development and delivery process, and reach a common ground on the ideal process and work flow tools to be adopted between the native and distributed teams.
Acquire and Assimilate
This phase must be used to recruit and put-together a customized team with the agreed composition and skills. One the new team is in place, I insist that my customers invest significant time and resources to arrange intense and structured brainstorming and interactions between the teams. I encourage my customers to indulge in ‘shuttle diplomacy’, whereby either the native teams travel to the location of the distributed teams, or vice versa, and spend anywhere from 4-8 weeks. Trust me, time spent on assimilation can reap rich rewards and ensure:
- Cultural integration
- Knowledge transfer
- Team building
- Organizational alignment
- Common work culture
This phase will enable both teams to understand each other, establish trust and transparency, and facilitate knowledge transfer in terms of product and technology training. This intense interaction will enable the new team to gain insights into the process and tools that are being used, learn about the roles and responsibilities, and also helps the customer to set initial expectations and goals.
Adjust and Accelerate
Once the new team is properly acclimatized with the customer’s product, technology, process, and goals, it is time to start producing. The goal in this phase must be to produce initial results, measure and evaluate with agreed benchmarks or quality/performance metrics, and adjust process and workflow to produce better results. Adopting proven best practices for distributed development such as ‘pair programming’ has proven very effective in driving the alignment of the native and distributed teams, and to ensure that both teams produce comparable results, working in tandem.
In this age of globalization, and quest for the best talent, it is but inevitable that many western businesses, especially those that are driven by technology and software, have adopted global sourcing strategies. Businesses are driven by right-sourcing – identifying the right long-term partners and vendors with the right skills to handle specific processes or components, irrespective of their geographic location. The success of giants like Google, Apple, Facebook, Amazon and many other technology companies in leveraging global sourcing to realize their technology and innovation roadmaps, has proven beyond a doubt the efficacy of distributed development. This strategic approach enabled businesses to overcome a multitude of challenges and reap enormous benefits including, gaining access to highly skilled talent, operational flexibility and scalability, and cost optimization. In fact, for many businesses, having a globally distributed development and service capability has become a key competitive differentiator.
In the past two decades, India, with its vast pool of skilled technology talent, has developed mature capabilities and emerged as a preferred offshoring destination for IT services. I was fortunate to not only witness, but also be a part of the evolution of the IT service industry from a cost-arbitrage model handling low-value tasks, to that of a strategic partner handling increasingly sophisticated technologies to build world class products and services, and deliver significant business value.
Let me reiterate, by stating that distributed development is an effective and proven business model that is here to stay, and proper onboarding will guarantee its success.