35 पॉइंट द्वारा GN⁺ 2025-11-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • engineering management को लेकर industry की expectations business environment में बदलाव के साथ बार-बार दोबारा परिभाषित हुई हैं, और हर दौर में 'good leadership' की परिभाषा बदलती रही है
  • 2000s के आख़िरी दौर में team opportunities को पकड़ना और organization को navigate करना, 2010s में engineers को attract, retain, motivate करना, और 2020s में hands-on execution क्षमता पर ज़ोर दिया गया
  • हर transition के साथ एक moral narrative भी जुड़ जाता है, लेकिन असली driver hiring competition, ZIRP का अंत, और AI tools productivity expectations जैसी business realities होती हैं
  • प्रभावी managers को execution, team, ownership, alignment जैसी core skills और taste, clarity, ambiguity navigation, timescale management जैसी growth skills के बीच संतुलन बनाना चाहिए
  • लंबी अवधि में energy management, role चुनने के मानदंड, और life stage के हिसाब से 40 साल के career design को ध्यान में रखते हुए अपने काम को टिकाऊ तरीके से डिज़ाइन करना महत्वपूर्ण है

leadership expectations में दौर के हिसाब से बदलाव

  • 2000s के आख़िरी दौर में Yahoo के समय: 2 साल में manager के साथ 1:1 meeting सिर्फ़ दो बार हुई, और उस समय management style का केंद्र था team के लिए अहम opportunities को पकड़ना और उन organizations को navigate करना जो प्रगति में बाधा बन सकती थीं
    • यह Tracy Kidder की The Soul of A New Machine में दिखने वाली team leader style से मिलता-जुलता था
    • आज के मानकों से यह कमज़ोर लग सकता है, लेकिन उस समय के context में यह प्रभावी था
  • 2010s: यह hypergrowth का दौर था, जहाँ budget constraints नहीं थीं और उत्कृष्ट engineers की hiring manager की सबसे अहम क्षमता मानी जाती थी
    • managers को management transition के पहले चरण में software लिखना बंद करो जैसी सलाह दी जाती थी, और उस समय यह उचित guidance थी
  • 2020s (2022 के उत्तरार्ध से): ऊँची ब्याज दरों के साथ ZIRP (zero interest rate policy) का अंत हुआ, और यह अनुमान उभरा कि generative LLM गहरी engineering organizations की जगह ले सकते हैं
    • organizations flatter होने लगीं, और जो roles पहले coordination करते थे उनसे अब hands-on keyboard काम की अपेक्षा होने लगी
    • पिछले दौर के बेहतरीन managers को अब core leaders नहीं बल्कि bureaucrats के रूप में फिर से पेश किया जाने लगा

moral narrative और असली driver

  • हर transition के साथ एक morality tale जुड़ जाती है
    • 2010s: "engineers का empowered होना मूलभूत अच्छाई है" जैसी कथा → जबकि असली वजह hiring competition थी
    • 2020s: "bureaucratic middle managers ने organizations को rigid और inefficient बना दिया" जैसी कथा → जबकि असली driver ZIRP का अंत और AI tools से productivity बढ़ने की अपेक्षा थी
  • निष्कर्ष: अगर आप मौजूदा moral narrative को ही सच मान लेंगे, तो industry के फिर बदलने पर आप गंभीर रूप से नुकसानदेह स्थिति में पहुँच सकते हैं
    • असली बदलाव का इंजन business conditions में बदलाव है, और इसी वजह से leadership का ‘सही जवाब’ लगातार बदलता रहता है

engineering management की 8 बुनियादी क्षमताएँ

  • एक प्रभावी manager के लिए ज़रूरी क्षमताओं को Core Skills और Growth Skills नाम के दो clusters में बाँटा गया है

Core Skills

  • ये हर role में ज़रूरी skills हैं, entry-level management roles सहित
  • 1. Execution

    • team को अपेक्षित tangible और intangible काम deliver करने के लिए lead करना
    • उदाहरण: project launch, on-call rotation management, sprint planning, incident management
    • अगर team execution नहीं कर सकती, तो manager के रूप में शुरुआत करने या टिके रहने का अवसर नहीं मिलता
  • 2. Team

    • team और उसके environment को इस तरह shape करना कि वह सफल हो सके
    • सिर्फ़ team के लिए या सिर्फ़ leadership के लिए काम करने के बजाय दोनों के बीच संतुलन बनाना
    • उदाहरण: hiring, coaching, performance management, upper management के सामने advocacy
  • 3. Ownership

    • कठिन realities के बीच भी लगातार प्रगति के लिए reality को समझते हुए आगे बढ़ना
    • यह ढूँढना नहीं कि काम न होने का दोष किसका है, बल्कि काम पूरा कैसे हो यह ढूँढना
    • उदाहरण: मुश्किल काम उठाना, असहज स्थिति में आगे आना, systemic problems के बावजूद ज़िम्मेदारी लेना
  • 4. Alignment

    • leadership, stakeholders, team, और problem domain के बीच shared understanding बनाना
    • लोगों को चौंकाए बिना या चौंकाते हुए भी व्यावहारिक plan खोजना
    • उदाहरण: बड़े issues और crisis के दौरान updates को document और share करना

Growth Skills

  • ये वे skills हैं जो तय करती हैं कि आप career में कितनी दूर जा सकते हैं
  • 5. Taste

    • technical, business, और process/strategy स्तर पर "क्या अच्छा है" यह पहचानने की judgement
    • व्यापक taste ही असली senior roles की सार्वभौमिक कसौटी है
    • Amazon के "Are Right, A Lot" principle की पूर्वशर्त
    • उदाहरण: proposed product concept को बेहतर बनाना, high-risk rewrite से बचना, team के काम में usability issue पकड़ना
  • 6. Clarity

    • team, stakeholders, और leadership को यह क्या और क्यों समझ आना कि काम क्या हो रहा है और क्यों
    • उन्हें यह समझाना कि सबसे बड़े issues को कैसे पार किया जा रहा है
    • "हम scalability issues से जूझ रहे हैं" कहने के बजाय "हम नए cluster में user login database को shard कर रहे हैं ताकि load घटे" जैसा ठोस विवरण
    • उदाहरण: progress के levers पहचानना, crisis से निकलने की योजना बनाना, और उस योजना पर execution दिखाना
  • 7. Navigating Ambiguity

    • जटिल समस्याओं से राय-सहित और लागू करने योग्य approach तक पहुँचना
    • बेहद messy और open-ended problems में भी आगे बढ़ने का रास्ता निकालना
    • उदाहरण: नया business line launch करना, developer experience सुधारना, 1 से N cloud regions तक scale करना
    • senior leaders आपके पास ambiguous problems लाते हैं या नहीं, यह इस skill का संकेतक है
  • 8. Working Across Timescales

    • यह सुनिश्चित करना कि आपकी responsibility का क्षेत्र short-term और long-term दोनों में आगे बढ़े
    • आज shortcuts लेकर सफलता दिख सकती है, लेकिन कल वही disaster बन सकती है
    • उदाहरण: स्पष्ट destination रखना, short-term work को उसी दिशा में ले जाना, long-term में rigid और short-term में flexible रहना

हर skill के लिए self-diagnosis

  • हर capability के लिए खुद से पूछे जाने वाले reflection questions
  • Execution

    • आख़िरी बार team को delivery में friction कब हुआ था? क्या यह बार-बार होने वाली समस्या है?
    • आख़िरी बार कोई कठिन चीज़ कब launch हुई जो वास्तव में बहुत अच्छी चली?
    • आख़िरी बार आप किसी time-sensitive और executives को दिखने वाले project में कब शामिल थे?
  • Team

    • आख़िरी उत्कृष्ट performer किसे hire किया था?
    • क्या आपने अपने सबसे अच्छे performers को बनाए रखा?
    • कौन से उत्कृष्ट performers आपकी team में शामिल होना चाहते हैं?
    • कौन से peers आपकी team को बहुत प्रभावी मानते हैं?
    • executives ने आख़िरी बार आपकी team को exceptional कब कहा था?
  • Ownership

    • team ने आख़िरी बार विपरीत परिस्थितियों को पार करके कोई महत्वपूर्ण चीज़ कब deliver की? (क्या stakeholders भी इससे सहमत होंगे?)
    • आख़िरी कठिन समस्या कौन-सी थी जिसे आपने हल किया और वह दोबारा नहीं हुई?
    • cross-team gap सुलझाने से पहले आपने आख़िरी बार समस्या कब पहले ही हल कर दी थी?
  • Alignment

    • आख़िरी बार कोई stakeholder आपसे कब surprise हुआ था? इसे दोबारा होने से रोकने के लिए आप क्या कर सकते हैं?
    • कोई नया stakeholder priority tradeoff को उसके rationale सहित कैसे समझेगा?
    • आपने आख़िरी बार किसी stakeholder को relationship खराब किए बिना कब निराश किया था?
    • कौन-सा stakeholder आपके भरोसे company join करेगा?
  • Taste

    • हाल का कौन-सा decision आपकी मौजूदगी से अर्थपूर्ण रूप से बेहतर हुआ?
    • अगर product owner चला जाए, तो कौन-से decisions लेना मुश्किल हो जाएगा?
    • कौन-सी subtle clarification ने design या launch को बड़े स्तर पर बदल दिया?
    • आगे की समस्या पहले देख लेने से आपने team outcome को कैसे बदला?
  • Clarity

    • हाल में आपने team को कौन-सा कठिन tradeoff लेने में मदद की?
    • आपकी सीधी भागीदारी के बिना भी team वही tradeoff ले सके, इसके लिए क्या चाहिए?
    • हाल में कौन-सा decision पलटा गया? कैसे?
  • Navigating Ambiguity

    • आपके support से पहले कौन-सी समस्या अटकी हुई थी और बाद में खुल गई?
    • आपने इसे कैसे हल किया?
    • क्या senior leaders आपके पास ambiguous problems लाते हैं? क्यों?
  • Working Across Timescales

    • short-term और long-term priorities के बीच हाल का tradeoff क्या था?
    • timescale tradeoffs को आप कैसे communicate करते हैं?
    • कौन-सा long-term goal आप काफ़ी short-term cost उठाकर protect कर रहे हैं?

Core Skills समय के साथ कैसे बदलती हैं

  • "core" और "growth" skills का अंतर साफ़ दिखता है, लेकिन कुछ skills fad के बदलने के साथ core और growth के बीच खिसकती रहती हैं
  • Execution आज बुनियादी skill है, लेकिन hypergrowth दौर में यह कम core थी, और investor-driven दौर में इससे भी कम
  • fad से आगे जाकर सफल होने के लिए हर skill में काफ़ी व्यापक आधार चाहिए, नहीं तो जब कोई दौर अप्रत्याशित रूप से खत्म होगा तो आपको कमज़ोर manager माना जा सकता है
  • टिके रहने के लिए इन 8 क्षमताओं को समग्र रूप से संतुलित रखना ज़रूरी है

energy management का महत्व

  • The Engineering Executive's Primer के "Manage your priorities and energy" chapter का उल्लेख
  • ‘priorities और energy management’ का विचार इस बात पर ज़ोर देता है कि सिर्फ़ ideal या mathematical prioritization के सहारे manager लंबे समय तक नहीं चल सकता
    • काम का परफ़ेक्ट बँटवारा impact को maximize करने वाला कोई mathematical ideal नहीं है
    • mathematical ideal और ऐसा काम जो लंबे समय तक motivation और energy दे सके — इनके बीच संतुलन ज़रूरी है
  • लंबे समय तक काम करने के लिए अपनी दिनचर्या में कुछ ऐसी activities शामिल करनी चाहिए जो आपकी energy को recharge करें
    • उदाहरण: जिसे coding पसंद है, वह manager अगर थोड़ा code लिखे तो लंबे समय में ज़्यादा टिक सकता है
    • जिसे process सुधारना पसंद है, वह efficiency improvements साथ लेकर चले तो ज़्यादा टिकेगा
  • ‘perfect optimization’ से ज़्यादा महत्वपूर्ण है ‘sustainable momentum’ बनाना; असली career outcomes पर यही अधिक असर डालता है

40 साल के career का नज़रिया

  • A forty-year career लेख के विचारों की पड़ताल
  • हर role में pace, people, prestige, profit, learning जैसी अलग-अलग dimensions को प्राथमिकता देने का अवसर होता है
  • कोई एक "सही जवाब" नहीं है; हर बार tradeoffs होते हैं
  • career की शुरुआती choices आगे के 40 सालों में compound effect पैदा करती हैं
  • लेखक के मामले में: career की शुरुआत में दूसरों के प्रति ज़िम्मेदारियाँ कम थीं, इसलिए Uber जैसी जगह पर बेहद मेहनत करने का अवसर था
  • अब परिवार की ज़िम्मेदारियाँ ज़्यादा हैं, इसलिए वैसे लगातार काम करने वाले tradeoff को स्वीकार करने की इच्छा नहीं है
  • इन tradeoffs को समझना और जानबूझकर निर्णय लेना career को आकार देने के सबसे मूल्यवान कामों में से एक है
  • इन dimensions पर विचार किए बिना और आधे जीवन तक सक्रिय बने रहने वाले tradeoffs को समझे बिना, स्वस्थ self-awareness के साथ career बनाना बहुत कठिन है

1 टिप्पणियां

 
GN⁺ 2025-11-26
Hacker News राय
  • मैंने बड़ी कंपनियों से लेकर startup तक चार जगह Engineering Manager(EM) के रूप में काम किया है, और मुझे लगता है कि ‘EM role’ असल में लगभग एक मिथक है

    • हर कंपनी में यह role पूरी तरह अलग था; कहीं यह product-केंद्रित था, तो कहीं लोगों के management-केंद्रित

    • टीम में bottleneck कहाँ है, उसके हिसाब से Product / Process / People / Programming इन चार धुरियों में से किसी एक को मजबूत करना ही असली बात है

    • लोग कम हों तो खुद coding करते हुए scope adjust करना पड़ता है, और PM न हो तो product planning से लेकर customer communication तक संभालना पड़ता है

    • लोग ज़्यादा हों तो coding छोड़कर career management और organization के भीतर coordination पर ध्यान देना पड़ता है

    • अगर reporting line CEO के करीब हो, तो sales, operations और customer response तक में पुल की भूमिका निभानी पड़ती है

    • आखिरकार सबसे ज़रूरी चीज़ टीम का संतुलन बनाए रखने की समझ है

    • मुझे भी लगता है कि ज़्यादातर leadership positions कुछ ऐसी ही होती हैं

      • 300 लोगों की कंपनी में Principal Tech Lead के रूप में काम करते हुए मैंने PM, user interview, CEO demo बनाना और core technology development तक सब किया
      • जितना ऊपर leadership में जाते हैं, उतना ही ‘सबसे क़ीमती काम खुद ढूँढकर उसे अमल में लाने वाला व्यक्ति’ बनना पड़ता है
    • छोटी कंपनियों में ऐसी अनुकूलन क्षमता सिर्फ manager ही नहीं, individual contributor(IC) के लिए भी ज़रूरी होती है

    • मुझे लगता है कि यह comment मूल लेख से कहीं ज़्यादा अंतर्दृष्टिपूर्ण है

  • engineering management में बहुत से trends आते-जाते रहते हैं

    • एक समय ऐसा management culture trend था जिसमें कहा जाता था कि ‘तकनीक न भी आती हो तो सिर्फ management अच्छा होना चाहिए’; यह शायद आर्थिक कारणों से पैदा हुआ था

    • असली leadership समय से परे होती है, और अच्छा leader वह है जो टीम से उनकी अपनी क्षमता से भी बड़े नतीजे निकलवाए

    • बुरे leader से बचने का तरीका सीधा है — resources वापस ले लो और दूरी बना लो

    • कंपनी में यह अक्सर किसी दूसरी टीम में चले जाने के रूप में दिखता है, और ऐसे moves जमा हों तो अयोग्य leader अपने-आप उजागर हो जाता है

    • लेकिन engineers अक्सर project success के प्रति अपनी प्रतिबद्धता के कारण बुरे leader के नीचे भी लंबे समय तक टिके रहते हैं

      • leader बदलना एक जुआ है, और जीवन की परिस्थितियों के कारण कई बार आसानी से move करना भी संभव नहीं होता
    • हर leadership आख़िरकार technical leadership होनी चाहिए

      • domain expertise के बिना leadership एक भ्रम है
      • non-technical management के trend ने leadership को व्यापक संकट में डाल दिया, और politics, entertainment, technology जैसे हर क्षेत्र में रचनात्मक थकावट दिख रही है
  • मुझे engineering management के trendification की चिंता है

    • जब process को result से ऊपर रखा जाता है, तो औपचारिक व्यवहार और गलत incentives पैदा होते हैं

    • EM की performance को objectively evaluate करना मुश्किल होने से political behavior बढ़ता है

    • फिर भी, मेरा मानना है कि यह role भविष्य के leaders को तैयार करने का मुख्य चरण है

    • जब मैं युवा था, तो process मुझे झंझट लगते थे, लेकिन अब मैं guardrails की अहमियत समझता हूँ

      • अब मेरा focus automation और tooling के ज़रिए efficiency बढ़ाने पर है
    • मुझे लगता है कि अगर polymath team structure हो, जिसमें engineer, designer और PM साथ हों, तो evaluation ज़्यादा साफ़ हो सकती है

    • EM role की आलोचना इसलिए होती है क्योंकि कुछ लोग छोटे साम्राज्य के तानाशाह बन जाते हैं

  • बेहतरीन performer की सबसे बड़ी पहचान अनुकूलन क्षमता है

    • trends बदलते रहें, फिर भी जो व्यक्ति स्थिति और लोगों के हिसाब से अपना approach बदलता है, वही आखिर में सफल होता है

    • कभी-कभी असली output खुद खुशहाल टीम ही होती है

  • leadership 15 साल के trends से परे एक कालातीत विषय है

    • अमेरिकी सेना की परिभाषा के अनुसार leadership वह प्रक्रिया है, जिसमें purpose, direction और motivation के ज़रिए organization को बेहतर बनाया जाता है

    • लेकिन सेना के उदाहरण से दो बातें सीखने लायक हैं

      1. अगर पर्याप्त resources और समय हो, तो पूर्ण अनुशासन और स्वायत्त निर्णय दोनों को साथ रखा जा सकता है
      2. अगर ‘officer vs soldier’ जैसी hierarchy बना दी जाए, तो incentive mismatch के कारण goal हासिल करना मुश्किल हो जाता है
  • अच्छी engineering management का कोई वस्तुनिष्ठ मानदंड नहीं है

    • इसे organization की culture और habits के भीतर, context के अनुसार परिभाषित करना पड़ता है

    • ‘अच्छे manager’ का मानदंड organization के अंदर-बाहर की परिस्थितियों के साथ बदलता है

      • mass hiring के दौर में अलग होगा, और mass layoff के दौर में अलग
      • AI tools के युग में अच्छा manager कैसा दिखेगा, यह समझने में शायद अभी 5 साल और लगेंगे
    • policy का implementation ही असल में policy है

      • अगर policy lean staffing की हो, तो अच्छा manager वह है जो attrition रोकने में माहिर हो
  • leadership की कोई absolute definition नहीं है, लेकिन relative definition ज़रूर है

    • goals के साथ alignment की मात्रा ही मुख्य बात है, और उन goals को साफ़-साफ़ जानना ही सबसे मुश्किल काम है
  • आजकल बहुत-सी कंपनियाँ middle management कम करने की कोशिश कर रही हैं, लेकिन management function अब भी ज़रूरी है

    • वरना direction बिखर जाती है

    • अच्छा manager manual से नहीं, बल्कि स्थिति-निर्णय क्षमता से काम करता है

    • लेकिन ऐसे लेख पढ़कर पुराना PTSD याद आ जाता है

  • senior management के साथ रिश्ते में EM की सबसे अहम क्षमता alignment है

    • अगर Product Management कमज़ोर हो, तो EM कितना भी शानदार हो, पूरी organization डगमगा जाती है
    • आखिर में product team के साथ alignment ही सब कुछ तय करता है
  • हर skill आख़िरकार empathy पर जाकर टिकती है

    • alignment असल में empathy का ही दूसरा रूप है

    • मैं भी जब किसी को persuade करना चाहता हूँ, तो पहले ध्यान से सुनने और empathy से शुरुआत करता हूँ

      • उसके बाद ही proposal को स्वीकार किए जाने की जगह बनती है
    • लेकिन सिर्फ empathy काफ़ी नहीं; कभी-कभी नापसंद किए जाने का साहस भी चाहिए

      • अगर empathy ज़्यादा हो जाए, तो conflict की स्थिति में कोई फैसला ही नहीं हो पाता
    • empathy की अहमियत से मैं सहमत हूँ, लेकिन हक़ीक़त में चिल्लाकर बात मनवाने वाले leader भी होते हैं

      • ऐसे दृश्य देखकर लगता है कि सिर्फ empathy से organization नहीं चलती