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 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 background of my experience to set the context. My initial 15 years were spent on being an individual contributor rolein India and US. During 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 setup 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 the complete ownership of development onto 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 number one employee of the development lab and heading an unbranded company, I had an unenviable job of getting the good talent quickly with limited budget. I could retrain some support staff on product verification and validation and get started with 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 development and testing of all products from India. An important tip to the 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 product and not just people. The India lab grew to have more than half of the worldwide development team. Then this entity wasacquired by another US giant; I then took on a bigger role of managingglobal teams from India. Being part of large global organizations has given me enough experience and insight on managing globally distributed teams from India which I would like to share here in these columns.
GloballyDistributed 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 istechnologically and organizationally complex andpresents 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 inwork 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 team 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 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 world has its own advantages in providing 24×7 world wide 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 time difference between teams has its own share of issues in terms of having team meetings at convenient time. One solution that has worked in teams I have worked 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 at 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 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 the success. Setting goals at the top of the pyramid and cascaded 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 with respect to their goals. Staff should be involved in goal setting exercise 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 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 long tenure at Xerox, Oracle, Telelogic, IBM Labs. He is currently a co-founder of RightCloudz Technologies that simplifies cloud decision making for small, medium and large enterprises.
He can be reached at Sreehari.Narasipur@gmail.com