ईगो को अलग रखकर इंजीनियरिंग: सीख और अंतर्दृष्टि
प्रस्तावना
- टेक उद्योग में ईगो और संकीर्ण गुटबंदी (parochialism) टीमवर्क में बाधा डालने वाले प्रमुख तत्व हैं
- इंजीनियरिंग टीमों को अधिक प्रभावी और सहयोगी बनाने के तरीकों पर विचार करते हुए मिली अंतर्दृष्टियाँ साझा की गई हैं
जिम्मेदारियों के बँटवारे की दुविधा
- सिर्फ़ दो कर्मचारी हों तब भी काम का बँटवारा ज़रूरी होता है
- लेकिन बँटवारे का तरीका तुरंत और दीर्घकालिक, दोनों तरह के प्रभाव डाल सकता है
- कई कंपनियाँ इस समस्या पर गहराई से विचार नहीं करतीं
कंप्यूटर साइंस की हक़ीक़त
- कई कंप्यूटर साइंटिस्ट बाद में समझते हैं कि वे एक ऐसे क्षेत्र में आ गए हैं जिसका संबंध गणितीय अमूर्त कार्य से है
- इस शुरुआती झटके के कारण वे अपने करियर के अधिकांश हिस्से में कंप्यूटर के बाहर के क्षेत्रों में सीखी हुई बातों को लागू करने से बचते हैं
- अगर कार्यस्थल के माहौल पर भी उतनी ही गहराई से सोचा जाए जितना तकनीकी दृष्टिकोण पर, तो सुधार संभव है
संगठनों की बीमारियाँ और अनुभव
- सफल कंपनियाँ भी संगठनात्मक विकृतियों से बच नहीं पातीं, और उनसे बहुत कुछ सीखा जा सकता है
- शुरुआती करियर में देखे गए एक startup का उदाहरण:
- कंपनी छोटी और शुरुआती चरण में होने के बावजूद पहले से ही अत्यधिक नौकरशाही ढाँचा अपना चुकी थी
- वेब रिक्वेस्ट की गति बढ़ाने के गलत सिद्धांत पर एक "Python middleware" जोड़ा गया
- नतीजे में नेटवर्क hops बढ़ गए और performance गिर गई
- एक ही फीचर रिलीज़ करने के लिए कई भूमिकाओं के बीच जटिल सहयोग की ज़रूरत पड़ती थी
- database कर्मियों को DDL लिखना और stored procedure विकसित करना पड़ता था
- Python developers अक्षम middleware पर काम करते थे
- PHP developers frontend code लिखते थे
- इस तरह की विभाजित संरचना के कारण दो साल तक कोई नया फीचर रिलीज़ ही नहीं हो सका
- नतीजा
- अक्षम संरचना और workflow की वजह से पूरी टीम को निकाल दिया गया
- मुझे नहीं। शिकायत करने की वजह से मैं बच गया
बड़ी कंपनियों में भूमिकाओं के अलगाव की समस्या
- पृष्ठभूमि: 1,000 से अधिक कर्मचारियों वाली एक B2B product कंपनी में काम
- शुरुआत में स्पष्ट रूप से बँटी हुई functional teams (Feature Teams) और shared service teams (operations, DBA आदि) का ढाँचा था
- शुरुआत में यह एक सामान्य संरचना जैसा लगा
- समय के साथ भूमिकाएँ ज़रूरत से ज़्यादा बँटती गईं और अक्षमता बढ़ती गई
- रिलीज़ संभालने के लिए "Release Manager" जैसी नई भूमिका जोड़ दी गई
- भूमिका जोड़ने का कारण स्पष्ट नहीं था, और संगठन धीरे-धीरे और जटिल होता गया
- समस्या के उदाहरण:
- frontend engineers को सिर्फ़ frontend और backend engineers को सिर्फ़ backend काम तक सीमित कर दिया गया
- यह अलगाव किसी हद तक चल गया, लेकिन security team को हर security काम का एकमात्र ज़िम्मेदार बनाने वाली नीति ने गंभीर समस्याएँ पैदा कीं
- नतीजा: भूमिका को काम के बराबर मान लेने से संगठन की दक्षता घट गई
- टीमों के बीच सहयोग की कमी और काम की पुनरावृत्ति बढ़ी
बिखरा हुआ product portfolio और oversight संरचना की कमी
- एक ऐसी कंपनी में काम किया जो मुख्यतः native client applications बनाती थी
- शुरुआत में उसके पास एक सफल flagship client application था, लेकिन 2020s तक आते-आते कई बिखरे हुए और असंगत प्रोजेक्ट समानांतर चल रहे थे
- product portfolio management की समस्याएँ
- पूरे product landscape पर नज़र रखने वाली संरचना कमज़ोर थी
- tech stack या निर्णयों में products के बीच कोई समन्वय नहीं था
- हर product team स्वतंत्र रूप से CEO को रिपोर्ट करती थी, और CEO कोई समन्वयकारी प्रयास नहीं करते थे
- shared operations function बनाने की कोशिश
- operations group आर्किटेक्चर निर्णयों की प्रक्रिया में शामिल नहीं था, जिससे मुश्किलें पैदा हुईं
- operations टीम अतीत में dev teams द्वारा इस्तेमाल की गई सैकड़ों services को संभालने में इतनी व्यस्त थी कि महत्वपूर्ण फैसलों में शामिल होने का समय ही नहीं था
- इसे संगठनात्मक अक्षमता का एक आदर्श उदाहरण माना जा सकता है
[संगठनात्मक समस्या पैटर्न का सामान्यीकरण]
पैटर्न 1: भूमिका और काम के बीच भ्रम
- अक्सर नई तरह के काम के लिए नई job description बना दी जाती है
- उदाहरण: AI से जुड़ा काम मौजूदा engineers कर सकते हैं, फिर भी "AI engineer" जैसी नई भूमिका बना दी जाती है
- इससे संगठन के भीतर टकराव पैदा हो सकता है और मौजूदा टीम सदस्यों का मनोबल गिर सकता है
- इस तरह का अत्यधिक role separation अनावश्यक bureaucracy पैदा करता है
पैटर्न 2: DevOps क्रांति का अधूरा प्रसार
- कई कंपनियाँ दावा करती हैं कि उन्होंने "DevOps लागू कर लिया", लेकिन असलियत में विभाजन और टकराव बने रहते हैं
- operations team और dev team, या SRE और dev team के बीच स्पष्ट सीमाएँ सहयोग को कमज़ोर करती हैं
- DevOps का मूल उद्देश्य सहयोग और सहानुभूति के ज़रिए दीवारें गिराना था, लेकिन व्यवहार में यह कम ही दिखता है
पैटर्न 3: कठोर कार्य-विभाजन की सीमाएँ
- काम को बारीकी से बाँटना और विशेषज्ञता के आधार पर अलग करना leaders को स्वाभाविक लग सकता है
- उदाहरण: AI का काम AI विशेषज्ञ को, operations का काम operations staff को
- लेकिन ऐसा ढाँचा bottleneck पैदा करता है
- अतिरिक्त engineers नई tasks पैदा करके गति बढ़ाना चाहते हैं, लेकिन नतीजे में analysis queue का इंतज़ार non-linear तरीके से बढ़ जाता है
- जैसे ही data scientists या analysis resources सीमा पर पहुँचते हैं, पूरी process धीमी हो जाती है
पैटर्न 4: गलत संगठनात्मक ढाँचा अतिरिक्त काम पैदा करता है
- जब संगठनात्मक सीमाएँ अस्पष्ट हों या गलत तय हों, तो अनावश्यक workload बढ़ता है
- उदाहरण: security team हर security issue को खुद संभालती है, और security tickets की queue बन जाती है
- dev teams security को ध्यान में रखे बिना काम आगे बढ़ाती रहती हैं, जिससे अंततः security का काम और बढ़ता है
- इसे अल्पकाल में नज़रअंदाज़ किया जा सकता है, लेकिन दीर्घकाल में यह गंभीर समस्या बन जाता है
पैटर्न 5: इंसानी पूर्वाग्रह की पुरानी समस्या
- लोग अपनी भूमिका को बढ़ाकर और दूसरों की भूमिका को कम करके आँकते हैं
- कुछ लोग server-related काम को "तकनीकी" नहीं मानते
- इसके उलट, product work को कम तकनीकी समझना भी आम बात है
- ऐसा रवैया टीमों के बीच भरोसा कम करता है और सहयोग रोकता है
- "प्रतिभाशाली लेकिन हठी व्यक्ति" सिस्टम स्तर पर कोई वास्तविक मूल्य नहीं दे पाता
- leaders और संगठन अक्सर ऐसे रवैये को गलती से "स्मार्ट" या "valuable" समझ लेते हैं
[गुटबंदी और ईगो]
- गुटबंदी (Parochialism) और ईगो (Ego) संगठन के भीतर बड़ी अक्षमताओं के प्रमुख कारण हैं
- गुटबंदी: दूसरों के क्षेत्र में कदम न रखने की प्रवृत्ति या जिज्ञासा की कमी
- ईगो: काम पर गर्व कभी सकारात्मक असर डाल सकता है, लेकिन क्षेत्र बचाने या दूसरों की क्षमता को कम आँकने के रूप में इसका नकारात्मक असर भी दिख सकता है
- ये सहज प्रवृत्तियाँ सहानुभूति की कमी पैदा करती हैं और सहयोग में बाधा डालती हैं
बेहतर उदाहरण: सफल इंजीनियरिंग टीम का अनुभव
- एक पुराने startup में क्षैतिज रूप से बँटी हुई "fiefdom" जैसी संरचना को सरल बनाकर छोटे टीम ढाँचों में बदला गया
- DevOps को गंभीरता से अपनाने वाले leaders ने दीवारें तोड़ीं और सहयोग को बढ़ावा दिया
- लगभग दो साल की "creative destruction" के दौरान हर टीम सदस्य ने अलग-अलग तरह के कामों में हिस्सा लिया
- नतीजतन infrastructure की stability और software release करने की क्षमता वापस आई
- संगठनात्मक पुनर्गठन के बाद इंजीनियरिंग टीमों को समय और autonomy मिली
- इसके आधार पर चर्चा हुई कि टीम की अतिरिक्त क्षमता का उपयोग कैसे किया जाए
प्रस्ताव 1: बड़े पैमाने पर रिफैक्टरिंग (Proposition 1: Boil the Ocean)
- अक्सर टीमें अतिरिक्त संसाधनों से उन हिस्सों की बड़े पैमाने पर refactoring करती हैं जिन्हें वे पसंद नहीं करतीं
- लेकिन यह तरीका पहले भी आज़माया जा चुका था और लोकप्रिय नहीं था
प्रस्ताव 2: "दिखावटी" गतिविधियाँ (Proposition 2: Dress Like Big Dorks)
- टीम के खाली समय का उपयोग टीम संस्कृति दिखाने वाले merchandise जैसी चीज़ें बनाने में किया गया
- लेकिन यह मुख्य रणनीति के रूप में उपयुक्त नहीं था
- निर्णायक घटना: designer की build error
- एक रात designer ने build तोड़ दी, और टीम को उसे recover करना पड़ा
- शुरुआत में सुझाव आया कि designer और coders की भूमिकाएँ और साफ़-साफ़ बाँट दी जाएँ
- लेकिन टीम के एक सदस्य ने designer को सीधे deployment key दे देने का साहसी फैसला लिया
- नतीजा:
- designer code work में शामिल हुआ और collaboration का स्तर बेहतर हुआ
- टीम ने monitoring, test suite आदि बनाए ताकि सुरक्षित working environment बने
- work efficiency और productivity में बड़ा सुधार हुआ
प्रस्ताव 3: दूसरी टीमों को सशक्त बनाना (Proposition 3: Empower Everybody Else)
- टीम की अतिरिक्त क्षमता का उपयोग दूसरी टीमों को support और सक्षम बनाने में किया गया
- यह तकनीकी और गैर-तकनीकी, दोनों तरह की टीमों पर लागू हुआ
- इससे पूरे संगठन में सहयोग बढ़ा और बेहतर execution संभव हुआ
अमल की प्रतिबद्धता
- designer वाली घटना के बाद विभिन्न समूहों के साथ काम करते हुए ऐसे ही कई सफल अनुभव हुए
- टीम के free time और संगठनात्मक अधिकार का उपयोग इस तरह किया गया कि हर टीम प्रभावी ढंग से सहयोग कर सके
- सफल execution की बुनियाद पूरे संगठन में सहयोग और सहानुभूति थी
[सफल execution कैसा दिखता है]
- विशेषज्ञ बनाम owner
- टीमों में domain experts होते हैं, लेकिन किसी खास काम या domain का एकमात्र "owner" नहीं होता
- security उदाहरण: हर security issue को security team के पास भेजने के बजाय, पूरी टीम security की ज़िम्मेदारी लेती है और security team बाकी सदस्यों की क्षमता बढ़ाने का काम करती है
- यही मॉडल दूसरे क्षेत्रों में भी लागू होना चाहिए था, लेकिन अधिकांश टीमें ऐसा नहीं कर पाईं
- विफल उदाहरण
- frontend और backend engineers को सख़्ती से अलग कर दिया गया
- सहयोग की कमी ने GraphQL जैसी अनावश्यक जटिलता पैदा की
- कुछ खास भूमिकाओं में विशेषज्ञों की ज़रूरत होती है, लेकिन "frontend" और "backend" जैसी titles में बाँटना अक्षम है
- मुख्य सिद्धांत:
- "domain expert, owner नहीं"
- विशेषज्ञों को अपने मूल काम के अलावा बाकी टीम सदस्यों की मदद के लिए भी समय देना चाहिए
सक्रिय सहयोग को बढ़ावा देना
- खाली समय उपलब्ध कराना
- कुल मिलाकर टीमवर्क बनाए रखने के लिए टीम सदस्यों को कुछ breathing room दिया जाए
- केवल स्वाभाविक सहयोग का इंतज़ार न करके, जानबूझकर सिस्टम में ऊर्जा डाली जाए
- मनोवैज्ञानिक सुरक्षा और in-group का विस्तार
- लोग अपने समूह के भीतर मनोवैज्ञानिक सुरक्षा महसूस करते हैं, तभी वे प्रयोग करते हैं या नया सीखते हैं
- टीम सदस्यों के "in-group" को विस्तृत करने के लिए समय और संसाधन निवेश किए जाएँ
- bootcamp: लोगों को दूसरी टीमों के साथ काम करने के लिए मजबूर करके सहयोग के अवसर बनाए जाएँ
- hackathon: इसी तरह का असर पैदा करने वाला एक और माध्यम
जानबूझकर तय किए गए टीम मूल्य
- टीम की सोच और सिद्धांत तय करना
- code review, bootcamp, hackathon जैसी गतिविधियों के बड़े उद्देश्य स्पष्ट रूप से तय किए जाएँ
- यह घोषित किया जाए कि elitism ज़हरीला है
- ऐसी संस्कृति बनाई जाए जिसमें हर व्यक्ति "जो काम ज़रूरी है, वह खुद करे"
- पारस्परिक भरोसा और सुधार की अपेक्षा
- जब भी कोई किसी और के काम को छुए, तो उसे बेहतर हालत में छोड़ने की मज़बूत अपेक्षा हो
- ऐसी संस्कृति टीम सदस्यों को खुशी-खुशी सहयोग करने के लिए प्रेरित करती है
समापन विचार
- टेक उद्योग की समस्या: elitism और हठी नेतृत्व
- विनम्रता से रहित हठी नेता टीम सहयोग को कमज़ोर करते हैं और अनावश्यक कठोरता को बढ़ावा देते हैं
- टेक उद्योग अक्सर ऐसे नेताओं को उपयोगी समझने की भूल करता है, जबकि यह एक परजीवी और हानिकारक प्रवृत्ति है
- दूसरों के प्रति सम्मानपूर्ण व्यवहार कोई कट्टरपंथी विचार नहीं होना चाहिए, लेकिन व्यवहार में अक्सर ऐसा नहीं है
- सहयोग बेहतर नतीजे लाता है
- सहयोग परिणाम बेहतर करता है, और हठी नेताओं के बिना जीवन बेहतर होता है
- गुटबंदी और ईगो को खत्म करने के लिए प्रयास ज़रूरी हैं
- सशक्तिकरण का महत्व
- अगर टीम सदस्यों को जिज्ञासा के साथ सहयोग के लिए प्रोत्साहित करना है, तो leaders की अनुमति और समर्थन ज़रूरी है
- उदाहरण: deployment का काम SRE के बजाय developers को सीधे करने देना
- शुरुआत में developers की गलतियों को लेकर चिंता थी, लेकिन अधिकांश developers ने समस्याएँ खुद सुलझाईं और यह सफल रहा
- product engineers ने खुद समस्याएँ सँभालने की इच्छा दिखाई
- सिस्टम में slack देना
- bootcamp या hackathon जैसे कार्यक्रमों के लिए लगातार प्रतिबद्धता चाहिए
- अगर सिस्टम में slack न हो, तो ऐसे कार्यक्रम जल्दी गायब हो जाते हैं
- हम कंप्यूटर को 100% उपयोग पर नहीं चलाते, लेकिन खुद से अक्सर यही उम्मीद रखते हैं
- मूल्यों और rewards का महत्व
- leaders को सहयोग और जिज्ञासा को पुरस्कृत करना चाहिए और उसे टीम संस्कृति का हिस्सा बनाना चाहिए
- CEOs अक्सर सकारात्मक कार्यक्रमों (bootcamp, hackathon) को खत्म करना चाहते हैं, लेकिन नकारात्मक कार्यक्रमों (अनिवार्य code review) को हटाने की कोशिश कम करते हैं
- यह गलत धारणा छोड़नी होगी कि "दर्द" ही परिणाम लाता है
- दर्द परिणाम का सही प्रॉक्सी नहीं है; सहयोग और भरोसा बेहतर प्रदर्शन लाते हैं
7 टिप्पणियां
> टीम के सदस्यों को जिज्ञासा के साथ सहयोग करने के लिए प्रोत्साहित करने हेतु, लीडर की अनुमति और समर्थन आवश्यक है
मेरा मानना है कि टीम के सदस्यों को अपने क्षेत्र तक सीमित न रहकर, दूसरे सदस्यों के क्षेत्र के प्रति भी जिज्ञासा रखने के लिए प्रोत्साहित करना महत्वपूर्ण है!
हक़ीक़त में...!
हर दिन प्रगति के लिए लगातार दबाव बनाने वाले agile startup में यह एक असंभव-सी संरचना लगती है..
सभी प्रैक्टिकल टीम सदस्यों को जॉइनिंग के शुरुआती दौर की रुचि लगातार बनाए रखनी चाहिए, लेकिन उस पहलू के लिए आमतौर पर या तो कोई सपोर्ट नहीं होता, या वह अपर्याप्त होता है.
बिल्कुल सही बात है..
लेकिन हक़ीक़त तो.................. T_T
वाकई बहुत अच्छा लेख लग रहा है!
अच्छा लेख है।
Hacker News राय
यह राय है कि software development में programmer के अहंकार को अलग रखना महत्वपूर्ण है। teamwork के ज़रिए software product को टीम की उपलब्धि के रूप में देखना बेहतर है.
development career से मिले सबक के रूप में सलाह दी गई है कि अनावश्यक process न जोड़े जाएँ, हर भूमिका में product ownership की अपेक्षा की जाए, प्रतिक्रियात्मक फ़ैसलों से बचा जाए, और टीमों के बीच सहयोग को बढ़ावा दिया जाए.
सबसे अच्छी टीमें उन pizza teams और ज़रूरत पड़ने पर सलाह देने वाले specialists से बनती हैं जो पूरे stack की ownership लेते हैं.
यह राय है कि sports metaphor tech क्षेत्र में लोकप्रिय नहीं हैं, लेकिन sports team की dynamics अच्छी business team से मिलती-जुलती है.
संगठन की सफलता इस पर निर्भर करती है कि हर सदस्य समूह की ज़रूरतें पूरी करने के लिए निःस्वार्थ ढंग से काम करे.
जानबूझकर टीम values तय करने के महत्व पर ज़ोर दिया गया है.
growth विभाग में काम करते हुए, शुरुआत में manager सभी commits की समीक्षा और merge करता था, लेकिन बाद में एहसास हुआ कि production में सीधे deploy करने का अधिकार खुद के पास भी था.
domain owner की तुलना में domain expert को अधिक पसंद किया जाता है, और ज़रूरत से ज़्यादा स्पष्ट specialization समस्याएँ पैदा कर सकती है.