मेरे जानने वाले सबसे खराब प्रोग्रामर
(dannorth.net)- एक Big Bank consulting team ने व्यक्तिगत productivity को पूरा किए गए stories/story points से मापने की कोशिश की, और Tim Mackinnon को इस metric पर बार-बार 0 score मिला
- 0 score मिलने की वजह यह नहीं थी कि वे काम नहीं कर रहे थे, बल्कि यह थी कि वे अपने नाम से story नहीं लेते थे और दिन का ज़्यादातर हिस्सा pair programming में बिताते थे
- कम अनुभवी developers को वे सीधे जवाब देने के बजाय Socratic questions के ज़रिए सीखने का मौका बनाते थे, और senior developers के साथ अलग-अलग नज़रियों से मिलकर बेहतर solutions खोजते थे
- Tim के साथ टीम ज़्यादा प्रभावी, productive और aligned तरीके से काम करती थी, और manager ने आखिरकार Tim को रखते हुए व्यक्तिगत productivity metric को चुपचाप हटा दिया
- व्यक्तिगत contribution को अलग करके मापने का तरीका Tim जैसे योगदानों को 0 बना सकता है, इसलिए productivity को business impact और team-level flow के रूप में देखना चाहिए
व्यक्तिगत metrics से बना “0-score programmer”
- Big Bank की एक टीम ने व्यक्तिगत performance evaluation और development purposes के लिए individual performance metrics लागू किए
- manager ने code lines या bugs की संख्या जैसे आसानी से manipulate हो सकने वाले metrics से बचते हुए, business value का प्रतिनिधि मानकर completed stories या story points को मापने का आधार बनाया
- Jira जैसे tool में हर व्यक्ति का नाम story पर जुड़ा होता था, इसलिए individual productivity metrics बनाना आसान था
- Tim Mackinnon का score सिर्फ कम नहीं था; हर हफ्ते और हर iteration में शाब्दिक रूप से 0 था
- manager का मानना था कि Tim को टीम से हटाकर किसी ऐसे व्यक्ति से replace करना चाहिए जो stories वास्तव में “deliver” करता हो, लेकिन team lead ने इससे इनकार किया
Tim ने वास्तव में क्या deliver किया
- Tim अपने नाम से stories नहीं लेते थे; इसके बजाय वे रोज़ अलग-अलग team members के साथ pairing करके काम करते थे
- कम अनुभवी developer के साथ काम करते समय वे उन्हें खुद drive करने देते और समाधान तक धीरे-धीरे guide करते
- वे जवाब थोपते या push नहीं करते थे
- “what if”, “how else” जैसे सवालों और Socratic questions से learning moments बनाते थे
- senior developers के साथ वे co-creation या sparring जैसी शैली में काम करते थे, और अलग-अलग worldviews को समस्या पर लागू करके ऐसे नतीजे बनाते थे जो अकेले सोच पाना मुश्किल होता
- Tim सीधे software deliver करने के बजाय, software deliver करने वाली टीम को विकसित करते थे
- पूरी टीम ज़्यादा प्रभावी और productive तरीके से चलती थी
- ज़्यादा aligned और ज़्यादा उदार तरीके से काम करती थी
- साथ काम करने का अनुभव भी ज़्यादा enjoyable हो जाता था
- जब manager टीम को observe करने आया, Tim हमेशा किसी और के साथ “उस व्यक्ति का काम” कर रहे होते थे, और इससे output की quality बेहतर होती और value delivery time भी कम होता
- आखिरकार टीम ने Tim को बनाए रखा, और individual productivity metrics के बजाय team accountability चुनी
- high-performing unit के रूप में संगठन को दिए गए business impact को track और celebrate किया गया
Productivity में क्या देखना चाहिए
- productivity measurement अपने-आप में ज़रूरी है, और accountability के लिए measurable business impact ideal है
- बचाई गई राशि
- उत्पन्न की गई राशि
- सुरक्षित रखी गई राशि
- अगर direct business impact मापना मुश्किल हो, तो proxy business metrics भी इस्तेमाल किए जा सकते हैं
- complex adaptive systems में किसी एक व्यक्ति के contribution को अलग करके मापने की बुनियादी धारणा ही अस्थिर हो जाती है
- DORA metrics किसी individual piston के contribution को नहीं, बल्कि work system कैसे operate करता है इसे मापते हैं
- इन्हें Westrum culture indicators के रूप में देखा जा सकता है
- इन्हें यह देखने वाले metrics के रूप में भी देखा जा सकता है कि technical changes production तक कैसे flow करते हैं
- individual metrics Tim जैसे लोगों के वास्तविक contribution को 0 बना सकते हैं, और team-level performance व system-level flow को देखने का तरीका अधिक उपयुक्त है
1 टिप्पणियां
Hacker News की टिप्पणियाँ
करीब 20 साल पहले मैं एक मध्यम आकार की software company में काम करता था, जो Mac और Windows के लिए desktop app बेचती थी। टीम के ज़्यादातर लोगों को सिर्फ Mac का अनुभव था और वे Windows अभी सीख ही रहे थे, इसलिए Windows version में बहुत समस्याएँ थीं
उस समय मैं Windows expert के तौर पर जाना जाता था, इसलिए मुझे उस version को बेहतर बनाने और टीम को Windows programming से परिचित कराने में मदद करने के लिए hire किया गया
दिन का पहला हिस्सा आम तौर पर “house call” जैसा होता था—दूसरे developers के कमरों में घूमकर pair programming करना, bugs की जाँच करना, और Windows API best practices पर चर्चा करना। बाद में एक सहकर्मी ने पूछा कि “तुम इतना समय इतनी उदारता से कैसे दे पाते हो”
कुछ महीनों बाद review में कहा गया कि “productivity उम्मीद के मुताबिक नहीं है, खासकर यह देखते हुए कि बाकी टीम की productivity हाल में बढ़ी है,” और मुझे लगा था कि मुझे hire करने की वजह तो यही थी
ज्ञान साझा करना वह सबसे बड़ा लाभ है जो आप दूसरे developers को दे सकते हैं, लेकिन जो लोग यह रास्ता चुनते हैं उन्हें बहुत कम reward मिलता है
ऐसे developers न होते तो हम आज की software दुनिया के करीब भी नहीं पहुँच पाते, और भले ही उन्हें सीधे धन्यवाद न मिले, उनकी value निश्चित रूप से है
सभी repair tasks की priority समान थी, लेकिन difficulty अलग-अलग थी। मैंने एक महीने तक सीखकर, और क्योंकि कोई और नहीं कर रहा था, base station repair अपने ऊपर ले ली; इसमें ज़्यादा समय लगता था, लेकिन operations के लिए यह कहीं अधिक महत्वपूर्ण था
महीने के अंत की meeting में utilization का pie chart आया, और मैं अनुभवी seniors की तुलना में बहुत खराब दिख रहा था
तब मैंने सीखा कि seniors तेज़ और आसान काम ही क्यों चुनते हैं, और internal politics का अस्तित्व क्या होता है। career की शुरुआत में ही खराब manager मिलना उल्टा अच्छा ही रहा
नए boss ने माना कि पहली review में उन्होंने असल में मेरे लिए performance improvement plan लिख रखा था, लेकिन open office में shift होने के बाद जब उन्होंने देखा कि मदद लेने के लिए लोग मेरे पास line लगाते हैं और मैं किसी को वापस नहीं भेजता, तो उन्होंने उसे फेंक दिया
cubicle seat खोना थोड़ा irritate करने वाला था, लेकिन उसी वजह से open office के बारे में मेरी राय positive हुई
हालांकि अब मैं किसी भी office में काम नहीं करता, और remote न होने वाला काम फिर से लेने का इरादा नहीं है
reputation पहले बनती है, उसके बाद ही आप कुछ बदल सकते हैं; उससे पहले मुश्किल होता है
बहुत से लोग “team” के लिए optimize करते-करते ऊपर वालों की negative perception के कारण निकाल दिए गए या promotion से पीछे रह गए। इसके उलट, जो लोग company के मौजूदा महत्व वाले criteria पर अच्छी reputation बना लेते हैं, उनके bad behavior को भी काफ़ी लंबे समय तक tolerate किया जाता है
क्या वे तुरंत किसी बेहतर जगह चले गए, क्या company के performance metrics के हिसाब से अपना समय कम बाँटना शुरू किया, या क्या org chart में पर्याप्त ऊँचे किसी व्यक्ति को समझा पाए कि उन्हें सचमुच उसी role के लिए hire किया गया था
Bell Labs की एक घटना याद आती है
किसी ने patents की संख्या जैसे criteria से सबसे productive employees की गणना की, तो पता चला कि उनमें से कई लोग एक ही व्यक्ति के साथ lunch करते थे
वह व्यक्ति खुद व्यक्तिगत productivity में बहुत ऊँचा नहीं था, लेकिन हमेशा गहरे और persuasive सवाल पूछता था, जिससे उसके सहकर्मी मापने योग्य रूप से अधिक productive हो जाते थे
Bell Labs के patent department के lawyers यह समझाने के लिए कोई organizational principle खोज रहे थे कि कुछ लोग ज़्यादा productive क्यों हैं, और common point बस इतना था कि ज़्यादा patents वाले employees अक्सर electrical engineer Harry Nyquist के साथ lunch या breakfast करते थे
Nyquist ने कोई specific idea नहीं दिया था; वे लोगों को खुलकर सोचने के लिए प्रेरित करते थे, और सबसे बढ़कर अच्छे सवाल पूछते थे
लोगों का समूह एक नाज़ुक structure होता है, इसलिए अच्छी team atmosphere और अच्छे सवाल अदृश्य रूप से स्थिति सुधार सकते हैं
वरना fair salary पाना मुश्किल है
मेरे हिसाब से नहीं
कई साल तक जिस कंपनी में काम किया, वहाँ अगर आप हफ्ते में 10 points नहीं बनाते थे तो आपको performance improvement के दायरे में डाल दिया जाता था, चाहे junior हों या senior
मैं कई teams से गुज़रा, और team points कैसे measure करती है, यह developers के stress level देखकर तुरंत समझ आ जाता था
जो teams नेक नीयत से points नापने की कोशिश करती थीं, वे तनाव में रहती थीं, ज़्यादातर में burnout के संकेत होते थे, और वे हफ्ते में 60 घंटे काम करती थीं
इसके उलट, जो teams system को game की तरह treat करती थीं और समझती थीं कि यह असंभव task है, वे tickets को जितने ज्यादा हो सकें उतने points देती थीं या उन्हें छोटे tickets में तोड़कर लगातार score जमा करती थीं, और बिना stress के खुश रहती थीं
ऐसे माहौल में नियमों के हिसाब से चलना बेवकूफ़ी वाली strategy थी, और जब मैंने आखिरकार नौकरी छोड़ी तो कंपनी के 7 senior engineers भी 4 महीने के अंदर मेरे पीछे-पीछे निकल गए
बड़े uncertainty और risk वाली stories की बजाय, उन्हें ऐसी stories में बाँटना लक्ष्य है जिन्हें लगातार और बिना stress के हासिल किया जा सके
इसका मतलब यह नहीं कि वह workplace अच्छा लगता है, लेकिन जिन developers को लगा कि उन्होंने system को game किया, वे कुल मिलाकर Scrum जिस तरीके को बढ़ावा देना चाहता है उसी तरह चलते दिखे
हालांकि हर हफ्ते minimum points force करके point inflation को बढ़ावा देना भयानक management है
क्योंकि उन्होंने उन्हीं लोगों से, दबाव न डालने की तुलना में, ज्यादा काम निकलवा लिया
एक पुराने boss ने खुलकर कहा था कि project खत्म करने के लिए वे “लोगों को hire करके जला देते हैं”, और उनका plan था कि अगर वे 6 महीने उपयोगी काम कर दें तो काफी है
अगर कोई stress और कम pay सहकर रुका रहे तो कंपनी के लिए bonus जैसा था, और मैं भी ज्यादा देर नहीं टिका
अगर उस हफ्ते पूरा नहीं हुआ, तो ticket को complete mark कर देते और बचा हुआ काम bug के तौर पर नया खोल देते थे
“जिस पल कोई measurement लक्ष्य बन जाता है, वह measurement अच्छा measurement नहीं रह जाता”
कुछ जगहों पर लक्ष्य की ओर शुद्ध productivity से ज्यादा यह जानना महत्वपूर्ण था कि manager क्या expect कर सकता है
नेक नीयत से estimate लगाने वालों ने शायद सोचा होगा कि management भी नेक नीयत से काम करती है, लेकिन कई projects wishful thinking से बनाए जाते हैं या लोगों को “motivate” करने के लिए जानबूझकर बहुत छोटी deadlines रखी जाती हैं
वह stress manager की emotional satisfaction के अलावा शायद कोई खास value नहीं बनाता था
जब software engineer की performance कोई non-technical व्यक्ति evaluate करता है, तो नतीजे dramatic हो सकते हैं
मेरा दोस्त “Tommy” networking में बहुत skilled IT person था, और government-owned energy company में जाने के कुछ ही हफ्तों बाद उसे HQ की सभी buildings समेत network को modern equipment से पूरी तरह rebuild करना पड़ा
कंपनी यह काम किसी external vendor को देना चाहती थी, लेकिन finance department ने जो cost तय की थी उसे देखकर Tommy हैरान रह गया, और उसने कहा कि routers, switches, cables जैसे physical equipment और wiring के लिए 2 लोग मिल जाएँ तो वह इसे खुद कर सकता है
उसने कुछ ही हफ्तों में initial budget के दसवें हिस्से से भी कम cost में काम पूरा कर दिया, लेकिन उसे सिर्फ boss की मौखिक “धन्यवाद, अच्छा काम किया” ही मिली
पुराने खयालात वाले bosses के दौर में, जो असली value समझ नहीं पाते, IT professionals के लिए यह सचमुच कड़वा अनुभव है
बाद में Tommy contractor के रूप में जाकर extra compensation ले सकता था
एक वाकई शानदार developer जिसके साथ मैंने काम किया था, बेहतरीन code भी लिखता था और ऐसा भयानक code भी लिखता था जिसे तुरंत फेंककर दोबारा बनाना पड़े; और दोनों ही बातें उसे साथ काम करने के लिए अच्छा बनाती थीं
अच्छे code की value समझाने की जरूरत नहीं है, और संभव है कि हम आज भी उसका code use कर रहे हों
लेकिन वह emergency situations में भी कमाल का था
जब customer पूरी तरह रुक गया था और गलती हमारी हो सकती थी, वह तुरंत सामने आता, problem को जल्दी समझता, और customer को फिर से चलाने के लिए गंदा spaghetti code तेजी से लिखकर install कर देता
वह आँखों को चुभने वाला code था जिसे check in या refactor नहीं किया जा सकता था, लेकिन जब तक कोई बाद में उसे ठीक से fix करे, तत्काल crisis टल जाती थी
मुझे तो इस दूसरी ability पर और ज्यादा हैरानी होती थी, क्योंकि यह बहुत rare skill थी, और वह बस अच्छा इंसान था इसलिए सब उसे पसंद करते थे
फिर भी मैं काम जल्दी खत्म करता हूँ, और मेरे अजीब code ने emergency solve करके या bid जिताकर कई बार दिन बचाया है
“perfectionist” developers से communication कठिन है, और उनके लिए अगर code पर्याप्त रूप से design नहीं है तो speed की जरूरत समझने के बावजूद वह बेकार दिखता है
बेशक वे भी मेरे बारे में उलटा सोचते होंगे
अब हम हर हफ्ते meetings रखकर problem कम कर रहे हैं, और यह काफी अच्छी तरह काम कर रहा है
सबसे मुश्किल यह तय करना है कि जब emergency नहीं है, लेकिन schedule tight है और specs unclear हैं, तब किस type का approach सही है; कम से कम फैसला मिलकर हो जाता है
इसे खुद सीखना असंभव नहीं है, लेकिन common problems और solutions को इतना याद करना कि उन्हें mechanical तरीके से type कर सकें, मेरे लिए सचमुच तकलीफदेह काम है
जब तक आप company के मालिक नहीं हैं, आपका मूल्यांकन हमेशा दिखने वाली value से होता है
अगर employer visually आपकी value नहीं देख पाता, तो वहाँ आपके टिकने की संभावना कम है
पूरी तरह meritocratic performance system आदर्श हो सकता है, लेकिन अगर hiring या evaluation किसी और के हाथ में है, तो सफलता 100% इस पर निर्भर है कि वह व्यक्ति आपको कैसे देखता है
यह perception इस बात से बनता है कि चीजें ऊपर से कैसी दिखती हैं, चाहे वह कंपनी के लिए वास्तव में valuable हो या नहीं
यहाँ बात programming skill या real value की नहीं, बल्कि employment और evaluation की है; और कई लोग high productivity के साथ अपनी reputation management भी अच्छी तरह करते हैं
निजी तौर पर, मैं चाहता हूं कि टीम के seniors सचमुच कठिन कामों को असल में पूरा करें
juniors को काम करने में मदद करना अच्छी बात है, लेकिन जिन कठिन और जटिल कामों को ज्ञान, अनुभव और interpersonal skills की कमी के कारण junior नहीं कर सकते, उनके लिए अब भी अनुभवी लोगों की जरूरत होती है
कोई भी pair programming उसे पूरी तरह replace नहीं कर सकती
ऐसी स्थिति से बचना चाहिए जहां कम-value वाले features तो बहुत अच्छी तरह implement हो जाएं, लेकिन सबसे अनुभवी लोग कम अनुभवी लोगों को unit test लिखना जैसी चीजें सिखाने में लगे रहें और high-impact, high-priority work पूरा न हो
सिर्फ इसलिए कि junior को दिया गया है, इसका मतलब यह नहीं कि वह by default आसान problem है; वरना engineers को grow कैसे कराया जाएगा
सभी seniors को junior mentoring और collaboration में समय नहीं लगाना चाहिए, लेकिन टीम में ऐसे कुछ लोग हों तो वे force multiplier की भूमिका निभाते हैं और पूरी टीम को फायदा होता है
hiring के समय यह पता न रहा हो, तब भी अगर उसने एक उपयोगी niche role ढूंढ लिया था, तो company को इसे formal role में बदल देना चाहिए था
वह एक coach था, और अगर उसे उस role के लिए hire किया गया होता तो ठीक था, लेकिन शायद अगर coach चाहिए होता तो अलग से hire किया जाता
कठिन features कई बार juniors अनंत समय मिलने पर भी पूरा नहीं कर पाते, क्योंकि उनके पास अभी skills नहीं होतीं और वे skills बनने में सालों लगते हैं
कभी-कभी senior की मदद जरूरी होती है, लेकिन अगर इसकी वजह से senior खुद कुछ भी बना नहीं पाता, तो company के नजरिए से इसका मतलब कमजोर हो जाता है
कठिन feature किसी पर्याप्त senior व्यक्ति को दें, और अगर junior को बढ़ाना है तो उस काम के आसान हिस्से साथ में बांटें और senior से समझाने को कहें कि वह क्या कर रहा है
सभी की मदद करने वाला Tim का रवैया शानदार है, लेकिन यह भी अजीब है कि दूसरे programmers को इतनी ज्यादा मदद चाहिए कि Tim के पास अपना output देने का समय ही नहीं बचता
समस्या Tim नहीं है, बल्कि management में है जिसने experts के हमेशा मदद मांगने वाली स्थिति और volunteer जैसे Tim के कभी भी मदद करने वाले structure को ठीक माना
शुरुआत में ही अगर seniors में से किसी ने इसे ठीक से बनाया होता, तो junior भी इसे modify कर पाता
अगर उस senior ने बनाया और फिर भी structure के कारण यह कठिन और जटिल है, तो सवाल उठता है कि उसे senior क्यों कहा जाता है
फिर भी सभी seniors का काम सिर्फ juniors की मदद करना नहीं हो सकता
आजकल ऐसा व्यक्ति बनना मुश्किल है
सब कुछ दिखने वाले performance पर केंद्रित है, इसलिए ऐसे लोग layoff के target बनने में आसान होते हैं, और मैंने इसे खुद झेला है
team players, mentors, software architects धीरे-धीरे पीछे धकेले जा रहे हैं, और बहुत सारा code उगलने वाले coders उनकी जगह ले रहे हैं
technical debt के कारण feature delivery और maintainability समय के साथ गिरती जाए, फिर भी managers ऐसे developer को पसंद करते हैं जो actual released features या bugs की संख्या से अलग, हफ्ते में लगातार 5000 से ज्यादा lines लिखता हो
एक team lead और complex projects manage कर चुके engineer के तौर पर, हफ्ते में 2000 से ज्यादा lines code लिखने वाला व्यक्ति मुझे डरावना लगता है
यह साल में 100,000 से ज्यादा lines code है, और unnecessary complexity के बारे में सोचना पड़ता है
वही feature शायद 10,000 lines में, कम bugs के साथ और आधे समय में implement हो सकता है, लेकिन तब यह हफ्ते में सिर्फ 380 lines होगा और manager को पसंद नहीं आएगा
मैं मानता हूं कि हजारों lines निकालने वाला developer project की long-term direction पर पर्याप्त गहराई से नहीं सोचता, और उस code का ज्यादातर हिस्सा throwaway code जैसा लगता है
Google ने इसे कुछ हद तक Tech Lead role के रूप में institutionalize किया है, और इस engineer से individual contributor से ज्यादा force multiplier और mentor की तरह काम करने की उम्मीद होती है
यह हमेशा design के मुताबिक काम नहीं करता, शायद कम ही करता है, और TL people coordination, planning और छोटी-मोटी बहसों में फंसकर engineer की तरह काम नहीं कर पाता
फिर भी role का intent ठीक है
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
हर चीज को measure करने और जो numbers मिल सकें उन्हीं के आधार पर act करने का विचार 19वीं सदी से रहा है
managers तब से वही practices दोहराते रहे हैं, और results भी उसी तरह काफी स्थिर रहे हैं
जिस company में मैं थोड़े समय के लिए था, उसके owner चाहते थे कि latest web framework और trends के साथ चलने के लिए web service हर 6 महीने में scratch से फिर लिखी जाए
हफ्ते में 5000 lines वाला hero होता तो वे उसे वहीं hire कर लेते
maintenance projects में कभी-कभी मैं पूरा हफ्ता एक भी line लिखे बिना बिताता हूं, और कभी तो पूरे हफ्ते code lines कम करने में लगाता हूं
शानदार
rowing में seat racing नाम की training होती है, जिसमें आठ seats के अलग-अलग combinations में लोगों को डालकर और निकालकर सबसे तेज combination खोजा जाता है
individual ताकत भी metric होती है, लेकिन race boat में कौन बैठेगा, यह team speed तय करती है
आखिरकार सबसे तेज combination में सबसे ताकतवर आठ लोग ज्यों के त्यों आ जाएं, ऐसा कम ही होता है; अक्सर एक-दो “magical” लोग होते हैं जो paper पर ज्यादा बेहतर न दिखते हुए भी जिस boat में डालो उसे तेज बना देते हैं
वे दूसरों के balance, rhythm और power को subtle तरीके से improve करते हैं
कुछ coaches इसे खुशी से accept नहीं करते और resist करते हैं, और नतीजे में wins कम हो जाती हैं
software teams के साथ भी यह बहुत मिलता-जुलता है, और अंत में अहम चीज combination और results ही हैं
जब मुझसे “तकनीकी leadership” की coaching करने को कहा जाता है, तो मैं हमेशा कहता हूं कि facilitator-type employees पर ध्यान से नज़र रखें
उनकी मदद दूसरे कर्मचारियों को ज़्यादा productive और effective बनाती है, और कुछ लोगों को खुद कमाल का काम करके सारा credit लेने के बजाय दूसरों को शानदार काम करने में मदद करने से ज़्यादा job satisfaction मिलता है
ऐसे लोगों के score अक्सर कम आते हैं, लेकिन अगर वे चले जाएं तो team productivity में net decrease होता है
इसलिए मैं ऐसा tool देना चाहता हूं जिससे असल में productive न होने वाले लोगों और उन लोगों में फर्क किया जा सके जिनकी productivity दूसरों की सफलता में दिखती है
सिर्फ़ एक metric मापना और उसी के हिसाब से manage करना कभी अच्छा नहीं होता
क्योंकि जो लोग metrics को game करते हैं वे “जीतते” हैं, और ऐसा व्यवहार promotion तक ले जाता है
मैंने Google leadership को भी यह बात कही थी, लेकिन Laszlo ने कहा, “हमारे पास यही system है और यह perfect नहीं है, लेकिन हम इसी के साथ चलेंगे. इसके भीतर काम करना है या नहीं, यह आपकी choice है”
उस meeting भर से ही इतना समझ आ गया था कि senior leadership बेहतर engineering environment बनाना चाहती है या नहीं
कई नए managers, खासकर वे जो पहले individual contributor engineers रहे हैं, सोचते हैं कि “best” members को रखकर और “bad” members को निकालकर team morale और output दोनों बेहतर हो जाएंगे
लेकिन “best” की उनकी समझ लोगों को manage करने के criteria पर नहीं, बल्कि अपने पुराने काम को अच्छी तरह करने के criteria पर आधारित होती है
इसलिए वे अपने जैसी skills और habits वाले लोगों को पसंद करते हैं, और अलग skills और habits वाले लोगों को कम आंकते हैं
जब उन्हें यह एहसास होता है तो उनकी आंखें फैल जाती हैं—वह पल हमेशा दिलचस्प होता है
zero interest rate policy ने Jira boards manage करने और task lists संभालने वाले senior director जैसी roles बढ़ा दीं, और वास्तविक काम कर सकने वाले लोग कम कर दिए
मैं इस विचार के खिलाफ नहीं हूं कि कोई व्यक्ति दूसरों की productivity को facilitate कर सकता है, लेकिन अंततः कुछ खत्म करने के लिए उन “दूसरे लोगों” की ज़रूरत होती है
वरना organization necrosis का शिकार हो जाता है