आपके सर्वश्रेष्ठ इंजीनियर दूसरी जगह इंटरव्यू क्यों दे रहे हैं

• संगठन के भीतर information filtering structure के कारण प्रबंधन को इंजीनियरों की असंतुष्टि का पता इस्तीफे की सूचना मिलने के बाद ही चलता है, और जो इस्तीफा महीनों पहले तय हो चुका हो उसे तब तक पलटना बहुत देर हो चुकी होती है
• इंजीनियरों के नौकरी छोड़ने की असली वजह वेतन नहीं, बल्कि तकनीकी निर्णयों की अनदेखी का अनुभव, ऐसा technical debt जिसे चुकाना संभव न हो, और बेकार कामों में लगा दिया जाना है
• मिडल मैनेजर अक्सर समस्याओं को अपने स्तर पर ही सुलझाने की कोशिश करते हैं, और इसे पेशेवर क्षमता मानते हैं, लेकिन व्यवहार में यह information suppression की तरह काम करता है
• skip-level बातचीत (जब प्रबंधन निचले स्तर के इंजीनियरों से सीधे बात करता है) को संगठन की सेहत के लिए हानिकारक बताकर टाला जाता है, लेकिन वास्तव में यह मिडल मैनेजरों को जवाबदेही से बचाने का काम करता है
• एक सीनियर इंजीनियर को बदलने की लागत $275,000~$395,000 तक पहुंचती है, जो हफ्ते में कुछ घंटे skip-level बातचीत पर होने वाले खर्च ($50,000/वर्ष) से कहीं अधिक है
• अगर संगठन शुरुआती चरण में skip-level, external diagnosis, और वास्तविक समस्या-समाधान में निवेश करे, तो करोड़ों रुपये के replacement cost कम किए जा सकते हैं; वरना कंपनी कारण समझे बिना ही अच्छे इंजीनियर खोती रहती है

---

प्रस्तावना: एक सीनियर इंजीनियर का जाना और 1.4M डॉलर का नुकसान

• $40M ARR वाली एक SaaS कंपनी में, एक सीनियर इंजीनियर ने scale न हो सकने वाली DB architecture का 6 महीने तक विरोध किया, लेकिन product organization का “पहले जल्दी ship करो, बाद में refactor कर लेंगे” वाला निर्णय वैसे ही लागू कर दिया गया
  • engineering leadership को भी लगता था कि वह सही है, फिर भी उन्होंने product team का विरोध करके बात आगे नहीं बढ़ाई
  • उसने तकनीकी फैसले की वजह से नहीं, बल्कि अपना निर्णय कोई मायने नहीं रखता यह महसूस होने के कारण उसी हफ्ते इंटरव्यू देना शुरू कर दिया
• 8 महीने बाद सिस्टम में हर दिन performance issue आने लगे, और 18 महीने बाद 5 सीनियर इंजीनियर कंपनी छोड़ चुके थे; तब कंपनी ने यह समझने के लिए एक fractional CTO को नियुक्त किया कि यह सब क्यों हो रहा है
• जांच में पता चला कि executives को यह बिल्कुल पता ही नहीं था कि इंजीनियर असंतुष्ट हैं, जब तक इस्तीफे वाले ईमेल आने शुरू नहीं हुए
  • exit interview में ऊपर-ऊपर से सिर्फ “बेहतर अवसर” और “ज़्यादा competitive compensation” जैसी बातें दर्ज हुईं
  • CEO ने बाकी इंजीनियरों की सैलरी 15% बढ़ा दी, लेकिन उसके बाद भी attrition जारी रहा
• 5 सीनियर इंजीनियरों को replace करने की लागत, जिसमें hiring, productivity loss, और knowledge loss शामिल थे, लगभग $1.4M आंकी गई
• यह समस्या compensation नहीं, बल्कि information flow की विफलता से पैदा हुई थी, और इसकी जड़ थी “ऊपर जाने वाली जानकारी को फ़िल्टर कर देने वाली hierarchical structure”

Hierarchies filter bad news out — पदानुक्रम बुरी खबर को छानकर गायब कर देता है

• संगठन जटिलता संभालने के लिए hierarchy और management layers लाते हैं, लेकिन इसके साथ ऐसी संरचना बन जाती है जिसमें हर layer पर जानकारी छंटती जाती है
  • अगर कोई junior कहे “कुछ गड़बड़ लग रही है”, तो senior उसे संवारकर manager तक पहुंचाता है, और manager पहले यह देखता है कि “क्या यह रिपोर्ट करने लायक है, और क्या इससे उसकी स्थिति खराब होगी”
  • VP→CTO→CEO तक पहुंचते-पहुंचते मूल समस्या की details और urgency एक-एक करके गायब हो जाती हैं
• यह filtering हमेशा दुर्भावनापूर्ण नहीं होती; अक्सर यह उस संस्कृति से निकलती है जिसमें मिडल मैनेजर मानते हैं कि समस्याओं को अपने स्तर पर संभालना ही उनकी जिम्मेदारी है
  • “समस्या को ऊपर ले जाना = विफलता” माना जाता है, और “सिर्फ समाधान लेकर ऊपर जाना” professionalism समझा जाता है
  • नतीजे में यह समस्याओं को छिपाने वाला mechanism बन जाता है
• 120 लोगों की engineering organization के एक उदाहरण में, frontend team ने मार्च में नए dashboard के performance issue खोजे और code review में सार्वजनिक रूप से चिंता जताई
  • मई में manager ने समाधान विकल्पों की समीक्षा की, और जून में VP को बस इतना बताया गया कि “dashboard performance optimization चल रहा है”
  • जुलाई में CTO ने सिर्फ इतना सुना कि “थोड़ा performance work” चल रहा है, और अगस्त में जाकर सबसे बड़े ग्राहक ने dashboard को unusable बताते हुए औपचारिक शिकायत की, तब executives को यह एक ‘अचानक’ संकट लगा
• हकीकत यह थी कि इंजीनियर 5 महीने से समस्या जानते थे, जबकि resources allocate करने वाले executives हमेशा कई महीने पुरानी, पतली कर दी गई जानकारी पर निर्णय ले रहे थे
• इस ढांचे में इंजीनियर अगस्त में जान लेता है कि DB टिक नहीं पाएगा, manager अक्टूबर में असंतोष समझता है, VP दिसंबर में morale गिरने को देखता है, और CTO फरवरी में सामूहिक इस्तीफे देखता है—ऐसी information delay chain बार-बार दोहराई जाती है

The convenient fiction of chain of command — ‘reporting line’ नाम की सुविधाजनक कल्पना

• कई संगठन skip-level (जब executive इंजीनियरों से सीधे बात करता है) को “सिस्टम तोड़ने वाला व्यवहार” मानकर लगभग वर्जित बना देते हैं
  • मिडल मैनेजर की authority कमजोर होगी, अविश्वास का संकेत जाएगा, या micromanagement होगा—ये आम तर्क दिए जाते हैं
  • ऊपर से यह संगठन की सेहत की चिंता लगती है, लेकिन वास्तव में यह मिडल management layer को जवाबदेही और जांच से बचाने वाला तंत्र बन जाती है
• जब CTO इंजीनियरों से सीधे बात करता है, तब उसे पता चलता है कि जमीन पर वास्तव में क्या हो रहा है
  • इसके उलट, जो CTO सिर्फ management layers से होकर आए reports देखता है, वह वास्तविकता का वही संस्करण देखता है जो managers उसे दिखाना चाहते हैं
  • skip-level पर अनकहा प्रतिबंध इसी दूसरे मॉडल को सुरक्षित करता है
• “executive का समय महंगा है, इसलिए उन्हें सिर्फ strategy पर ध्यान देना चाहिए” वाला तर्क वहीं टूट जाता है जहां strategy गलत जानकारी पर टिकने लगती है
  • अगर CTO हर हफ्ते सिर्फ कुछ घंटे लगाए, तो वह सीधे सुन सकता है कि असल में क्या अटका हुआ है, किसका मन काम से हट चुका है, और कौन-सी technical bet विफल हो रही है
  • 3–4 layer पार कर आई reports पर निर्भर रहना प्रति घंटे सस्ता लग सकता है, लेकिन यह बार-बार बड़े गलत फैसले कराने वाला कहीं ज्यादा महंगा विकल्प है
• skip-level के लिए बहुत ज़्यादा समय नहीं चाहिए; बस लगातार पैटर्न और पूरी coverage सुनिश्चित होनी चाहिए
  • संगठन जितना बड़ा होता है, एक-एक व्यक्ति से बात का अंतराल उतना बढ़ सकता है, लेकिन ऐसी संरचना बनाए रखना संभव है जिसमें CTO हर quarter कम से कम एक बार हर इंजीनियर से सीधे बात करे
  • ऐसी सीधी बातचीत में इंजीनियर वे बातें बता देते हैं जो वे manager से कभी नहीं कहेंगे, और औपचारिक reporting line की तुलना में 3–6 महीने पहले early warning मिल जाती है
• एक payments company के उदाहरण में, नए CTO ने हर हफ्ते 30 मिनट के office hours शुरू किए, जिन्हें कोई भी manager की अनुमति के बिना बुक कर सकता था
  • तब यह सामने आया कि deployment system अस्थिर था, इसलिए शुक्रवार को deploy करने से बचने की संस्कृति बन गई थी; इतने false alarm थे कि monitoring पर किसी को भरोसा नहीं था; और API documentation इतनी पुरानी हो चुकी थी कि onboarding का पूरा पहला महीना trial and error में निकल जाता था
  • हर manager इन्हें “अपने स्तर पर संभाल रहे हैं” कहकर ऊपर नहीं ले गया था; CTO ने उसी quarter में तीनों समस्याओं को हल करने के लिए budget आवंटित किया, और 6 महीने बाद voluntary attrition लगभग शून्य के करीब पहुंच गई

Agency, not salary — लोग वेतन नहीं, ‘agency’ खोने की वजह से जाते हैं

• इंजीनियरों के नौकरी बदलने के कारणों को exit interview में अक्सर “compensation” के रूप में पेश किया जाता है, लेकिन वास्तविक पैटर्न अधिक सूक्ष्म होते हैं और अक्सर ऐसे कारणों से शुरू होते हैं जिनके बारे में खुलकर कहना असहज होता है
• 1. पहला पैटर्न है agency का खो जाना
  • इंजीनियरों से ऐसे सिस्टम बनाने को कहा जाता है जिनके बारे में वे जानते हैं कि वे निश्चित रूप से विफल होंगे, और non-technical कारणों से उनके फैसले लगातार पलटे जाते हैं
  • जब उनकी भविष्यवाणी की गई विफलता सच हो जाती है, तब भी उन पर यह जिम्मेदारी डाल दी जाती है कि “इसे रोका क्यों नहीं गया”, और इस ढांचे में एक विशेषज्ञ के रूप में अपनी समझ के बेकार होने का एहसास लगातार जमा होता रहता है
  • एक fintech कंपनी ने पहले से सत्यापित authentication solution का उपयोग करने के बजाय उसे खुद implement करने का फैसला किया, और senior इंजीनियरों ने जोखिम और यह core domain न होने का हवाला देकर इसका विरोध किया
    • product टीम ने एक खास UX flow के लिए custom implementation पर जोर दिया, और engineering leadership senior इंजीनियरों की राय से सहमत होने के बावजूद आखिरकार इसे रोक नहीं सकी
    • नतीजतन custom authentication system में पहले ही महीने 3 security vulnerabilities मिलीं, emergency patch लगाने पड़े, और 6 महीने के development resources खर्च हो गए; उस senior इंजीनियर ने निर्णय पक्का होने वाले उसी हफ्ते नौकरी बदलने की तैयारी शुरू कर दी
  • अगर लागत को संख्याओं में देखें, तो custom authentication पर 180,000 डॉलर खर्च किए गए, जबकि खरीदा जा सकने वाला समाधान सालाना 12,000 डॉलर का था
    • अगर वह इंजीनियर कंपनी में बना रहता, तो roadmap के अनुसार वह सालाना 400,000 डॉलर ARR पैदा करने वाली feature पर काम कर सकता था,
    • यानी सिर्फ इस निर्णय से ही पहले साल में कम से कम 580,000 डॉलर का नुकसान हुआ
• 2. दूसरा पैटर्न है तकनीकी कर्ज का उस स्तर तक टल जाना जिसे चुकाना लगभग असंभव हो जाए
  • DB replication, deployment automation, monitoring improvements जैसे core infrastructure काम हर quarter feature development के पीछे धकेले जाते रहते हैं,
  • और इंजीनियर लगभग सटीक तौर पर जानते हैं कि क्या, कब और कहाँ टूटेगा, फिर भी बस उसे होते हुए देखते रहते हैं
  • एक ecommerce कंपनी ने 18 महीने तक DB infrastructure का काम टालते रहना जारी रखा; इस दौरान traffic हर साल 40% की दर से बढ़ता रहा, लेकिन infrastructure वैसा ही रहा
    • 19वें महीने में DB पूरे platform की bottleneck बन गई, peak time में response time 200ms से 4 सेकंड तक पहुंच गया, conversion rate गिरने से 1.2 मिलियन डॉलर के आसपास revenue loss हुआ और 240,000 डॉलर के emergency infrastructure cost आए
    • infrastructure काम के लिए सबसे जोरदार मांग करने वाले 3 senior इंजीनियरों में से 2 तब तक जा चुके थे
• 3. तीसरा पैटर्न है होशियार लोगों से बेवकूफाना काम करवाने वाली संरचना
  • सालाना 180,000–190,000 डॉलर पाने वाले senior इंजीनियर से ऐसे सिस्टम की maintenance कराना जिसे कब का बंद हो जाना चाहिए था, अर्थहीन दोहराव वाले काम, और ऐसी documentation व estimation meetings कराना जिन पर न किसी को भरोसा है न कोई उन्हें पढ़ता है
  • एक SaaS कंपनी में 6 साल पुराने legacy reporting system से सालाना 80,000 डॉलर revenue आ रहा था, लेकिन एक senior इंजीनियर (सालाना 190,000 डॉलर) अपना 60% समय उसी सिस्टम को बनाए रखने में लगा रहा था
    • कंपनी व्यावहारिक रूप से 80,000 डॉलर revenue के लिए सालाना 114,000 डॉलर जला रही थी, और उस इंजीनियर ने 12 ग्राहकों को नए platform पर migrate करने का प्रस्ताव दिया, लेकिन “strategic customers” कहकर मना कर दिया गया
    • उसने 3 महीने बाद इस्तीफा दे दिया, और replacement cost recruiting व onboarding सहित 220,000 डॉलर तक पहुंच गई, जबकि customer migration लगभग 40,000 डॉलर में पूरा हो सकता था

The early signals executives miss — अधिकारी जिन ‘शुरुआती चेतावनियों’ को नहीं देख पाते

• जिन संकेतों को management इस्तीफा मिलने तक नहीं देख पाता, वे 6–12 महीने पहले से ही दूसरे स्तरों पर साफ दिखाई देने लगते हैं
• 1. junior/mid-level इंजीनियर जो पहला संकेत देखते हैं, वह है senior का लड़ना छोड़ देना
  • senior अब architecture review में जोरदार राय नहीं रखते, और review सिर्फ औपचारिक approval प्रक्रिया बनकर रह जाता है
  • backlog में technical काम लगातार जमा होता जाता है, लेकिन उन्हें लगभग कभी assign नहीं किया जाता, और “ये हमने try किया था, ऊपर से मना हो गया” जैसी बात अक्सर सुनाई देने लगती है
  • एक logistics कंपनी के junior इंजीनियर ने 6 महीने तक ऐसा बदलाव देखा
    • पहले जो architect विस्तार से code review करता था, वह अब ज्यादातर सिर्फ “LGTM” की एक लाइन लिखकर approve करने लगा था,
    • और जब उसने अनौपचारिक बातचीत में यह सुना कि “मेरी राय से वैसे भी नतीजा नहीं बदलेगा, इसलिए मैंने बस समय बचाने का फैसला किया है”, तब उसे सबसे पहले समझ आया कि यह senior जल्द ही चला जाएगा
    • 3 महीने बाद सचमुच इस्तीफा हो गया, और manager को लगा कि उसे इसका बिल्कुल अंदाजा नहीं था
• 2. senior खुद जिस चरण से गुजरता है, वह है 4–8 महीने पहले शुरू होने वाला pattern recognition और moral fatigue
  • “यह विफल होगा, और leadership नहीं सुनेगी” जैसी निश्चितता, गलत चीज बनाने के लिए मजबूर किए जाने की नैतिक चोट, और “इस जगह मेरी विशेषज्ञता का कोई मतलब नहीं” जैसा भाव
  • ऊपर से देखने पर वह बैठकों में कम बहस करता है और ज्यादा सहयोगी दिखता है, इसलिए leader को उल्टा यह लग सकता है कि वह “और mature हो गया है”
• 3. manager जो संकेत देखता है, वह है इस्तीफे से 2–4 महीने पहले आने वाला व्यवहार में सूक्ष्म बदलाव
  • 1:1 में भागीदारी कम हो जाती है, team discussions में बोलना घट जाता है,
  • LinkedIn अपडेट होने लगता है, industry events में जाना बढ़ जाता है, documentation अचानक बहुत बारीकी से होने लगती है, और junior इंजीनियरों को अपने systems विस्तार से सिखाना शुरू कर दिया जाता है
  • इस समय कई managers को लगता है कि उच्च attrition rate उनके लिए नुकसानदेह साबित होगा, इसलिए वे ऊपर रिपोर्ट करने के बजाय चुपचाप इसे सुलझाने की कोशिश करते हैं, और स्थिति को तभी स्वीकारते हैं जब candidate के पास पहले से offer आ चुका होता है
  • एक media कंपनी के manager ने देखा कि एक senior अचानक हर चीज दस्तावेज़ित करने लगा है, और इसे उसने सिर्फ इस रूप में सकारात्मक माना कि “आखिरकार वह knowledge sharing कर रहा है”,
    • जबकि वास्तव में वह जाते समय knowledge gap को लेकर अपराधबोध की वजह से यह सब लिख रहा था, और यह बात manager को उसके जाने के बाद समझ आई
• 4. अधिकारी के सामने आखिर में सिर्फ 0–1 महीने पहले आने वाली resignation notice ही पहुंचती है, और उससे पहले के सभी संकेत संगठन की परतों में बिखर चुके होते हैं

Why one departure becomes five — एक व्यक्ति का जाना कैसे पाँच लोगों के जाने में बदल जाता है

• एक इस्तीफा एक data point हो सकता है, लेकिन जब तीन लोग लगातार जाते हैं, तो बचे हुए लोग इसे “कुछ गड़बड़ है” के संकेत के रूप में पढ़ना शुरू कर देते हैं
  • खासकर जब कोई सम्मानित सहकर्मी जाता है, तो बाकी लोग सोचने लगते हैं, “क्या वह कुछ ऐसा देख रहा था जो मैं नहीं देख पा रहा?”
• बाहरी recruiters भी इस पैटर्न को बहुत जल्दी पहचान लेते हैं
  • जब एक ही team के इंजीनियर LinkedIn search में बार-बार दिखने लगते हैं और profile updates एक साथ बढ़ते हैं, तो उस team को focused recruiting target बना लिया जाता है
  • जिन इंजीनियरों ने नौकरी बदलने के बारे में सोचा भी नहीं था, वे भी संपर्क मिलने पर interview देने लगते हैं, और उनमें से कुछ को सचमुच बेहतर अवसर मिल जाते हैं
• एक cloud infrastructure कंपनी ने 3 हफ्तों के अंतर से 2 senior इंजीनियरों को खोने के बाद, अगले 3 महीनों में 5 और लोगों को खो दिया
  • internal retrospective में पाया गया कि शुरुआती दो लोगों के जाने से “कहीं कंपनी की financial health में कोई समस्या तो नहीं” जैसी information vacuum से पैदा हुई चिंता बढ़ गई थी,
  • जबकि असली वजह पहले बताई गई agency loss और technical debt की समस्या थी; लेकिन जब तक बाकी लोग यह अनुमान लगाते रहे कि “जो लोग गए हैं वे कुछ ऐसा जानते हैं जो मैं नहीं जानता”, तब तक recruiters ने इस मौके का आक्रामक इस्तेमाल कर लिया
• knowledge loss की लागत को संख्याओं में पकड़ना मुश्किल है, लेकिन यह आने वाली तिमाहियों में होने वाली गलतियों, delays और rework के रूप में सामने आती है
  • जो senior जा चुका था, उसके पास यह समझ थी कि “कौन-सी 3 lines of code को छूना नहीं है, और कौन-सी 3,000 lines हटाई जा सकती हैं”,
  • वह यह भी जानता था कि कौन-सा ग्राहक विशेष requirement क्यों रखता है, और कौन-सा technical debt सिर्फ “देखने में खराब” है बनाम कौन-सा “वास्तव में खतरनाक” है
• एक payments कंपनी के मामले में, settlement system बनाने वाला senior इंजीनियर जाने के बाद, नए इंजीनियर ने code बदलते समय एक payment provider API के undocumented edge case को नहीं जाना, और नतीजतन एक खास transaction type पूरी तरह fail होने लगी
  • इस bug को ढूंढने में 2 हफ्ते लगे, engineering लागत लगभग 45,000 डॉलर रही, और failed transactions को manually reconcile करने के दौरान 180,000 डॉलर स्तर की समस्या पैदा हुई,
  • जबकि मूल senior ने उस API के bug को trial and error से खोजा था और बस अपने दिमाग में याद रखा हुआ था

Sometimes it really is the money — कभी-कभी मामला सचमुच पैसे का होता है, और कभी ‘बहाने के रूप में compensation’ का

• कुछ मामलों में मुआवज़ा वास्तव में मूल कारण होता है, और उसका timing pattern अलग होता है
  • जब बाज़ार की तुलना में वेतन साफ़ तौर पर कम हो, बढ़ी हुई ज़िम्मेदारियों के अनुरूप मुआवज़ा न हो, या नए भर्ती हुए लोगों को उसी संरचना में आपके बराबर वेतन मिलता रहे,
  • नौकरी बदलने से पहले सीधे तौर पर पहले मुआवज़े की समस्या उठाना इस बात का संकेत है कि यह ऐसा क्षेत्र है जिसे compensation issue के रूप में हल किया जा सकता है
• इसके उलट, अगर सिर्फ़ exit interview में ही “मुआवज़ा” सामने आता है, और व्यक्ति कई महीनों से चुपचाप इंटरव्यू दे रहा था, तो अक्सर मुआवज़ा प्रेरक कारण नहीं बल्कि औचित्य देने का साधन होता है
  • नया offer 30% ज़्यादा होने पर वह “market level” की बात करता है, लेकिन matching proposal देने पर भी “मैं तो पहले ही दूसरी जगह स्वीकार कर चुका हूँ” कहकर ठंडी प्रतिक्रिया देता है
  • ऐसे मामलों में जाने की असली वजह पहले बताई गई agency, technical debt, और अर्थहीन काम को लेकर निकला निष्कर्ष होती है
• इस लेख में सुझाया गया सरल test है: “क्या 20% बढ़ोतरी देकर रोका जा सकता है?”
  • अगर जवाब हो “इतना हो तो मैं सोच सकता हूँ”, तो संभव है कि मुआवज़ा ही मुख्य मुद्दा हो,
  • लेकिन अगर इसके बावजूद मन पहले ही हट चुका हो, तो इसका मतलब है कि वह कामकाजी माहौल को बिगड़ा हुआ मान चुका है, और सिर्फ़ पैसे से समस्या हल नहीं होगी
• एक developer tools कंपनी ने मुआवज़े की वजह से गए 8 लोगों का विस्तार से विश्लेषण किया,
  • इनमें से जिन 5 लोगों को कंपनी हर हाल में रोकना चाहती थी, उन्हें matching से भी बेहतर counter offer दिया गया, लेकिन 3 ने मना कर दिया
  • बाद की बातचीत में पता चला कि उनके जाने की वजह लगातार बदलता roadmap और अर्थहीन हो चुका काम था, और यह एहसास कि “अब कंपनी की दिशा पर भरोसा नहीं किया जा सकता”
  • exit interview में उन्होंने सिर्फ़ “मुआवज़ा” कहा, लेकिन असली समस्या काम के अपने अर्थ का खो जाना थी

Prevention beats retention bonuses — बाद में दिए जाने वाले bonus से कहीं सस्ता है ‘शुरुआती हस्तक्षेप’

• शुरुआती हस्तक्षेप के लिए ऐसे information channels चाहिए जो hierarchy filter को bypass करें, और कुछ तरीके बार-बार प्रभावी साबित होते हैं
• पहला है नियमित skip-level बातचीत
  • हर हफ़्ते कुछ घंटे अलग-अलग स्तरों के engineers से सीधे बात करने में लगाएँ, तो औपचारिक reporting line से ऊपर न आने वाली वास्तविक productivity blockers, समस्याग्रस्त technical decisions, और गिरते morale के बिंदु सुनाई देते हैं
  • संगठन बड़ा होने पर एक व्यक्ति के साथ बातचीत की आवृत्ति कम की जा सकती है, लेकिन पूरे संगठन की coverage बनाए रखने वाली design महत्वपूर्ण है
• लगभग 100 लोगों के engineering संगठन के एक CTO ने हर हफ़्ते 4 घंटे skip-level पर लगाए,
  • 30-30 मिनट के two-week rotation पर हर महीने लगभग 30 लोगों से बात करने और 7 महीनों में पूरे संगठन का एक चक्कर पूरा करने वाली संरचना बनाई
  • schedule हमेशा खुला रहता था ताकि engineers ज़रूरत पड़ने पर बुक कर सकें, और नतीजतन voluntary attrition 18% सालाना से घटकर 7% रह गया; CTO का मानना था कि ऐसा इसलिए हुआ क्योंकि “समस्याएँ छोटी और ठीक की जा सकने वाली अवस्था में ही सुनाई दे गईं”
• दूसरा है external diagnostic perspective
  • reporting line का हिस्सा न होने वाला और HR authority न रखने वाला fractional CTO या external advisor जब interview करता है, तो लोग कहीं ज़्यादा ईमानदारी से बोलते हैं
  • वही सवाल कोई internal executive भी पूछ सकता है, लेकिन जवाब अलग होने की वजह ‘जवाब देने वाले को महसूस होने वाला जोखिम’ है
• एक SaaS कंपनी ने 6 महीनों में 4 senior लोगों को खोने के बाद fractional CTO को लगाकर सभी स्तरों पर interview कराए,
  • engineers की नज़र में मुख्य समस्या यह थी कि architecture review वास्तविक निर्णय लेने की जगह नहीं, बल्कि बाद में ज़िम्मेदारी टालने के लिए किया जाने वाला एक नाटक लगती थी
  • review requirements पूरी करके approval मिल जाने के बाद भी, कुछ हफ़्तों में product decisions के कारण सब फिर पलट जाता था,
  • कंपनी ने यह process हटा दिया और technical implementation पर engineering को वास्तविक veto power दे दी
• तीसरा है कम-से-कम एक चीज़ को सच में ठीक करना
  • अगर सिर्फ़ बातें सुनी जाएँ और कोई बदलाव न हो, तो लोगों में यह सीख बैठ जाती है कि “बोलने से कोई फ़ायदा नहीं”,
  • लेकिन एक भी चीज़ दिखने लायक़ तरीके से ठीक हो जाए, तो पूरे संगठन में यह संकेत फैलता है कि “बोलो, तो बदलाव होता है”
• एक healthcare tech कंपनी में जब एक developer ने CTO के साथ skip-level में कहा कि tests चलने में 45 मिनट लगते हैं, इसलिए development धीमा हो जाता है,
  • CTO ने पूछा, “इसे अब तक ठीक क्यों नहीं किया गया?”, और developer ने जवाब दिया कि उसने कई बार manager से कहा था, लेकिन हर बार इसे पीछे कर दिया गया
  • CTO ने तुरंत 2 हफ़्तों का कामकाजी समय allocate किया, और test time को 8 मिनट तक घटाने में सफलता मिली,
  • इस अनुभव की चर्चा फैलते ही दूसरे engineers भी skip-level में समस्याएँ लाने लगे
  • इसकी लागत लगभग $12,000 के engineering time की थी, लेकिन “बोलो, तो बदलाव होता है” इस संकेत का मूल्य उससे कहीं बड़ा था

The $1.4m misdiagnosis — ग़लत diagnosis से पैदा हुई 1.4 million dollar की भारी भूल

• एक senior व्यक्ति को replace करने की सावधानीपूर्ण लागत-आधारित गणना लगभग $275,000 से $395,000 के बीच बैठती है
  • recruiting cost: सालाना वेतन का लगभग 20–25%
  • vacancy period में productivity loss: 3–6 महीनों के लिए, सालाना $150,000 productivity मानकर, लगभग $40,000–$75,000
  • onboarding के दौरान आधी-अधूरी productivity: 6 महीनों तक 50% efficiency पर काम करने से लगभग $35,000–$40,000 का नुकसान
  • इसके अलावा knowledge loss, decision delays, और rework जैसे ऐसे नुकसान भी होते हैं जिन्हें मापना कठिन है
• 5 senior लोगों के जाने का मतलब $1.4–2.0M के स्तर का नुकसान हो सकता है, जो ऊपर के उदाहरण वाली कंपनी के cost estimate से मेल खाता है
• इसके उलट, असल समस्या को ठीक करने की लागत बहुत कम होती है, लेकिन उसके लिए संगठनात्मक संरचना और राजनीति को छूना पड़ता है
  • कुछ features टालने, अनावश्यक processes हटाने, और technical decisions engineers को सौंपने के बजाय,
  • कई संगठन यह समझाना पसंद करते हैं कि “engineers वैसे ही महँगे होते हैं, और बाज़ार में competition बहुत तीव्र है”
  • यह व्याख्या सुविधाजनक है क्योंकि इससे internal change की ज़रूरत नहीं पड़ती, लेकिन यह वास्तविक कारणों (information structure, decision-making style) को छिपा देती है
• एक Series B कंपनी ने 18 महीनों में 7 engineers खो दिए, और CEO का मानना था कि “प्रतिद्वंद्वी कंपनियाँ ज़्यादा पैसा दे रही हैं”, लेकिन
  • बाद के विश्लेषण में पता चला कि उनमें से 5 लोगों ने जाने से 6 महीने पहले ठोस technical decisions, process burden, और priority issues के बारे में अपने manager से बात की थी
  • इन मुद्दों को 1:1 notes में सिर्फ़ “monitoring” जैसी टिप्पणी के साथ दर्ज किया गया, और किसी भी स्तर पर executives तक नहीं पहुँचाया गया
  • नतीजा यह हुआ कि executives “मुआवज़े की समस्या” मानते रहे, जबकि engineers इस निष्कर्ष पर पहुँचे कि “मेरी राय मायने नहीं रखती”; यानी दोनों पक्ष पूरी तरह अलग वास्तविकताओं में जी रहे थे

Information is cheaper than replacement — जानकारी जुटाना replacement से कहीं ज़्यादा सस्ता है

• नौकरी छोड़कर जाने वाले engineers के पास ऐसी बातें होती हैं जो executives नहीं जानते
  • जैसे कौन-से technical decisions विफल हो रहे हैं, कौन-सी process समय बर्बाद कर रही है, और किस तरह का management लोगों को थका रहा है
  • यह जानकारी हमेशा संगठन के भीतर मौजूद होती है, लेकिन hierarchy filters और middle-management incentives की वजह से executive level तक पहुँच नहीं पाती
• असली सवाल है: “क्या यह जानकारी इस्तीफ़े से पहले सुनी जाएगी, या फिर उन समस्याओं को हादसे में बदलते देखने के बाद ही सीखा जाएगा जिन्हें वे लोग पहले रोक सकते थे?”
  • जो संगठन यह काम अच्छी तरह करते हैं, वे information flow को strategic asset की तरह देखते हैं, skip-level channels को औपचारिक रूप से design करते हैं,
  • और filtered reports की तुलना में field से सीधे मिलने वाले ‘ground truth’ को अधिक महत्व देने वाली संरचना बनाते हैं
• ऐसे संगठनों में यह माना जाता है कि executives का समय ग़लत strategy meetings में खर्च होने से बेहतर है कि
  • हर हफ़्ते कुछ घंटे भी ज़मीनी स्तर की बातें सुनने में लगाए जाएँ, तो ROI ज़्यादा मिलता है
  • सिर्फ़ एक senior व्यक्ति का जाना रुक जाए, तो executives के समय में सालाना दसियों हज़ार डॉलर के निवेश का पाँच गुना से भी ज़्यादा return निकल सकता है
• इसके उलट, जो संगठन इसे ग़लत तरीके से संभालते हैं, वे जानकारी की सटीकता से ज़्यादा managers की सुविधा को प्राथमिकता देते हैं
  • skip-level को taboo मानते हैं, बुरी ख़बरें हटाई हुई reports पर निर्भर रहते हैं,
  • attrition की समस्या को इस्तीफ़ा आने पर ही पहचानते हैं, और लोगों को replace करने पर लाखों डॉलर खर्च करने के बाद भी “आख़िर सर्वश्रेष्ठ लोग क्यों जा रहे हैं” यह कभी सच में समझ नहीं पाते
• शुरुआत में उदाहरण वाले senior engineer अब ऐसी कंपनी में काम कर रहे हैं जहाँ technical architecture पर engineering के पास veto power है, और CTO नियमित skip-level बनाए रखता है
  • न वह और न ही उसके सहकर्मी नौकरी बदलने की तैयारी कर रहे हैं, और कंपनी की voluntary attrition rate उसी चरण की कंपनियों के औसत से आधी से भी कम, यानी लगभग 12% है
  • इस कंपनी के executives “इतनी देर होने से पहले कि चीज़ें संभाली न जा सकें” यह सुन लेते हैं कि क्या टूट रहा है, और यह किसी जटिल व्यवस्था से नहीं बल्कि एक सरल mechanism से आता है: लगातार पूछना, और बोलने लायक़ संरचना बनाए रखना

[wedding]

यह तो executives को देखना चाहिए, लेकिन मज़ेदार बात यह है कि भागने वाले हम ही इसे देख रहे हैं.. हा..

[rrr6ttt]

सच में

[kuthia]

असल में, बहुत कम कंपनियाँ होती हैं जिनका बिज़नेस लक्ष्य वास्तव में अच्छी इंजीनियरिंग होता है...

[bakyeono]

लगता है हम सभी का अनुभव एक जैसा ही है, क्या इससे थोड़ी तसल्ली मिलती है...?

[redlasha]

सच में, इससे पूरी तरह सहमत हूँ।

[sinbumu]

सच में कई हिस्सों से रिलेट कर पाया, हाहा। इतनी झुंझलाहट होती है कि बस छोड़ो और जितने पैसे मिलते हैं उतना ही काम करो वाले मोड में चला जाता हूँ, तो उल्टा लोग खुश होते हैं कि काम ज़्यादा smoothly आगे बढ़ रहा है। असल में तो डेवलपमेंट की दिशा में risk दिख रहा होता है, लेकिन अब हालत ऐसी हो गई है कि मुझे उससे कोई मतलब ही नहीं रहा।

[nutella]

लगता है इस लेख की Part 1, "why senior engineers leave", और Part 2, "The Economic Intervention That Stops Engineer Attrition" भी हैं.

https://codegood.co/writing/…

[xguru]

ओह, धन्यवाद। इसे भी अलग topic के रूप में रजिस्टर कर दिया है: इंजीनियरों की job change को रोकने के आर्थिक हस्तक्षेप के तरीके

[duddnd649]

क्या इस लेख को executives तक पहुँचने से रोक नहीं सकते..

[cysl0]

इसमें एक भी गलत बात नहीं है।

[seoseonyu]

यह लेख बहुत relatable है।

[nicewook]

मैं इससे सहमत हूँ।

[nullptr]

"दुनिया हर जगह एक जैसी है"

[qaplazlm41]

यह तो executives को देखना चाहिए...

[jjw9512151]

सच में, बातों को एक-एक fact के साथ ज़बरदस्त तरीके से तोड़कर रखा है.. lol

[caniel]

पूरी तरह सहमत हूँ।

[ethanhur]

हम दुनिया हैं