सीनियर इंजीनियर खराब प्रोजेक्ट्स को बस होने क्यों देते हैं

 (lalitm.com)
23 पॉइंट द्वारा GN⁺ 2026-01-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • सीनियर इंजीनियर ‘सही होने’ से ज़्यादा ‘प्रभावी कार्रवाई’ को महत्व देते हैं, और हर गलत प्रोजेक्ट को रोकने की कोशिश नहीं करते
  • ‘खराब प्रोजेक्ट’ में तकनीकी, राजनीतिक और UX समस्याएँ शामिल हो सकती हैं, और यह अक्सर व्यक्तिपरक आकलन पर निर्भर करता है
  • प्रभाव को बैंक खाते की तरह मैनेज करना चाहिए, क्योंकि बार-बार विरोध करने पर भरोसा कम हो सकता है और व्यक्ति ‘राजनीतिक दिवालियापन’ की स्थिति में पहुँच सकता है
  • दखल देना है या नहीं, यह प्रोजेक्ट की निकटता, टीम पर प्रभाव, और कंपनी-स्तरीय नुकसान के पैमाने के आधार पर तय होता है
  • हर समस्या सुलझाने की कोशिश करने के बजाय रणनीतिक रूप से हस्तक्षेप का समय चुनना चाहिए, और बाकी मामलों में अवलोकन व तैयारी से काम लेना चाहिए

खराब प्रोजेक्ट की परिभाषा और उदाहरण

  • ‘खराब प्रोजेक्ट’ अनावश्यक समस्याओं को हल करने, जटिल डिज़ाइन, या राजनीतिक प्रेरणाओं जैसी कई शक्लों में सामने आ सकता है
    • UX के नज़रिए से, यह ऐसे मामलों में हो सकता है जहाँ ऐसी समस्या हल की जा रही हो जो है ही नहीं, या मौजूदा flow को तोड़ा जा रहा हो
    • तकनीकी रूप से इसमें ज़रूरत से ज़्यादा जटिलता, गलत library का चुनाव, और अक्षम architecture शामिल हो सकते हैं
    • राजनीतिक रूप से, यह promotion या ट्रेंड का पीछा करने के लिए बनाए गए प्रोजेक्ट्स हो सकते हैं
  • कोई प्रोजेक्ट अच्छा है या खराब, यह अक्सर समय बीतने के बाद ही स्पष्ट होने वाला व्यक्तिपरक निर्णय होता है, शुरुआत में नहीं
  • Google का एक उदाहरण यह था कि platform team ने core user flow को किसी दूसरी team को सौंपने की कोशिश की, लेकिन यह प्रोजेक्ट राजनीतिक कारणों से असफल हो गया
    • तकनीकी रूप से यह शानदार था, लेकिन टीमों के बीच अधिकार संबंधी समस्याओं के कारण 2 साल बाद बंद कर दिया गया
    • इससे यह सीख मिलती है कि राजनीति और समस्या की सही परिभाषा, तकनीकी उत्कृष्टता जितनी ही महत्वपूर्ण हैं

हर खराब प्रोजेक्ट को रोका नहीं जा सकता, इसके कारण

  • software कंपनियों में ‘तेज़ execution’ की ओर झुकाव बहुत मज़बूत होता है, इसलिए चिंताएँ उठाना गति धीमी करने जैसा माना जाता है
    • इसलिए जब तक बात बहुत बड़ी समस्या न लगे, उसे नज़रअंदाज़ किए जाने की संभावना अधिक रहती है
  • बार-बार विरोध करने पर व्यक्ति को ‘नकारात्मक इंसान’ का टैग लग सकता है, जबकि रोकी गई विफलताओं का श्रेय नहीं मिलता
  • विरोध करने से किसी और के promotion या किसी वरिष्ठ executive के प्रोजेक्ट पर असर पड़ सकता है, इसलिए इसमें राजनीतिक जोखिम भी होता है
  • एक इंजीनियर की ध्यान देने की क्षमता सीमित होती है, और हर समस्या में दखल देने से वह निंदक बन सकता है

प्रभाव को ‘बैंक खाते’ की तरह मैनेज करना

  • प्रभाव परिणामों और सहयोग से जमा होने वाली पूंजी है, और हर विरोध के साथ इसमें से निकासी होती है
    • $5 चेक: code review स्तर की छोटी टिप्पणी
    • $500 चेक: architecture निर्णय या timeline पर आपत्ति
    • $50,000 चेक: executive-स्तर के प्रोजेक्ट को रोकने की कोशिश
  • छोटी-छोटी बातों पर बार-बार दखल देने से बड़े मुद्दों पर प्रतिक्रिया देने की क्षमता खत्म हो जाती है
  • जब प्रभाव खत्म हो जाता है, तो व्यक्ति मीटिंग इनवाइट्स से बाहर किया जाना, राय की अनदेखी होना जैसी ‘राजनीतिक दिवालियापन’ की स्थिति में पहुँच सकता है

हस्तक्षेप का समय तय करने के मानदंड

  • विशेषज्ञता की जाँच: यह सुनिश्चित करना कि आपका आकलन पर्याप्त आधार वाला है
  • अपनी बात की सीमा समझना: राय देना ‘आदेश’ नहीं बल्कि ‘दृष्टिकोण साझा करना’ है
  • निर्णय के तीन तत्व
    • निकटता (Proximity): प्रोजेक्ट आपकी टीम के जितना करीब होगा, दखल की लागत उतनी कम होगी
    • टीम प्रभाव (Team Impact): विफलता से टीम को सीधा नुकसान होने की आशंका हो, तो दखल का महत्व बढ़ता है
    • कंपनी पैमाना (Company Scale): विफलता का असर पूरे संगठन पर बड़ा हो, तो हस्तक्षेप ज़रूरी हो सकता है

खराब प्रोजेक्ट्स से निपटने के तरीके

  • सीधा हस्तक्षेप: प्रोजेक्ट रोकने की मांग करना या गंभीर चिंता वाला दस्तावेज़ जमा करना
    • इसके लिए दृढ़ विश्वास और जोखिम उठाने की तैयारी चाहिए
  • आंशिक हस्तक्षेप: डिज़ाइन की दिशा बदलना या बेहतर समाधान की ओर मार्गदर्शन करना
    • सहयोगात्मक रवैये से आगे बढ़ने पर आपको ‘मदद करने वाले व्यक्ति’ के रूप में देखा जा सकता है
  • हस्तक्षेप न करना: जब राजनीतिक जड़ता या प्रभाव की सीमा के कारण दखल की उपयोगिता कम हो
    • अगर टीम संबंधित है, तो निर्भरता कम करने या विकल्प तैयार करने जैसे बचाव उपाय करने चाहिए
    • अगर संबंध नहीं है, तो शांत रहकर अवलोकन करें और केवल अंदरूनी स्तर पर राय साझा करें
  • टीम प्रबंधन: टीम के सदस्यों के साथ वास्तविक स्थिति ईमानदारी से साझा करें, लेकिन अनावश्यक राजनीतिक विवरणों से बचें

निष्कर्ष

  • “सही होना और प्रभावी होना अलग बातें हैं” — यही मूल समझ है
  • बड़ी कंपनियों में तर्क से ज़्यादा राजनीति और संदर्भ काम करते हैं, और हर गलती को तुरंत सुधारा नहीं जा सकता
  • प्रभाव और भरोसे का रणनीतिक उपयोग करके उन क्षणों पर ध्यान देना चाहिए जहाँ वास्तविक बदलाव संभव हो
  • बाकी मामलों में सहकर्मियों के साथ बात साझा करें, तैयारी करें, और अवलोकन से सीखें
  • भले ही हर चीज़ पूरी तरह हल न हो, यह दृष्टिकोण लंबे समय तक टिकाऊ है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-01-17
Hacker News की राय

  • पहले एक मैनेजर ने कहा था, “कभी-कभी लोगों को असफल होने देना चाहिए”
    कुछ लोगों को लगातार संभालते रहने में बहुत ज़्यादा ऊर्जा लगती थी। उम्मीद थी कि वे कभी खुद तैरना सीखेंगे, लेकिन कभी-कभी वह मेहनत कहीं बेहतर जगह लगाई जा सकती थी
    एक प्रोजेक्ट था जो मेरी भागीदारी के बिना चला, लेकिन मेरे ज्ञान के बिना वह कभी सफल हो ही नहीं सकता था। वह टीम इतनी खराब थी कि सवालों को भी अपने काम में ऐसे मिला देती थी जैसे वही काम हो
    ऊपर से जब पता चला कि मैनेजमेंट मेरी टीम को नीचा दिखा रहा है और उनकी तारीफ़ कर रहा है, तो यह सच में अपमानजनक लगा। उनका implementation बेहद खराब था

    • मैं अक्सर कहता हूँ, “कभी-कभी मैनेजर को असफल होने देना चाहिए”
      कुछ मैनेजर यह सुनना पसंद नहीं करते कि उनका आइडिया काम नहीं करेगा। अगर आप विरोध करें, तो असफलता का कारण आपको ही ठहराया जाता है
      इसलिए मैं काम आगे बढ़ाता हूँ, लेकिन उन्हें बार-बार स्थिति बताता रहता हूँ। इससे वे अनुमानित असफलता खुद देख लेते हैं, और मेरी पहचान उस असफलता से अलग रहती है
    • जब मैनेजमेंट असफल होता है, तो वे एक-दूसरे को दोष नहीं देते। उसकी जगह consultant बुलाकर senior engineer को निकाल देते हैं
    • मैंने कभी यह सुना था, “लोगों को अपना data खुद इकट्ठा करना पड़ता है।” आखिरकार, सीधे टकराए बिना सीख नहीं होती
    • मुझे लगता है कि किसी व्यक्ति की असफलता और प्रोजेक्ट की असफलता अलग चीज़ें हैं
      व्यक्ति की असफलता कम लागत वाली और शिक्षाप्रद हो सकती है। कभी-कभी उनका तरीका काम भी कर जाता है, और तब संगठन को नया knowledge asset मिल जाता है
    • लोगों को खुद सीखने के लिए छोड़ देना जोखिम भरा होता है। आपको भरोसा करना पड़ता है कि उनमें self-awareness है और वे मेरे सहारे पर निर्भर नहीं हैं
      हो सकता है वे असफल हों और कुछ सीखें भी नहीं। लेकिन अगर आपने अपनी तरफ़ से पूरी कोशिश की है, तो कम-से-कम अंतरात्मा की शांति तो होगी

  • किसी प्रोजेक्ट का “खराब” होना उसके ज़्यादातर lifecycle में व्यक्तिपरक होता है
    एक बार किसी बाहरी व्यक्ति ने प्रोजेक्ट का विरोध किया और उसे रुकवाने की कोशिश की, लेकिन आखिर में वह रिलीज़ होकर सफल हुआ, और उनकी साख टूट गई
    अपनी प्रतिष्ठा कहाँ लगानी है, यह सोच-समझकर तय करना चाहिए

    • मैंने भी ऐसा ही कुछ झेला है। सहयोग के लिए बनी संस्था में इतनी खुली स्वार्थपरता मैंने पहली बार देखी थी
      पता है कि दुनिया हमेशा धूप और इंद्रधनुष से भरी नहीं होती, लेकिन उस समय यह सच में बहुत निराशाजनक था

  • जैसे कहते हैं, “न मेरा बंदर, न मेरा सर्कस”, वैसे ही मैं उन चीज़ों में दखल नहीं देता जो मेरी ज़िम्मेदारी नहीं हैं
    architect के रूप में काम करते हुए भी मैंने UI या business logic जैसे अपने दायरे से बाहर की चीज़ों पर अनचाही सलाह नहीं दी
    ऊपर के मैनेजर जो तय करें, मैं बस उसका पालन करता हूँ। consultant के रूप में काम करते हुए भी मैंने यही सिद्धांत रखा
    मैं सिर्फ़ अपनी विशेषज्ञता वाले क्षेत्र में सावधानी से दखल देता हूँ। वह भी केवल C-suite की मंज़ूरी होने पर

  • यह सलाह SMBs के लिए काफ़ी उपयुक्त है। लेकिन बड़ी कंपनियों में किसी प्रोजेक्ट के खिलाफ़ राय देना लगभग बेकार होता है
    अगर वह सफल हो जाए तो आप मूर्ख लगते हैं, और असफल हो जाए तो भी किसी को याद नहीं रहता
    असली ROI तब मिलता है जब असफलता के बाद आप समाधान लेकर आते हैं। लोगों को “problem solver” पसंद आते हैं
    मैंने कभी automated E2E tests का प्रस्ताव दिया था, जिसे ठुकरा दिया गया। बाद में जब समस्या हुई, तो वही framework निकालकर लाया गया और मुझे हीरो जैसा माना गया

    • कंपनी में जितना ऊपर जाते हैं, उतना ही दूसरों की गलतियों की ज़िम्मेदारी लेनी पड़ती है और बदले में इनाम कम मिलता है
      मुझे तो लगता है कि निचले पद पर बिना तनाव के रहना ज़्यादा समझदारी है
    • startup में कुछ engineers अगर कह दें “यह बिल्कुल बेतुका है”, तो वे आपदा रोक सकते हैं
      वहीं बड़ी कंपनियाँ राजनीति की वजह से सालों और करोड़ों डॉलर बर्बाद कर देती हैं

  • मैं “समस्या को अनदेखा नहीं करना चाहिए” वाले पक्ष में हूँ
    अगर आप मदद करने की स्थिति में हैं, तो चुपचाप ही सही, दूसरा तरीका सुझाना चाहिए। ज़रूरी नहीं कि भावुक होकर प्रतिक्रिया दी जाए

    • “मदद करने की स्थिति में होना” यही असली शर्त है
      छोटे संगठनों में अच्छे ideas आसानी से अपनाए जाते हैं, लेकिन बड़े संगठनों में political risk बहुत अधिक होता है
      सच में मदद कर पाने की संभावना से ज़्यादा अपनी प्रतिष्ठा खोने की संभावना होती है। इसलिए किस लड़ाई को चुनना है, यह महत्वपूर्ण है
    • छोटे संगठनों में शुरुआती चरण में दखल देना शायद एक कर्तव्य भी हो सकता है
      लेकिन बड़े संगठनों में जो प्रोजेक्ट पहले से चल रहा हो, उसे बदलने में बहुत ज़्यादा समय और ऊर्जा लगती है
    • “खराब प्रोजेक्ट को वैसे ही छोड़ दो” यह वाक्य थोड़ा भ्रामक है
      असल में हम अक्सर उस प्रोजेक्ट को नियंत्रित ही नहीं कर सकते। “दूसरी टीम ऐसा क्यों कर रही है, मुझे नहीं पता” शायद ज़्यादा सही शीर्षक होगा
    • अगर मुझे असफलता की आशंका हो, तो मैं अपनी राय दस्तावेज़ में लिखकर वहीं छोड़ देता हूँ
      professionalism का मतलब है कि जब बोलना चाहिए, तब बोलो। लेकिन अनुभव से कहूँ तो कुछ बदलता बहुत कम है
    • अगर आप जानते हैं, तो बोलिए, लेकिन उसके बाद भावनात्मक बोझ मत उठाइए। अगर आपकी सलाह को नज़रअंदाज़ कर दिया गया, तो वह मेरी समस्या नहीं है

  • मैं अभी वास्तव में ऐसी ही स्थिति देख रहा हूँ
    business owner ने लागत और गति के कारण low-code platform चुना, लेकिन आखिर में भारी-भरकम जुगाड़ू customization की ज़रूरत पड़ गई
    मेरी टीम TypeScript में दिन में कई बार deploy करती है, जबकि वह टीम महीने में एक बार deploy करती है और curl से अजीब-अजीब काम कर रही है

  • यह सलाह Big Tech की राजनीतिक हक़ीक़त में तो शानदार है, लेकिन अंततः यह कुछ corporate pacifism जैसी लगती है
    दूसरे माहौल में पैसे और motivation को यूँ जलाने की गुंजाइश नहीं होती
    (फिर भी Lalit ने जटिल organizational dynamics को छोटे लेख में अच्छी तरह समेटा है)

    • मैंने Big Tech में काम नहीं किया, लेकिन छोटे संगठनों में भी यही चीज़ देखी है
      जो व्यक्ति हर समय नुक़्ताचीनी करता है, उसे आखिरकार नकारात्मक व्यक्ति का टैग मिल जाता है
      आखिरकार मुख्य सलाह यही है कि ऊर्जा बचाकर रखो ताकि ज़रूरी समय पर इस्तेमाल हो सके। हर समस्या कंपनी के अस्तित्व का सवाल नहीं होती
    • pacifism निष्क्रियता नहीं है। बल्कि यह सबसे सक्रिय और प्रभावी राजनीतिक कार्रवाई हो सकती है

  • engineer के पास राजनीतिक रूप से किसी खराब प्रोजेक्ट को “असफल होने देने” का अधिकार नहीं होता
    वह मैनेजमेंट की ज़िम्मेदारी है। engineer को केवल तकनीकी सलाह देनी चाहिए
    लेकिन इन dynamics को समझना ज़रूरी है ताकि आपके करियर पर असर न पड़े
    product team और platform team के बीच क्षेत्रीय खींचतान साफ़ नेतृत्व की कमी का परिणाम है
    अगर आप जानना चाहते हैं कि ऐसा बार-बार क्यों होता है, तो Google से जुड़ी यह पोस्ट देखी जा सकती है

  • इस तरह की सोच बड़े संगठनों, खासकर सरकारी संस्थानों में आम है
    लागत कोई दूसरा विभाग उठाता है, और ताकत को manage किए जा रहे लोगों की संख्या से मापा जाता है
    ऐसी संगठनात्मक सड़न को रोकने के लिए leader को स्पष्ट metrics और preventive systems बनाने चाहिए

    • इंसान स्वाभाविक रूप से सकारात्मक लोगों को पसंद करता है और नकारात्मक लोगों को नापसंद
      political capital को नज़रअंदाज़ करने से वह ग़ायब नहीं हो जाता

  • यह एक अच्छा रूपक है
    leadership और trust बनाने पर ऐसा स्थान बनता है जहाँ आप कह सकते हैं, “आप ग़लत हैं”
    लेकिन leader हमेशा engineers पर भरोसा क्यों नहीं करते, इसका कारण यह है कि कभी-कभी engineer ही ग़लत होते हैं
    engineer खामियाँ ढूँढ़ने में बहुत अच्छे होते हैं, लेकिन business context समझने में अक्सर कमज़ोर
    इसलिए कोई आइडिया “बेवकूफ़ी भरा” लगे, तब भी पहले उसका संदर्भ समझकर ही निर्णय करना चाहिए
    जब आप सच में खत्म कर देने लायक आइडिया और सिर्फ़ खामी वाले आइडिया में फर्क कर सकते हैं, तभी संगठन के भीतर trust मिलता है