रफ़्तार का धर्म

• “तेज़ी से आगे बढ़ना” जब व्यावहारिक ज़रूरत से आगे बढ़कर गंभीरता और महत्वाकांक्षा का सबूत बन जाता है, तो सावधानी से की गई समीक्षा को momentum रोकने वाला रवैया माना जाता है
• असली गति तब आती है जब काम, सीमाएँ और dependencies को समझकर, स्पष्ट निर्णय लेने के बाद execution किया जाए; लेकिन कई संगठन अस्पष्ट requirements और अधूरे decisions को ही गति का नाम दे देते हैं
• समझने वाले चरण को जल्दी निपटा देने पर rework को “iteration”, अव्यवस्था को “alignment”, और रोकी जा सकने वाली विफलता को “learning” के रूप में दर्ज किया जाता है, और अविश्वसनीय systems व workaround प्रक्रियाएँ business की मुख्य संरचना बन जाती हैं
• तत्कालता वह स्थिति है जब किसी महत्वपूर्ण काम पर सचमुच समय का दबाव हो, लेकिन जल्दबाज़ी वह स्थिति है जिसमें स्पष्टता सुनिश्चित किए बिना सिर्फ़ action से भावनात्मक राहत लेने की कोशिश की जाती है
• सही तरीके से काम करने के लिए पहले समझना, निर्णय लेना, पर्याप्त समीक्षा करना और फिर आगे बढ़ना ज़रूरी है; सोच, संदर्भ और ज़िम्मेदारी को छोड़ देने की क़ीमत टूटी हुई systems, थकी हुई teams, छूट चुके customers और लंबे समय तक चलने वाले operational घावों के रूप में लौटती है

---

जब रफ़्तार को प्रगति समझ लिया जाता है

• तेज़ launch, response, hiring, scaling और pivot को अपने आप में महत्वाकांक्षा और गंभीरता का सबूत मान लिया जाता है
  • रफ़्तार धीमी करके सोचने का अनुरोध momentum में बाधा माना जाता है
  • संरचनात्मक रूप से कमज़ोर plan की ओर इशारा करना नकारात्मक रवैया समझा जाता है
• गति, निर्णय की अनुशासित प्रक्रिया के बिना भी आगे बढ़ते रहने का एहसास देने वाले संगठनात्मक नशे की तरह काम करती है
  • सबको लगता है कि वे व्यस्त हैं और सब कुछ urgent है, इसलिए activity को ही progress का सबूत बनाया जा सकता है
  • लेकिन जिसे अक्सर speed कहा जाता है, उसका बड़ा हिस्सा सिर्फ़ नया नाम दी गई अधीरता होती है
• असली गति तब संभव होती है जब काम और constraints स्पष्ट हों, सक्षम ज़िम्मेदार लोग साफ़-सुथरे तरीके से पूरे किए गए decisions के आधार पर execute करें, और बार-बार वही चर्चा दोहरानी न पड़े
• जिन स्थितियों को आम तौर पर speed कहा जाता है, उनमें अक्सर अस्पष्ट requirements, अधूरे decisions, बिना जाँची dependencies और अपर्याप्त context बचा रहता है
  • यह एक ऐसी संरचना होती है जहाँ उम्मीद की जाती है कि अनिर्णीत समस्याएँ अगला ज़िम्मेदार व्यक्ति सुलझा लेगा, और फिर output टूटने पर सब हैरान होते हैं
  • यह इस धारणा पर बनाया गया होता है कि सोचने की प्रक्रिया सबसे महँगा हिस्सा है, और इसी वजह से विफल होता है
• यह पैटर्न सिर्फ़ software में नहीं, बल्कि operations, management, hiring, logistics, customer service, और product development में भी दिखता है, जब activity को progress समझ लिया जाता है
• समझने के लिए ज़रूरी चरण को जल्दी निपटाने के बाद, उसके नतीजों को सँभालने में दस गुना समय खर्च होता है, और रिकॉर्ड में अर्थ भी उलट जाते हैं
  • शुरुआत की जल्दबाज़ी “तेज़ execution” बन जाती है
  • सँभालने का काम “अप्रत्याशित घटना”, rework “iteration”, अव्यवस्था “alignment”, और रोकी जा सकने वाली विफलता “learning” बन जाती है
• जब हर छोटे decision में समझ से ज़्यादा speed को चुना जाता है, तो ऐसे systems जमा होते जाते हैं जिन पर कोई भरोसा नहीं करता, ऐसी प्रक्रियाएँ जिन्हें कोई समझता नहीं, ऐसी meetings जिन्हें कोई चाहता नहीं, और ऐसे dashboards जिन पर किसी को विश्वास नहीं होता
  • अस्थायी workaround आख़िरकार business को संभालने वाली अनिवार्य संरचना बन जाते हैं
  • बाद की “modernization” भी speed की पूजा को जस का तस छोड़कर सिर्फ़ दिखने वाली अव्यवस्था बदल देती है

बिना जल्दबाज़ी के सही तरीके से आगे कैसे बढ़ें

• रफ़्तार धीमी करने का मतलब धीरे काम करना नहीं, बल्कि काम को स्पष्ट बनाने की प्रक्रिया को छोड़े बिना आगे बढ़ना है
  • यह देखना ज़रूरी है कि वास्तव में क्या बनाया जा रहा है और किन लोगों की उस पर dependency है
  • यह भी देखना चाहिए कि अगर assumptions ग़लत हों तो क्या टूटेगा, क्या पहले से पता है, और किन बातों को हम न जानने का नाटक कर रहे हैं
  • अतीत में विफलता कहाँ हुई थी और सफलता के लिए कौन-सी शर्तें ज़रूरी हैं, यह भी जाँचना चाहिए
• ये बुनियादी सवाल movement से मिलने वाली तत्काल संतुष्टि को खत्म कर देते हैं और urgency या PowerPoint के पीछे छिपना मुश्किल बना देते हैं
  • क्योंकि इनमें काम को सचमुच समझना और detail decisions की ज़िम्मेदारी लेना पड़ता है, इसलिए लोग अक्सर इनसे बचना चाहते हैं
• speed decisions को लगातार अस्पष्ट बनाए रखने और details को किसी और की emergency में बदल देने की सुविधा देती है
  • जब emergency पैदा होती है, तो और तेज़ fixes, hiring, replacement और launch को फिर से समाधान बना दिया जाता है, और वही समस्या इलाज की तरह दोहराई जाती है
• तत्कालता तब उचित है जब किसी महत्वपूर्ण काम पर सचमुच समय की सीमा हो, लेकिन जल्दबाज़ी तब पैदा होती है जब स्पष्टता की ज़िम्मेदारी उठाए बिना action से भावनात्मक राहत लेनी हो
• speed की आलोचना का मतलब यह नहीं कि जानबूझकर धीरे चला जाए या हर decision को meeting में बदल दिया जाए
  • सोच-समझकर काम करने का सबूत देने के लिए deployment infrastructure खुद बनाने में 6 महीने लगाने की भी ज़रूरत नहीं है
  • बात सिर्फ़ इतनी है कि काम का इतना सम्मान किया जाए कि उसे शुरुआत से ही सही तरीके से किया जाए
• सही क्रम है समझना → निर्णय → पर्याप्त समीक्षा → execution
  • अगर यह क्रम उलट दिया जाए, तो उसकी क़ीमत टूटी हुई systems, थकी हुई teams और चुपचाप चले जाने वाले customers के रूप में चुकानी पड़ती है
  • और ऐसे operational घाव भी रह जाते हैं जिन्हें वर्षों तक workaround से ढोना पड़ता है, क्योंकि मूल कारण को फिर से समझने का धैर्य नहीं बचता
• बाज़ार में बदलाव, competition, कठिन customers, छोटी teams, तंग budget और बंद होती opportunities वास्तविक constraints हो सकते हैं
  • लेकिन इन्हें अक्सर आगे बढ़ने से पहले स्थिति को समझने वाले धीमे और कठिन काम से बचने के बहाने के रूप में भी इस्तेमाल किया जाता है
• बेहतर तरीका यह है कि शांति बनाए रखते हुए भी decisions लेते रहें और launch करते रहें
  • panic को गंभीरता, हर रुकावट को कमजोरी, और movement को ही progress समझने की गलती न करें
  • सोच, स्पष्टता, context और ज़िम्मेदारी को छोड़ देने से थोड़ी देर के लिए गति मिल सकती है, लेकिन उसका परिणाम systems और maintenance संभालने वाले लोगों को लगातार उठाना पड़ता है
  • कुछ काम जल्दबाज़ी छोड़ने के बाद ही तेज़ हो सकते हैं

[GN⁺]

Hacker News की राय

• धीरे करोगे तो smooth होगा, और smooth होगा तो तेज़ होगा
  गति के बारे में जो सीखा है, उसके हिसाब से लोग अक्सर मापते ही नहीं, या फिर सिर्फ़ वे चीज़ें गलत तरीके से मापते हैं जो तुरंत सुविधाजनक लगती हैं। सही मापन आँकड़ों से वस्तुनिष्ठ बनता है, लेकिन कुछ लोग ऐसे भी होते हैं जो आत्म-चिंतन में कमजोर व्यक्ति की तरह मापन ही ठीक से नहीं कर पाते। अनुमानित आँकड़े 80% से ज़्यादा बार गलत होते हैं और कई orders of magnitude तक चूक सकते हैं। मापन से निकले छोटे सुधार अप्रत्याशित रूप से बहुत बड़े होकर जुड़ते जाते हैं, और तेज़ होने का सबसे पक्का तरीका तकनीक और तरीकों को बदलना है। भर्ती धीमी होती है और देरी से चल रहे प्रोजेक्ट में लोगों को जोड़ने से वह और धीमा हो जाता है; technology stack की निचली layers को जितना बेहतर करते हैं, उतनी ही गति और लचीलापन साथ मिलता है, और इसका उपयोग करके scale बढ़ाया जा सकता है

  • रोइंग करने वाले बिना घर्षण के चलने की अवस्था को swing कहते हैं। जैसे झूले को जबरदस्ती हिलाने के बजाय गुरुत्वाकर्षण और momentum पर शरीर छोड़ दिया जाता है, वैसे ही नाव भी स्वाभाविक रूप से तेज़ चलना चाहती है, इसलिए ज़रूरी है कि बेतहाशा हाथ-पैर मारकर उसमें बाधा न डाली जाए। ज़रूरत से ज़्यादा कोशिश गति बिगाड़ती है, और swing कोई जोर लगाने की अवस्था नहीं, बल्कि पहले से हासिल की गई अवस्था है — Houghton Mifflin, Mind Over Water
  • यह समझना मुश्किल है कि कुछ लोग आत्म-चिंतन क्यों नहीं कर पाते, और क्या सचमुच ऐसे लोग होते हैं जिनके लिए आत्म-चिंतन अपने आप में असंभव है
  • अगर आप codebase में पहली बार ठीक से मापने वाले व्यक्ति हैं, तो बात छोटे सुधारों तक सीमित नहीं रहती। आम तौर पर बड़े और साफ़ दिखने वाले सुधार के मौके हर जगह बिखरे होते हैं
  • हर चीज़ को मापा नहीं जा सकता, और क्या मापना है यह चुनना अपने आप में एक संपादकीय फैसला है जो bias ले आता है

• तकनीकी रूप से गलत न होने पर भी, अगर ग्राहक की समस्या का व्यावहारिक समाधान खोजने में 6 हफ्तों की जगह 6 महीने लगाकर ग्राहक को थका दिया जाए, तो प्रोजेक्ट असफल हो सकता है। ग्राहक के नज़रिए से गति एक feature और आर्थिक value है
  टेक्सास की अगस्त की दोपहर में खराब एयर कंडीशनर ठीक कराने के लिए technician बुलाने वाली स्थिति को याद कर लें। जटिल और अनिश्चित क्षेत्रों में तेज़ी से iterate करने वाली प्रक्रिया महत्वपूर्ण होती है, और यह ग्राहक की दिखाई देने वाली प्रतिक्रिया से आंकना बेहतर है कि गति बहुत ज़्यादा है या नहीं

  • सॉफ्टवेयर ग्राहक बहुत अलग-अलग हो सकते हैं: event app ऑर्डर करने वाली कंपनी, e-commerce platform बनाने वाला Walmart, AWS services इस्तेमाल करने वाला developer, या सामान्य Windows·iOS user। जब quality, reliability और solution ग्राहक के control में नहीं हैं, तो पहले से यह जानने का कोई तरीका नहीं कि development बहुत तेज़ है या नहीं
    एयर कंडीशनर की मरम्मत emergency fix के करीब है; बेहतर उपमा यह होगी कि टेक्सास की गर्मी से बचने के लिए कुछ दिनों में घर बना दिया जाए और फिर insulation, ढीली दीवारें, बाहर की wiring, और घर के नीचे बहती plumbing को 6 साल तक ठीक करते रहना पड़े
  • लेख भी मानता है कि असली गति तब आती है जब काम और constraints समझे जाएँ, अनुभवी लोग स्पष्ट फैसले लें और बार-बार बहस किए बिना execute करें। planning और सहमति में बाधा डालने वाली हड़बड़ी गलतियाँ और लागत बढ़ाती है, और project, भरोसे व morale को खराब कर सकती है; panic mode को default बना देने से तेज़ नतीजे भी नहीं मिलते
  • उस स्थिति के बारे में भी सोचना चाहिए जिसमें technician एक हफ्ते में छह बार आया और हर बार कहा कि ठीक कर दिया, लेकिन एयर कंडीशनर फिर भी लगातार खराब होता रहा
  • संदेह है कि क्या यह लेख urgency को ही नज़रअंदाज़ करने की बात कह रहा है, और यह भी जानना चाहूँगा कि वास्तव में कितनी कंपनियाँ या लोग urgency को अनदेखा करते हैं
    business-critical outages में पद की परवाह किए बिना कुछ भी आज़माकर अक्सर अव्यवस्था बढ़ा दी जाती थी, और सहयोग करके समस्या समझने के बाद हल करने की तुलना में कुल समय और impact का दायरा बड़ा हो जाता था। थोड़ा ठहरकर urgency समेत पूरी समस्या को समझने वाला शांत और लगातार तरीका अंततः ज़्यादा तेज़ था, और यह ग्राहकों को progress बताने व उनकी चिंताएँ कम करने के साथ भी compatible है
  • पहले व्यावहारिक समाधान के मानदंड तय करने होंगे। 6 हफ्ते काफी हैं यह निर्णय भी 6 महीने जितना ही subjective है; अगर शुरू में कामचलाऊ लगने वाले output को लगातार update करना पड़े, तो देखना होगा कि ग्राहक कितनी बार तक सहेंगे और 7वें हफ्ते की समस्या कितनी गंभीर होगी। waterfall model को agile में बदलने के बाद हम लगातार update होते व्यावहारिक समाधानों के बीच रहने लगे हैं

• गति की पूजा venture capital की timeline से आती है। venture capitalists को अपने limited partners को returns लौटाने की deadline होती है, इसलिए रुचि पाने के लिए यह विश्वास दिलाना पड़ता है कि उसी schedule में 10x growth संभव है
  अगर आप उस schedule से सचमुच बंध जाते हैं, तो तकनीकी वास्तविकता को अनदेखा करके मनमानी deadlines तय करने वाले और deadline न पूरी होने पर project बंद कर देने वाले व्यक्ति बनना आसान है

  • वह deadline venture capitalist के लिए मनमानी नहीं होती; उसे cost of capital तय करती है। market और तकनीकी हालात महत्वपूर्ण नहीं होते, और profit, revenue या market share में से कोई भी पर्याप्त तेज़ी से न बढ़े तो उसे loss मानकर company बंद कर दी जाती है
    अगर पागलों जैसी growth नहीं तो मौत वाली संरचना और आपके goals मेल नहीं खाते, तो venture capital नहीं लेना चाहिए। बिना जल्दबाज़ी के develop करना है तो ऐसी startup चुननी चाहिए जिसके पास verified product-market fit (PMF) हो और growth curve की जिम्मेदारी संभालने वाली शानदार sales team हो
  • venture-backed companies कुल companies का बहुत छोटा हिस्सा हैं। विकल्प यानी debt financing में deadlines और urgency बल्कि कहीं ज़्यादा होती हैं
  • venture capital के बिना bootstrapped तरीके से बढ़ने वाली company की urgency और भी ज़्यादा हो सकती है। अगर जल्दी बड़ी सफलता न मिले, तो जल्दी delivery करके revenue बनाने और ठीक-ठाक salary लेने का दबाव वास्तविक होता है, और काम बाँटने के लिए ज़्यादा लोग hire करना भी मुश्किल होता है
    venture-backed startup में भरपूर cash cushion और अतिरिक्त support की संभावना थी, इसलिए वह उल्टा कम कठिन लगा। investors stock market से ज़्यादा returns चाहते हैं, और founders FAANG में नौकरी करने से ज़्यादा wealth चाहते हैं, इसलिए risk के अनुरूप reward का दबाव funding method से अलग होकर भी पैदा होता है
  • मनमाने project milestones या schedules भी उपयोगी होते हैं। उन्हें project बंद करने का मानदंड बनाने की ज़रूरत नहीं, लेकिन वे बाहरी बदलावों की तुलना में effort के results दिखाने वाला benchmark बनते हैं
  • सिर्फ़ technical reality ही नहीं, बल्कि मूल्यवान ढंग से करने लायक लगभग हर चीज़ को अनदेखा करवा देने के मामले में venture capital दुनिया का cancer जैसा है

• एक cynical Army colonel अक्सर कहा करता था, “पर्याप्त छोटी time unit में periodic motion भी progress जैसा दिखता है”, और “धीरे करोगे तो smooth होगा, और smooth होगा तो तेज़ होगा”

  • track race के sharp curve में धीमा महसूस होता है और और तेज़ धकेलने का मन करता है, लेकिन उल्टा और धीमा होकर smooth और controlled तरीके से सही line पर मुड़ना बाद की acceleration को बेहतर बनाता है। यह धीरे enter करो और तेज़ exit करो का principle है
    calculations के हिसाब से भी 100-foot के slow curve में speed 1 mile per hour बढ़ाने के बजाय quarter-mile straight में speed 1 mile per hour बढ़ाना ज़्यादा फायदेमंद है
  • basic military training में instructors यह बात लगातार दोहराते थे। officer training course के दौरान जब हम tear gas pellets गर्म करने वाले concrete bunker में गए, तो आँखों में जबरदस्त जलन होने लगी, लेकिन सचेत होकर सोचने से पहले ही gas mask निकालकर पहन लिया और filter व decontamination cream की procedure भी ठीक-ठीक कर दी
    gas mask उतारकर आँखें मलने की इच्छा को दबा पाने की वजह यह थी कि धीमी और दोहराई गई training automated तेज़ action में बदल गई थी। magazine change और forward assist चलाने पर भी यही principle लागू होता है

• इंजीनियरिंग के नजरिए से धीरे करने पर ही चीजें स्मूथ और तेज होती हैं, लेकिन sales के नजरिए से धीमा मतलब बस धीमा ही होता है। अगर आप 6 महीने बाद बेहतर quality का वादा कर रहे हों और इसी बीच competitor 5–10 साल वाला कोई दुर्लभ contract ले जाए, तो मामला सिर्फ दूसरे काम पर focus करने का नहीं रह जाता; हो सकता है कि पूरी टीम को ही निकालना पड़े, क्योंकि उसे deploy करने की जगह न बचे।
  कंपनी को सही तरीके से बनाने का समय देते हुए भी शुरुआत से ही नतीजे मांगना ही failure point है। Infrastructure, design system, component library, system design पर 6 महीने या 1 साल लगाने के बाद अगर दिखाने लायक कोई result न हो, तो billing और tracking अजीब हो जाते हैं, और आगे development बहुत तेज हो जाएगा वाला वादा management पर काम नहीं करता।

  • Urgency वास्तविक हो सकती है, लेकिन planning छोड़ देने से चीजें तेज नहीं हो जातीं। कई बार सिर्फ कुछ घंटे planning कर लेने से कई हफ्तों की बेकार मेहनत और rework बच सकता है।
  • छोटे समय में जल्दबाजी सही लग सकती है, लेकिन काटे गए corners आखिरकार पीछा पकड़ ही लेते हैं। अगर आपने sales team को बड़े contract के लिए structure पर सोचने का समय दिए बिना special features ठूंसने या testing पूरी होने से पहले launch करने की मांग करते देखा है, तो यह अच्छी तरह समझ आएगा। सामने वाला एक contract जीत भी जाए, तो लंबी दौड़ तक जीतना दुर्लभ है।
    सावधानी और जिम्मेदारी से धीरे करना और अक्षमता की वजह से धीमा होना—इनमें फर्क करना जरूरी है। Market pressure वास्तविक है, और लगातार धीमी टीमें गायब हो जाती हैं। कभी-कभी धीमापन smoothness और speed में बदलता है, और कभी-कभी वह बस धीमापन ही होता है; इसलिए दोनों के बीच का फर्क जानना ही असली बात है।

• करियर की शुरुआत में मुझे एहसास हुआ कि management कभी-कभी मानता है कि अगर आप stress बाहर से दिखा नहीं रहे, तो आप मामले को गंभीरता से नहीं ले रहे। “urgency महसूस नहीं हो रही” जैसी बातों ने उस समय मुझे मानसिक रूप से काफी हिला दिया था।

  • असली management का काम competing options के बीच limited resources कैसे allocate करने हैं, यह तय करना है। लेकिन कई managers और team members management को लोगों को control करने का काम मानते हैं, और असल में वे सिर्फ supervisor की भूमिका में रह जाते हैं, जो देखता है कि लोग और ज्यादा मेहनत कर रहे हैं या नहीं।
  • मुझसे भी वही बात कही गई थी, लेकिन हिलने के बजाय मैंने निष्कर्ष निकाला कि जो व्यक्ति दिखावे और वास्तविकता में फर्क नहीं कर सकता, उसे CEO नहीं होना चाहिए।
  • बेचैन manager अक्सर सामने वाले के बेचैन न दिखने से भी बेचैन हो जाता है, लेकिन ऐसे managers भी बहुत हैं जो ऐसा नहीं करते।

• “हलचल और प्रगति को एक मत समझो। rocking chair लगातार हिलती रहती है, लेकिन आगे नहीं बढ़ती” — Alfred A. Montapert

• लेख से सहमत होना मुश्किल नहीं है, लेकिन चर्चा से deadline पूरी तरह गायब है। Speed की मांग हमेशा vacuum में पैदा नहीं होती; अगर वह अनुचित हो तो उसका विरोध करना चाहिए, लेकिन वास्तविकता में क्या हमेशा विकल्प होता है, यह सवाल है।

  • लेख काम को कुछ ज्यादा ही ideal और आरामदेह नजरिए से देखता लगता है। Perfectionism में फंसकर feedback का इंतजार करने या अनावश्यक चीजें बनाने के बजाय, कुछ चीजें तोड़ते हुए भी तेजी से आगे बढ़ने का स्पष्ट फायदा है। यह agile management का बुनियादी सबक है, और भले ही यह absolute न हो, आम तौर पर जिस speed पर आप comfortable महसूस करते हैं, उससे ज्यादा तेज pace फायदेमंद होता है।
  • लेखक के तौर पर, मैं deadlines को ज्यादातर artificial constraint मानता हूं। launch conditions या supplier production schedule जैसी न बदली जा सकने वाली deadlines भी होती हैं, लेकिन अक्सर इन्हें असली लक्ष्य से ध्यान हटाने और जल्दबाजी कराने के बहाने या psychological whip की तरह इस्तेमाल किया जाता है।
    सिर्फ deadline पूरी करने के लिए जल्दबाजी करने पर अभी तो चीजें तेज दिख सकती हैं, लेकिन नतीजा टीम के best possible output से खराब निकलता है, और बाद में उस गड़बड़ को साफ करने में और ज्यादा समय लगता है। बात यह नहीं है कि हर स्थिति में आराम से चला जाए, बल्कि यह है कि जिन environments में लोग हमेशा तेजी से चलते हैं फिर भी लक्ष्य शायद ही पूरा करते हैं, वहां जांचें कि कहीं जल्दबाजी खुद failure का कारण तो नहीं।
    FedEx ने delivery staff के लिए नया dashboard deploy किया, जिसके बाद MacBook intake process में system अटक गया। कर्मचारी ने manual processing करके receipt दी, लेकिन गलत label print हो गया। नतीजा यह हुआ कि laptop Apple तक पहुंचा ही नहीं; कई हफ्तों तक कई कर्मचारियों को बार-बार स्थिति समझानी पड़ी, और एक महीने बाद Apple को 5,000 डॉलर का नया laptop भेजना पड़ा। यह arbitrary deadline के कारण जल्दबाजी में बनाए गए software का उदाहरण है, जिसने भारी समय और पैसा बर्बाद किया। Speed कम करने की बात psychological comfort के लिए नहीं, बल्कि वर्तमान और भविष्य की chaos रोकने के लिए है।
  • ज्यादातर deadlines artificial और खुद बनाई हुई constraints होती हैं। इसका मतलब यह नहीं कि घर का आधा हिस्सा जल रहा हो और हम meeting schedule करके Slack पर चर्चा करें; कुछ काम सच में ज्यादा urgent होते हैं। लेख absolutism नहीं है, बल्कि speed worship की आलोचना करता है और स्थिति के मुताबिक judgment की discipline मांगता है।

• speed और velocity vector अलग चीजें हैं। 100-मंजिला इमारत से गिरता व्यक्ति सोच सकता है कि वह जबरदस्त speed से उड़ रहा है, लेकिन लक्ष्य की ओर velocity vector तब बनता है जब आप ढेर सारी dependencies पर विचार करके सही navigation करते हैं।
  बड़ी कंपनियों में दोनों ही मायने नहीं रखते, और ज्यादातर outputs खराब होते हैं। Deadlines annual performance reviews के हिसाब से plan की जाती हैं, और management के पसंदीदा लोगों ने सही metrics हासिल किए—ऐसी success stories बनाई जाती हैं, या milestones बदलकर rewards दिए जाते हैं। उस success की शानदार supervision करने के लिए management खुद भी reward पाता है।

• करियर लंबा होने के साथ यह principle और साफ होता जाता है। लेकिन अगर कोई युवा सहकर्मी अभी इसे समझे बिना मेरे management layer से ऊपर बैठ जाए, तो समस्या हो सकती है।
  “मेरी कुछ सबसे बड़ी उपलब्धियां वह code था जिसे मैंने लिखने का फैसला नहीं किया” जैसी बात कहकर मैं अक्सर reflection करवाने की कोशिश करता हूं।