- यह लेख टेक कंपनी में इंजीनियर किस तरह संगठनात्मक राजनीति में प्रभावी ढंग से भाग ले सकते हैं, इसके लिए व्यावहारिक रणनीतियाँ पेश करता है और उन कई इंजीनियरों की राजनीतिक बेबसी को दूर करने के तरीकों पर चर्चा करता है
- इंजीनियर राजनीतिक खेल के खिलाड़ी नहीं बल्कि एक औज़ार होते हैं, लेकिन उच्च-प्रोफ़ाइल प्रोजेक्ट्स की सफलता में सक्रिय समर्थन देकर या संगठन की बदलती प्राथमिकताओं के अनुसार तकनीकी आइडिया प्रस्तावित करके वे राजनीतिक प्रभाव डाल सकते हैं
- संगठन की दिलचस्पियाँ लहरों की तरह बदलती रहती हैं, इसलिए stability, developer experience, performance improvement जैसी अलग-अलग दिशाओं के तकनीकी प्रोग्राम पहले से तैयार रखना और सही समय पर उन्हें प्रस्तावित करना मुख्य रणनीति है
- जब राजनीतिक आवश्यकता और अच्छे आइडिया की कमी टकराती है, तब सबसे खराब तकनीकी फैसले लिए जाते हैं; ऐसे में senior engineers की जिम्मेदारी है कि वे सही समय पर सही आइडिया रखें
- निराशावादी नज़रिए से यह सत्ता संघर्ष का एक औज़ार बनना है, लेकिन आशावादी नज़रिए से यह management की priorities का सम्मान करते हुए अपने तकनीकी लक्ष्यों को हासिल करने का तरीका है
इंजीनियरों की राजनीतिक बेबसी को लेकर आम धारणा
- बहुत से software engineers कंपनी की राजनीति को लेकर भाग्यवादपूर्ण रवैया रखते हैं और मानते हैं कि इसमें भाग लेना बेकार है
- तकनीकी फैसले अक्सर पूरी तरह स्वार्थी कारणों से लिए जाते हैं, इसलिए सदाशयी इंजीनियर उनका असर नहीं बदल सकते
- प्रभावशाली stakeholders इतने अक्षम और dysfunctional होते हैं कि उनकी माँगों को समझना और समाधान देना लगभग असंभव हो जाता है
- राजनीतिक खेल ऐसी गोपनीय जानकारी पर निर्भर करता है जो इंजीनियरों के पास नहीं होती, इसलिए इसमें शामिल होने की कोशिश केवल हाथ-पाँव मारने जैसी बन जाती है
- managers और executives अपना अधिकांश समय राजनीति में लगाते हैं, जबकि इंजीनियर engineering में लगे रहते हैं; इसलिए इंजीनियर शुरुआत से ही गंभीर राजनीतिक नुकसान में होते हैं
- यह सच है कि software engineers असली राजनीतिक खिलाड़ियों के बराबर स्तर पर यह खेल नहीं खेल सकते
- अगर इंजीनियर Game of Thrones जैसी साज़िशें रचने लगें, तो यह भयानक गलती होगी; ऐसे दाँव तुरंत पकड़ लिए जाते हैं और उल्टा उनके खिलाफ इस्तेमाल होते हैं
- साज़िशें चलाने के लिए अभ्यास और शक्ति चाहिए, और software engineers के पास आम तौर पर दोनों नहीं होते
राजनीति में भागीदारी के व्यावहारिक तरीके
- बड़ी कंपनियों में software engineers राजनीतिक खेल के खिलाड़ी नहीं बल्कि औज़ार होते हैं, यह एक साधारण सच्चाई है; फिर भी बिना साज़िश के राजनीति में भाग लेने के कई तरीके मौजूद हैं
- सबसे आसान तरीका है उच्च-प्रोफ़ाइल प्रोजेक्ट की सफलता के लिए सक्रिय रूप से काम करना
- यह लगभग उसी तरह है जैसा आपको सामान्य काम के हिस्से के रूप में करना चाहिए
- अगर कंपनी किसी नए प्रोजेक्ट में बहुत निवेश कर रही है — आजकल संभवतः कोई AI प्रोजेक्ट — तो अपनी engineering क्षमता से उसे सफल बनाना उस VP या executive के लिए राजनीतिक रूप से फायदेमंद कदम है जो उसे चला रहा है
- इसके बदले आपको bonus, promotion में मदद, या भविष्य के high-profile projects में भूमिकाएँ जैसी वे चीज़ें मिल सकती हैं जो कोई executive टेक कंपनी में दे सकता है
तकनीकी आइडिया को राजनीतिक अभियान में इस्तेमाल करना
- एक थोड़ा कठिन लेकिन अधिक नियंत्रण देने वाला तरीका यह है कि अपने पसंदीदा आइडिया को मौजूदा राजनीतिक अभियान के काम का बनाया जाए
- मान लीजिए आप किसी मौजूदा feature को अलग service में विभाजित करना चाहते हैं; तब दो तरीके होते हैं
- मुश्किल तरीका: अपनी राजनीतिक पूँजी खर्च करके समर्थन जुटाइए, managers को इसकी अहमियत समझाइए, और धीरे-धीरे संशयवादियों को मनाकर प्रोजेक्ट को मंज़ूरी दिलाइए
- आसान तरीका: किसी executive को अपनी (काफी बड़ी) राजनीतिक पूँजी इस प्रोजेक्ट पर खर्च करने दीजिए
- तब तक इंतज़ार कीजिए जब तक प्रोजेक्ट से मेल खाने वाले किसी लक्ष्य पर कंपनी-व्यापी निर्देश न आ जाएँ, जैसे किसी बड़े incident के बाद stability पर ज़ोर
- फिर अपने manager से कहिए कि आपका प्रोजेक्ट इस लक्ष्य के लिए उपयुक्त हो सकता है
- अगर आपका आकलन सही हुआ, तो संगठन प्रोजेक्ट का समर्थन करेगा, और राजनीतिक पूँजी खर्च होने के बजाय उल्टा बढ़ेगी
संगठन की दिलचस्पियों की लहर पर सवारी
- संगठन की दिलचस्पी लहरों की तरह आती है
- जब stability का दौर आता है, तब VPs कुछ करने के लिए बेताब होते हैं; वे अपने बॉस को दिखाने लायक कोई भरोसेमंद stability project ढूँढ़ना चाहते हैं, लेकिन उसे खुद करने की क्षमता नहीं होती
- आम तौर पर वे engineering team जो भी प्रस्तावित करे, उसे फंड करने के लिए तैयार रहते हैं
- दूसरी तरफ, जब संगठन का ध्यान कहीं और हो — जैसे किसी बड़े नए product launch पर — तब वे नहीं चाहते कि इंजीनियर ग्राहक को न दिखने वाले internal stability-focused refactoring पर समय लगाएँ
- टेक कंपनी में तकनीकी काम पूरा करने के लिए सही लहर का इंतज़ार करना पड़ता है
- अलग-अलग दिशाओं के तकनीकी प्रोग्राम पहले से तैयार रखना एक अच्छा विचार है
- मज़बूत इंजीनियर सामान्य काम के दौरान अपने-आप ऐसी चीज़ें पहचान लेते हैं
- उदाहरण के तौर पर योजनाएँ:
- billing code को cached API calls की जगह webhooks से update होने वाले stored data पर migrate करना
- पुराने hand-rolled build pipeline को हटाकर उसकी जगह Vite लाना
- भारी traffic वाले अव्यवस्थित Python service को Golang में फिर से लिखना
- public docs को serve करने वाले धीमे CMS frontend को तेज static site से बदलना
सही समय पर प्रस्ताव रखने का महत्व
- जब executives billing को लेकर चिंतित हों, तब billing refactor को stability improvement के रूप में पेश किया जा सकता है
- जब developer experience को लेकर चिंता हो, तब build pipeline बदलने का प्रस्ताव रखा जा सकता है
- जब ग्राहक performance की शिकायत करें, तब Golang rewrite को एक अच्छे विकल्प के रूप में रखा जा सकता है
- जब CEO public docs की स्थिति देखकर घबरा जाए, तब static site के रूप में rebuild करने की दलील दी जा सकती है
- मुख्य बात यह है कि उस महीने का ट्रेंड चाहे जो भी हो, आपके पास तुरंत लागू किए जा सकने वाले, विस्तार से सोचे गए और प्रभावी काम के प्रोग्राम तैयार होने चाहिए
सबसे खराब तकनीकी फैसले कब बनते हैं
- इस तरीके का पालन न करने पर भी कुछ प्रोग्राम फंडिंग पा जाएँगे, लेकिन अगर आप ऐसा नहीं करते तो यह आपके नियंत्रण में नहीं रहेगा कि कौन-सा प्रोग्राम चुना जाएगा
- कंपनी में सबसे खराब तकनीकी फैसले वहीं होते हैं जहाँ कुछ करने की राजनीतिक ज़रूरत और अच्छे आइडिया की अनुपस्थिति टकराती है
- जब अच्छे आइडिया नहीं होते, तब बुरे आइडिया का सहारा लिया जाता है, लेकिन यह नतीजा किसी को पसंद नहीं आता
- executive के लिए बुरा: उसे निराशाजनक तकनीकी परिणाम को सफलता की तरह बेचना पड़ता है
- इंजीनियर के लिए बुरा: उसे अपना समय और मेहनत गलत आइडिया बनाने में लगानी पड़ती है
- अगर आप बहुत senior engineer हैं, तो VPs चुपचाप इसके लिए आपको दोष देंगे — और वे गलत भी नहीं होंगे
- सही समय पर सही आइडिया तैयार रखना आपकी जिम्मेदारी है
दो नज़रिए
- निराशावादी नज़रिया: इसे इस सलाह की तरह पढ़ा जा सकता है कि कंपनी चलाने वाले समाज-विरोधी लोगों के अंतहीन अंदरूनी सत्ता-संघर्ष में इस्तेमाल होने वाला एक सुविधाजनक औज़ार बन जाइए
- आशावादी नज़रिया: इसे इस सलाह की तरह पढ़ा जा सकता है कि executives को कंपनी की समग्र priorities तय करने दीजिए — क्योंकि वही उनका काम है — और अपनी तकनीकी योजनाओं को उसके अनुरूप रखिए
- किसी भी नज़रिए से देखें, सही समय पर सही योजना आगे बढ़ाने से आप अधिक तकनीकी लक्ष्य हासिल कर सकते हैं
Hacker News की प्रतिक्रिया और संबंधित उद्धरण
- इस लेख को Hacker News पर काफ़ी ध्यान मिला और राजनीति पर लिखे दूसरे लेखों की तुलना में इसे कहीं अधिक सकारात्मक प्रतिक्रिया मिली
- एक टिप्पणी ने Milton Friedman के उद्धरण का ज़िक्र करते हुए इस लेख के विचार को व्यापक राजनीतिक नीति पर लागू किया
- "संकट — चाहे वास्तविक हो या महसूस किया गया — ही असली बदलाव लाता है। जब वह संकट आता है, तब उठाए जाने वाले कदम आस-पास उपलब्ध आइडिया पर निर्भर करते हैं। यही हमारा बुनियादी काम है: मौजूदा नीतियों के विकल्प विकसित करना, और उन्हें तब तक जीवित और उपलब्ध रखना जब तक राजनीतिक रूप से असंभव चीज़ राजनीतिक रूप से अपरिहार्य न बन जाए"
- कुछ टिप्पणियों ने इस दृष्टिकोण को जरूरत से ज़्यादा खेल-जैसा और स्वार्थी कहकर आलोचना की, लेकिन लेखक के अनुसार यह आपके लक्ष्य पर निर्भर करता है
- एक टिप्पणी ने इस लेख के सार को अच्छी तरह समेटा: "निर्देशों का इंतज़ार करने, खाली समय में बुरे आइडिया पर निंदक बने रहने, और जो आप चाहते हैं वह न करने के बजाय, लेखक अच्छे और महत्वपूर्ण आइडिया का backlog बनाए रखता है ताकि जब कोई महत्वपूर्ण व्यक्ति कहे कि कुछ अब priority है, तब उसे सामने रखा जा सके। वह timing पर समझौता करके भी अपना मनचाहा काम पूरा कर लेता है"
1 टिप्पणियां
Hacker News की राय
इस पोस्ट का सार यह है
पहला पॉइंट सुनने में obvious लग सकता है, लेकिन करियर की शुरुआत में बहुत से लोगों को मैंने यही बात बार-बार coach की है बहुत से लोग जो मुश्किल में थे या PIP की ओर जा रहे थे, उनके लिए सिर्फ नीचे वाला loop ठीक से चलाना ही turning point साबित हुआ
मैं दूसरे पॉइंट को अपनी खुद की agenda की तैयारी के रूप में देखता हूँ। उदाहरण के लिए, अगर मैं codebase को और minimal बनाना चाहता हूँ, तो मौका आते ही तुरंत propose कर सकूँ, इसके लिए PoC और जुड़े हुए details पहले से तैयार रखता हूँ इस तैयारी की वजह से, जब site speed, SEO से जुड़े issue या bug फूट पड़ते हैं, तब उसी minimal idea को solution के तौर पर भी पेश किया जा सकता है यह concept दिलचस्प तो है, लेकिन इसे व्यवहार में कैसे लागू करूँ, इस पर मैं काफी सोचता हूँ। मैं अक्सर सोचता हूँ कि क्या भविष्य में काम आने वाले prep docs बनाकर रखूँ। कुछ वैसा जैसे blog चलाने की तरह अपने काम को लगातार document करना और मौके का इंतज़ार करना हो सकता है बहुत सा extra काम बेकार चला जाए, लेकिन सच कहूँ तो ऐसा बहुत कुछ मैं पहले से ही कर रहा हूँ
एक और बात जोड़ना चाहूँगा: मेरे मैनेजर से ज़्यादा political power रखने वाले लोगों के खिलाफ़ जाकर काम मनमाने ढंग से नहीं करना चाहिए। हाँ, अगर उनसे भी ऊपर का कोई व्यक्ति सार्वजनिक रूप से निर्देश दे, तो वह exception है बात यह नहीं कि जो वे चाहते हैं वही हर हाल में करो, बल्कि यह कि बेवजह उन्हें नाराज़ न करना ज़रूरी है दुश्मन बनाने में लगभग कभी फायदा नहीं होता, और ज़्यादातर मैनेजर संकट की घड़ी में self-protection के लिए मुझे scapegoat भी बना सकते हैं
मैं मैनेजर को सीधे ‘क्या करना चाहिए’ यह suggest करने वाला तरीका पसंद करता हूँ। अहम issues को टेबल पर रखता हूँ और बताता हूँ कि वे क्यों महत्वपूर्ण हैं मुझे proactively आगे आकर अपनी expertise के ज़रिए मैनेजर को लाभ पहुँचाना चाहिए मेरे पास भी अभी ऐसे बहुत ज़्यादा अनुभव नहीं हैं, लेकिन कुछ सफल उदाहरण ज़रूर हैं
जैसे-जैसे ऊपर जाते हैं, यह सलाह और भी अहम हो जाती है। engineering manager के लिए भी यही सच है, और जब मैं director था और सीधे CTO को report करता था, तब भी मैं यही सिद्धांत लागू करने की कोशिश करता था
मुझे पसंद आने वाले quotes में से एक है: "केवल वास्तविक संकट, या महसूस किया गया संकट, ही असली बदलाव लाता है। उस समय उठाए गए कदम इस बात से तय होते हैं कि आसपास कौन-से ideas तैर रहे हैं। हमारा मूल काम है वैकल्पिक policies विकसित करना, उन्हें जीवित बनाए रखना, और जो राजनीतिक रूप से असंभव दिखता है उसे राजनीतिक रूप से अनिवार्य बना देना" - Milton Friedman 1 Pager और technical docs लिखकर पहले से share कर देना, और संकट आने पर उन्हें फिर से quote करना, मेरे ideas को आगे बढ़ाने में असरदार रहा है मैंने जिस architecture direction को सही समझा, उसे धीरे-धीरे push करते हुए लक्ष्य के और करीब पहुँचने का अनुभव किया है, और consensus बनाना महत्वपूर्ण है बेशक, मुझसे कहीं बेहतर political skill रखने वाले VP या director से मैं कई बार पीछे भी रह गया हूँ लेकिन 1 Pager की library तैयार रखना, उसे casually share करते रहना, और उसे हवा में ‘फैला’ देना जब तक execution की motivation न बन जाए, यह कहीं ज़्यादा असरदार रहा है
“राजनीतिक लड़ाई में हार गया” वाली बात से मैं जुड़ाव महसूस करता हूँ। middle manager या उससे ऊपर जाने के बाद जो बात मुझे चौंकाने वाली लगी, वह यह थी कि नीचे के स्तर के कर्मचारियों की politics बहुत साफ़ दिखाई देती है बहुत से IC या first-level EM अपनी political sense या social IQ को बढ़ा-चढ़ाकर आँकते हैं साथ ही, संगठन के भीतर communication की depth और breadth अलग होती है, इसलिए कोई अगर सोचता है कि वह किसी stakeholder को मना रहा है, तो हो सकता है वही stakeholder बाद में उसके manager को चुपचाप पूरा context बता दे management team में रहते हुए, जब हम कई बार ऐसी half-baked politics को quietly control करने की कोशिश कर रहे थे, तब मैंने ऐसे दृश्य बार-बार देखे
“1 Pager और technical docs को हवा में तैरता रहने देना” असल में किस तरह किया जाता है, यह मैं जानना चाहूँगा
उस quote से मैं सहमत हूँ और यह तरीका असरदार भी लगता है। लेकिन वास्तविकता में time scale पागल कर देने जितना लंबा हो सकता है, इसलिए थकान आ सकती है और कई बार संकट को पूरी तरह ignore भी कर दिया जाता है, इसलिए वह सामान्य रूप से पहचाना ही नहीं जाता या normalise हो जाता है
जानना चाहूँगा कि 1 Pager की वजह से आपको recognition मिला और career में promotion भी मिला, या वह सिर्फ ideas को हक़ीक़त में बदलने में ही मददगार रहा
मेरे हिसाब से यह सबसे अच्छा तरीका है
production में बार-बार deploy करो (theoretical काम से ज़्यादा practical delivery पर फोकस)
meaningful results हासिल करो (agreed metrics के आधार पर)
management या PM में कोई ऐसा ‘salesman’ हो जो मेरी success को अच्छी तरह बेच सके लेकिन फिर भी दिक्कत आती है। हमेशा कोई नया VP या leader आता है जो innovation दिखाना चाहता है। existing system को maintain करने वाली team को outdated ठहरा दिया जाता है, और नया VP AI जैसी progressive ideas से अपनी दिशा को highlight करता है। मेरा code deploy होते ही “legacy” बन जाता है फिर VP चमकदार future के बड़े-बड़े वादे करने लगता है, और वर्तमान हक़ीक़त को संभालने वाली मेरी भूमिका उससे कभी compete नहीं कर पाती। reality sexy भी नहीं है, मज़ेदार भी नहीं। इस तरह आदमी पुरानी व्यवस्था का हिस्सा बन जाता है आख़िर में मूल बात patronage relationship की है: ऊपर वाले VP को सफल बनाओ, और जब वह job बदलकर जाए तो अपने लिए उसके साथ move करने की position बना लो
मुझे लगता है यह बिल्कुल सही बात है। एक कदम और आगे जाएँ तो staff engineer के तौर पर यह साफ़ कर देना ज़रूरी है कि “मैं सिर्फ code नहीं हूँ।” code deploy होते ही debt/legacy बन जाता है मेरे लिए सबसे अच्छा यह है कि मैं “code advocate” बनकर न रहूँ, बल्कि leadership, product, decision makers आदि के साथ EQUAL PARTNER की तरह position करूँ। यह मूल रूप से framing का मामला है। वही काम करने पर भी अगर मैं ‘काम का साथी’ दिखूँ तो leaders मुझे proactive helper मानते हैं, वरना मुझे किसी ऐसे obstacle की तरह देखा जाता है जिसे जबरन मनाना पड़े
“PM में कोई ऐसा होना चाहिए जो मेरी achievements अच्छी तरह sell कर सके” इस बात से मैं बहुत सहमत हूँ। पीछे मुड़कर देखूँ तो, मेरे career में सबसे बड़ा फ़र्क शायद इस बात ने डाला कि मैं खराब PM से कितनी जल्दी दूर हो पाया अच्छा PM सब कुछ बेहतर कर देता है, लेकिन ऐसे लोग मिलना कठिन है। उल्टा, अगर PM दिशा ठीक से न पकड़े तो सब बिखर जाता है, और जैसे ही वह PM हटता है, माहौल अचानक बदल जाता है
“future promises से compete नहीं किया जा सकता” वाला वाक्य मुझे बहुत पसंद आया। ऐसा बहुत बार होता है। भले ही वे promises पिछली 26 बार भी पूरे न हुए हों, “शानदार भविष्य” हमेशा प्रभावशाली लगता है
असली काम करने वालों के लिए बार-बार production में deploy करने का concept (rep=execution focus, no theory) अच्छा है, लेकिन VP के हवा-हवाई future promises को feasibility से ज़्यादा मूल्य क्यों मिलता है, यह समझ नहीं आता
“theoretical work” जैसा शब्द मैंने नहीं सुना, लेकिन ऐसी जगहें ज़रूर हैं जहाँ रोज़ deploy होता है। फिर भी मुझे नहीं लगता कि बार-बार deploy करना हमेशा ideal है। एक दिन में आप कोई वास्तव में substantive चीज़ कैसे ship कर सकते हैं? मेरे जैसे projects, जो company के लिए extra revenue लाते हैं, एक दिन में पूरे नहीं हो सकते। अगर काम एक दिन में पूरा हो जाता, तो इसका मतलब हुआ कि साल में सिर्फ चार बार engineer की ज़रूरत पड़ती। इसलिए यह “frequent deploy” भी एक vanity metric हो सकता है
मैंने भी कभी dysfunctional company में काम नहीं किया, इसलिए इस लेख के शुरुआती हिस्से से मुझे बिल्कुल relate नहीं होता मेरे अनुभव में top-down communication हमेशा सक्रिय रहा है, और भले ही development ऐसी दिशा में हो जिससे मैं सहमत न हूँ, पहले से पर्याप्त चर्चा होती है, जिससे यह समझना दिलचस्प होता है कि कोई smart colleague चीज़ों को मुझसे अलग क्यों देखता है शायद इसलिए कि मैंने सिर्फ engineer-founded companies में काम किया है, या फिर मैं बस भाग्यशाली रहा हूँ
बड़ी companies में ऊपरी स्तर के VP के goals भी व्यापक होते हैं और means की परिभाषा भी। यह हमेशा बुरी बात नहीं है। किसी खास technology या methodology पर lock-in होने से पहले कई approaches आज़माने का मौका मिलता है। बेशक इसमें waste भी होता है, लेकिन industry में आए tectonic shifts पर तुरंत प्रतिक्रिया देकर executive mandate पूरा करने में यह efficient भी हो सकता है
आपने किस size की companies में काम किया है, यह जानना चाहूँगा
“थोड़ा कठिन लेकिन ज़्यादा control पाने का तरीका यह है कि अपने ideas को मौजूदा political campaign से जोड़ दो” मैंने VP-driven projects से कुशलता से चिपक जाना सीख लिया है। कड़वा लगता है, लेकिन असर पक्का है
इस camp में अक्सर जो frustration सुनाई देती है, वह यह है: “मैंने पूरा codebase perfectly refactor कर दिया, लेकिन किसी ने notice ही नहीं किया” पहले एक परिचित को यह कहते सुना था कि उसने महीनों लगाकर data pipeline को पूरी तरह साफ़ कर दिया, लेकिन किसी को उसकी value समझ नहीं आई — इसने मुझे कई बातें सोचने पर मजबूर किया एक engineer के रूप में मैं जानता हूँ कि ऐसे काम की value होती है, लेकिन PM/EM के perspective से देखें तो यह कुछ वैसा है जैसे कोई PM एक महीने तक कंपनी की सारी engineering docs में सिर्फ punctuation ठीक करता रहे और sorting कर दे, और फिर सवाल उठे: “तो इसका business पर क्या impact हुआ?” PM की नज़र से फिर यह समझना कठिन हो जाता है कि प्रभाव पैदा करने वाला engineer कौन है और कौन सिर्फ ‘formatting work’ कर रहा है आख़िरकार, जो काम आप करने वाले हैं, उसे पहले से non-technical audience के लिए उपयुक्त format में साफ़-साफ़ समझाना महत्वपूर्ण है मैंने पहले unit tests और integration tests को push करने की कोशिश की थी, लेकिन political will की कमी के कारण वे बार-बार priority list में नहीं आ पाए। फिर जब एक बड़ा SEV हुआ, तब मैंने कहा, “ऐसी चीज़ें रोकनी हैं तो tests चाहिए,” और तब जाकर सबने उसकी value मानी। अब tests की ज़रूरत सबको समझ आती है
मैं पूरी तरह सहमत हूँ। अगर मैं किसी action को priority बनवाना चाहता हूँ, तो मुझे उसे priority तय करने वाले व्यक्ति की logic और language में समझाना होगा उदाहरण के लिए, PM आम तौर पर monetary terms में सोचते हैं। अगर मैं कहूँ कि test coverage बढ़ाने जैसा मेरा technical goal सालाना 200 dev hour लेगा, लेकिन 400 dev hour बचाएगा, support tickets 15% कम करेगा, future business scenarios enable करेगा, वगैरह, तो उसे मनाना बहुत आसान हो जाता है मेरी पसंदीदा trick यह है कि tech debt वाले काम को “technical work” की तरह नहीं, बल्कि साफ़ business impact के रूप में package करूँ, ताकि PM खुद उसे roadmap में डाल दे यह तरीका experience बढ़ने के साथ और आसान होता जाता है। शुरुआत में लोग skeptical होते हैं, लेकिन समय के साथ मेरे estimates और outcomes की credibility बनती है, और जो काम पहले कई meetings लेते थे, वे अब 10 मिनट की बातचीत में हो जाते हैं
मैं इस राय से भी सहमत हूँ। लेकिन इसे उल्टा करके भी देखा जा सकता है मान लीजिए construction site पर कोई व्यक्ति safety systems की बारीकी से जाँच और maintenance करके accidents रोकता है, लेकिन management उस value को पहचानती ही नहीं और reward भी नहीं देती अगर किसी लाभ को सिर्फ इसलिए मान्यता न मिले कि वह ROI में quantify नहीं हुआ, तो यह खुद management की बहुत बड़ी विफलता है, और जहाँ safety का सवाल जीवन से जुड़ा हो, वहाँ यह moral failure भी है असल दुनिया में यही अभी Boeing में होता दिख रहा है
बात यह है कि value को audience की समझ की भाषा में समझाया जाए। यह अंततः sales skill है, और मुझे लगता है कि ज़्यादातर developers के पास न तो इसका अनुभव होता है, न वे इसे आसानी से पहचानते हैं। अच्छा manager अगर अच्छी support दे, और मेरे साथ mindset मिलाने वाला staff dev या engineering manager हो, तो सच में नतीजे बहुत बड़े निकलते हैं ऐसे साथियों के साथ काम करते हुए मैं हमेशा आभारी महसूस करता हूँ
अगर हाथ धोने की ज़रूरत तक समझाकर उसके लिए investment approval लेना पड़े, तो team में कुछ न कुछ गड़बड़ है। जैसे top-class restaurant के chef को यह समझाने की ज़रूरत ही नहीं होनी चाहिए कि ‘soap खरीदना चाहिए या नहीं’, उसी तरह किसी ऐसे संगठन में जाना जहाँ यह सब default हो, मेरे हिसाब से career का अगला स्तर है। सफल SWE वही है जो ऐसे baseline वाले team में काम करता है
सहमत हूँ। refactoring developer की natural responsibility है। feature बनाते समय उसे साथ में स्वाभाविक रूप से कर लो और deadline update कर दो, तो engineers के बीच ही बात रह जाती है और persuasion बहुत आसान हो जाता है, साथ ही लंबे समय में codebase quality तेज़ी से बेहतर होती है। उसका नतीजा है आसान maintenance और नए features की तेज़ development
मैं जो सबसे बड़ी political capital बना सकता हूँ, वह मेरी technical understanding और capability है। लेकिन यह ताकत तभी काम आती है जब मैं company-wide strategy और context के भीतर सलाह दूँ और सचमुच deliver भी करूँ जब मैं सही सलाह देता हूँ और company के लिए उसे अमल में लाता हूँ, तो लोग मेरी बात सुनने लगते हैं और मुझ पर निर्भर होने लगते हैं। अंततः इससे मुझे दिशा तय करने की authority मिलती है अलग से risk management के लिए plan B तैयार रखना, और ज़रूरत पड़ने पर उसे propose और execute करना, यही सबसे अच्छा तरीका है
एक काफ़ी उग्र लेकिन अच्छे points वाली career book है उसमें एक बात यह है कि technical capability कभी-कभी मेरे career और power, दोनों के लिए हानिकारक हो सकती है। अगर मैं अपना समय और ऊर्जा सचमुच कुछ करने में लगाता हूँ, तो सक्षम manager सक्रिय रूप से कोशिश करेगा कि मैं अपनी सीट पर ही बँधा रहूँ और political influence न बना पाऊँ दूसरी ओर, अगर मैं manager बन जाऊँ, तो फिर खुद कुछ भी असल में न करो, बल्कि जितनी ज़्यादा initiatives (projects, policies, changes) शुरू कर सको, करो, और अपनी political capital को चतुराई से चलाते रहो उन initiatives से वास्तविक value पैदा होती है या नहीं, यह महत्वपूर्ण नहीं है, और इसकी चिंता भी नहीं करनी चाहिए। मैं तो पहले ही आगे बढ़ चुका हूँ, और जो लोग अब भी यहीं रहकर success और value creation पर अटके हैं, वे पीछे छूट जाते हैं ज़रूरत पड़े तो manager बाद में credit भी ले सकता है और कह सकता है, “यह मैंने किया”
“काम तभी होता है जब ‘flavor of the month’ के हिसाब से posture बदलने वाली dedicated teams हों” — यही मेरी political theory है। Washington DC में भी यही होता है। कोई विशाल master plan नहीं होता; मौके का इंतज़ार करती हुई एक फ़ौज तैयार रहती है, जो अवसर मिलते ही pitch कर दे
अगर political fights की practice करनी पड़े और power build करनी पड़े, तो बेहतर है नई company ढूँढ़ी जाए हो सकता है आप मुझे naive समझें, लेकिन हर company ऐसी नहीं होती। मेरी company ऐसी नहीं है