- “10x इंजीनियर” का विचार सहज रूप से आकर्षक लगता है, लेकिन वास्तविक उत्पादकता को वस्तुनिष्ठ रूप से मापना बहुत कठिन है, और इसे अपरिवर्तनीय व्यक्तिगत गुण मानना भी गलत दृष्टिकोण है
- सॉफ़्टवेयर की वास्तविक ownership और outcomes का निर्धारण engineering team स्तर के सहयोग और क्षमता से होता है
- सचमुच बेहतरीन संगठन वे हैं जो सिर्फ़ असाधारण लोगों पर निर्भर नहीं रहते, बल्कि ऐसा माहौल बनाते हैं जहाँ सामान्य इंजीनियर लगातार अच्छे परिणाम दे सकें
- सिस्टम को इस तथ्य को ध्यान में रखकर डिज़ाइन किया जाना चाहिए कि सामान्य लोग गलती कर सकते हैं या थक सकते हैं, और ध्यान “10x team” बनाने पर होना चाहिए
- सॉफ़्टवेयर सिस्टम डिज़ाइन और संस्कृति “सामान्य लोगों” की विशेषताओं, विविधता और विकास की संभावना पर आधारित होनी चाहिए
- अंततः उत्पादकता का मुख्य संकेतक business impact है, और “सर्वश्रेष्ठ प्रतिभा” नहीं बल्कि “उपयुक्त व्यक्ति” को भर्ती करना और टीम बनाना महत्वपूर्ण है
“सामान्य इंजीनियर” की सराहना में
- यह लेख “10x इंजीनियर” की अवधारणा की आलोचना करता है और उन संगठनों के महत्व को समझाता है जहाँ सामान्य इंजीनियर उत्कृष्ट टीम परिणाम पैदा करते हैं
“10x इंजीनियर” मिथक और उसकी सीमाएँ
- लगभग हर किसी ने अपने करियर में ऐसे असाधारण इंजीनियर देखे हैं जो मानो जादूगर हों
- इसी से “10x इंजीनियर” की अवधारणा पैदा हुई, लेकिन इसका आधार कमज़ोर है और यह पूर्वाग्रह को भी मज़बूत कर सकती है
- उत्पादकता के लिए एकल मापदंड तय करना लगभग असंभव है
- इस्तेमाल होने वाला tech stack, domain, development stage, market conditions, experience आदि जैसे चर अनंत संयोजनों में मौजूद होते हैं
- कोई व्यक्ति किसी खास क्षेत्र में 10x इंजीनियर हो सकता है, लेकिन अधिकतर क्षेत्रों में सामान्य या औसत से नीचे हो सकता है
- कोई व्यक्ति कभी उत्कृष्ट DBRE रहा हो, फिर भी समय के साथ उस क्षेत्र में सामान्य स्तर पर आ सकता है
- अंततः, कोई भी हर क्षेत्र में हमेशा 10 गुना बेहतर नहीं हो सकता
टीम-केंद्रित सॉफ़्टवेयर ownership
- सॉफ़्टवेयर का ownership और प्रबंधन टीम के पास होना चाहिए, किसी एक व्यक्ति के पास नहीं
- सॉफ़्टवेयर की delivery, maintenance, improvement, scaling, refactoring आदि की पूरी प्रक्रिया टीम स्तर पर होती है
- जिस सिस्टम का ownership एक ही व्यक्ति के पास हो, वह व्यक्ति छुट्टी पर जाए या नौकरी बदल दे तो वह single point of failure (SPOF) बन जाता है और संगठन की कमज़ोरी साबित होता है
- startup में शुरुआती चरण में व्यक्तिगत ownership अपरिहार्य हो सकता है, लेकिन संगठन के बढ़ने पर इसे अनिवार्य रूप से team ownership में बदलना चाहिए
- engineering leader का मुख्य काम high-performance team बनाना होना चाहिए; “10x इंजीनियर” से अधिक महत्वपूर्ण 10x team है
वास्तविक high-performance संगठन की शर्तें
- कई कंपनियाँ FAANG पृष्ठभूमि, प्रतिष्ठित विश्वविद्यालयों और Staff Engineer-केंद्रित टीम बनाना पसंद करती हैं
- लेकिन वास्तव में अच्छा संगठन वह है जहाँ सामान्य इंजीनियर स्थिर रूप से वास्तविक impact पैदा कर सकें
- वह संगठन अधिक प्रतिस्पर्धी होता है जो सिर्फ़ “श्रेष्ठ” लोगों के भरोसे न रहे, बल्कि ऐसा सिस्टम बनाए जिसमें सामान्य developer भी पहल करते हुए बढ़ सकें और product तथा business पर सकारात्मक प्रभाव डाल सकें
- उलटे, ऐसे संगठन ही अधिक world-class engineers तैयार करते हैं
“सामान्यता” के अर्थ को फिर से परिभाषित करना
- सॉफ़्टवेयर उद्योग में “top 10%”, “top .1%” जैसी elite-केंद्रित सोच बहुत प्रचलित है
- लेकिन यह मानना महत्वपूर्ण है कि अधिकांश इंजीनियर विविध अनुभव और अभ्यास के ज़रिए विकसित हुए सामान्य लोग हैं
- कोई भी जन्म से “महान इंजीनियर” नहीं होता
- महान इंजीनियर बनाए जाते हैं — कोई भी सीखने और अनुभव के माध्यम से उत्कृष्ट बन सकता है
सामान्य लोगों के लिए सिस्टम डिज़ाइन
- भर्ती के समय असाधारण ताकत को देखना सही है, लेकिन सिस्टम डिज़ाइन करते समय इस वास्तविकता को ध्यान में रखना चाहिए कि लोग सामान्य रूप से गलती करते हैं, थकते हैं और परिचित चीज़ों पर निर्भर रहते हैं
- सामान्य इंजीनियर cognitive bias, fatigue, emotional fluctuation आदि से प्रभावित होते हैं
- जब सिस्टम कुछ गिने-चुने बहुत स्मार्ट लोगों के लिए नहीं बल्कि सामान्य इंजीनियरों के नज़रिए से डिज़ाइन किए जाते हैं, तब उत्कृष्ट प्रतिभाओं की रचनात्मक क्षमता स्वयं product पर केंद्रित हो सकती है
“10x team” कैसे बनाई जाए
- कोड लिखने और deploy करने के बीच का अंतर जितना हो सके उतना कम करें
- तेज़ deployment cycle cognitive load को कम करती है और तेज़ experiment तथा feedback को संभव बनाती है
- deployment जितना धीमा होगा, उतने अधिक changes एक साथ जमा होंगे, जिससे समस्या का पता लगाना और rollback करना कठिन होगा
- गलतियों से recovery और rollback को आसान बनाएं
- developers को अपना code स्वयं deploy करने और समस्या मिलते ही तेज़ी से recovery करने में सक्षम होना चाहिए
- सही काम को आसान और गलत काम को कठिन बनाएं
- designers और platform engineers के साथ मिलकर guardrails और self-service ढाँचा बनाएं
- observability और instrumentation tools में सक्रिय निवेश करें
- वास्तविक code behavior को दृश्य रूप में दिखाकर हर इंजीनियर के लिए सिस्टम को समझना और debug करना आसान बनाएं
- internal tools और productivity सुधार पर engineering resources निवेश करें
- ऐसे सिस्टम के लिए अलग ownership चाहिए और इन्हें company-wide priority बनना चाहिए
- समावेशी संस्कृति बनाएं
- ऐसा माहौल जहाँ कोई भी सवाल पूछ सके, गलती कर सके और खोजबीन कर सके
- विविध background, skill और अनुभव वाले लोगों की टीम अधिक resilient होती है और बदलाव के प्रति अधिक मज़बूत होती है
- हर स्तर के इंजीनियरों का मिश्रित टीम गठन करें
- junior से senior तक, एक-दूसरे से सीखते और सिखाते हुए साथ बढ़ने वाली संरचना
- ऐसे सिस्टम नए लोगों के onboarding और टीमों के बीच mobility में भी दोबारा उपयोग किए जा सकते हैं
उत्पादकता का असली मापदंड: "business impact"
- अंततः सॉफ़्टवेयर engineering में उत्पादकता का मापदंड business impact है
- सार केवल बहुत सारा code लिखना नहीं, बल्कि समस्याएँ सुलझाना और value create करना है
- वास्तव में उद्योग को आगे बढ़ाने वाले केवल Staff+ engineers नहीं, बल्कि senior और mid-level engineers हैं
- यही लोग संगठन की नींव बनाते हैं और लगातार business को आगे बढ़ाते हैं
- अगर केवल Staff+ level ही impact पैदा कर सकता है, तो यह संगठन में समस्या का संकेत है
world-class engineers को विकसित करने वाला संगठन
- सच्चा अच्छा संगठन वह है जहाँ उत्कृष्ट इंजीनियर न होने पर भी हर कोई impact पैदा कर सके
- श्रेष्ठ संगठन वे हैं जहाँ अलग से दुनिया के सर्वश्रेष्ठ लोगों को चुने बिना भी स्वाभाविक रूप से सबसे अधिक world-class engineers पैदा होते हैं
- जहाँ इंजीनियर problem solving, growth, impact पर ध्यान केंद्रित कर सकें, वहीं प्रतिभा आकर्षित होती है, और “खुशी से काम करने और बढ़ने का अनुभव” स्वयं एक सकारात्मक चक्र बनाता है
- नेता की भूमिका उत्कृष्ट प्रतिभाओं की व्यक्तिगत क्षमता पर निर्भर रहने की नहीं, बल्कि उसे पूरे संगठन की वृद्धि और customer value से जोड़ने की होनी चाहिए
“सर्वश्रेष्ठ प्रतिभा” से अधिक “उपयुक्त व्यक्ति” की भर्ती
- उद्योग अक्सर सिर्फ़ “सर्वश्रेष्ठ” को खोजता है, लेकिन असली महत्व सिस्टम और वातावरण का है
- “सर्वश्रेष्ठ प्रतिभा” से ज़्यादा, टीम और संगठन के लिए उपयुक्त व्यक्ति को ढूँढना बड़ी प्रतिस्पर्धात्मक बढ़त है
- बिना किसी कमज़ोरी वाले व्यक्ति से अधिक प्रभावी यह है कि टीम ऐसे उपयुक्त लोगों से बनाई जाए जिनकी विशिष्ट ताकतें संगठन की विविधता और सामंजस्य को बेहतर करें
- समावेशी और विविध टीम वास्तव में परिणाम, विकास और दीर्घकालिक सफलता को आगे बढ़ाती है
- जहाँ हर कोई काम का आनंद ले, बढ़े और सार्थक परिणाम दे, वही सच में विश्व-स्तरीय संगठन है; और असफलता या गलती से भी सीखने वाली संस्कृति में इंजीनियर और संगठन दोनों विकसित होते हैं
- ऐसे संगठन ही अगली पीढ़ी के इंजीनियरों को आकर्षित करते हैं और पहले से उत्कृष्ट प्रतिभाओं को भी टिके रहने लायक वातावरण देते हैं
1 टिप्पणियां
Hacker News राय
मैं इस बात से सहमत हूँ कि software ownership और delivery की सबसे छोटी इकाई engineering team होती है, लेकिन यह दृष्टिकोण थोड़ा निराशाजनक भी लगता है। ऐसी संरचना उस संस्कृति से जुड़ी है जहाँ engineer, manager या product विभाग की तुलना में दूसरे दर्जे के नागरिक बन जाते हैं। हमारी ज़िम्मेदारी सिर्फ delivery तक सीमित रहती है, लेकिन टीम की बहुत छोटी सीमा से आगे किसी सचमुच मायने रखने वाले फैसले को हम स्वतंत्र रूप से नहीं ले सकते। सबसे बेहतरीन टीमों में discretion की अवधि कई महीनों, यहाँ तक कि कई सालों तक हो सकती है, लेकिन ज़्यादातर टीमों में यह घटकर कुछ दिन या कुछ हफ्तों तक सिमट जाती है। जबकि व्यवहार में ऐसा ढाँचा पूरी तरह संभव है जहाँ engineers के पास वास्तविक ownership हो और सिस्टम टूटे बिना या ख़तरनाक बने बिना लंबे समय तक चल सके। इसका राज है पर्याप्त slack सुनिश्चित करना, अच्छे काम को प्रोत्साहित करना, और टीम के किसी भी सदस्य को ज़रूरत के अनुसार काम बदलने की पर्याप्त आज़ादी देना। जब हर किसी के पास ownership हो और वे long-term फैसले ले सकें, साथ ही ad hoc सहयोग और tacit knowledge sharing भी होता रहे, तो कोई भी अचानक आकर मदद कर सकता है या पूरा काम संभाल भी सकता है। मेरे अनुभव में ऐसी टीमों में सामान्य टीमों की तुलना में rewrite ज़्यादा होते हैं, लेकिन कुल मिलाकर वे कहीं अधिक productive होती हैं। सिस्टम को छोटे हिस्सों में धीरे-धीरे rewrite करना design evolution और संगठन के भीतर knowledge तथा capability accumulation, दोनों के लिए बहुत प्रभावी है। ऊपर से यह भले waste जैसा दिखे, लेकिन संगठन को लचीला और resilient बनाने के लिए यह ज़रूरी slack है। बल्कि मुझे increasingly यक़ीन होता जा रहा है कि top-down संगठन जिन processes को तथाकथित waste मानकर घटाना चाहते हैं, वे दरअसल इसी महत्वपूर्ण ‘slack’ को खत्म कर रहे होते हैं
engineering के बाहर के लोग अक्सर engineers द्वारा लिए गए long-term फैसलों का सीधे आकलन नहीं कर पाते, और उन्हें यह भी नहीं पता होता कि उसके लिए किस तरह reward देना चाहिए। यहाँ तक कि engineering team के बाहर जाने पर भी यही बात लागू होती है। internal value वाले long-term काम का वास्तव में मूल्य है या नहीं, इसे वे खुद evaluate नहीं कर सकते। अगर आपको अपने long-term decision-making और slack time के इस्तेमाल पर भरोसा है, तो delivery के आधार पर reward मिलना भी ठीक है। क्योंकि किसी न किसी दिन वही long-term काम बेहतर नतीजों के रूप में लौटेगा
मेरा मानना है कि software rewrite development process में एक महत्वपूर्ण भूमिका निभाता है। सच्चा ‘agile’ वही है जिसमें पहली architecture पर ज़रूरत से ज़्यादा अटकने के बजाय जल्दी prototype बनाया जाए और बदलती requirements के प्रति flexible रहा जाए। coding, writing की तरह है; पहला draft भले कच्चा हो, लेकिन पहले उसे लिख लेना और दूसरे version में उसे बेहतर बनाना कहीं अधिक efficient होता है। पहले draft का लक्ष्य अच्छा बनाना नहीं, बल्कि जल्दी कुछ बनाकर problem space को explore करना और edge cases पहचानना होता है। लेकिन यह काम करने का तरीका management को आसानी से समझ नहीं आता। जैसे ही वे working prototype देखते हैं, वे कहते हैं ‘इसे अभी launch कर दो’, और rewrite के लिए समय नहीं देते। अगर कोई समाधान है, तो वह यह होगा कि संगठन की hierarchy को flatter बनाया जाए और engineers को code ownership वास्तव में वापस दी जाए। engineer और product owner मिलकर लोकतांत्रिक तरीके से decision लें, ऐसी संरचना बेहतर होगी
मैं भी कभी ‘individual ownership’ को बहुत महत्व देता था, और आज भी मानता हूँ कि engineers ownership ले सकते हैं, लेकिन यह भी स्वीकार करता हूँ कि वास्तव में बहुत से engineers यह चाहते ही नहीं। ज़्यादातर engineers team-level ownership तक तो ठीक रहते हैं, लेकिन individual engineer स्तर की ownership में उनकी खास दिलचस्पी नहीं होती। उनके लिए यह बस नौकरी है। अगर इसे पूरी तरह व्यक्तियों पर छोड़ दिया जाए, तो टीम के भीतर अविश्वास पैदा हो सकता है, या जिनमें leadership tendency कम है वे अलग-थलग पड़ सकते हैं, और अंततः ऐसी स्थिति बन सकती है जहाँ किसी के पास भी वास्तविक discretion न बचे। team unit के रूप में ownership और discretion देना कहीं सरल और अधिक प्रभावी है। यह team lead या manager की उपस्थिति से संभव होने वाली dynamic भी है। individual software ownership रखने पर headcount changes, stability, career जैसी वजहों से failure का जोखिम बहुत बढ़ जाता है। संगठन कितना भी स्वस्थ क्यों न हो, छोटे-बड़े मुद्दे हमेशा होते हैं, और ऐसी संरचना में failure तक पहुँचने का रास्ता सबसे छोटा हो जाता है। gearbox से समझना आसान है। अगर सिर्फ एक gear हो और वह टूट जाए, तो गाड़ी रुक जाती है; लेकिन कई gear हों, तो असुविधा के बावजूद, कोई एक टूटने पर भी यात्रा जारी रह सकती है
मुझे सच में लगता है कि वास्तविक individual ownership संभव है। बल्कि शायद यही इकलौता तरीका है जो सच में ‘productive’ हो सकता है। लेकिन यह मूल मुद्दा नहीं है। व्यक्ति replace नहीं किए जा सकते, लेकिन team member कुछ हद तक संरचना पर निर्भर होकर replaceable हो सकते हैं। संगठन जितना बड़ा होता है, वह team-level predictability उतनी ज़्यादा चाहता है, और इसके लिए member replaceability यानी redundancy चाहिए। engineering में भी reliability यानी resilience के लिए redundancy रखी जाती है, और efficiency अक्सर redundancy घटाने के साथ एक trade-off जैसी होती है
हम ऐसे ढाँचे में काम करते रहे हैं जहाँ हमें सिर्फ 'delivery' के लिए ज़िम्मेदार माना जाता है, और ownership का मतलब अंततः बस बोझ बढ़ना था, बिना किसी वास्तविक reward के। काम सिर्फ पेज पर features जोड़ने तक सीमित रह जाता है। अगर अतिरिक्त responsibility दी जाती है, तो उसके लिए अतिरिक्त compensation भी होना चाहिए। manager या executive का reward उनके responsibility वाले लोगों की संख्या के साथ बढ़ता है, तो developers के साथ भी ऐसा ही होना चाहिए
मुझे पूरा यक़ीन है कि सबसे अच्छी टीम वही होती है जिसकी संस्कृति साधारण engineers से भी असाधारण परिणाम निकलवा सके। आमतौर पर जिस ‘engineering quality’ या talent hiring की बात होती है, उससे कहीं ज़्यादा महत्वपूर्ण culture, trust, systems और process हैं। लोग कहते हैं, “कोई भी ऐसा संगठन बना सकता है जहाँ top engineers हों,” लेकिन वास्तव में ऐसी टीम बनाने वाले संगठन बहुत कम हैं। लगभग सभी trading firms या special/research organizations हैं। आख़िर ज़्यादातर ऐसा क्यों नहीं कर पाते, यह सवाल बना रहता है। अंततः “productivity” का मतलब ही अस्पष्ट है। कुछ evaluation systems तो केवल इस बात को मापते हैं कि कोई व्यक्ति संगठन के भीतर की dysfunction को कितना सहकर पार कर सकता है, लेकिन मैं इसे असली ‘top engineer’ का अर्थ नहीं मानता
सचमुच बेहतरीन engineers की supply सीमित है, इसलिए बड़ी कंपनियाँ ज़्यादा रोचक काम या ऊँची salary देकर उसी talent को खींच ले जाती हैं
जैसा दूसरों ने कहा, पैसे की समस्या बड़ी है, लेकिन ‘समय’ भी उतना ही बड़ा कारक है। कंपनियों के पास परफ़ेक्ट “unicorn” talent आने का इंतज़ार करने की फुर्सत नहीं होती, इसलिए वे अक्सर तुरंत उपलब्ध लोगों से hiring भरती हैं। कुछ कंपनियों में, खासकर quant finance जैसी जगहों पर, एक ऐसा super engineer जो systems programming, mathematics, और financial markets—तीनों को समझता हो, तीन विशेषज्ञों की टीम से भी अधिक value दे सकता है। लेकिन ऐसे व्यक्ति को ढूँढने में बहुत समय लगता है। केवल web development को ही देखें, तो network protocols, system admin, distributed systems, database, और frontend तक हर चीज़ को गहराई से समझने वाला सच्चा full-stack developer बेहद दुर्लभ है। केवल वे संगठन जिनके पास पर्याप्त समय और पैसा है, ऐसे लोगों को इकट्ठा कर सर्वश्रेष्ठ product बना सकते हैं। बेशक, क्या product को वास्तव में उस स्तर की quality चाहिए भी या नहीं, यह अलग सवाल है
मूल रूप से पूरी दुनिया में “top engineers” की supply बेहद सीमित है। अगर आप top 10% salary दे सकते हैं और उसी स्तर का talent आकर्षित व बनाए रख सकते हैं, तो यह अपने आप में सफलता है। सच तो यह है कि ‘कोई भी’ ऐसा नहीं कर सकता; इसके लिए ऐसा leadership चाहिए जो learning और growth पर केंद्रित sociotechnical systems डिज़ाइन कर सके। यह अपने आप में भी शानदार उपलब्धि है
सबसे बड़ी समस्या यह है कि ज़्यादातर first-line और second-line management उतने अच्छे नहीं होते। उनके पास productive environment बनाने और बनाए रखने की क्षमता कम होती है। मूल समाधान अंततः ‘पैसा’ ही है। अगर पैसा बहुत हो, तो लोग अधिकांश कठिन परिस्थितियाँ सह लेते हैं
बजट की बात अलग, लेकिन बहुत brilliant engineer team play के लिए हमेशा अच्छे हों, यह ज़रूरी नहीं। तेज़ दिमाग कभी-कभी उन आवश्यक compromises या उबाऊ लेकिन ज़रूरी कामों में बाधा बन सकता है
मैं इस दावे से काफ़ी असहमत हूँ कि “business impact ही productivity का एकमात्र माप है।” ऐसा नज़रिया ध्यान को measurable changes और short-term results की तरफ मोड़ देता है, और skilled engineers की असली value छूट जाती है। असली माहिर वे होते हैं जो किसी project या company को लगभग बर्बाद कर देने वाले risk landmine को पहले ही रोक देते हैं। लेकिन ऐसा ‘गायब हो चुका risk’ मापना मुश्किल है, और उसे सामान्य ढंग से समझाना तो लगभग असंभव है
“impact” ज़रूरी नहीं कि short-term दृष्टिकोण ही हो। संगठन पर सबसे अधिक impact डालने वाले लोग long-term दृष्टि से काम करते हैं
मैं ‘productivity’ और ‘impact’ को जानबूझकर कुछ हद तक अस्पष्ट शब्दों में कहता हूँ। जैसे, “कुल मिलाकर देखें तो X ने बहुत अच्छा काम किया।” ऐसी बातें न तो आसानी से quantifiable हैं, न साफ़ नियमों में बाँधी जा सकती हैं, लेकिन जटिल और creative organizations में मानव insight और judgment स्वाभाविक रूप से अधिक महत्वपूर्ण होते हैं। management को हर हाल में numbers में बदलने की कोशिश करना मूल रूप से short-sighted है
मैं यह नहीं कह रहा कि project management या risk avoidance जैसी चीज़ों से engineer की value मापना सही है, लेकिन हर चीज़ को केवल ‘business impact’ में समेट देना भी असहज करता है। दुनिया में बहुत-से अर्थपूर्ण काम हैं जिनका पैसे से कोई लेना-देना नहीं। जिन engineers का मैं सबसे अधिक सम्मान करता हूँ, वे post-2001 Silicon Valley के दंतकथात्मक लोग नहीं, बल्कि John von Neumann, Robert Oppenheimer, Nikola Tesla, Leonardo da Vinci, रोमन जलसेतु और मिस्र के पिरामिड बनाने वाले अज्ञात लोग, और Babylonian-Mesoamerican astronomers जैसे लोग हैं। क्या उन्होंने business impact छोड़ा? मान लें Tesla ने कभी Westinghouse को लाभ पहुँचाया भी हो, तब भी उससे उनकी उपलब्धियों की व्याख्या नहीं होती। सच तो यह है कि business के लिहाज़ से वे साधारण ही थे। यही बात आधुनिक computing industry के दिग्गजों पर भी लागू होती है। Nvidia या Geoff Hinton की बड़ी सफलता में यह ‘luck’ भी शामिल था कि internet के ad-driven होने के साथ data विस्फोट हुआ। ऐसे भी कई मामले हैं जहाँ सच्चे प्रतिभाशाली लोग उपेक्षित रह गए। Doug Lenat जैसे AI क्षेत्र के बड़े नाम भी इतिहास की धारा में पूरी तरह पहचाने नहीं जा सके। सफलता का होना या न होना अक्सर व्यक्ति के प्रयास से स्वतंत्र भी होता है
आप या तो efficient system बना सकते हैं, या ऐसा system जो disaster की संभावना को न्यूनतम करे। वास्तव में कौन-सी आपदा टल गई, यह साबित करना कठिन है, और नकारात्मक प्रभाव तो वैसे भी ‘घटित न हुई घटना’ होता है, इसलिए उसे परिणाम की तरह दिखाना मुश्किल है
कंपनी को ‘unknown unknowns’ के risk को किसी न किसी तरह बेहतर quantify करने की कोशिश करनी चाहिए
सौभाग्य से अब तक मैंने कई शानदार टीमों में काम किया है, और फिलहाल ऐसी ही एक टीम का नेतृत्व भी कर रहा हूँ। लेख के विपरीत, अक्सर ऐसी टीमों को manage करना संगठन के लिए और अधिक कठिन होता है। बड़े संगठन standardization पर ध्यान देते हैं, और इसी वजह से कई बार बेहतरीन engineers अपनी क्षमता दिखा नहीं पाते और demotivated हो जाते हैं। मैं इस निराशावादी सोच से सहमत नहीं कि हर किसी को great engineer नहीं बनाया जा सकता। वास्तव में, अगर लगातार निवेश किया जाए, तो लोगों को शानदार engineer बनाया जा सकता है, और लंबे समय में बड़े talent pool से मिलने वाला लाभ उस निवेश की लागत से कहीं अधिक हो सकता है
सिर्फ इसलिए कि किसी चीज़ को प्रभावी ढंग से measure नहीं किया जा सकता, इसका मतलब यह नहीं कि वह चीज़ अस्तित्व में ही नहीं है। individual productivity, यानी किसी व्यक्ति के काम का प्रदर्शन, निश्चित रूप से मौजूद है। शायद group-level productivity को मापना बस आसान होता है। “business impact” तो कई बार इससे भी अधिक arbitrary होता है, और अगर उसी को मापदंड बना लिया जाए, तो वास्तव में productive लोगों को बनाए रखना मुश्किल हो जाता है। specialized knowledge का आकलन, जब तक सामने वाले के पास समान अनुभव न हो, बहुत कठिन है। सलाह तो दी जा सकती है, लेकिन सामने वाले में उसे स्वीकार करने की बौद्धिक openness है या नहीं, यह अलग बात है। मैं कैसे जानूँ कि मैं genius हूँ या केवल अत्यधिक आत्मविश्वासी व्यक्ति
समस्या यह नहीं कि productivity को ‘measure’ नहीं किया जा सकता, बल्कि यह कि उसे abstract स्तर पर ‘define’ भी नहीं किया जा सकता। केवल यह मापना कि किसी ने “replacement” से कितना अधिक योगदान दिया, यह नहीं बताता कि वह परिणाम ठीक-ठीक कैसे आया। वास्तव में व्यक्ति का प्रभाव context और पूरे संगठन से निर्धारित होता है। अगर आप इससे भी अधिक direct definition देने की कोशिश करें, तो हर संगठन और हर स्थिति में जवाब अलग निकलेगा। इस पर सोचना निश्चित ही सार्थक है, लेकिन ‘Top 1% engineer’ जैसा मानदंड वास्तव में कितना अर्थपूर्ण है, यह भी अपने आप में सवाल है
सच्चा genius शिष्टाचार बनाए रखते हुए अपने परिणामों को आसानी से समझा सकता है। इसलिए मुझे लगता है कि अंतर को पहचानना पूरी तरह संभव है
यह पंक्ति मुझे बहुत पसंद आई: “सबसे अच्छा संगठन वह है जो सामान्य engineers को महान काम करने में सक्षम बनाता है।” हर team member का superstar होना ज़रूरी नहीं। जो बात सच में महत्वपूर्ण है, वह यह है कि औसत developer को भी पर्याप्त support मिले ताकि वह अच्छा, भरोसेमंद काम कर सके
“सही काम को आसान और ग़लत काम को कठिन बनाओ” — यह सिद्धांत मेरे द्वारा देखी गई हर platform team के मुख्य slogan जैसा लगता है। लक्ष्य यह है कि engineers जिन समस्याओं का सामना करें, उनके लिए ‘सही जवाब’ अपने आप स्पष्ट लगे और उसे implement करना आसान हो। अगर system reliability और manageability के साथ इस तरह डिज़ाइन किया जाए कि स्वाभाविक रूप से वही development muscle memory बन जाए, तो पूरी organization को फायदा होता है। यह सिद्धांत आगे भी हमेशा सच रहेगा
जब भी golang, python, COBOL, lisp, perl, React, brainfuck जैसी कई languages/frameworks का ज़िक्र होता है, मुझे लंबे समय से यह महसूस हुआ है कि लोग React को पूरे frontend ecosystem के बराबर मान लेने की प्रवृत्ति रखते हैं। जबकि वास्तव में React के बाहर भी frontend की एक बड़ी दुनिया है, फिर भी लोग मानो सोचते हैं कि React ही सब कुछ है
हमारी कंपनी में हम हमेशा अच्छे attitude वाले average engineer को hire करना पसंद करते हैं। जिन लोगों के credentials अच्छे हों लेकिन attitude ख़राब हो, वे impression management में माहिर होते हैं, इसलिए ऊपर के लोगों का भरोसा जल्दी जीत लेते हैं, और फिर लगभग असीमित शक्ति हासिल कर लेते हैं। जब ऐसे लोग जम जाते हैं, तो आसपास के लोगों के लिए, चाहे वे अंदर से कितने भी आहत हों, समस्या उठाना कठिन हो जाता है। ऊपर के लोग भी अपने perception से मेल न खाने वाले data को आसानी से नज़रअंदाज़ कर देते हैं। objective data की तुलना में perception पर भरोसा करना कहीं आसान है
मैं इस बात से पूरी तरह सहमत हूँ कि “कोई भी ऐसा संगठन बना सकता है जहाँ top engineers काम करें, और individual ability पर ज़रूरत से ज़्यादा ज़ोर देना leadership की असली भूमिका को धुंधला कर देता है। कम अनुभवी engineers को भी अपनी क्षमता लगाकर परिणाम देने योग्य बनाने वाला system एक बहुत बड़ा competitive advantage है।” मैं 10x engineer नहीं हूँ, लेकिन हाल के अनुभव में, जब टीम में experience और skill कम वाले लोग ज़्यादा थे, तो सारे complex tickets मुझे ही लेने पड़ते थे। अगर यह pattern बार-बार दोहराया जाए, तो अंततः ज़्यादातर काम एक ही व्यक्ति पर आ जाता है, और वह भूमिका थकाऊ भी लगती है और unfair भी। सच कहूँ तो, मुझे लगता है कि अच्छे SRE में थोड़ी-सी आलस्य की प्रवृत्ति भी होनी चाहिए, इसलिए मैं चाहता था कि team members काम बाँटें। इसी वजह से मैंने कुछ हफ्तों तक बहुत मेहनत करके सबसे complex हिस्सों में कई abstractions लागू किए (मैं मुख्यतः IAC पर काम करता हूँ; software में भी यही pattern दिखता है)। इसके बाद skill या experience में अपेक्षाकृत कमज़ोर engineers भी मेरी भूमिका का हिस्सा बाँटने लगे, और मेरा समय अधिक रोचक समस्याओं पर लगने लगा। बिना किसी निर्देश के ऐसा प्रयास मैंने पहली बार किया। इसके उलट, अगर ऐसी संरचना न हो और कोई अकेले hero की तरह काम करे, तो पूरी टीम उसके पीछे-पीछे चलती रहती है और उसकी गलतियों को संभालती रहती है, और अंततः टीम सचमुच बहुत inefficient बन जाती है