Staff Engineer बनाम Engineering Manager

 (blog.alexewerlof.com)
31 पॉइंट द्वारा xguru 2025-04-08 | 4 टिप्पणियां | WhatsApp पर शेयर करें
  • Staff Engineer की ज़रूरत कब पड़ती है, और Engineering Manager से यह कैसे अलग है?
    • कई engineers और managers इन दोनों roles को लेकर भ्रमित रहते हैं
  • जो EM people management से बचकर tech पर फोकस करना चाहते हैं, या जो Senior Engineer technical leadership लेना चाहते हैं, वे अक्सर इस पर विचार करते हैं
  • हर role की responsibility और scope को स्पष्ट रूप से समझना महत्वपूर्ण है

मुझसे पूछे गए सवाल

  • EM: "मैं people management के बजाय tech पर फोकस करना चाहता हूँ। क्या Staff Engineer role मेरे लिए सही रहेगा?"
  • Senior EM: "Management का काम बहुत ज़्यादा हो गया है। क्या मुझे technical काम सँभालने के लिए Staff Engineer hire करना चाहिए?"
  • Staff Engineer: "मैं व्यवहार में team manager की तरह काम कर रहा हूँ, और मुझे यह पसंद भी है। क्या मुझे EM में switch कर लेना चाहिए?"
  • Senior Engineer: "Staff Engineer की responsibilities क्या होती हैं? यह तो किसी retired developer जैसा लगता है।"
  • New Staff Engineer: "‘dotted reporting lines’ क्या होती हैं? मेरा एक line manager है, तो क्या मुझे किसी दूसरे manager की भी चिंता करनी चाहिए?"

Staff Engineer की ज़रूरत कब होती है?

  • Engineers tech बनाते और maintain करते हैं, लेकिन tech अपने आप में अकेली मौजूद नहीं होती
  • यह किसी समस्या का solution होती है, और समस्या को product के रूप में परिभाषित किया जाता है
  • Product अंतिम उपयोगकर्ता या internal customer को service देता है
  • Product उपयोगकर्ता की समस्या हल करने का साधन है, जैसे:
    • दौड़ने की दूरी मापने और दूसरे users के साथ share करने वाला app
    • hotel booking website
    • दूसरी teams द्वारा इस्तेमाल किया जाने वाला infrastructure platform
    • attendance reporting system
  • ऐसे products बनाने वाले engineers आम तौर पर Engineering Manager(EM) द्वारा lead की जाने वाली team का हिस्सा होते हैं
  • EM, team members (engineers) और उनके द्वारा बनाए गए technical artifacts के लिए accountability रखते हैं
  • लेकिन नीचे जैसी स्थितियों में, यह सारी responsibility पूरी तरह निभाना मुश्किल हो जाता है:
    • जब team बहुत बड़ी हो
    • जब tech बहुत complex हो
    • या जब दोनों बातें एक साथ मौजूद हों
  • ऐसे में EM के पास समय और ऊर्जा (bandwidth) कम पड़ने लगती है, और लोगों तथा tech दोनों के लिए पूरी accountability निभाना कठिन हो जाता है
  • अगर EM के लिए सारी accountability निभाना मुश्किल हो, तो delegation की दो strategies पर विचार किया जा सकता है:
    • administrative work delegation:
      • HR processes और tools को optimize करके
      • या assistant hire करके people management का बोझ कम किया जा सकता है
      • एक team के लिए dedicated assistant रखना ज़्यादा लग सकता है, लेकिन कई teams द्वारा एक assistant share करने के उदाहरण भी हैं
      • AI tools का उपयोग scheduling, management से जुड़े सवालों के जवाब, feedback collection जैसे mechanical tasks को आंशिक रूप से replace करने के लिए किया जा सकता है
      • अच्छे HR systems management का बोझ बहुत कम कर सकते हैं
    • technical work delegation:
      • Staff Engineer hire करके technical बोझ साझा किया जा सकता है
  • लेकिन assistant या AI, EM की core responsibilities वाले नीचे जैसे people-centered work की जगह नहीं ले सकते:
    • अच्छी team बनाना
    • mentoring
    • performance reviews
    • hiring आदि
  • दूसरी ओर, पूरा technical काम Staff Engineer को सौंप देना एक anti-pattern माना जाता है
    • Staff Engineer को EM का technical translator नहीं बनना चाहिए
    • EM को technical responsibility में भी एक निश्चित स्तर बनाए रखना चाहिए
  • इसलिए Engineering Manager के लिए technical sense बनाए रखना अनिवार्य है, और

वे स्थितियाँ जहाँ Staff Engineer उपयोगी होता है

  • नीचे जैसी स्थितियों में Staff Engineer संगठन को वास्तविक value दे सकता है:
    • जब EM के लिए technical load संभालना मुश्किल हो
      • उदाहरण: legacy tech बहुत हो और लगातार maintenance की ज़रूरत हो
      • जब complex solutions कई teams में फैले हों या deep technical knowledge की ज़रूरत हो
      • (यह recommended pattern नहीं है, फिर भी) कभी-कभी EM खुद technical नहीं होता
    • जब technical work के किसी हिस्से के लिए स्पष्ट accountability दी जा सके
    • जब tech का scope एक EM की management capacity से बाहर चला जाए
  • Staff Engineer को लोगों नहीं, बल्कि tech के लिए accountable होना चाहिए
    • इसमें team member management या performance review जैसी responsibilities शामिल नहीं होतीं
  • हर organization, product और लोग अलग होते हैं, इसलिए हर situation पर एक universal rule लागू नहीं किया जा सकता
  • संदर्भ: responsibility और accountability में सूक्ष्म अंतर है,
  • Staff Engineer में नीचे जैसी विशेषताएँ होनी चाहिए:
    • tech की गहरी समझ और उच्च technical literacy
    • स्पष्ट technical accountability
    • people management responsibility न होने के कारण tech में निवेश करने के लिए अधिक समय
  • वहीं, EM को भी technical responsibility से पूरी तरह अलग नहीं होना चाहिए
    • उसे अब भी tech में कुछ स्तर तक शामिल रहना और समझ बनाए रखना चाहिए
  • Staff Engineer की असली value कई teams में फैली technical leadership से आती है
  • अगर किसी एक team के भीतर Staff Engineer रखा जाए, तो नीचे जैसी समस्याएँ आ सकती हैं:
    • technical accountability overlap हो जाती है
    • role confusion पैदा होता है, और अंत में एक ही role को कई titles में बाँटने जैसी inefficiency बनती है

अपवादस्वरूप team-level पर काम करने की स्थितियाँ

  • आम तौर पर Staff Engineer cross-team technical leadership पर फोकस करता है, लेकिन नीचे जैसी स्थितियों में team-level पर अस्थायी रूप से काम करना संभव है:
    • जब नया EM legacy tech stack को जल्दी समझना चाहता हो
    • जब नया Staff Engineer छोटे scope से onboarding शुरू कर रहा हो
    • जब technical debt बहुत अधिक हो और system health metrics खराब हो गए हों
    • जब technical complexity के कारण maintenance मुश्किल हो
  • ऐसी स्थिति में team-level Staff Engineer एक temporary arrangement होना चाहिए

  • Staff Engineer की असली value

    • teams के बीच glue की भूमिका निभाना
    • दूसरे engineers के साथ मैदान में काम करते हुए, उनकी आवाज़ को leadership तक पहुँचाना
      • आम तौर पर engineers, salary, छुट्टी या evaluation authority रखने वाले व्यक्ति की तुलना में साथी engineers से अधिक ईमानदारी से बात करते हैं
    • गहरी technical leadership देना
      • EM की तुलना में meetings, 1:1s और management work कम होने से, engineering capability और technical depth बढ़ाने पर अधिक फोकस किया जा सकता है

  • सबसे बड़ा risk factor: Ivory Tower Architect

    • वास्तविक समस्याओं या code से दूर हो चुका abstract theorist बन जाना
    • इस समस्या पर Ivory Tower Architect में विस्तार से चर्चा है

कई teams में फैले systems के लिए Staff Engineer की भूमिका

  • Staff Engineer, किसी एक team के बजाय पूरे system को कवर करने वाली technical leadership के लिए सबसे उपयुक्त है
  • Will Larson के essay में Staff Engineer के 4 archetypes बताए गए हैं:
    • Tech Lead: team के भीतर technical leader
    • Architect: system architecture designer
    • Solver: complex technical problems का solver
    • Right Hand: technical organization के leader का दायाँ हाथ
  • diagram में दिखाए गए team-level Tech Lead को Staff Engineer कहना थोड़ा कठिन है
    • वास्तविक Staff Engineer की value cross-team coordination और technical integration से आती है
    • Introduction to Staff Engineering देखें
      • Staff Engineer सिर्फ एक title नहीं, बल्कि technical leadership पर आधारित एक mindset है
      • यह role कई teams और products में technical coordination और problem-solving संभालता है
      • लोगों या product पर formal authority के बिना भी influence डालता है, और पूरे organization की technical strategy और direction को आगे बढ़ाता है
      • Engineering Manager से अलग, यह management से अधिक deep technical expertise और cross-org collaboration के माध्यम से value create करता है
      • यह hands-on रहकर actual work में शामिल होता है, और दूसरे engineers की growth में mentor की भूमिका भी निभाता है
  • वास्तविक organizations में technical systems किसी एक team तक सीमित नहीं होते, बल्कि कई teams में फैle होते हैं या teams के बीच गहराई से जुड़े होते हैं
    • ऐसे मामलों में पूरे system की responsibility लेने वाले dedicated Staff Engineer की ज़रूरत होती है
    • हर team कौन-सा हिस्सा संभाल रही है, इससे अलग पूरे system को देखने का नज़रिया और accountability ज़रूरी है

Staff Engineer को सिर्फ tech नहीं, लोगों और product से भी होकर गुजरना पड़ता है

  • मुख्य बिंदु: tech अपने आप किसी से बात नहीं करती और न किसी की सुनती है
    • tech अकेले मौजूद नहीं रह सकती; उसका अर्थ लोगों (engineers) और product (problem) के माध्यम से बनता है
  • Staff Engineer को वास्तविक value देने के लिए नीचे की चीज़ों से होकर गुजरना ही पड़ता है:
    • engineers के साथ collaboration
    • product team के साथ alignment
  • इसी वजह से Staff Engineer के पास dotted reporting lines होती हैं
    • यह formal न होते हुए भी महत्वपूर्ण cross-org collaboration और commitments की कड़ी है
  • कुछ ध्यान से देखने वाले लोग पूछते हैं कि Staff से नीचे की ओर arrows क्यों जाती हैं
    • कारण 1: अच्छी leadership authority पर नहीं, collaboration पर आधारित होती है
      • Staff Engineer, team-level EM या PM को technical improvements के लिए requests collaborative तरीके से देता है
      • यह एकतरफ़ा आदेश नहीं, बल्कि engineers और product roadmap दोनों को ध्यान में रखकर किया गया सहयोग होना चाहिए
    • कारण 2: Staff Engineer एक IC (Individual Contributor) होता है, इसलिए उसके formal direct reports नहीं होते
      • अगर EM/PM के साथ regular conversation channel हो, तो वह सिर्फ reporting के लिए नहीं, बल्कि:
        • tech की वर्तमान स्थिति (status quo)
        • product problems हल करने के लिए technical vision
        • उसके लिए organizational technical strategy
        • इन तीनों पर दो-तरफ़ा बातचीत के लिए आदर्श होना चाहिए
  • ऐसी उलझी reporting structures को व्यवस्थित करने और teams के बीच technical/product alignment में मदद के लिए
    • company-wide strategy document बहुत उपयोगी होता है
    • इसकी बुनियाद Strategy basics में देखी जा सकती है

      • Diagnosis

        • problem space की जाँच के बाद, हल की जाने वाली मुख्य issues और उनके कारण पहचाने जाते हैं
        • strategy की ज़रूरत क्यों है, यह समझाया जाता है
        • symptoms और root causes की पहचान कर यह विश्लेषण किया जाता है कि वे अभी क्यों महत्वपूर्ण हैं
        • खराब strategies में यह हिस्सा अक्सर छोड़ दिया जाता है या सिर्फ current state का वर्णन किया जाता है
        • अच्छी diagnosis के लिए objective investigation और detective जैसी सोच चाहिए

      • Guiding Policy

        • पहचानी गई समस्याओं को हल करने के लिए high-level approach
        • यह solution पर फोकस करती है और पूरे organization को align करती है
        • हर tactical detail पर बार-बार सोचने की ज़रूरत के बिना दिशा देती है
        • खराब strategy में इस policy (HOW) और diagnosis (WHY) के बीच संबंध नहीं होता

      • Coherent Actions

        • policy के अनुसार diagnosis में पहचानी गई समस्याओं को हल करने के लिए concrete action plan
        • कौन (WHO), क्या (WHAT), और कब (WHEN) करेगा, यह स्पष्ट करती है
        • यहाँ सबसे महत्वपूर्ण चीज़ consistency है, ताकि अलग-अलग teams मिलकर एक ही दिशा में बढ़ें

tech scope को एक team तक सीमित करने का दूसरा तरीका: Kebab vs Cake model

  • organization structure को इस तरह design किया जा सकता है कि tech कई teams में फैले बिना एक team के भीतर ही solve हो
  • इसका एक प्रमुख तरीका है Kebab vs Cake model
    • consumer journey के आधार पर teams बनाकर, technical accountability का scope कम करने वाला structural approach
    • इस model का विस्तृत विवरण Kebab vs Cake organization में देखें

    • Kebab architecture

      • teams, delivered capabilities के आधार पर बनती हैं
      • user journey कई teams के artifacts से होकर गुजरती है
      • फायदा: autonomy और loose coupling
      • नुकसान: handoff होने का risk

    • Cake architecture

      • teams, user journey के आधार पर बनती हैं
      • abstraction layers के माध्यम से cognitive load manage किया जाता है
      • फायदा: end-to-end ownership और कम handoffs
      • नुकसान: cognitive load बढ़ने का risk
  • Staff Engineer सिर्फ एक technical role नहीं, बल्कि पूरे system की accountability लेने वाला owner होता है, और उसमें ये 3 चीज़ें होनी चाहिए:
    • Knowledge:
      • tech stack और product problem की गहरी समझ
      • ज़रूरत पड़ने पर उसे समझा भी सके और खुद implement भी कर सके
    • Mandate:
      • tech कैसे evolve और maintain होगी, इस पर राय देने की स्थिति
    • Responsibility:
      • system health (outages, technical debt, documentation, technical disconnects आदि) के लिए responsibility
  • Staff Engineer सिर्फ technical role नहीं है, और organization को technical दिशा देने में soft skills अनिवार्य हैं
    • influential communication, collaboration ability, leadership आदि की ज़रूरत होती है
  • लेकिन अगर soft skills पर ही ज़रूरत से ज़्यादा ज़ोर दिया जाए, तो नीचे जैसी समस्या हो सकती है:
    • वास्तविकता से कटी हुई आदर्शवादी बातें करना, पर actual coding या problem-solving में शामिल न होना
    • और इस तरह Ivory Tower Architect बनने का खतरा

निष्कर्ष

  • हर organization को Staff Engineer की ज़रूरत हो, ऐसा नहीं है। नीचे जैसी स्थितियों में इसके बिना भी काम चल सकता है:
    • जब EM पर्याप्त technical capability रखता हो और team की tech को सीधे lead कर सकता हो
    • जब tech stack स्वस्थ और maintain करने में आसान हो
    • जब tech एक ही team के भीतर पूरी हो जाती हो, और teams के बीच dependencies बहुत कम हों (Cake organization model इसका एक उदाहरण है)
    • जब organization इतनी mature हो कि किसी specific owner के बिना भी पूरे system को अच्छे से चला सके
  • इसके उलट, अगर organization में Staff Engineer है, तो नीचे की बातें स्पष्ट होनी चाहिए:
    • technical ownership स्पष्ट रूप से तय हो
    • और उस responsibility के लिए Staff Engineer को स्पष्ट accountability दी जाए
  • मुख्य निष्कर्ष:
    • Ivory Tower Architect से बचना चाहिए (यह व्यावहारिक नहीं है)
    • एक role को कई titles में बाँटना inefficient है
    • non-technical EM भी inefficient होता है
  • अंत में, यह लेख कोई absolute rule नहीं, बल्कि संदर्भ के लिए essay है
    • organizations, tech, product, operations और लोग सभी अलग होते हैं, इसलिए स्थिति के अनुसार लचीला निर्णय महत्वपूर्ण है
    • अंधानुकरण (cargo culting) से बचें → संबंधित लेख देखें

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

4 टिप्पणियां

 
kuthia 2025-04-09

लगता है वे CTO के हाथ-पैर जैसे हैं
 
bus710 2025-04-09

स्टाफ इंजीनियर: बहुत कोशिश करने के बाद भी जब काम न बने, तो परेशान करने के लिए जिसके पास जाया जाए।
 
bobross0 2025-04-10

अरे हाहाहा, पूरी तरह relatable है
 
ethanhur 2025-04-08

लेख की सामग्री से बहुत ज़्यादा संबंधित नहीं है, लेकिन मैं accountability और responsibility के बारे में सोच रहा था, इसलिए नीचे दिया गया लिंक मेरे लिए काफ़ी मददगार रहा।

https://blog.alexewerlof.com/p/accountable-vs-responsible