इंजीनियरों का job switch रोकने के लिए आर्थिक हस्तक्षेप के तरीके

• सीनियर इंजीनियरों के छोड़कर जाने की समस्या information flow की नहीं, बल्कि management incentive structure की समस्या है, और तिमाही performance के लिए optimized compensation system लंबे समय के investment मांगने वाले talent retention से बुनियादी तौर पर टकराता है
• एक सीनियर इंजीनियर के जाने पर कुल लागत 5 लाख से 10 लाख डॉलर तक पहुंच सकती है, लेकिन hiring cost, vacancy cost, onboarding, और tribal knowledge के loss जैसी चीजें अलग-अलग budgets में बंटी होने के कारण दिखाई नहीं देतीं
• 14 महीने पहले दी गई चेतावनी को नज़रअंदाज़ करने वाली एक payment processing कंपनी ने Black Friday पर 34.7 लाख डॉलर का नुकसान उठाया, जबकि मूल fix cost केवल 80,000 डॉलर थी
• 6 structural interventions (attrition cost accounting, incident tracking, executive on-call, compensation में retention rate को शामिल करना, technical advisory board, IC track के लिए समान compensation) को incentives को फिर से align करने वाले समाधान के रूप में पेश किया गया है
• ये interventions तभी असरदार होते हैं जब management retention को एक economic problem के रूप में पहचाने और structural change स्वीकार करने की इच्छा रखे; औपचारिक या सतही implementation उल्टा नुकसान पहुंचा सकता है

---

जानकारी बहने पर भी व्यवहार क्यों नहीं बदलता

> "The constraint is not information flow. It is economics."

• यह लेख इंजीनियर attrition पर आधारित श्रृंखला का दूसरा भाग है, और पहले भाग आपके सर्वश्रेष्ठ इंजीनियर कहीं और interview क्यों दे रहे हैं में उठाई गई information asymmetry की समस्या के बाद की स्थिति को आगे बढ़ाता है
• पहले भाग में बताया गया था कि सीनियर इंजीनियर क्यों छोड़कर जाते हैं, और मुख्य कारण यह था कि समस्या मौजूद होने पर भी management तक पहुंचने वाली संरचना ही नहीं होती
• लेकिन यह लेख उस मान्यता को एक कदम आगे ले जाता है
  • यह देखता है कि जब information flow को वास्तव में बेहतर किया जाता है तब क्या होता है
  • निष्कर्ष यह है कि intuition के विपरीत, ज़्यादातर मामलों में कुछ भी नहीं बदलता
• संगठन समस्या को पहचानने के लिए कई तंत्र अपनाते हैं
  • skip-level 1:1 meetings शुरू करना
  • anonymous feedback channels चलाना
  • बाहरी consultants के जरिए retention survey कराना
• इसके बाद इंजीनियर समस्याओं को बहुत स्पष्ट तरीके से बताते हैं
  • technical debt morale को खा रही है
  • architecture decisions में expertise को नज़रअंदाज़ किया जा रहा है
  • on-call का बोझ sustainable स्तर से बाहर है
• management यह सब सुनकर सिर हिलाता है
  • समस्या को मानता है
  • priority बदलने की बात करता है
• लेकिन जैसे ही अगली तिमाही आती है, decision-making फिर पहले जैसी ही दोहराई जाती है
  • उसी तरीके से quarterly goals हासिल किए जाते हैं
  • और उस तरीके का मतलब है अभी-अभी सुनी गई समस्याओं को फिर से नज़रअंदाज़ करना
• इसी बिंदु पर लेख अपनी मुख्य बात साफ करता है
  • समस्या जानकारी की कमी नहीं है
  • समस्या है economic structure, यानी incentive design

असली समस्या: executives की incentive structure

• VP of Engineering के सामने अक्टूबर में आने वाली decision calculation का उदाहरण
  • तिमाही performance review में 3 महीने बाकी हैं, और एक इंजीनियर के stock vesting में 6 महीने बाकी हैं
• एक सीनियर platform engineer यह अनुरोध करता है
  • authentication system को 6 हफ्तों के लिए refactor करना चाहता है
  • technical debt जमा हो चुकी है और संरचना कमजोर हो गई है
  • दो security researchers पहले ही risk signal दे चुके हैं
• लेकिन मौजूदा स्थिति अस्पष्ट है
  • कोई वास्तविक outage नहीं है, कोई customer complaint नहीं है, और revenue impact भी नहीं है
  • मौजूद है तो सिर्फ इंजीनियर की चेतावनी कि “अभी नहीं सुधारा तो यह संकट बन जाएगा”
• VP के पास दो विकल्प हैं
  • विकल्प A: refactoring को मंज़ूरी देना
    • 6 हफ्तों तक feature development की गति में कमी स्वीकार करना
    • quarterly OKR miss होने की संभावना बनना
    • CEO को समझाना कि “customer को दिखाई न देने वाले technical काम” की वजह से roadmap क्यों delay हुआ
    • sales team द्वारा पहले से commit की गई feature launch timeline के हिलने का जोखिम
    • नतीजतन साल के अंत के bonus पर सीधा नकारात्मक असर पड़ने की संभावना
    • इस विकल्प का reward 12 से 18 महीने बाद मिलता है: वह सीनियर इंजीनियर इस कारण संगठन में बना रहता है कि “technical judgment का सम्मान किया जाता है”
  • विकल्प B: feature-first फैसला
    • technical debt को “महत्वपूर्ण” मानते हुए भी उसे “अगली तिमाही” तक टाल देना
    • तय roadmap को वैसे ही ship करके OKR हासिल करना और bonus लेना
    • सीनियर इंजीनियर फिलहाल बना रहता है, क्योंकि उसके stock options अभी vest नहीं हुए हैं
    • authentication system बाद में फटता है तो वह भविष्य की तिमाही की समस्या होगी
    • अगर इंजीनियर 6 महीने बाद चला भी जाए, तो hiring से replace किया जा सकता है — ऐसा मान लिया जाता है
• इस संरचना में विकल्प B हमेशा जीतता है - जब तक कि चीज़ें सचमुच विफल न हो जाएं
  • product launch के दौरान core system outage होता है, 18 महीनों में 5 सीनियर इंजीनियर छोड़कर चले जाते हैं, और CFO पूछना शुरू करता है कि “हम re-hiring cost पर हर साल 14 लाख डॉलर क्यों खर्च कर रहे हैं” — तब तक B ही जीतता है
• क्योंकि यह मूलभूत mismatch है
  • executive compensation structure quarterly performance के लिए optimized है
  • लेकिन engineer retention और technical debt कम करना long-term investment मांगता है
  • सिर्फ information flow सुधारने से यह gap नहीं भर सकता
  • समाधान है economic structure को ही फिर से design करना

Why the Math Favors Dysfunction - गणित बताता है कि विफलता लगभग तय है

• छिपी हुई लागतें अदृश्य तरीकों से काम करती हैं, जिससे तार्किक लोग भी अतार्किक व्यवहार करने लगते हैं

• सालाना $200,000 कमाने वाले 1 सीनियर इंजीनियर के जाने पर वास्तविक कुल लागत $500,000 ~ $1,000,000 या उससे अधिक मानी जाती है

  • अधिकांश executives यह संख्या सुनकर इसे बढ़ा-चढ़ाकर बताई गई मानते हैं, लेकिन ऐसा नहीं है। इसकी गणना इस प्रकार की जाती है

• प्रत्यक्ष replacement लागत: $85,000-$100,000

  • hiring fee: बाहरी recruiter fee 20-25% होने पर $200,000 वाले इंजीनियर के लिए $40,000-$50,000
    • अगर internal hiring (job board, sourcing tools, recruiter salary) से खुद किया जाए तो $15,000-$20,000
  • signing bonus: प्रतिस्पर्धी market में सीनियर candidates को लाने के लिए $20,000-$40,000 चाहिए
    • खासकर जब वे अपनी मौजूदा कंपनी में equity छोड़कर आ रहे हों, तब यह लगभग अनिवार्य होता है
  • relocation लागत: घरेलू relocation हो तो $10,000-$30,000, international relocation इससे अधिक

• vacancy लागत: $50,000-$100,000

  • सीनियर इंजीनियर को hire करने में औसतन 3-6 महीने लगते हैं
  • vacancy अवधि में उस इंजीनियर का काम रुकता नहीं है, बल्कि एक साथ दो तरह की लागतें पैदा होती हैं
    • एक, काम के redistribution से team productivity घटती है, और दूसरी, काम छोड़ देने से opportunity cost पैदा होती है
  • काम redistribution लागत $25,000-$40,000:
    • जाने वाले इंजीनियर के लगभग 60% काम को बाकी team members में बाँटा जाता है
    • यह resources का मुक्त पुनर्वितरण नहीं, बल्कि productivity में गिरावट बन जाता है
    • जिन इंजीनियरों का workload पहले से ही भरा हुआ है, उन्हें अब अनजाने क्षेत्रों के code review करने होते हैं, उन systems पर सवालों के जवाब देने होते हैं जिन्हें उन्होंने खुद नहीं बनाया, और उन services को maintain करना पड़ता है जिन्हें वे पूरी तरह समझते भी नहीं
    • अगर 3 इंजीनियर 20% अतिरिक्त काम absorb करें, तो वे सिर्फ 20% ज्यादा काम नहीं कर रहे होते, बल्कि context switching से उनकी overall efficiency घटती है
    • vacancy अवधि में प्रति इंजीनियर 10-15% productivity loss होता है
    • काम redistribution लागत की गणना
      • काम absorb करने वाले इंजीनियरों की संख्या × productivity में कमी की दर × vacancy अवधि (महीने) × (औसत वार्षिक वेतन / 12)
      • एक सामान्य scenario में 3 इंजीनियर × 12% productivity loss × 4 महीने × ($180,000 / 12) = $21,600
      • अगर जाने वाला इंजीनियर infra, security, platform जैसे उच्च विशेषज्ञता वाले क्षेत्र संभालता था, तो यह $30,000–$40,000 तक बढ़ सकता है
  • काम छोड़ने की लागत $25,000-$60,000:
    • बाकी 40% काम redistribute नहीं होता, बल्कि टल जाता है या पूरी तरह छोड़ दिया जाता है
    • platform improvements, technical debt कम करना, architecture evolution, documentation, mentoring जैसे काम feature release से सीधे जुड़े नहीं होते, लेकिन भविष्य के संकट रोकने के लिए जरूरी होते हैं, और इन्हें चुपचाप roadmap से हटा दिया जाता है
    • work abandonment की तत्काल लागत उस काम के salary-equivalent value से निकाली जाती है जो किया ही नहीं गया
      • जाने वाले इंजीनियर के काम का 40% vacancy अवधि के दौरान किया नहीं जाता
      • गणना: 40% × 4 महीने × ($200,000 / 12) = $26,667
    • लेकिन असली लागत यहीं तुरंत खत्म नहीं होती
      • टाला गया काम बाद की तिमाहियों में संचित लागत पैदा करता है
      • उदाहरण के लिए
        • अगर सीनियर infra इंजीनियर द्वारा योजनाबद्ध database optimization टल जाए
          • query performance धीरे-धीरे खराब होती जाती है
          • और अंततः मूल काम के दायरे से कहीं बड़ी emergency response की जरूरत पड़ती है
        • अगर उस इंजीनियर की architecture review रुक जाए
          • तो महँगी गलतियों को पहले से पकड़ लेने वाली expertise के बिना
          • technical decisions लिए जाते हैं
    • मापी जा सकने वाली work abandonment लागत है
      • “वह काम जो मूल रूप से होना चाहिए था लेकिन हुआ नहीं” का value
      • इसका conservative formula यह है
        • (छोड़े गए काम का अनुपात × वार्षिक वेतन / 12) × vacancy के महीने
        • (40% × $200,000 / 12) × 4 महीने = $26,667
    • वास्तविक work abandonment लागत का दायरा $25,000–$60,000
      • यह इस बात पर निर्भर करता है कि छोड़ा गया काम preventive था या feature-centric
  • कुल vacancy लागत (Combined Vacancy Cost): $50,000–$100,000
    • यह काम redistribution लागत $25,000–$40,000 और work abandonment लागत $25,000–$60,000 को जोड़ने का परिणाम है
    • यह सिर्फ 4 महीने तक पद खाली रहने की स्थिति में होने वाले प्रत्यक्ष और मापने योग्य प्रभावों को दर्शाता है
  • यह गणना स्वयं conservative रखी गई है

• onboarding और adaptation लागत: $100,000-$125,000

  • नए सीनियर इंजीनियर की productivity: पहले महीने लगभग 25%, 2-3 महीने में 50%, 4-5 महीने में 75%, और 6वें महीने में full productivity
    • पहला महीना: productivity में 75% loss = ($200,000 / 12 महीने) × 0.75 = $12,500
    • 2~3 महीना: productivity में 50% loss = ($200,000 / 12 महीने) × 0.50 × 2 = $16,667
    • 4~5 महीना: productivity में 25% loss = ($200,000 / 12 महीने) × 0.25 × 2 = $8,333
    • पहले 6 महीनों का कुल productivity gap: $37,500
  • onboarding staff लागत: नए सीनियर इंजीनियर के लिए पहले महीने प्रति सप्ताह 10-15 घंटे, और 2-3 महीने में प्रति सप्ताह 5-8 घंटे अन्य इंजीनियरों का समय खर्च होता है
    • पहला महीना: 12 घंटे/सप्ताह × 4 सप्ताह × $90 प्रति घंटा = $4,320
    • 2~3 महीना: 6 घंटे/सप्ताह × 8 सप्ताह × $90 प्रति घंटा = $4,320
    • $90 प्रति घंटा के आधार पर onboarding staff लागत: $8,640
  • यानी पहले 6 महीनों में $46,140 का नुकसान होता है
  • लेकिन अधिकांश सीनियर इंजीनियरों को पिछले इंजीनियर के स्तर की domain expertise तक पहुँचने में लगभग 1 साल लगता है, इसलिए $92,000-$125,000 का अनुमान लगाया जाता है

• Tribal Knowledge की हानि: $100,000-$300,000

  • इसे quantify करना सबसे कठिन है, लेकिन बाद की तिमाहियों में यह गलतियों के रूप में सामने आती है
  • जाने वाला इंजीनियर जिन बातों को जानता था:
    • codebase के कौन से हिस्से नाजुक हैं और जिनमें बदलाव बहुत सावधानी से करना चाहिए
    • किन customers की विशेष requirements थीं और क्यों
    • कौन से architectural decisions जानबूझकर किए गए trade-offs थे और कौन से technical debt
    • 10,000-line service में वास्तव में महत्वपूर्ण 3 lines of code
    • कोई खास database query देखने में inefficient क्यों लगती है, लेकिन उसे वैसे ही क्यों लिखा गया था (3 साल पहले मिली एक खास condition में “स्पष्ट” optimization ने data corruption कर दिया था)
  • context की कमी से होने वाली गलतियाँ: नया इंजीनियर “slow” query को optimize करते हुए कंपनी के 2 सबसे बड़े ग्राहकों के core workflow को रोक देता है
    • समस्या पहचानने में 2 दिन ($4,615), सही fix लागू करने में 1 सप्ताह ($7,692), customer relationship recovery
    • एक single incident की लागत लगभग $12,000-$15,000, और पहले साल में हर departing सीनियर इंजीनियर पर 3-5 बार ऐसी घटनाएँ
  • decision delay: जिस सवाल का जवाब जाने वाला इंजीनियर 30 सेकंड में दे देता, उसके लिए अब 3 घंटे की code archaeology, Slack history search, और “क्या किसी को पता है ऐसा क्यों किया था?” जैसी बातचीत चाहिए
    • अगर यह 6 महीनों तक सप्ताह में 2 बार हो: $14,040
  • टले या छोड़े गए projects: सिर्फ जाने वाला इंजीनियर authentication system को इतना समझता था कि SSO integration सुरक्षित रूप से implement कर सके
    • वह project 6-9 महीने टल जाता है, और अगर SSO किसी $500,000 enterprise contract के लिए जरूरी था, तो देरी की लागत मापी जा सकती है
  • इस तरह के internal knowledge loss का conservative estimate: इस्तीफे के बाद 12 महीनों में $100,000 से $300,000 तक

• प्रति engineer attrition कुल लागत

  • प्रत्यक्ष replacement: $85,000-$100,000
  • vacancy लागत: $50,000-$100,000
  • adaptation और onboarding: $92,000-$125,000
  • internal knowledge loss: $100,000-$300,000
  • conservative total: $327,000-$625,000
  • project delay और opportunity cost सहित वास्तविक total: $500,000-$1,000,000

• ये लागतें पूरे बजट में बिखर जाती हैं और शोर में छिप जाती हैं: hiring cost HR बजट में चली जाती है, productivity loss ट्रैक नहीं होता, और internal knowledge का खत्म होना quarterly report में दिखता ही नहीं

  • technical debt को टालना और feature prioritization के फैसले तुरंत और दिखने वाले नतीजे पैदा करते हैं: sales team demo, marketing launch announcement, और CEO की board report जैसी चीजें
  • अर्थशास्त्री इसे "उबलते मेंढक" की समस्या कहते हैं:
    • किसी एक कर्मचारी का जाना संभालने लायक लगता है, technical work को टालना तर्कसंगत लगता है, और quarterly trade-off भी अलग-अलग देखने पर जायज़ लगता है
    • जब तक पैटर्न साफ़ दिखने लगता है (जैसे सालाना senior engineer attrition rate 18%, जमा हुआ technical debt, और लगातार system outage), तब तक संगठन दुर्व्यवस्था को पहले ही सामान्य मानने लगता है

रिकवरी (Recovery) कैसी दिखती है

• Black Friday आपदा से 14 महीने पहले, एक mid-sized payment processing कंपनी के senior platform engineer ने ठोस चिंताएँ उठाईं
  • “transaction processing system अपेक्षित holiday traffic संभाल नहीं पाएगा”
  • database sharding और queue optimization की ज़रूरत पर विस्तृत प्रस्ताव जमा किया: 6 हफ्ते का engineering time, infrastructure cost $80,000 अनुमानित
• VP of Product ने इसे कम प्राथमिकता दे दी:
  • यह माना गया कि दो अन्य feature launches अधिक महत्वपूर्ण हैं
  • quarterly review में “संभावित समस्याओं को पहले से पहचानने की क्षमता” की प्रशंसा की गई, लेकिन architecture proposal Jira में पड़ा रह गया
• उस engineer ने 4 महीने बाद 15% salary hike लेकर competitor जॉइन कर लिया, 3 महीने की खोज और $47,000 hiring cost के बाद replacement hire किया गया, और productivity तक पहुँचने में 5 महीने और लगे
• इस बीच senior engineers के 2 और attrition हुए: 1 technical debt से निराश था, 1 ने बाहर Principal Engineer role स्वीकार कर लिया, क्योंकि कंपनी में ऐसा role था ही नहीं
• उस पहली warning पर दोबारा चर्चा 9 महीने बाद architecture review में हुई
  • तब तक प्रस्ताव का context और समाधान को लेकर organizational memory पहले ही खो चुकी थी
  • एक junior engineer को “alternatives investigate” करने का काम दिया गया
• Black Friday के दिन, सुबह 9:47 बजे transaction spike के साथ आपदा शुरू हुई
  • सुबह 10:23 बजे से database ने write requests reject करना शुरू कर दिया
  • bottleneck ठीक वही जगह थी जिसकी ओर 14 महीने पहले इशारा किया गया था, और इस outage की वजह से $2.5M के transactions process नहीं हो पाए
  • recovery में 5 घंटे लगे
    • emergency infrastructure scaling पर $180,000 खर्च हुए और permanent architecture changes के लिए 3 engineers ने पूरी छुट्टी के दौरान overtime किया
  • 3 दिसंबर को CTO की अगुवाई में management को एक नया item शामिल करते हुए postmortem सौंपा गया
    • “Previously Raised Concerns” section जोड़ा गया, जिसमें उस engineer की शुरुआती warning, उसे deprioritize करने का फैसला, और बाद में हुए attrition—all documented थे
    • CFO ने total cost की गणना की
  • engineer attrition cost (3 senior engineers): प्रति व्यक्ति $235,000 की measurable cost
    • recruiting $47,000 + signing bonus $30,000 + vacancy cost $83,000 (औसतन 4 महीने) + onboarding·ramp-up $75,000
    • कुल $705,000
  • tribal knowledge loss cost: $2.2M
    • database structure, failure modes, और पहले के solutions की समझ संगठन से गायब हो गई
    • समस्या को फिर से खोजा गया, solution की दोबारा जाँच की गई, और emergency में implement करना पड़ा
    • इस knowledge gap ने planned migration को crisis response में बदल दिया
    • investigation cost, गलत कोशिशें, emergency vendor involvement, और merchant response costs जमा होते गए
  • failed transaction cost:
    • payment processing failures की राशि $2.5M
    • fee rate 2.9% थी, इसलिए direct revenue loss $72,500 था, लेकिन contract के तहत सभी transactions process करने की बाध्यता थी
    • इसलिए failed processing की वजह से SLA violation penalty $180,000 और merchant support व churn prevention cost $45,000 लगी
  • emergency infrastructure cost: $180,000
    • emergency database scaling (additional read replicas, upgraded instances, expedited vendor support cost)
    • load balancer reconfiguration और CDN optimization से 14 महीने पहले अनुमानित traffic को संभालना संभव हुआ
  • recovery और follow-up action cost: $87,000
    • 3 senior engineers ने holiday weekend में 72 घंटे 2.5x overtime rate पर काम किया: $51,923
    • broader engineering team का 2 हफ्ते का follow-up work: $38,462
  • कुल incident cost: $3.47M
  • मूल रूप से प्रस्तावित prevention cost: $80,000 (जिसमें 1 senior engineer के 6 हफ्तों का engineering work time और infrastructure cost शामिल था)
  • postmortem के पहले पेज पर $3.47M vs $80,000 लिखा था, और इसी संख्या ने बातचीत की दिशा बदल दी
• CEO ने board के सवालों के जवाब में retention analysis का निर्देश दिया
  • senior engineer attrition rate सालाना 34% थी (profitable companies के industry average से दोगुने से भी अधिक)
  • exit interviews, जिन्हें पहले management review के बिना archive कर दिया जाता था, उनमें एक consistent pattern दिखा
    • प्रतिभाशाली engineers तब छोड़कर जाते थे जब उनकी technical concerns को स्वीकार तो किया जाता था, लेकिन उन पर अमल नहीं होता था
  • 18 महीनों में 4 सुधारात्मक कदम लागू किए गए:
    • CFO ने quarterly reports में customer acquisition cost के साथ attrition cost tracking शुरू की — अचानक $235,000 average attrition cost marketing spend decisions जैसे documents में दिखने लगी
    • सभी executives ने quarterly on-call rotation में हिस्सा लिया — database work को deprioritize करने वाले VP of Product को पहले ही हफ्ते 23-page की report मिली, जिसमें 19 items पिछले 6 महीनों में flag किए गए technical debt से जुड़े थे
    • compensation committee ने executive variable pay में talent retention factor जोड़ा: senior engineers की 90% annual retention bonus calculation का 25% हिस्सा बनी
    • director और VP level compensation के अनुरूप Staff और Principal IC tracks बनाए गए
• 18 महीने बाद, इस payment कंपनी में senior engineer attrition rate घटकर सालाना 9% रह गई
• और अधिक महत्वपूर्ण बात, architecture review process बदल गई:
  • technical debt proposals में अब calculated failure cost शामिल होती है
  • executives अब नियमित रूप से पूछते हैं, “अगर इसे defer किया जाए तो engineer attrition risk कितना है?”
• database concern मूल रूप से उठाने वाला platform engineer Principal Engineer के रूप में वापस लौटा
  • उसके जाने के समय की तुलना में 40% अधिक salary — खास तौर पर infrastructure scaling lead करने के लिए hire किया गया
• उस engineer की वापसी, और संख्याओं से साबित बदलाव, इस बात का प्रतीक थी कि संगठन की economic calculation सचमुच बदल गई थी

छह intervention जो वास्तव में असरदार साबित हुए

• प्रोत्साहनों को फिर से संरेखित करने वाले संरचनात्मक हस्तक्षेप, न कि सूचना इकट्ठा करने या सहानुभूति गतिविधियाँ, बल्कि आर्थिक पुनर्रचना

• प्रभाव की पदानुक्रम

  • 6 हस्तक्षेप बोझिल लग सकते हैं, लेकिन इम्प्लीमेंटेशन की कठिनाई और value creation तक लगने वाला समय एक जैसा नहीं होता, इसलिए क्रम महत्वपूर्ण है
  • सबसे तेज़ परिणाम देने का तरीका: ऐसे हस्तक्षेप जिनके लिए संगठन की न्यूनतम सहमति ही चाहिए
    • Attrition cost accounting (#1): केवल CFO की मंज़ूरी और financial analyst के समय की ज़रूरत
    • अनदेखी की गई चेतावनियों से हुई incidents की tracking (#2): केवल SRE process में बदलाव चाहिए। बजट या restructuring की ज़रूरत नहीं, सिर्फ़ व्यवस्थित postmortem documentation काफ़ी है
    • दोनों 30 दिनों के भीतर शुरू किए जा सकते हैं, और कठिन लड़ाइयों के लिए quantified evidence देते हैं
  • मध्यम-अवधि के हस्तक्षेप: cultural change चाहिए, लेकिन compensation restructuring नहीं
    • Executive on-call rotation (#3): यह तब सफल होता है जब कोई executive infra improvement work टालने के नतीजों को सीधे अनुभव करता है, और तब वह policy स्वाभाविक रूप से टिक जाती है
    • अधिकारयुक्त technical advisory board (#5): यह तभी असरदार होता है जब executives सच में यह स्वीकार करें कि उनके फ़ैसले पलटे जा सकते हैं; छोटे स्तर पर pilot के रूप में चलाया गया मॉडल कुछ quarters में विफल हो जाता है
    • इम्प्लीमेंटेशन समय 3-6 महीने: क्योंकि इसमें सिर्फ़ policy change नहीं बल्कि trust building भी चाहिए
  • संरचनात्मक हस्तक्षेप: board या compensation committee की मंज़ूरी चाहिए, 6-12 महीने लगते हैं, लेकिन सबसे गहरा बदलाव देते हैं
    • compensation system में talent retention metric शामिल करना (#4): जब executive bonus senior engineer retention पर निर्भर हो, तो technical debt रातोंरात रणनीतिक रूप से महत्वपूर्ण बन जाता है
    • IC track parity सुनिश्चित करना (#6): जब Staff engineer बिना team management के executive-स्तर का वेतन पा सके, तो technical expertise को बनाए रखना संरचनात्मक रूप से संभव हो जाता है
  • न्यूनतम viable हस्तक्षेप: अलग-अलग स्तरों के दो तत्वों का संयोजन
    • Attrition cost accounting (तेज़ परिणाम) + compensation में retention metric (संरचनात्मक बदलाव)
    • पहला business case बनाता है, दूसरा executives के लिए कार्रवाई को तर्कसंगत बनाता है
  • संकट में चल रही कंपनी: तेज़ परिणाम वाले कदम तुरंत लागू करें + साथ-साथ संरचनात्मक बदलाव डिज़ाइन करें
  • शुरुआती चेतावनी संकेत वाली कंपनी: measurement (cost accounting, incident tracking) से शुरुआत करें + result data के आधार पर गहरे हस्तक्षेपों को उचित ठहराएँ

• 1. Attrition cost accounting

  • जो दिखता नहीं उसे दिखने योग्य बनाना: हर senior engineer के जाने की कुल लागत निकालना
    • औसत recruiting cost $35,000
    • पूरी productivity तक पहुँचने में लगभग 6 महीने (senior engineer के वेतन का 50%)
    • knowledge loss के कारण project delays
    • उन architecture decisions की opportunity cost जिन्हें सिर्फ़ वही engineer समझता था
  • इन आँकड़ों को मासिक आधार पर track करें और CAC, revenue metrics के उसी executive dashboard में शामिल करें
  • एक financial services कंपनी ने quarterly attrition cost track की, और पाया
    • Q1: 2 senior engineers गए, $400,000
    • Q3: सालाना अनुमानित लागत $900,000
    • जब CFO ने इसे सालाना engineering budget $3M के साथ पेश किया
    • तब CEO का सवाल “वे क्यों गए?” से बदलकर “उन्हें रोकने के लिए कितना चाहिए?” हो गया
    • नतीजतन technical debt cleanup और compensation adjustment में $400,000 निवेश किया गया
      senior attrition rate 43% कम हुई और निवेश की लागत दो quarters में पूरी वसूल हो गई

• 2. अनदेखी की गई चेतावनियों के कारण हुई घटनाओं को track करना

  • postmortem template में बदलाव करके अनिवार्य section "Prior Warnings" जोड़ें
  • incident owner से यह अनिवार्य करें कि वह Jira, Slack, architecture review notes, और email में इस failure mode से जुड़ी पिछली चेतावनियाँ खोजे
  • दस्तावेज़ में यह दर्ज हो: चेतावनी कब उठाई गई, किसने उठाई, कौन-सी कार्रवाई सुझाई गई, और priority क्यों घटाई गई
  • incident cost की गणना: downtime का revenue impact, customer support का बोझ, recovery में लगा engineering time
  • एक healthcare tech कंपनी ने यह तरीका अपनाने के बाद
    • 6 महीनों के भीतर पाया कि production incidents में 70% की पहले से भविष्यवाणी की गई थी
    • engineers ने concerns उठाई थीं, लेकिन management ने feature development पर फोकस करते हुए समस्या को कम प्राथमिकता दी
    • 1 साल की कुल लागत: रोकथाम योग्य incidents पर $1.8M खर्च हुआ
    • जब management ने देखा कि 16 major outages में से 14 में technical warnings सही थीं, तो उन्हें pattern की गंभीरता समझ आई
    • जब predictions लगातार सही साबित हुईं, तो व्यवहार में बदलाव आया

• 3. Executive on-call rotation

  • सभी executives (product, VP, director सहित) हर quarter में 1 हफ्ता on-call रहें
  • Escalation policy:
    • यदि on-call engineer यह माने कि alert किसी ऐसे fix या टाले गए technical work से जुड़ा है जिसे पहले low priority दिया गया था
    • तो समय या दिन की परवाह किए बिना उस फ़ैसले के ज़िम्मेदार व्यक्ति को सीधे रिपोर्ट किया जाए
  • यह किसी भी dashboard से अधिक शक्तिशाली अनुभवात्मक सीख देता है
  • उदाहरण: एक VP of Product ने 7 महीने पहले engineers द्वारा “अच्छा हो तो ठीक” fix के रूप में चिह्नित किए गए उसी database connection pool issue के कारण 5 दिनों में 17 calls झेले
    • उस issue को P3 मार्क किया गया था, और VP ने उसकी जगह 3 features की release को प्राथमिकता दी थी
    • लगातार 5 बार सुबह 3 बजे call आने के बाद इसे P0 में बदल दिया गया, और 8 दिनों में fix कर दिया गया
    • बाद में उस VP ने माना, "मुझे लगता था engineers alert fatigue को बढ़ा-चढ़ाकर बताते हैं। ऐसा नहीं था।"

• 4. Executive compensation में talent retention metrics शामिल करना

  • executive variable compensation का 25% senior engineer retention rate पर निर्भर हो, इस तरह संरचना बदलें
  • "senior" की परिभाषा: 2 साल या उससे अधिक tenure, performance review में expectations से ऊपर, या critical systems की ज़िम्मेदारी
  • लक्ष्य निर्धारण: senior engineers की वार्षिक 90% retention
    • लक्ष्य से कम होने पर bonus आनुपातिक रूप से घटे
    • लक्ष्य से अधिक होने पर bonus multiplier के साथ दिया जाए
  • उदाहरण: एक Series B SaaS कंपनी ने 2021 में यह संरचना लागू की
    • senior engineer attrition सालाना 28%
    • executives की शुरुआती आपत्ति: "अगर किसी को बेहतर offer मिलता है तो हम उसे नियंत्रित नहीं कर सकते"
    • CEO का जवाब: "तो फिर हम मान रहे हैं कि salary के अलावा हमारी कोई प्रतिस्पर्धात्मक बढ़त नहीं है। या तो इसे सुधारो, या compensation पर असर स्वीकार करो।"
    • 1 साल के भीतर attrition rate 11% तक घट गई
    • exit interview pattern बदला: जाने वाले engineers ने dysfunction-based attrition (अनदेखी technical concerns, growth की कमी, toxic culture) के बजाय opportunity-based attrition (बड़ी कंपनी में senior promotion, startup शुरू करना, relocation) का ज़िक्र किया
    • जब executives ने अब retention के लिए जवाबदेही महसूस की, तो bonus goals हासिल करना सबसे आसान हिस्सा बन गया

• 5. वास्तविक अधिकार वाला Technical Advisory Board (TAB)

  • engineering org द्वारा चुने गए (executive नियुक्त नहीं) 5 senior engineers से committee बनाई जाए
  • C-level leaders के साथ quarterly meeting
  • एक अधिकार: हर quarter में 1 executive decision को veto कर सकता है
  • आवश्यकताएँ: veto करते समय technical justification, estimated cost, risk analysis सहित लिखित alternative proposal देना अनिवार्य
    • executives केवल CEO approval और documented reason के साथ ही veto को निरस्त कर सकते हैं
  • उदाहरण: एक blockchain infra कंपनी ने 2020 की शुरुआत में TAB बनाया
    • 2 साल में 2 बार veto का इस्तेमाल हुआ
    • पहला veto: proprietary consensus framework बनाने के फ़ैसले को रोका, और उसके बजाय मौजूदा open source protocol को extend करने का प्रस्ताव दिया। अनुमानित 18 महीने का development time बचा
    • दूसरा veto: comprehensive rollback testing के बिना database migration release होने से रोका। implementation के बाद के analysis में TAB ने $2M के data corruption incident को टलना बताया
    • असली असर अधिक सूक्ष्म था: executives technical decisions final करने से पहले "क्या TAB इसे approve करेगा?" पूछने लगे
    • veto के ख़तरे ने TAB तक पहुँचे बिना ही proposal quality बदल दी
    • engineers ने महसूस किया कि उनकी technical judgment आख़िरकार executive decisions में महत्वपूर्ण हो गई है

• 6. compensation parity वाला IC (individual contributor) track

• IC career progression path को स्पष्ट रूप से परिभाषित करें: Staff Engineer, Principal Engineer, Distinguished Engineer

  • compensation bands क्रमशः Director, VP, SVP स्तर के बराबर होने चाहिए

• promotion criteria: team size या reporting structure के बजाय technical influence, architecture पर नेतृत्व, और दूसरे engineers की effectiveness बढ़ाने वाला multiplier effect

• उदाहरण: एक fintech कंपनी में 6 महीनों के भीतर 3 Staff-स्तर के engineers ने इस्तीफ़ा दिया

• इस्तीफ़ा इंटरव्यू में एक जैसा पैटर्न: "manager बने बिना L7 compensation तक पहुँचना संभव नहीं। management नहीं करना चाहता/चाहती, developer बने रहना चाहता/चाहती हूँ"

  • कंपनी ने compensation parity वाला IC track लागू किया
  • 1 साल के भीतर: पहले इंटरव्यू दे रहे 2 इंजीनियरों को Principal में प्रमोट किया गया, समान career path न रखने वाली प्रतिस्पर्धी कंपनियों से 3 senior IC भर्ती किए गए, senior technical attrition में 62% की कमी
  • इससे भी ज़्यादा महत्वपूर्ण, कंपनी में रुके इंजीनियरों ने अनुमानित 30 लाख डॉलर के architecture mistakes को रोकने में मदद की
    • यानी ऐसे फ़ैसले, जिन पर junior या mid-level इंजीनियर expertise या authority की कमी के कारण आपत्ति नहीं जता सकते थे

कार्यान्वयन पथ (Implementation Paths)

• कार्यान्वयन की समय-सारिणी संगठन की गंभीरता के अनुसार बदलती है

• संकटग्रस्त कंपनी (सीनियर attrition rate >20%, हाल में गंभीर outage हुआ)

  • सप्ताह 1-2: वास्तविक 12-महीने की attrition cost की गणना करें (hiring cost, productivity ramp-up time, project delay, और कमी वाले ज्ञान के नुकसान सहित), resignation interview patterns का विश्लेषण करें, और production incidents को पहले अनदेखी की गई warnings से map करें
  • सप्ताह 3-4: CFO और CEO के सामने निष्कर्ष प्रस्तुत करें, pattern दिखाएँ (technical concern उठाया गया → priority कम की गई → engineer attrition → incident या cost), कुल नुकसान को quantify करें, और तत्काल intervention प्रस्तावित करें
  • सप्ताह 5-8: executive on-call rotation शुरू करें (सबसे तेज़ cultural shift), attrition cost tracking शुरू करें (लगातार बदलाव के लिए case बनाना), 3 engineers के साथ TAB pilot बनाएँ, और executive dashboard में monthly attrition cost tracking शुरू करें
  • सप्ताह 9-12: board के सामने compensation structure changes रखें, executive bonus को retention से link करें, IC career track की सार्वजनिक घोषणा करें, और क्या बदला और क्यों बदला इसे पारदर्शी तरीके से communicate करें

• शुरुआती चेतावनी संकेत वाली कंपनी (attrition rate 12-18%, engineers 1:1 में चिंता जता रहे हैं)

  • महीना 1-2: attrition cost tracking और economic case बनाना शुरू करें, engineers का survey करें कि retention risk क्या है और उन्हें क्या रोक सकता है, और सबसे ज़्यादा बताए गए 3 concerns की पहचान करें
  • महीना 3-4: resource executive और executive on-call rotation pilot चलाएँ, TAB pilot शुरू करें, और दोनों का उपयोग technical debt और organizational friction को surface करने के लिए करें, deferred work cost को document करें
  • महीना 5-6: स्थायी compensation structure changes लागू करें, TAB authority को औपचारिक करें, IC career track criteria और compensation bands प्रकाशित करें, और senior engineer retention को स्पष्ट executive goal के रूप में सेट करें

जब यह प्रभावी नहीं होता

• ये interventions 3 scenarios में अनुमानित रूप से विफल होते हैं, और इसे स्वीकार न करने पर केवल समय बर्बाद होता है

• 1. ऐसा business model जो मूल रूप से attrition को मानकर बनाया गया है

  • consulting firms और contract companies में सालाना 20-40% attrition अपेक्षित होता है
  • business model staffing replacement cost को pricing में शामिल करता है, और billing rates इस धारणा पर तय किए जाते हैं कि organization-specific expertise सीमित होगी
  • product companies के लिए बनाई गई retention strategies वहाँ अर्थहीन हैं जहाँ client rotation स्वाभाविक attrition को बढ़ावा देती है और partner track जानबूझकर up-and-out pressure बनाता है
  • इसी तरह product-market fit से पहले के शुरुआती startup में engineer attrition retention failure नहीं, बल्कि ज़रूरी pivot का संकेत हो सकता है
    • अगर कंपनी हर 6 महीने में बुनियादी दिशा बदल रही है, तो कम retention system dysfunction नहीं बल्कि उपयुक्त talent reallocation हो सकता है

• 2. केवल लागू करने का दिखावा (Implementation Theater)

  • सिर्फ़ औपचारिक interventions, कोई intervention न होने से भी बदतर परिणाम देती हैं
  • वास्तविक veto authority के बिना TAB, engineer concerns को बाँटकर निकालने वाला vent बन जाता है
    • जब लोग ऐसी proposals पर समय लगाते हैं जिन्हें व्यवस्थित रूप से अनदेखा किया जाता है, तो नाराज़गी और बढ़ती है
  • root cause resolution से न जुड़ा executive on-call rotation, जवाबदेही के बिना दिखावटी empathy पैदा करता है
    • जिस VP को ऐसे issues पर call मिलता है जिन्हें वह priority देकर हल नहीं कर सकता, वह सिर्फ़ इतना सीखता है कि engineers अक्सर शिकायत करते हैं
  • attrition cost accounting जिसे calculate तो किया जाता है लेकिन executive dashboard या compensation discussion में कभी शामिल नहीं किया जाता, सैद्धांतिक बहस बनकर रह जाती है
  • आधे-अधूरे लागू किए गए interventions दिखाते हैं कि leadership structural change की असली इच्छा के बिना सिर्फ़ दिलचस्पी दिखाने का नाटक कर रही है

• 3. सांस्कृतिक पूर्वशर्तों का अभाव

  • इन interventions के लिए ऐसी cultural preconditions चाहिए जो कई organizations में अनुपस्थित होती हैं: leadership को reputation management नहीं बल्कि वास्तविक behavioral change चाहिए होना चाहिए
  • अगर executives engineer retention को economic problem नहीं बल्कि PR problem मानते हैं, तो वे केवल सबसे visible interventions (advisory council, listening tours) लागू करेंगे और महँगी चीज़ों (compensation restructuring, वास्तविक veto authority) से बचेंगे
  • diagnostic test: executive variable compensation के 25% को senior engineer retention से जोड़ने का प्रस्ताव रखें
    • अगर leadership तुरंत बताने लगे कि यह हमारी कंपनी में क्यों नहीं चल सकता, तो यही उत्तर है
      • वे ऐसा समाधान चाहते हैं जिसकी व्यक्तिगत लागत उन्हें न उठानी पड़े
  • जो कंपनियाँ engineers को veto authority देने, executive pay को retention से जोड़ने, और quarterly financial review में attrition cost शामिल करने के लिए तैयार नहीं हैं, वे structural change के लिए तैयार नहीं हैं
  • वे केवल concerns को स्वीकार करती हैं, “अतिरिक्त research” की सलाह देती हैं, और senior engineers के लगातार जाने के दौरान धूल जमा करती consulting reports से संतुष्ट रहती हैं
  • interventions तभी काम करते हैं जब leadership यह मान ले कि सालाना $1.4 million की attrition cost, उसे रोकने के लिए ज़रूरी कदमों से बड़ी है
    • उस समझ के बिना कोई भी advisory council economic alignment की जगह नहीं ले सकती

नया आर्थिक हिसाब

• लेखक के नेतृत्व वाली एक blockchain infrastructure company ने 3 साल में 10 engineers से 187 engineers तक विस्तार किया, फिर भी
  • senior engineer attrition rate को सालाना औसतन 6% पर बनाए रखा, जो hypergrowth companies में सामान्य 35~40% turnover से कहीं बेहतर था
• इस सफलता का कारण perks या cultural devices नहीं बल्कि incentive structure का redesign था
  • middle managers को सब कुछ control में दिखाने के लिए नहीं, बल्कि technical risk को जल्दी surface करने के लिए reward किया जाता था
  • postmortem में पहले की warnings को document करना अनिवार्य था; अनदेखी की गई warnings, priority कम करने वाले व्यक्ति के performance review का हिस्सा बनती थीं
  • technical leadership के पास architecture decisions पर veto authority थी. हमने इसे 2 बार इस्तेमाल किया, लेकिन veto की संभावना मात्र से ही overall proposal quality बेहतर हो गई
  • IC career track शुरुआत से मौजूद था; सबसे senior non-manager को ज़्यादातर directors से अधिक वेतन मिलता था
• system cost: compensation adjustments, governance overhead, और technical debt को priority देने के कारण कुछ features delay करने की सालाना लागत लगभग $400,000
• बचत:
  • $2.1 million की रोकी गई attrition cost (industry-standard 35% attrition को senior engineer headcount पर लागू करके)
  • इसके अलावा, senior engineers के पास stop authority होने के कारण ऐसे architecture decisions से भी बड़ी लेकिन मापना कठिन बचत हुई, जो वरना multi-million-dollar incidents पैदा कर सकते थे

असहज सच

• ज़्यादातर कंपनियाँ इन interventions को तब तक लागू नहीं करतीं जब तक उन पर मजबूरी न आ जाए
• यह मजबूरी आम तौर पर विनाशकारी होती है: multi-million-dollar production incident, ऐसा mass attrition जो core team को अपंग कर दे, या कोई competitor आपकी उस चीज़ की पेशकश करके—यानी technical judgment का सम्मान—आपकी आधी core engineering talent छीन ले, जिसे आपने ठुकराया था
• तब तक आप prevention नहीं बल्कि damage control में फँस चुके होते हैं
  • recovery महँगी होती है, क्योंकि अगला संकट रोक सकने वाले सबसे अच्छे engineers पहले ही जा चुके होते हैं
  • उनके replacements प्रतिभाशाली तो होते हैं, लेकिन organizational knowledge की कमी के कारण यह नहीं जानते कि कौन-सी warning देनी चाहिए, और doom loop तेज़ हो जाता है
• सवाल यह नहीं है कि ये interventions काम करते हैं या नहीं, सबूत स्पष्ट हैं
  • जो कंपनियाँ executive incentives को retention के साथ align करती हैं, engineers को meaningful authority देती हैं, और attrition को economic problem की तरह treat करती हैं, वे retention, incident rate, और long-term technical health में लगातार बेहतर प्रदर्शन करती हैं
• अगर skilled engineers जा रहे हैं और सामान्य solutions काम नहीं कर रहे, तो समस्या communication नहीं बल्कि economics हो सकती है

[duddnd649]

मैनेजमेंट ने यह सुना और सिर हिलाकर सहमति जताई
समस्या को स्वीकार किया
कहा कि वे प्राथमिकताएँ समायोजित करेंगे
> यहीं आकर बात अटक जाती है

[bichi]

असुविधाजनक सच +

असल फैसला लेना जिन मैनेजमेंट लोगों को होता है, वे यह लेख पढ़कर भी इसे समझ नहीं पाएंगे

[mstorm]

मैं सहमत हूँ।

[rrr6ttt]

सच में

[jjw9512151]

यह सच में बहुत मूल्यवान लेख है क्योंकि इसमें समाधान मौजूद हैं। धन्यवाद।

[ds2ilz]

मैं इसे मोबाइल पर देख रहा/रही हूँ, और लगता है कि alignment की समस्या की वजह से मुख्य लेख के बीच कुछ ऐसी lists हैं जिनमें एक पंक्ति में सिर्फ़ एक अक्षर ही दिख रहा है। इसके अलावा, depth थोड़ा भी बढ़ते ही पंक्ति की लंबाई बहुत नाटकीय रूप से छोटी हो जाती है।

[curioe]

संपादित कर दिया है। बताने के लिए धन्यवाद।

[cysl0]

हाँ, iOS 26.1 x safari में भी वही समस्या है

[bini59]

मैं भी refactoring करना चाहता हूँ

[ethanhur]

मुझे incentive दिखाइए, मैं आपको परिणाम दिखाऊँगा - Charlie Munger