2 Golden Tips On How To Manage An Indian Team
I just read a very interesting blog post on managing Indian teams, written by Dutch culture trainer Frank Garten. His article starts with a phrase that I indeed have heard many times:
“People from India always deliver late, and when a project is delayed, they will never tell you but rather say everything is fine”.
Frank gives some general rules of thumb to change your own behavior (as opposed to trying to change the other’s behavior):
Practical advice therefore for the Western project manager is to
- Say clearly what you expect of people, how to carry out their work and how to report back to you (on what, using which medium, when, etc.)
- Describe work processes on paper, and even practice work processes with the people who carry them out
- Do not expect people to be creative and pro-active. Explain them very explicit, and very often, what ‘creative’ and ‘pro-active’ means to you. Be very explicit about the fact that you want them to think out-of-the-box and voice their opinion. Help and encourage them often to do so.
During my 9 years working with Indian teams, I have found that people tend to choose one of 2 paths to solve the cultural gap with Indians: either they specify everything until the last dot OR they try to develop an open and entrepreneurial culture within the team they collaborate with.
I won’t argue that describing every detail to an Indian, will work. The issue is though that it’s frustrating for a Westerner to do so (maybe even more for the northern europeans than the Americans). We’re used to having people come up with their own ideas, giving a view on the outcome we expect, give them the conditions and let them figure out their own way to achieve the desired outcome.
In a software project, having to specify every detail onshore takes a lot of time. And even if you do this, it’s likely that you still won’t get back exactly what you described.
So the approach that I have found to work in our company is twofold:
A. select people and develop people on 2 core values (we have 6, but these 2 solve the puzzle described in this article): responsibility and openness.
B. choose an agile process
A. Selecting and stimulating openness and responsibility
Dutch are open at the risk of being very blunt. Indians tend not to be open, mainly to ‘keep the peace’ (resulting in a friendliness that I personally love). As Frank describes, it’s important to communicate why you find this important time and again. When you select people that are more open than the average and train them on openness, they will open up.
Because of the hierarchical society, people are used to getting instructions instead of taking 100% responsibility for their own work. Hire people who feel responsible for the work that they produce (one simple question that helps you drop many people within a minute: do you tend to ask for permission upfront or forgiveness afterwards?). In our company, we put every programmer in direct contact with a customer from day 1. No excuses, you’re all naked and you have to make your customer happy. Your performance is measured by the review you get directly from your client and you’re responsible for getting the review. Your salary also depends on the review you get. In this system, people who avoid responsibility won’t stay long. There are no project managers or testers to improve bad results.
B. Use an agile process
Scrum has two central elements that help avoid the rigid solution of describing everything in detail:
- requirements are specified by the whole team (team+scrum master+product owner). B. there is a meeting rythm in which every day the team discusses what they’re working on and where they’re stuck and regularly the way of working is reviewed.
Conclusion: If you select the right people and instill an agile process, delays in projects will happen as frequently as you’re used to with your local team. And if there is a delay, you’ll know and you’ll have plenty of opportunities to steer your project in the right direction.
I have written several books about this topic, if you want to get deeper insights into these two tips, you can download our books here.
Ik heb net een zeer interessante blog post gelezen over het managen van Indiase teams, geschreven door de Nederlandse cultuurtrainer Frank Garten. Zijn artikel begint met een zin die ik absoluut vaker heb gehoord:
“Mensen uit India leveren altijd laat op en als een project vertraagd is zullen ze je dat nooit vertellen, maar liever zeggen dat alles goed gaat.”
Frank geeft een aantal algemene standaarden om je eigen gedrag te veranderen (in tegenstelling tot het proberen te veranderen van de anders gedrag):
Praktisch advies voor de Westerse projectmanager is dan ook om
- Duidelijk te zeggen wat je verwacht van mensen. Hoe ze hun werk moeten doen en hoe ze verslag aan je uit moeten brengen (waarover, via welk medium, wanneer, etc.)
- Beschrijf werkprocessen op papier en oefen zelfs werkprocessen met de mensen die ze uitvoeren
- Verwacht niet dat mensen creatief en proactief zijn. Leg ze zeer expliciet en zeer vaak uit wat ‘creatief’ en ‘proactief’ voor jou betekent. Wees zeer expliciet over het feit dat je wil dat ze out-of-the-box denken hun meningen uiten. Help en stimuleer ze vaak om dit te doen.
Tijdens de 9 jaar waarin ik gewerkt heb met Indiase teams, heb ik gemerkt dat mensen geneigd zijn één van deze 2 paden te kiezen om het cultuurverschil met Indiërs op te lossen: of ze specificeren alles tot op de laatste punt, OF ze proberen een open en ondernemende cultuur te ontwikkelen binnen het team waarmee ze samenwerken.
Ik zal niet beweren dat elk detail aan een Indiër beschrijven niet werkt. Het probleem is alleen dat het frustrerend is voor een Westerling om dat te doen (misschien zelfs meer voor de Noord-Europeanen dan voor de Amerikanen). We zijn eraan gewend dat mensen met hun eigen ideeën komen, waarop wij een mening geven over de uitkomst die we verwachten, we ze voorwaarden meegeven en ze hun eigen manier laten vinden om de gewenste uitkomst te bereiken.
In een softwareproject neemt het veel tijd in beslag om elk detail on-shore te moeten specificeren. En als je dit al doet, krijg je waarschijnlijk alsnog niet precies terug wat je beschreven had.
Dus de aanpak waarvan ik gemerkt heb dat werkt in ons bedrijf is tweezijdig:
- Selecteer en ontwikkel mensen op 2 kernwaardes (wij hebben er 6, maar deze 2 lossen de puzzel beschreven in dit artikel op): verantwoordelijkheid en openheid.
- Kies een agile proces
- Het selecteren en simuleren van openheid en verantwoordelijkheid
Nederlanders zijn open met het risico zeer bot te zijn. Indiërs neigen ernaar om niet open te zijn, vooral om de ‘vrede te bewaren’ (resulterend in een vriendelijkheid waar ik persoonlijk van houd). Zoals Frank beschrijft: het is belangrijk te communiceren waarom je dit belangrijk vindt, keer op keer. Als je mensen selecteert die meer open zijn dan gemiddeld en ze traint op openheid, zullen ze zich openstellen.
Door de hiërarchische samenleving zijn mensen gewend om instructies te krijgen in plaats van zelf 100% verantwoordelijkheid te nemen voor hun eigen werk. Neem mensen aan die zich verantwoordelijk voelen voor het werk dat ze leveren (een simpele vraag die je snel helpt vele mensen weg te strepen is: vraag je liever vooraf om goedkeuring, of naderhand om vergeving?). In ons bedrijf zorgen we ervoor dat elke programmeur vanaf dag 1 in contact staat met de klant. Geen excuses, je bent helemaal naakt en moet jouw klant blij maken. Je prestatie wordt gemeten door de reviews die we direct van onze klanten krijgen en je bent zelf verantwoordelijk voor het krijgen van die reviews. Je salaris hangt ook af van de reviews die je krijgt. Met dit systeem blijven de mensen die verantwoordelijkheid vermijden niet lang. Er zijn geen project managers of testers om slechte resultaten te verbeteren.
- Gebruik een agile proces
Scrum heeft twee centrale elementen die helpen bij het voorkomen van de starre oplossing van het beschrijven van alles in detail:
- Benodigdheden zijn gespecificeerd door het hele team (team+scrum master+producteigenaar)
- Er is een vergaderritme waarin het team elke dag bespreekt waar ze mee bezig zijn en waar ze vast zitten en regelmatig wordt hierbij de werkwijze herzien.
Conclusie: Als je de juiste mensen selecteert en een agile proces inboezemt, komen vertragingen in projecten even vaak voor als dat je gewend bent met je lokale team. En als er vertraging optreedt, weet je daarvan en heb je genoeg mogelijkheden om het project de juiste richting op te sturen.
Ik heb verscheidene boeken geschreven over dit onderwerp. Als je dieper inzicht in deze twee tips wilt, kun je de boeken hier downloaden.
About Hugo Messer
Hugo Messer is a Dutch entrepreneur, distributed agile team specialist, and author. He is the founder and owner of Bridge Global, a software services provider, and ekipa.co., an agile coaching agency. He has been building and managing teams around the world for the past several years. His passion is to enable people that are spread across cultures, geography and time zones to cooperate. Whether it’s offshoring or nearshoring, he knows what it takes to make global cooperation work.
View all posts by Hugo Messer →
Like!! I blog quite often and I genuinely thank you for your information. The article has truly peaked my interest.