ग्लोबल इंजीनियरिंग टीम चलाने की छिपी हुई लागतें और उन्हें कम करने के तरीके

• काश यह बात मुझे ग्लोबल टेक टीम मैनेज करने से पहले पता होती

  टाइमज़ोन के पार 24/7 डेवलपमेंट का वादा करने की कीमत अक्सर execution speed में भारी गिरावट के रूप में चुकानी पड़ती है

• सिद्धांत रूप में, दुनिया भर की प्रतिभा का उपयोग करना, व्यापक कवरेज पाना, और ग्लोबल वर्कफोर्स चलाना आकर्षक लग सकता है
• लेकिन 5 साल तक distributed teams को मैनेज करने के बाद, मैं एक असहज निष्कर्ष पर पहुँचा:

  एक ही क्षेत्र में काम करने वाली टीमों का प्रदर्शन कई टाइमज़ोन में फैली टीमों से लगातार बेहतर होता है

• यह बात remote हो या office-based, दोनों स्थितियों में समान रूप से लागू होती है
• Getaround में फ्रांस और अमेरिका के कई क्षेत्रों (खासकर SF, LA) को एक साथ ऑपरेट करने के अनुभव से मैं साफ़ तौर पर कह सकता हूँ:

  टाइमज़ोन के पार collaboration मूल रूप से कठिन समस्या है, और हम सबसे अच्छा यही कर सकते हैं कि उसके नुकसान को कम करें

अनुभव और पृष्ठभूमि

• लेखक पहले लगभग 2/3 समय office में और 1/3 समय remote/hybrid मोड में काम करता था
• पिछले 5 वर्षों से उसने ग्लोबली distributed teams को मैनेज किया है, और अपनी पहली management role से ही remote teams चलाता रहा है
• यह "remote vs. office work" बहस नहीं है। कोई भी मॉडल हर स्थिति में बेहतर नहीं होता; सही तरीका टीम और उसके goals पर निर्भर करता है
• महत्वपूर्ण बात यह है कि मैंने खुद ग्लोबल टीम बनाने का चुनाव नहीं किया था
  • कई लीडरों की तरह, मुझे भी यह चुनौती company acquisition के ज़रिए मिली
  • Getaround ने उस फ्रेंच कंपनी का अधिग्रहण किया जहाँ लेखक काम कर रहा था, और बाद की कई acquisitions के साथ नई टाइमज़ोन और अलग-अलग सांस्कृतिक अंतर को मैनेज करने की स्थिति बार-बार बनी
• इस प्रक्रिया में, मुझे acquired team की स्थिति (जो बड़े संगठन में integrate हो रही थी) और existing organization की स्थिति (जो नई acquired team को integrate कर रही थी), दोनों का अनुभव मिला
• इन सब अनुभवों से निकला निष्कर्ष
  • सबसे प्रभावी तरीका है टीम को संभव हो तो नज़दीकी क्षेत्र में चलाना। यानी office से physical distance लगभग 3–5 घंटे के भीतर होनी चाहिए
  • यह केवल ज़्यादा control के लिए नहीं है। इसका उद्देश्य ज़रूरी मौकों पर आमने-सामने मिलकर काम करने के अवसर बनाना है
  • खासकर company acquisition के बाद टीम integration में physical distance का बड़ा असर पड़ता है, क्योंकि
    • structured onboarding संभव होता है
    • व्यक्तिगत रिश्ते बनाने के अवसर बढ़ते हैं → और यही लंबी अवधि की सफलता का अहम तत्व है
• अंततः, ग्लोबल टीम को प्रभावी ढंग से चलाने के लिए टाइमज़ोन अंतर को कम रखना और ज़रूरत पड़ने पर लोगों के मिल सकने का माहौल बनाना बहुत महत्वपूर्ण है

मुख्य समस्याएँ (जितनी सोची थी, उससे ज़्यादा गंभीर)

1. रीयल-टाइम collaboration लगभग असंभव हो जाता है

• अलग-अलग क्षेत्रों में एक साथ काम करना स्वभावतः कठिन है
• एक साधारण सवाल भी समय के अंतर की वजह से कई संदेशों के आदान-प्रदान में बदल जाता है, जिससे processing time बहुत बढ़ जाता है
• अक्सर context बदल जाने पर सवाल फिर से पूछना पड़ता है
• यदि कोई समर्पित सदस्य सुबह बहुत जल्दी या रात देर तक meetings में शामिल होकर अल्पकालिक समाधान निकालने की कोशिश करे, तो अंततः वह burnout की ओर जाता है
• व्यक्तिगत त्याग पर आधारित operating model टिकाऊ नहीं होता

2. टाइमज़ोन अंतर deal-breaker बन जाता है

• 3 घंटे का अंतर: न्यूयॉर्क-सेन फ्रांसिस्को जैसा अंतर हो तो किसी तरह manage किया जा सकता है
• 6 घंटे का अंतर: न्यूयॉर्क-पेरिस जैसी स्थिति में हर बार किसी एक पक्ष को अपने schedule की कुर्बानी देनी पड़ती है
• 9 घंटे का अंतर: LA-पेरिस की तरह, साधारण फैसले भी कई दिनों तक टलते रहते हैं
• context बदलते ही फिर से वही सवाल पूछने का दुष्चक्र शुरू हो जाता है

3. अनुमान से कहीं अधिक जटिल आर्थिक समस्या

• अक्सर labor cost बचाने के लिए distributed team चलाई जाती है
• लेकिन management, QA, rework जैसी छिपी हुई लागतें बढ़ने लगती हैं, जिससे अनुमानित बचत काफ़ी कम हो जाती है
• agency या contractors का उपयोग करने पर भी, अच्छी firms महँगी होती हैं और सस्ती firms में rework अधिक होता है, इसलिए कुल लागत बढ़ जाती है
• ऐसे engineers को भर्ती करना और बनाए रखना, जो codebase और organization culture को गहराई से समझते हों, अपने आप में बड़ा निवेश माँगता है
• सही मायनों में काम करने वाली ग्लोबल टीम बनाने के लिए हर क्षेत्र में leadership और culture खड़ा करने लायक पर्याप्त निवेश अनिवार्य है

4. meetings बहुत बड़ा बोझ बन जाती हैं

• जब meetings ज़रूरी हों, तो अलग-अलग टाइमज़ोन के कारण हमेशा किसी न किसी को बहुत सुबह या देर रात जुड़ना पड़ता है
• fairness के लिए कठिन समय को बारी-बारी से बाँट भी दिया जाए, तो अंत में हर व्यक्ति थोड़ा-थोड़ा परेशान होता है
• meeting recordings या notes साझा करने से भी live discussion का असर पूरी तरह replace नहीं होता

5. टीम संरचना अस्वाभाविक हो जाती है

• टाइमज़ोन के आधार पर टीम बँटने लगती है और silos बन जाते हैं
• आपसी dependency कम करने की कोशिश में collaboration synergy भी खो जाती है
• वास्तव में Getaround के M&A के बाद backend और mobile teams का क्षेत्रवार और अधिक अलग होकर काम करना देखा गया

6. सांस्कृतिक अंतर हर समस्या को और बढ़ा देते हैं

• टाइमज़ोन अलग हों तो आमतौर पर culture भी अलग होता है
• direct communication culture और context-focused culture के टकराव से ग़लतफ़हमियाँ पैदा होती हैं
• feedback style और decision-making process में अंतर के कारण टीम alignment कठिन हो जाता है
• जैसे “स्टोरी बहुत बड़ी है। इसे छोटे tasks में तोड़ना चाहिए” बनाम “मुझे लगता है इसे थोड़ा छोटे units में बनाया जा सकता है” जैसी अभिव्यक्ति के फर्क में भी टकराव दिख सकता है

7. करियर पर कम दिखने वाला असर

• leadership opportunities अक्सर HQ के टाइमज़ोन में केंद्रित हो जाती हैं
• remote क्षेत्र की टीमें महत्वपूर्ण चर्चाओं से बाहर रह सकती हैं
• रीयल-टाइम mentoring मुश्किल हो जाती है, और अहम projects HQ के नज़दीकी टीमों में केंद्रित होने लगते हैं
• Getaround में भी क्षेत्रों के बीच संतुलन बनाने की कोशिश हुई, लेकिन HQ के पक्ष में झुकाव वाली वास्तविकता मौजूद थी

सही संचालन का तरीका

शुरुआत पहले नज़दीकी क्षेत्र (Local) से करें

• टीम को संगठन के HQ के पास या अधिकतम 3–5 घंटे की दूरी के भीतर बनाया जाए
• ज़रूरत पड़ने पर लोग सीधे मिलकर काम कर सकते हैं, और सांस्कृतिक context भी अपेक्षाकृत समान रहता है
• टाइमज़ोन मेल खाने से रीयल-टाइम communication स्वाभाविक रहती है

अगर विस्तार ज़रूरी हो

• अगर talent, market presence या किसी और वजह से अपने क्षेत्र से बाहर विस्तार करना ही पड़े
  • हर क्षेत्र में पूर्ण, self-contained team बनाएँ। इधर-उधर बिखरी hiring न करें
  • HQ से कुछ core members को कई महीनों के लिए भेजें
    • best practices स्थापित करने के लिए
    • organization culture पहुँचाने के लिए
    • मज़बूत trust relationship बनाने के लिए
  • संरचना ऐसी रखें कि हर regional team अधिकतम हद तक स्वतंत्र रूप से काम कर सके
  • कोशिश करें कि मौजूदा location से 3 से अधिक टाइमज़ोन दूर न जाएँ
  • async तरीके से काम करने वाला एक स्पष्ट decision-making framework बनाएँ
• इससे अंततः एक dual model बनता है
  • एक ही क्षेत्र के भीतर लोग स्वतंत्र रूप से collaborate करते हैं
  • क्षेत्रों के बीच collaboration तय protocols के माध्यम से होती है
• ग्लोबल विस्तार अपने आप में बुरा नहीं है, लेकिन अक्सर इसे सिर्फ cost-saving के सरल उपाय के रूप में पेश किया जाता है, जबकि वास्तविकता कहीं अधिक जटिल होती है
  • speed, team cohesion, और career growth जैसी छिपी हुई लागतें अक्सर ऊपर-ऊपर दिखने वाले लाभों से अधिक भारी पड़ती हैं

ग्लोबल विस्तार पर सावधानी से विचार करना चाहिए, क्योंकि यह सिर्फ टाइमज़ोन बदलने की बात नहीं है; यह संगठन के सोचने, बनाने और बढ़ने के तरीके को स्थायी रूप से बदल देता है

[roxie]

Google जैसी ग्लोबल कंपनियां भी शायद तीन या उससे ज़्यादा क्षेत्रों में infrastructure engineers तैनात करके 24/7 reliability सुनिश्चित करती होंगी—क्या ऐसा ही है?

[alucardkang]

ग्लोबल इंजीनियरिंग की इस कल्पना से बाहर निकलने की ज़रूरत है..

इसके लिए बेहद आक्रामक process optimization चाहिए, लेकिन एक ही local मानक के आधार पर 3-shift development गेम इंडस्ट्री में आम बात है। उदाहरण के तौर पर, चीन के बड़े गेम स्टूडियो 3 शिफ्ट में 24 घंटे development कर रहे हैं।

EA, Ubisoft जैसी वे गेम कंपनियाँ जहाँ global engineering लंबे समय से स्थापित है, अपने-अपने time zone के हिसाब से काम करती हैं, इसलिए execution speed में delay होना लगभग अनिवार्य है। लेकिन कम living cost + labor cost इसे balance कर देती है, ऐसी भावना के साथ वे इसे operate करती हैं। (अब बड़े पैमाने पर restructuring के बाद स्थिति कैसी है, यह मुझे नहीं पता।)

[kandk]

आखिरकार बात तो labor cost घटाने की ही है।
जब labor cost अलग है, तब भी एक जैसा काम करवाने की कोशिश अपने आप में cultural clash है.. बेहतर होगा कि इसे outsourcing के रूप में किया जाए, जहाँ client-vendor का रिश्ता साफ़ हो।

[gguimoon]

मैं सहमत हूँ। 24 घंटे काम चलता रहता है मैनेजर या प्रबंधन का एक भ्रम है।