- बड़े संगठन डेटा-ड्रिवन होने, digital transformation और culture improvement की बात करते हैं, लेकिन अगर वास्तविक कार्रवाई साथ न हो, तो यह अंतर काम में निराशा और असंतोष बढ़ाता है
- 8,000 लोगों वाले संगठन के Power BI उदाहरण में 50–100 dashboards में से केवल लगभग 3 इस्तेमाल हुए, और maintenance cost करीब 1 मिलियन डॉलर आंकी गई
- संगठनों की खोखली बातें Sturgeon’s Law जैसी कम औसत क्षमता और उस ढांचे से पैदा होती हैं जिसमें managers के लिए टीम की असफलता की संभावना ईमानदारी से बताना मुश्किल होता है
- “बजट नहीं है” कहने से ज्यादा, उसी department और role में अधिक वेतन पर नए व्यक्ति को hiring करना संगठन की असली प्राथमिकताएं बेहतर दिखाता है
- salary, culture और team operations पर घोषणाओं से ज्यादा, problematic employees को हटाने, बचे हुए लोगों को reward करने और ठोस कदमों को देखकर फैसला करना कम थकाने वाला है
बातों और असली चाहत के बीच का अंतर
- काम की निराशा तब बढ़ती है जब व्यक्ति या संगठन सार्वजनिक रूप से जो कहते हैं और वास्तव में जो महसूस करते या चाहते हैं, उनके बीच के बड़े अंतर को पहचान नहीं पाते
- जापानी अवधारणा honne-tatemae असली भावनाओं और सार्वजनिक रूप से दिखाए जाने वाले रवैये को अलग करने के लिए इस्तेमाल होती है
- यहां इसे जापानी culture की चर्चा से ज्यादा “वास्तव में क्या सोचते हैं” और “क्या कहना पड़ता है” को अलग करने वाली शब्दावली के रूप में इस्तेमाल किया गया है
Tatemae: डेटा-ड्रिवन होने की बात करने वाले संगठन
- बड़ी कंपनियों के managers लगभग हमेशा कहते हैं कि वे डेटा-ड्रिवन organization चाहते हैं, लेकिन वास्तव में उस दिशा में उठाए गए कदम बहुत कम दिखते हैं
- Power BI developers को उस देश की सालाना आय के हिसाब से 90th percentile के बराबर औसत salary मिलती है, लेकिन उनका काफी काम data sources से connect करने के बाद spreadsheet-based bar graphs को drag-and-drop करने तक सीमित रहता है
- Power BI usage metrics track करता है, और कई dashboards लगभग इस्तेमाल ही नहीं होते
- 8,000 लोगों वाले संगठन में पिछली टीम द्वारा बनाए गए 50–100 dashboards में से केवल लगभग 3 इस्तेमाल हुए
- जिन dashboards पर visits हुईं, उनमें भी अक्सर team members उसी दिन data refresh हुआ या नहीं, यह check करने गए थे
- team की maintenance cost करीब 1 मिलियन डॉलर आंकी गई
- manager यह नहीं कह सकता कि “हमें डेटा-ड्रिवन नहीं बनना है,” इसलिए संगठन digital transformation जैसे शब्दों से उन कोशिशों को सही ठहराते हैं जो असल revenue नहीं बनातीं
- पहले कभी ऐसी योजनाओं को सफलतापूर्वक पूरा न किया गया हो, फिर भी यह बात बार-बार दोहराई जाती है कि मौजूदा initiative खत्म होने पर चीजें बेहतर हो जाएंगी
Honne: संगठन की बकवास पैदा करने वाले दो दबाव
-
Sturgeon’s Law
- पहला दबाव Sturgeon’s Law है, यानी यह सरल वास्तविकता कि “हर चीज का 90% खास नहीं होता”
- कई managers ने लोगों को प्रभावी ढंग से manage करने के लिए स्वतंत्र रूप से कभी सोचा ही नहीं होता, और नतीजतन वे Agile जैसे buzzwords दोहराते हैं
- यह उदाहरण भी आता है कि कई programmers को abstraction क्या है, यह भी ठीक से नहीं पता
- जैसे अच्छे लोग, training और sport की समझ के बिना fencing team competition नहीं जीत सकती, वैसे ही जब अक्षम लोग निर्णय लेते हैं तो संगठन से अच्छे परिणाम की उम्मीद करना मुश्किल है
- जो लोग buzzwords को सचमुच दोहराते हैं और अपने career में स्पष्ट सफलता न होने पर सवाल नहीं उठाते, वे समय के साथ उन लोगों से ज्यादा आसानी से promote हो जाते हैं जो चापलूसी को मजबूरी में act करते हैं
-
अच्छे लोग भी अक्षम माहौल से घिरे रहते हैं
- भले ही आप अपने role में ठीक-ठाक 10% लोगों में आते हों, आसपास काम न कर पाने वाले बहुत लोग होते हैं, और काफी समय उनके बनाए problems हल करने में जाता है
- एक platform के उदाहरण में संगठन ने 2 साल में भारी खर्च किया, लेकिन जिम्मेदार engineers infrastructure control के लिए spreadsheets का इस्तेमाल कर रहे थे
- नतीजतन पूरे chaos के एक हिस्से को चलाने के लिए 400 worksheets वाली spreadsheet इस्तेमाल हुई
- ऐसे व्यक्ति वाली team के अच्छे नतीजे देने की संभावना कम होती है, और बड़े संगठनों की कई teams में ऐसा कम से कम एक व्यक्ति तो होता ही है
- अगर manager ईमानदारी से कह दे कि “इस team के लक्ष्य हासिल करने की संभावना नहीं है,” तो job बचाए रखना मुश्किल हो जाता है; इसलिए system ऐसे लोगों को चुनता है जो निराशा को पहचानते नहीं, ईमानदार होने का incentive नहीं रखते, या निराशा को स्वीकार नहीं करते
Ignoring Is Bliss: बातों से ज्यादा actions देखें
- Tao of Programming का quote उस स्थिति पर व्यंग्य करता है जहां विशाल headquarters vice presidents और accountants से फूला हुआ है, अनगिनत memos निकालता है, लेकिन कोई तार्किक उद्देश्य नहीं दिखता
- बड़े संगठन अक्सर मूल रूप से dysfunctional होते हैं, इसलिए जब तक किसी manager में intelligence, truthfulness और reality awareness तीनों न हों, उसकी बातों को लगभग ignore करना ही ज्यादा साफ रास्ता है
- “बजट नहीं है” वाक्य का वास्तव में कोई मतलब नहीं भी हो सकता
- एक दोस्त ने 5 साल ईमानदारी से काम करने के बाद raise मांगी, लेकिन बजट नहीं होने के कारण उसे मना कर दिया गया
- जब वह sabbatical पर गया, उसी department, उसी job title और उसी manager के तहत एक नया full-time role खुला
- वह role किसी और को उस पूरी amount के साथ, और उससे भी ज्यादा additional amount जोड़कर offer किया गया
- संगठन की बातों में केवल वही मायने रखता है जो वास्तव में problem solve करने वाली action हो
- “हम जल्द ही concerns को address करेंगे”
- “इस issue के लिए plan चाहिए”
- ऐसी बातों को actual action न हो तो ignore किया जा सकता है
वेतन, culture और performance को कैसे आंकें
- salary negotiation में अगर आप अपनी desired number बताकर पीछे नहीं हटते, तो जो संगठन इसे impossible कहते थे वे भी अक्सर आखिरकार वही amount दे देते हैं
- किसी team में join करना है या नहीं, यह तय करते समय संगठन द्वारा बताए गए work culture या वह कैसी team बनाना चाहता है, इस पर भरोसा करना ठीक कसौटी नहीं है
- performance को लेकर गंभीर संगठन उन employees को वास्तव में हटाते हैं जिनके साथ लोग काम नहीं करना चाहते, या जो अपने subordinates को परेशान करते हैं
- जो संगठन लोगों को value देता है, वह बचे हुए लोगों को reward करता है
- ऐसे actions के बिना culture और performance की बातें करना समय की बर्बादी है, और वह समय भी छीन लेता है जिसमें music सुना जा सकता था
system बदलने में energy न लगाने का विकल्प
- सिर्फ बातों से बदलाव की असली इच्छा साबित नहीं होती
- cancer treatment जैसे बड़े उद्देश्य की बात न हो, तो system बदलने में energy झोंकने के बजाय कुछ problems solve करके घर चले जाना ज्यादा शांतिपूर्ण है
- संगठन की घोषणाएं नहीं, केवल ठोस कदम ही बदलाव की इच्छा दिखाते हैं
1 टिप्पणियां
Hacker News की राय
ऐसे ब्लॉग पोस्ट HN पर बार-बार दिखते हैं, और हर बार थोड़ा खटकते हैं
लगता है प्रोग्रामर्स की एक किस्म है जो किसी भयानक बड़ी कंपनी में ऊँची तनख्वाह पर काम करती है, रात में उस कंपनी की बदहाली पर गुस्से भरे पोस्ट लिखती है, आखिर में “मैंने नौकरी छोड़ दी” वाले पोस्ट पर खत्म करती है, और फिर किसी दूसरी भयानक बड़ी कंपनी में चली जाती है
लेकिन हर workplace ऐसा नहीं होता, और मान भी लें कि विशाल कंपनियाँ अनिवार्य रूप से मूर्खों से भरी होती हैं, तब भी विशाल कंपनी में काम करना जरूरी नहीं है
अच्छी tech कंपनियाँ और संतोषजनक काम बहुत हैं, फिर भी blogosphere में बार-बार ऐसा pain porn दिखता है कि लोग किसी भयानक विशाल कंपनी से निकल नहीं सकते और “घर जाकर निराश हो जाते हैं”
अगर आपने ऊँची तनख्वाह के लिए मानसिक स्वास्थ्य से समझौता करने का चुनाव किया है तो ठीक है, लेकिन कृपया ऐसा न कहें जैसे कोई विकल्प था ही नहीं
मैं अमेरिका में नहीं रहता, इसलिए उतना नहीं कमा सकता, लेकिन अगर अमेरिका में होता तो अपमानजनक लगने वाले LeetCode भी जान लगाकर हल करता। सिर्फ एक वजह है: मैं पूरी जिंदगी काम नहीं करना चाहता
कम कमाते हुए किसी unicorn startup के शुरुआती employee जैसी lottery लगने की उम्मीद करना योजना नहीं, बस wishful thinking है; और बेकार software बनाते हुए अपनी प्रतिभा बर्बाद करने पर हर बार आत्मा थोड़ी-थोड़ी मरती है, लेकिन असली विकल्प बहुत कम हैं
बात यह नहीं कि छोटी कंपनी में काम नहीं कर सकते, बल्कि take-home pay में कमी सहनी पड़ेगी, इसलिए वह व्यावहारिक रूप से विकल्पों से बाहर हो जाती है
या तो कर्मचारियों के साथ बर्ताव खराब है, इसलिए hiring और retention के लिए ज्यादा देना पड़ता है; या management बार-बार अचानक layoffs करता है, इसलिए income loss के जोखिम की भरपाई करनी पड़ती है; या reputation इतनी खराब है कि उस कंपनी से जुड़ने का जोखिम उठवाने के लिए ज्यादा पैसा देना पड़ता है
अतिरिक्त compensation कंपनी इसलिए नहीं देती कि वह चाहती है, बल्कि इसलिए देती है क्योंकि उस काम को कर सकने वाले लोगों को hire और retain करने के लिए यह जरूरी है। “हम premium इसलिए देते हैं क्योंकि हम best developers hire करते हैं” वाली बात, जोखिम के कारण overpay करने को लेकर management की self-justification जैसी है
compensation देखते समय खुद से और interviewer से पूछें कि यह कंपनी extra compensation क्यों दे रही है; इससे आप कई सालों की बदहाली से बच सकते हैं
ज्यादातर organizations में ज्यादातर dashboards को बनाने वाली team के अलावा लगभग कोई इस्तेमाल नहीं करता। कोई report इस्तेमाल होनी है तो वह सच में useful होनी चाहिए, और usefulness आम तौर पर decision-makers को निर्णय लेने में मदद करना या frontline कर्मचारियों की रोजमर्रा का काम करने की क्षमता बढ़ाना होता है
Power BI जैसे tools इन दोनों उपयोगों के लिए अच्छे नहीं बैठते। पहले में executives को context के बिना charts की grid देखकर data समझना पड़ता है, और दूसरे में use case के हिसाब से सावधानी से design किया गया तेज user experience चाहिए, जो dashboards से लगभग असंभव है
इसलिए मैं इन दोनों उपयोगों को लक्ष्य बनाकर open-source BI tool Evidence.dev (https://github.com/evidence-dev/evidence) बना रहा हूँ। इसमें data के साथ सीधे context जोड़ा जा सकता है, use case के हिसाब से user experience design किया जा सकता है, और यह fast है
पिछली HN चर्चाएँ: https://news.ycombinator.com/item?id=35645464 (97 comments), https://news.ycombinator.com/item?id=28304781 (91 comments)
बड़ी कंपनियाँ ज्यादातर लोगों के लिए जरूरी नहीं कि बुरी जगह हों; बस management को efficiency और data-driven जैसी बातें कहना बंद करना चाहिए। कोई भी उन पर विश्वास नहीं करता, और वे खुद भी नहीं करते
यह लेख बहुत सुखद surprise था; और corporate chaos का बचाव करने के लिए कोई कूदे, उससे पहले तक यह दुखद रूप से सटीक था, साथ ही पढ़ते हुए कई बार हँसी भी आई
जवाब लगभग हमेशा financial incentives होता है। अब तक मैंने कई काफी नामी managers को जाना है; वे सभी होशियार और काम निकालने वाले लोग हैं, लेकिन अंतहीन meetings में घसीटे जाते हैं और मूल लेख में कई बार बताए गए scripts रटकर बोलते हैं। क्योंकि अगर वे ऐसा न करें तो उनका boss उन्हें useless समझेगा और आखिरकार निकाल देगा
लोग अच्छी salary वाली आरामदायक जगह ढूँढते हैं और economic या organizational ladder चढ़ने के लिए जो जरूरी हो, वह करते हैं। काफी लोग, शायद 20–30%, अच्छी तरह जानते हैं कि वे बकवास कर रहे हैं, लेकिन उन्हें लगता है कि उनके पास विकल्प नहीं है
उल्टा, पहले ऐसे भी मामले रहे हैं जहाँ company owners managers से विनती करते थे कि समस्याएँ जैसी हैं वैसी बताइए, बुरी खबर लाने पर कभी नहीं निकालेंगे इसकी कसम खाते थे और contract तक करते थे, फिर भी उनके नीचे के managers सब चापलूस yes-men थे
यह काफी tragic है और collective delusion जैसा दिखता है। पुराना लेख “Bullshit Jobs” बार-बार याद आता है; वह आज भी सही है और लगता है अगले कई दशकों, शायद सदियों तक भी सही रहेगा
व्यक्ति के incentives स्वाभाविक रूप से promotions से जुड़ते हैं, और “difficult person” बनना हर कोई टालना चाहता है। संगठन की social और political structure सुधारने की कोशिश करने से ज्यादा आसान है responsibility से बचना और blame shift करना
मान लें सुधारने में सफलता भी मिल जाए, तो भी organization शायद इतना sophisticated न हो कि उस काम को समझे और उसका credit दे
Tylenol की bottle के label को देखें तो trademark description, non-discrimination clause, और काल्पनिक liability situations पर कठिन legal language के कई paragraphs मिलते हैं, लेकिन असली dosage chart ढूँढना मुश्किल होता है
गलती होने पर जान किस चीज से जाती है, manufacturer किसे महत्वपूर्ण मानता है, और ये दोनों हमेशा अलग क्यों होते हैं
employee के नजरिये से risk लेने पर हासिल कुछ नहीं, इसलिए कोई भी risk स्वीकार करना कठिन हो जाता है
अगर समस्याएँ नहीं हैं तो middle manager की जरूरत ही क्या है। बेशक fake problems पैदा करने वालों को भी निकाल देना चाहिए
अगर आप हमेशा मेरी बात से सहमत ही होने वाले हैं तो मुझे आपकी जरूरत क्यों होगी
मूल लेख में ऐसा लगता है कि वह एक ऐसी चीज़ को तकनीकी तरीकों से हल करने की आम गलती कर रहा है जो मूल रूप से राजनीतिक समस्या है
अब तक मिले सभी Derek जानते थे कि वे किस स्थिति में हैं, और वे ऐसे दखलंदाज़ इंजीनियरों से बेहद डरते थे जो data से उनकी अक्षमता साबित कर सकते थे, इसलिए वे उन्हें ऐसी जगह धकेलने की कोशिश करते थे जहाँ ऐसा करना असंभव हो
“The Office” में Michael Scott का चित्रण कभी-कभी इतना वास्तविक लगता था कि चुभता था
लेकिन यह जान लेने पर इसे कम-से-कम मानसिक शांति के लिए इस्तेमाल किया जा सकता है। Derek को एक इंसान के रूप में जानें और उसका भरोसेमंद बनें, तो पता चलता है कि उनके बनाए कई “बेवकूफाना Jira tickets” असल में उन बेवकूफाना requirements और policies से निकलते हैं जिनका पालन करना पड़ता है
व्यस्तता और अक्षमता की गहरी वजह—चाहे वह ऊपर का manager हो या गलत policy—समझ में आ जाए, तो Derek लोगों के साथ मिलकर उन्हें bypass या ठीक किया जा सकता है। बेशक bypass करना ठीक करने से कहीं आसान है
फिर ऊपर के लोगों तक पहुँचकर यह समझना कि उन्होंने ऐसी policies क्यों बनाईं, और धीरे-धीरे बड़ी तस्वीर दिखने लगती है। आम तौर पर हर पागलपन के पीछे कोई वजह होती है, और वहाँ तक पहुँचने के लिए शिष्टता, धैर्य और सहानुभूति चाहिए
ऐसा करने की जरूरत क्यों है? क्योंकि अंततः आप “काम निकलवा देने वाले व्यक्ति” के रूप में जाने जाते हैं और अधिक रोचक व महत्वपूर्ण projects में खिंच जाते हैं। लोग व्यक्तिगत स्तर पर भी आप पर भरोसा करने लगते हैं, और भले ही राजनीतिक समस्याएँ हल न हों, उत्पादक बने रहने और आसपास के लोगों के साथ अच्छे संबंध रखने की मानसिक शांति तो मिलती है
मैं देखना चाहूँगा कि ऐसा लेख लिखने वाला व्यक्ति 10 साल बाद अपने संगठन को फिर से देखकर यह आंके कि उस समय उसका निर्णय सही था या नहीं
इसका मतलब यह नहीं कि हर संगठन में dysfunction नहीं होता, लेकिन जब मैं छोटा था तो दिखने वाली गलत चीज़ों पर अटक जाता था और उन समस्याओं को नज़रअंदाज़ करता था जिन्हें मैं खुद बना रहा था, या उन systems और programs को जिनसे संगठन सफल हुआ था
उम्र बढ़ने और दूसरे नजरिए वाली भूमिकाओं में आने पर मैंने पूरे system को दोष देना बहुत कम कर दिया। शायद मैं भाग्यशाली रहा, लेकिन यह लेखक समझदार लगता है, इसलिए 5 या 10 साल बाद उसके विचार भी देखना चाहूँगा
इसका मतलब यह नहीं कि hierarchy स्वभाव से बुरी है, लेकिन उस संरचना और उसके साथ आम तौर पर आने वाली चीज़ों के परिणाम होते हैं। छोटे scale पर भी यह productivity को गंभीर रूप से बाधित कर सकती है
जब इस पर गहराई से सोचना शुरू करते हैं, तो दिखता है कि Agile Manifesto का असर कितना व्यापक है, और उसकी बातें पारंपरिक corporate structure और उसके इर्द-गिर्द बने processes के लिए असल में nuclear bomb जैसी हैं
कई संगठनों के internal messages अक्सर सचमुच बुरी चीज़ों को ढकने वाले, या management के productive काम न कर पाने या न करना चाहने के कारण बनाए गए distractions जैसे लगे
उस नजरिए से छोटी team का dysfunction पूरे संगठन के लिए शायद बहुत मायने न रखे
छोटे होते समय मैं ऐसी बातों में उलझा रहता था, लेकिन बाद में पता चला कि headquarters जैसा व्यवहार करने वाले भरोसेमंद, suit पहने experts गैरकानूनी काम कर रहे थे, workplace affairs से परिवार बर्बाद कर रहे थे, आसपास वालों को परेशान कर रहे थे, और दूसरे लोगों का काम बिगाड़ रहे थे
उदाहरण के लिए, अगर 2017 में Amazon Devices की econometrics team में काम करते हुए आपने चिल्लाकर कहा कि पूरा संगठन खतरे में है, लेकिन PhD economists और executives ने अनसुना किया, और 5 साल बाद division में बड़ी कटौती हुई और अरबों dollars का नुकसान हुआ, तो आगे क्या?
अगर आपने WarnerMedia executives को चेतावनी दी कि Johnny Depp को पुरुष victim के रूप में निकाले जाने से ठीक पहले भीतर anti-male sentiment है, लेकिन नतीजतन दो मुख्य franchises बर्बाद हो गए, तो क्या करना चाहिए?
या अगर 2022 की शुरुआत में Amazon में financial technology division के unprofessional रवैये को देखकर आपने चेतावनी दी कि financial problems आने वाली हैं, फिर भी आपको अनसुना किया गया, तो क्या?
अगर आपने कई बार अरबों dollars की गलतियाँ पहले से सही पकड़ लीं, लेकिन employer को फर्क नहीं पड़ता, तो WarnerMedia, Amazon, Target, Disney, Bud Light जैसी जगहों पर दिखने वाली चीज़ों में हिस्सा नहीं लेना चाहता
यह कह पाने की स्थिति होनी चाहिए कि मैंने चुप रहकर चुप्पी की कीमत लेकर shareholders को धोखा नहीं दिया, बल्कि shareholders के लिए सही काम किया
100 चीज़ें टूटी हों, तब भी ज्यादातर मामलों में आखिरकार सब किसी तरह ठीक चलता रहता है
संगठन स्वाभाविक रूप से सुधार नहीं चाहते। bosses में feedback लेने लायक विनम्रता होनी चाहिए, लेकिन ज्यादातर लोग feedback स्वीकार नहीं कर पाते, खासकर वे bosses जो अपने subordinates को खुद से नीचे मानते हैं
पिछली नौकरी में सबसे बुद्धिमान कर्मचारियों के सुझाव भी bosses ने पूरी तरह ignore किए। बदलाव केवल तब हुआ जब customers, media, partners या auditors ने सुझाव दिए; कोई भी outsider, सबसे अनुभवी employee से ज्यादा company की दिशा पर असर रखता था। App Store की एक anonymous review भी ज्यादा प्रभावशाली थी
हमें ignore किए जाने की वजह साफ थी: bosses उन लोगों से निर्देश नहीं लेना चाहते थे जिन्हें वे manage करते थे। उनका घमंड और कमजोर आत्मसम्मान इसकी इजाजत नहीं देता था
कभी-कभी संगठन को बस यह नहीं पता होता कि वह जानता है; और अधिकतर वह पहले से जानता है कि क्या करना चाहिए, लेकिन कठिन फैसले पर टिके रहने के लिए किसी बाहरी पक्ष से मिलने वाला विश्वसनीय बहाना चाहिए होता है
8,000 कर्मचारियों वाली कंपनी में dashboard maintain करने की लागत 10 लाख डॉलर है जैसे आंकड़ों के आधार पर जब कोई लेख कहता है कि management गलत है, तो अक्सर लगता है कि engineer बहुत मामूली numbers पर ज़रूरत से ज़्यादा focus कर रहा है
8,000 कर्मचारियों के scale पर, अगर कोई manager ऐसा एक बदलाव ढूंढ ले जिससे employee efficiency साल में सिर्फ 125 डॉलर बढ़े, तो dashboard maintenance पर खर्च हुए पूरे 10 लाख डॉलर की भरपाई हो सकती है
हर साल एक नया 125 डॉलर वाला efficiency improvement मिल जाए, तो पांचवें साल तक सालाना 10 लाख डॉलर का खर्च हर साल 50 लाख डॉलर की बचत जैसा हो जाता है
औसत reader के लिए ज़्यादा अहम बात यह है कि इस क्षेत्र में एक बड़ा department है, जहां लगभग सारा काम अर्थहीन है। क्योंकि इस scale पर numbers मायने नहीं रखते
core business इतना ज़्यादा पैसा कमाता है कि वह ऐसे departments को पाल सकता है जो इस बात की फिर से पुष्टि करने के अलावा कुछ नहीं करते कि हम उनके जिम्मे किए गए काम की परवाह करते हैं
अपने-आप में यह ठीक है, लेकिन अगर आप यह सोचकर समय बर्बाद करें कि लोग सचमुच dashboard पढ़ना चाहते हैं, तो पागल हो जाएंगे। हकीकत में इसका कोई लेना-देना नहीं है; बस एक team चाहिए जो कह सके, “हम data को महत्व देते हैं”
“efficiency improvement” अक्सर एक नाटक जैसा होता है, ताकि तब effort दिखाया जा सके जब growth rate कम या शून्य हो और validate करने लायक कोई नया product भी न हो
अगर सच में कोई भी dashboard नहीं देखता, तो वह बेकार होगा, लेकिन views कम हों तब भी value बहुत बड़ी हो सकती है
एक और संभावना: बड़ी company में काम करने वाला मेरा non-developer दोस्त साल में सिर्फ 2 महीने मेहनत से काम करता था और बाकी 10 महीने कुछ नहीं करता था। जब उसने काम मांगा, तो boss ने कहा, “बस busy होने का दिखावा करो”
यह outsourcing के लिए अच्छा candidate लगता है, लेकिन उन 2 महीनों का काम काफी important था, और in-house employee आम तौर पर ज़्यादा भरोसेमंद होता है और company की knowledge भी ज़्यादा रखता है। असल में उसे उन 2 महीनों के काम का pay मिल रहा था और बाकी समय standby में रहने का
यह extreme और साफ़ उदाहरण है, लेकिन लगता है ऐसी चीज़ें आम होंगी; बस आम तौर पर “busy होने का दिखावा करो” की जगह “BI dashboard बनाओ” जैसे छोटे-मोटे काम दे दिए जाते हैं
यह रोज़ करीब 50 cent है, और “employees से paperclips reuse करवाकर company सालाना 10 लाख डॉलर बचाएगी” जैसी PR, marketing या self-promotion वाली बात जैसा है। क्या कोई सच में इस पर विश्वास करेगा?
क्या मतलब यह है कि 8,000 लोगों पर असर डाल सकने वाला manager रोज़ 50 cent बचाने की कोशिश करेगा, लेकिन बेकार reporting department को हटाकर एक झटके में सालाना 10 लाख डॉलर बचाने के बारे में नहीं सोचेगा?
ऊपर से, जो company cool दिखने के लिए 10 लाख डॉलर वाला department बनाए रखती है, उस पर यह भरोसा करना मुश्किल है कि वह हर साल बिखरे हुए efficiency improvements से 10 लाख डॉलर, वह भी लगातार 5 साल तक, ढूंढ लेगी
हालांकि मैं पूरी तरह विरोध में नहीं हूं। https://danluu.com/sounds-easy/, https://danluu.com/in-house/ में जैसे बताया गया है, बड़ी companies में बहुत छोटे percentage improvements भी absolute amount में बड़े होते हैं, इसलिए in-house expertise आसानी से अपना cost recover कर सकती है
लेकिन https://danluu.com/people-matter/ के निचले हिस्से की तरह, कुछ companies में लोगों ने जितना सालाना improvement करने का दावा किया, उन सारे numbers को जोड़ने पर वह actual revenue या user growth से कहीं ज़्यादा निकलता था। 8,000 लोगों के लिए रोज़ 50 cent improvement का दावा आसानी से prove या disprove नहीं किया जा सकता, इसलिए उसे inflate करना आसान है—यह criticism उसी से जुड़ती है
10 लाख डॉलर UK के average household की tax के बाद lifetime income के बराबर है। उसे “सचमुच मामूली number” कहना उपयोगी argument से ज़्यादा तिरस्कारभरा दिखावा लगता है
अगर वह सच में मामूली है, तो company एक बार में बड़ी बचत करने की कोशिश क्यों नहीं करेगी, और इसके बजाय हर साल, वह भी पांच गुना, ज़्यादा मुश्किल और बिखरे हुए तरीके से बचत करेगी—ऐसा क्यों माना जाए?
संदर्भ: https://www.dailymail.co.uk/news/article-442813/Dragons-Den-...
नौकरी में आने के बाद मुझे सबसे चौंकाने वाली बात, और लगता है लेखक ने भी ऐसा ही महसूस किया, यह थी कि ज्यादातर लोग काम में लगभग रोगात्मक स्तर की शान/गर्व नहीं रखते। “passion” शब्द मुझे पसंद नहीं, लेकिन मतलब कुछ वैसा ही है
मैं यह नहीं मानता कि वे लोग मूल रूप से आलसी बेवकूफ हैं। कुछ या कई ऐसे हो सकते हैं, लेकिन बहुत से लोग आलसी और उदासीन सहकर्मियों से रूपक रूप में पिट-पिटकर ऐसा रवैया सीख जाते हैं
कर्मचारियों के रूप में परिपक्व होते समय मैंने कई लोगों को यह बदलाव झेलते देखा है, और अपने भीतर भी महसूस किया है, इसलिए कह सकता हूँ कि मुझे पता है। मैं यह साबित नहीं कर सकता कि यह उम्र या जीवन की स्थिति—जैसे काम में खुद को साबित करना चाहने वाले युवा अविवाहित व्यक्ति और परिवार को प्राथमिकता देने वाले व्यक्ति—के फर्क से स्वतंत्र है
फिर भी मैंने खुद देखा है कि परिवार, जिम्मेदारियाँ और शौक होने के बावजूद लंबे समय तक ध्यान लगाकर गहराई से काम करने वाले कुशल कर्मचारी निश्चित रूप से मौजूद हैं
विरोध हो सकता है, लेकिन इस घटना को जो भी कहा जाए, मुझे लगता है यही age discrimination की नींव है। यह सचमुच देखा जाता है कि जीवन लोगों से उत्साह को पीट-पीटकर निकाल देता है और काम को बस ऑफिस आने-जाने की चीज बना देता है
यह सबके साथ नहीं होता। interns या नए-नए graduates के साथ काम करना मुझे इसलिए भी पसंद है कि skills और knowledge कम होने के बावजूद वे आम तौर पर अभी इस बदलाव से नहीं गुजरे होते
ऊपर से, ज्यादातर कंपनियों में हर दिन 100% देना promotion पर इतना बड़ा असर भी नहीं डालता। ठीक-ठाक बहाव में चलते हुए भी काफी आराम से टिके रहा जा सकता है
हाँ, अपवाद के तौर पर बहुत ज्यादा वेतन देने वाली कंपनियाँ होती हैं, और उन्हें हर दिन 100% देने वाले कर्मचारियों को रोके रखने के लिए ऊँची salary देनी पड़ती है
इसलिए जो बचता है वह बिना गर्व का काम होता है, और वही फिर निराशा पैदा करता है
सबसे अच्छी teams वे थीं जहाँ छोटी teams एक-दूसरे के काम और कभी-कभार के त्याग, जैसे on-call, की परवाह करती थीं और एक छोटे परिवार जैसी लगती थीं
जब दूर बैठा manager, जो आपको सिर्फ quarterly goals पूरा करने वाले system की तरह देखता है, उस बिना-गर्व वाली स्थिति से बीच में आकर छेड़छाड़ शुरू करता है, तो वह परिवार जैसा एहसास गायब हो जाता है और सब फिर आत्मा को कुचल देने वाली निरर्थकता में लौट जाता है
लेकिन इतनी लगन के बावजूद passion आपको layoff से नहीं बचाता। Fortnite से अरबों डॉलर कमाने वाली Epic ने भी परवाह न करने का फैसला किया। कोई पवित्र जगह नहीं है
व्यक्तिगत रूप से थोड़ी inefficiency या कभी-कभार की incompetence मुझे ठीक लगती है। games में मैंने जानबूझकर की गई incompetence लगभग नहीं देखी; designer को performance impact का पता न हो सकता है, और programmer पहली कोशिश में artist tools का user experience अच्छा न बना पाए, ऐसा भी हो सकता है
लेकिन 20 साल पहले कंपनियाँ कम-से-कम loyalty का दिखावा तो करती थीं और tenure को reward करने का दिखावा भी करती थीं, अब वह लगभग खत्म हो गया है। जब पता है कि 2–3 साल बाद, या 18 साल बाद, वे दिल तोड़ देंगे, तो दिल क्यों लगाएँ
https://gamerant.com/blizzard-layoffs-18-year-veteran/
क्योंकि इसका मतलब है A) जिंदगी काम के इर्द-गिर्द नहीं घूमती, और B) जरूरत पड़ने पर दिमाग में “मुझे फर्क नहीं पड़ता” वाला switch on/off करने की भावनात्मक ताकत है
मुझे यह परिपक्वता और सफलतापूर्वक adapt कर सकने वाले व्यक्ति का संकेत लगता है
मैं एक मध्यम आकार के सरकारी संगठन में काम करता हूँ; reorganization को 6 साल हो चुके हैं, कोई भी असल में जरूरत नहीं समझता इसलिए 2 साल बाद project cancel हो जाता है, schedule overrun की संभावना की वजह से rebuild छोड़ दिया जाता है, और original system maintain करने के लिए संबंधित background वाले लोग hire नहीं किए जाते
जिस group को automation की सख्त जरूरत है, उसे developers नहीं दिए जाते, फिर आखिर में किसी senior को ऐसे code odd-job worker की तरह लगा दिया जाता है, और security team सारे influence पर कब्जा रखती है पर यह नहीं सोचती कि वे लोगों की जिंदगी कितनी दयनीय बना रही है
हाँ, dysfunction कहना सही है
संगठन का उस expert द्वारा सुझाए गए बदलाव करने का कोई इरादा नहीं होता, लेकिन उसे hire करने के तथ्य से वे दावा कर सकते हैं कि वे समस्या से निपट रहे हैं
साथ ही, जब चीजें गलत होती हैं, या गलत होंगी, तो जिम्मेदारी डालकर निकालने के लिए एक scapegoat भी मिल जाता है
मैं समझता हूँ कि यह महत्वपूर्ण है, लेकिन कभी-कभी लगता है जैसे मेरे सामने इतनी security procedures लगा दी गई हैं ताकि मैं कोई काम ही न कर सकूँ
रोज एक घंटे से ज्यादा इधर-उधर login और logout करने में निकल जाता है, और deployment के समय security checks का इंतजार करते हुए फिर एक घंटा चला जाता है
समझदार व्यक्ति खुद को आसपास के लोगों से बेहतर नहीं मानता
यह लेख चिढ़ पैदा करता है। incentives और success के mismatch, और कठिन सच न बोलने के लिए corporate bullshit जैसी बातों में कुछ सही बातें हैं
लेकिन दूसरे भाग में लेखक द्वारा अपने लिए दावा की गई बुद्धिमत्ता को सहारा देने लायक ठोस तर्क की कमी है
software product बनाना fencing tournament से तुलना करना बहुत खींचा हुआ है, और दूसरे भाग के ज्यादातर तर्क उसी premise पर टिके हैं
बेहतरीन चीज बनाने के लिए किसी अद्भुत individual की नहीं, बल्कि बेहतरीन team की जरूरत होती है। इसलिए बहुत से लोग systems से निपटने की कोशिश करते हैं
individual incentives को देखते हुए यह कठिन है, लेकिन इसलिए नहीं कि सब मूर्ख हैं; बल्कि इसलिए कि हर कोई कंपनी से ज्यादा अपने हितों को समझदारी से प्राथमिकता देता है
मुझे लगता है यह prisoner’s dilemma की अभिव्यक्ति है
अगर संगठन में हर कोई सहयोग करे और अपनी पूरी कोशिश करे तो सब जीतेंगे, लेकिन अगर कुछ लोग या managers पहले अपना फायदा और job security देखने लगें, तो सही काम करने वाले लोग नुकसान उठाते हैं
हम सभी अपने बनाए हुए उपकरण के कैदी हैं