Having worked in the IT industry for more than three decades and being part of large multinational organizations in India and North America has given me a good understanding of the positives and negatives of East and the West and how to be successful while participating in a globally distributed software development process from India.
Let me start with the background of my experience to set the context. My initial 15 years were spent on being an individual contributor role in India and US. During the fifteenth year of my professional life, I returned to India to find that most companies would not hire a principal-level programmer and I unwillingly decided to become a manager.
I don't regret the decision I made in the winter of 1998 to take on the role of a second-line manager at a large multinational organization that had set up its shore center in India and was in growth mode.
I was tasked with the activity of growing a 5 member team in size, visibility, quality of work that they do, value adds that they bring to the global product.
My understanding of both cultures and relevant experience and having good teams helped me bring in more projects and grow the teams. Some of the teams became so self-reliant and competent; we could get complete ownership of development in India. We no longer were managing projects; we ran software products from India!
My next role was even more challenging. It was the role of a Vice President of development and Lab head in a Swedish multinational organization that wanted to move some new and some existing projects to India.
Being the number one employee of the development lab and heading an unbranded company, I had an unenviable job of getting good talent quickly with a limited budget.
I could retrain some support staff on product verification and validation and get started with an initial set of projects. The journey began by moving some outsourced work in-house.
Then on, a lot happened in quick succession enabling me to add a large number of teams to support the development and testing of all products from India.
An important tip to budding leaders is that the first-line managers that they hire should be technically competent for the role and be ready to get their hands dirty with coding, designing, and code review activities.
I never hired pure people managers for the simple reason that the manager's job in a product company is to manage products and not just people. The India lab grew to have more than half of the worldwide development team.
Then this entity was acquired by another US giant; I then took on a bigger role of managing global teams from India. Being part of large global organizations has given me enough experience and insight into managing globally distributed teams from India which I would like to share here in these columns.
Globally Distributed Software Development (GDSD) is not a new phenomenon but it is still a poorly explored area. There are newer problems in GDSD not seen in traditional software development.
GDSD is technologically and organizationally complex and presents a variety of challenges to be managed by participating development centers. In particular, issues begin with geographical distance and dispersion of teams.
Then there are related challenges that arise out of differences in work allocation, time zones, socio-economic culture, working style, performance measurement, and many more. I will discuss very briefly here how these challenges can be dealt with.
First thing that motivates people is good work or perceived good work. To be successful in GDSD the work allocated to each of the distributed teams has to be balanced both in quality and possibly in quantity.
While setting up a new team in a new location, care should be taken to study the skills that are abundant at that location and create teams that will add value to the organization.
A new team should be a welcome addition to the organization; it should not be in existence just for cost-cutting measures elsewhere. In the initial months, it is important to have many face-to-face meetings with sponsoring team and needs to have training sessions to ramp up the new team to full-time equivalents.
All distributed teams should work as one large virtual team and the feeling of "us and them" should not be allowed to creep in. All the teams including cross-functional teams should participate in the decision-making process. No team should feel that they are an outsourced wing. Oneness is of utmost importance.
Having teams in various time zones around the world has its advantages in providing 24×7 worldwide support much more effectively, in resolving escalated issues round the clock by well-connected teams that can pass on the defect baton in a fail-proof manner.
But the time difference between teams has its share of issues in terms of having team meetings at convenient times. One solution that has worked in teams I have worked with is to rotate the team meeting timings in such a way that inconvenience also comes in rotation and no team is affected all the time.
Additionally plan not to have all members of the team in the meeting all the time especially if the meeting happens in the middle of the night. Recording minutes of the meeting is of course very important. Enable facilities to call from home to reduce inconvenience.
Performance measurement in the initial years needs to be done within a geography as each team will be at various levels on a maturity ladder and thus cannot be compared with the same yardstick. As the teams mature in GDSD, a need to carry out a common performance appraisal across worldwide teams will arise.
This has to be carried out carefully and maintaining parity and transparency is very crucial for success. Setting goals at the top of the pyramid and cascading down is an essential first step in the process.
Everyone in the organization needs to know very clearly what their role is and how they are measured concerning their goals. Staff should be involved in goal setting exercises for them to proactively work towards achieving their goals.
The goals set should make the staff stretch to achieve them. Easy goals will make everyone feel that they have overachieved when in reality they could just be average.
There are many other areas not discussed in this article because of the paucity of space that are important in making a globally distributed software development from India a success. I will cover them in future articles.
About the author: Sreehari Narasipur a seasoned Software Technologist, Consultant, and Mentor with 30+ years of experience in building large engineering teams.
He has had a long tenure at Xerox, Oracle, Telelogic, and IBM Labs. He is currently a co-founder of RightCloudz Technologies which simplifies cloud decision-making for small, medium, and large enterprises.
He can be reached at Sreehari.Narasipur@gmail.com
