“हाँ” न माँगें, “नहीं” कहने को कहें (2022)

• छोटी कंपनी में अपने काम के दायरे के भीतर किसी काम को आगे बढ़ाते समय अनुमति का इंतज़ार करने के बजाय इन्कार करने का मौका और समय-सीमा देने का तरीका execution speed बढ़ा सकता है
• “क्या मैं action X install कर सकता/सकती हूँ?” जैसे approval request से manager पर समस्या की समीक्षा, समाधान के तरीके का आकलन और प्राथमिकता तय करने तक का बोझ आ जाता है, जिससे जवाब देर से मिल सकता है
• “मैं सोमवार को action X install करूँगा/करूँगी। अगर आप अलग सोचते हैं तो बताइए” कहने से execution की मंशा दिखती है और फिर भी manager के intervene करने की गुंजाइश रहती है
• यह तरीका तब उपयुक्त है जब काम आपके role scope के भीतर हो, feedback welcome हो, लेकिन जवाब न मिलने पर भी आगे बढ़ने लायक दिशा पर आपको भरोसा हो
• नज़दीकी समय-सीमा साथ में देने से जिन लोगों को प्रतिक्रिया देनी है, उनके जल्दी react करने की संभावना बढ़ती है, और execution रोके बिना stakeholders को informed रखा जा सकता है

---

अनुमति का इंतज़ार करने के बजाय इन्कार का मौका देना

• बहुत छोटे कदमों में भी आगे बढ़ने वाला execution bias ठहराव तोड़ने में मदद करता है
• मुख्य आदत “हाँ” माँगने के बजाय “नहीं” कहने को कहना है
  • अनुभव का आधार 200 से कम कर्मचारियों वाली छोटी कंपनियाँ हैं
  • बड़ी कंपनियों, non-profit संगठनों और सरकारी संगठनों में यही तरीका काम करेगा या नहीं, यह निश्चित नहीं है
• जब आप ऐसा काम करना चाहते हैं जो आपको अपने काम के दायरे में लगता है, लेकिन आश्वस्त होना चाहते हैं या manager को जानकारी देना चाहते हैं, तो आम तौर पर पहले अनुमति माँगते हैं
• इसके बजाय manager को इन्कार करने का मौका दें, और उस निर्णय के लिए स्पष्ट समय-सीमा भी साथ में बताएं

GitHub Action के उदाहरण से अंतर समझना

• उदाहरण ऐसी स्थिति का है जहाँ software quality सुधारने में मददगार लगने वाला नया GitHub Action repository में install करना है
  • यह कोई अचानक आया विचार नहीं, बल्कि research और local testing के बाद की स्थिति है
  • हो सकता है आपने किसी पूर्व सहकर्मी से उस GitHub Action को इस्तेमाल करने के अनुभव के बारे में भी पूछा हो
• “क्या मैं action X install कर सकता/सकती हूँ? यह हमारी XYZ समस्या में मदद करेगा” पूछने का तरीका manager से “हाँ” कहने से पहले अतिरिक्त काम करवाता है
  • XYZ समस्या की फिर से समीक्षा करनी होगी
  • X समस्या को कैसे हल करेगा, इसका आकलन करना होगा
  • दूसरे कामों के साथ priority देखनी होगी, या वे चाह सकते हैं कि जिम्मेदार व्यक्ति पहले अपनी जानकारी share करे
  • व्यस्त manager के लिए यह काम पीछे छूट सकता है, और कई बार remind करना पड़ सकता है
• विकल्प है कहना: “मैं XYZ समस्या हल करने के लिए action X install करूँगा/करूँगी। अगर आप अलग सोचते हैं तो बताइए, नहीं तो मैं सोमवार को इसे कर दूँगा/दूँगी”
  • यह संकेत देता है कि जिम्मेदार व्यक्ति समस्या को खुद handle करेगा
  • manager चाहे तो intervene कर सकता है, लेकिन जवाब देना अनिवार्य होने का बोझ कम हो जाता है
  • manager भूल जाए या कोई और काम आ जाए, तब भी progress नहीं रुकती
• यह तरीका सिर्फ व्यक्ति पर नहीं, बल्कि कई लोगों वाले groups पर भी लागू किया जा सकता है

समय-सीमा से बनने वाला response pressure

• समय-सीमा इस approach का मुख्य तत्व है
  • 15 जनवरी के संदर्भ में “मैं task X करूँगा/करूँगी” की तुलना में “मैं 17 जनवरी को task X करूँगा/करूँगी” तेज प्रतिक्रिया ला सकता है
  • “मैं 15 फरवरी को task X करूँगा/करूँगी” जैसी दूर की समय-सीमा की तुलना में निकट भविष्य की समय-सीमा अधिक immediate response ला सकती है
• feedback का मौका खुला रखें, लेकिन यह तरीका सबसे अच्छा तब काम करता है जब feedback न मिलने पर भी आगे बढ़ने लायक दिशा पर आपको भरोसा हो

[GN⁺]

Hacker News की राय

• जहाँ हर कोई व्यस्त रहता है और काम आसानी से दब जाता है, ऐसे बड़े संगठनों में यह एक अहम कौशल है
  ईमेल में समस्या समझाने के बाद लिखा जाता है: “अगर [N] दिनों के भीतर जवाब नहीं मिला, तो [Nवें दिन] मैं XYZ करूँगा/करूँगी।”
  मंज़ूरी माँगकर लाचार होकर इंतज़ार करने या बार-बार पीछा करने के बजाय, यह बताकर रिकॉर्ड छोड़ दिया जाता है कि चुप्पी रहने पर XYZ आगे बढ़ेगा
  कभी-कभी कुछ हफ्तों बाद कोई यह कहकर नाराज़ हो जाता है कि बिना बताए क्यों किया, लेकिन तब हर बार उन्हें वह रिकॉर्ड दिखाया जा सकता है जो उन्होंने मिस कर दिया था

  • “अगर जवाब नहीं मिला तो मैं XYZ करूँगा” अनावश्यक रूप से टकरावपूर्ण लगता है
    “इन कारणों से मैं XYZ करने की योजना बना रहा/रही हूँ, और [तारीख] को इसे आगे बढ़ाऊँगा/बढ़ाऊँगी। अगर कोई आपत्ति या चिंता हो तो बताइए” जैसे कहना भी काफ़ी है
    यह तरीका पहले से मज़बूत तर्क पेश करने पर मजबूर करता है, और उन सीमाओं या ग़लतियों से बचने के लिए feedback भी दिला सकता है जिनके बारे में आपको पता नहीं है
    Amazon के leadership principles को समस्या-समाधान की recipe की तरह अपनाने वाला cargo cult जैसा व्यवहार भी अजीब है। “bias for action” Amazon में इसलिए चलता है क्योंकि जो लोग एकतरफ़ा कदम उठाकर असफल होते हैं, वे बलि का बकरा बनकर निकाल दिए जाते हैं, और ऐसे लोग bias for action के गुणों पर ब्लॉग नहीं लिखते
  • जिज्ञासा है कि इसे व्यवहार में कैसे लिखा जाता है
    क्या यह कुछ ऐसा होता है: “1 मार्च को thingamajig को defragment किया जाएगा। यह संदेश उन लोगों को पहले से सूचित करने के लिए है जिन पर इस काम का असर पड़ सकता है। अगर कोई चिंता हो तो बताइए। 1 मार्च तक जवाब नहीं मिला तो thingamajig defragment कर दिया जाएगा”
  • यह थोड़ा fantasy जैसा लगता है, या फिर सिर्फ़ वहाँ संभव है जहाँ जिस नियम को तोड़ा जा रहा है उसका कारोबार पर लगभग कोई महत्व नहीं है
    “5 दिनों में जवाब न मिला तो मैं X कर दूँगा” यह बात उस समय कोई बचाव नहीं बनती जब आपने ऐसा काम किया हो जिस पर अनुशासनात्मक कार्रवाई हो सकती है
    जहाँ यह चल सकता है, वहाँ भी ज़्यादा से ज़्यादा बात ऐसे आंतरिक design decisions की होगी जिनका business से सीधा संबंध नहीं है
  • “कभी-कभी कुछ हफ्तों बाद कोई XYZ चुपचाप कर देने पर नाराज़ होता है” वाला हिस्सा संदिग्ध लगता है
    अगर कोई कह रहा है कि वह यह “हमेशा करता/करती है” और किसी जादुई वाक्य को template की तरह लिख देता/देती है, तो संदेह होता है कि यह सचमुच उसका अनुभव है या फिर लेख की तरह काम करना चाहने का projection
    नाराज़ सहकर्मियों को रिकॉर्ड दिखाकर जीत जाने का दृश्य सोचते ही बकवास-डिटेक्टर लाल स्तर तक पहुँच जाता है
  • यह इस बात का रिकॉर्ड बनाने में भी मददगार है कि कौन प्रगति रोक रहा है या मना कर रहा है

• इसे “पूछो मत, बताओ” कहा जाता है, और यह कंपनी के अंदर-बाहर काफ़ी काम आता है
  यह एक बुनियादी communication skill है, और नतीजों को संक्षिप्त और निर्णायक बनाता है
  मैं अपनी पत्नी के साथ भी अक्सर ऐसी बात करता हूँ। वह कभी-कभी 8 लोगों के group chat में “तुम लोग कितने बजे पहुँचोगे?” जैसा खुला सवाल भेज देती हैं। हमें पता था कि बच्चे की देखभाल के शेड्यूल की वजह से हम एक घंटा पहले पहुँचेंगे, इसलिए मैंने कहा कि बस बता दो: “हम इस समय पहुँचेंगे, और जो पहले drink करना चाहते हों वे bar में होंगे”
  जवाब माँगने की ज़रूरत नहीं पड़ी, और सब लोग जल्दी आ गए, कम-से-कम बातचीत में बात आसानी से सुलझ गई
  इसका थोड़ा संबंध “मंज़ूरी से बेहतर माफ़ी माँगो” वाली बात से है, लेकिन GitHub repository जैसी collaborative जगहों में दूसरों को प्रभावित करने वाले बड़े बदलाव यूँ ही फेंक देना सही नहीं है

  • मैं भी ऐसा करता/करती हूँ। यह सिर्फ़ बेहतर communication नहीं, बल्कि बेहतर जीवन जीने का तरीका भी है
    यानी ऐसी स्थिति में न रहना कि आनंद लेने के लिए दूसरों के coordination पर निर्भर रहना पड़े, बल्कि जो मैं करना चाहता/चाहती हूँ उसे शुरू कर देना और दूसरों को बता देना कि वे शामिल हो सकते हैं

• जब सहकर्मी पूछते हैं कि अपनी proposals को approve कैसे करवाएँ, तो मैं कुछ ऐसा ही सलाह देता/देती हूँ: “सामने वाले के लिए हाँ कहना जितना संभव हो उतना आसान बना दो”
  किसी पर 14 पैराग्राफ़ फेंककर यह उम्मीद नहीं करनी चाहिए कि वह तुरंत उसी स्तर तक पहुँच जाए जिस स्तर तक मैं कई घंटे लगाकर समस्या में घुस चुका/चुकी हूँ
  अगर आपको अपने approach पर भरोसा है, तो संक्षेप में बता दें कि समस्या क्या है और समाधान क्यों सही है, और जो लोग गहराई में जाना चाहें उनके लिए document link जोड़ दें। टीम या product owner से पहले ही सहमति ले लेना अच्छा रहता है
  उदाहरण: “मैं X को Y से हल करने जा रहा/रही हूँ। टीम के सभी लोग सहमत हैं। विस्तृत proposal document [link] पर है। अगर कोई अतिरिक्त feedback नहीं है, तो मैं मंगलवार को शुरू करूँगा/करूँगी”
  managers के पास हर detail देखने का समय नहीं होता, और अगर आपने व्यापक टीम के support सहित सब कुछ व्यवस्थित कर दिया है, तो उन्हें बस approve करना होता है, इसलिए वे इसकी सराहना करते हैं

  • अगर manager इस तरह काम करते हैं, तो लोकप्रियता प्रतियोगिता शुरू हो जाती है। ऐसे managers अक्षम या बेकार होते हैं
  • “अगर आपको भरोसा है” यही मुख्य बात है। मैं आत्ममुग्धता से नहीं, बल्कि वस्तुनिष्ठ आँकड़ों और अनिश्चितता के आधार पर confidence तय करता/करती हूँ
    अगर सफलता की संभावना 10% है लेकिन फिर भी कोशिश करने का कारण है, तो मैं वही कहता/कहती हूँ; इसे इस तरह की बकवास प्रस्तुति में नहीं लपेटता/लपेटती कि मुझे यक़ीन है यह सफल होगा। अगर सफलता की संभावना 80% है, तो मैं बाकी 20% भी नहीं छिपाता/छिपाती, और अगर 98% कहता/कहती हूँ, तो उसका मतलब है कि वह सचमुच लगभग उतनी ही है
    manager का काम ऐसे आँकड़ों को संभालना और risk hedge करना है। hedge funds यह काम पैसों से करते हैं, managers लोगों और resources से
    दुर्भाग्य से, एक सामान्य corporate manager अक्सर उस व्यक्ति को ज़्यादा पसंद करता है जो 100% सफलता का दावा करता है, जबकि वास्तव में 50% बार विफल होता है

• इसी तरह का एक और phrase radiating intent भी पसंद आता है
  यानी यह व्यापक रूप से बताना कि आप क्या और कब करने वाले हैं, stakeholders को स्पष्ट रूप से विरोध करने की जगह देना, लेकिन agreement, alignment या approval के पीछे अलग-अलग भागते न फिरना
  यह कुछ परिस्थितियों में अच्छा काम करता है, और आम तौर पर पहले बुनियादी trust कमाना पड़ता है
  https://medium.com/@ElizAyer/dont-ask-forgiveness-radiate-in...

  • “radiating intent” करने के 4 कारण समझ में आते हैं। यह मध्यम या उससे अधिक trust वाले संगठनों में अच्छा काम करता है
    Eliz Ayer द्वारा जोड़ा गया nuance भी अच्छा लगा: “निष्पक्ष रूप से कहें तो radiating intent से आप शायद कम काम कर पाएँ, क्योंकि यह रोकने या दखल देने वालों को बीच में आने का रास्ता देता है। और यह सलाह संदर्भ तथा संगठन पर बहुत निर्भर करती है, इसलिए हमेशा उपयुक्त नहीं होती”

• इस तरह का communication सामने वाले को तुरंत खतरनाक व्यक्ति जैसा महसूस करा सकता है
  ऊपर से यह समय बचाने वाला लगता है, लेकिन असल में यह बताने का तरीका है कि अगर manager उस कर्मचारी पर हमेशा नज़र न रखे कि वह क्या कर रहा है, तो वह ऐसा काम कर सकता है जो नहीं चाहा गया था
  मूल लेख इसे एक notification की तरह पेश करता है, लेकिन चाहे कितनी भी सद्भावना और समझ हो, notification अक्सर signal के शोर में दब जाते हैं, और जवाब न आना सहमति का मतलब नहीं होता। इसका मतलब यह भी हो सकता है कि संदेश मिला ही नहीं
  अगर कर्मचारी और manager पहले ही समस्या पर चर्चा कर चुके हों और अब समाधान लागू करने की स्थिति हो, तो यह ठीक हो सकता है, लेकिन जब आप पहली बार ऐसी समस्या उठा रहे हों जिस पर सामने वाले ने अभी तक विचार भी न किया हो, तब यह सबसे बुरा तरीका है। यह स्वार्थी है और teamwork के बिल्कुल उलट है
  यह भी लगता है जैसे लोग किसी दिग्गज 10x Rockstar इंजीनियर को ऐसा करते देख कर उसकी नकल कर रहे हों। वह इंजीनियर हमेशा अच्छा काम करता है, जानता है कि क्या करना है, और management के साथ उसका पारस्परिक समझ और सम्मान का रिश्ता होता है, इसलिए उसे self-management की गुंजाइश मिलती है। यह देखकर किसी ने शायद यह समझे बिना कि उसे ऐसा व्यवहार क्यों मिलता है और खुद उसे कैसे पाया जाए, मान लिया कि यह बात उस पर भी लागू होती है

  • आखिरकार सब कुछ रिश्ते पर निर्भर करता है
    अगर आपने लगातार तीन बार ऐसा किया और जवाब मिला “कृपया रुकिए”, तो कुछ गड़बड़ है। अगर लगातार तीन बार तारीफ़ मिली, तो इसे जारी रखिए
    सचमुच खतरनाक व्यक्ति वह है जो मना सुनने के बाद भी किसी न किसी तरह ज़्यादातर काम कर देता है और बाद में yes ढूँढता है। अगली बार भी वह यही करता है और feedback पर प्रतिक्रिया नहीं देता
    इसलिए असली बात यह है कि मुद्दा इस तरीके से ज़्यादा कार्य-संबंध का है। जहाँ भरोसा ज़्यादा हो और सब व्यस्त हों, वहाँ यह आज़माने लायक है
  • अगर कोई अनजान व्यक्ति मेरे साथ ऐसा करे, तो यह मुझे उद्दंड और चिढ़ाने वाला लगेगा
    लेकिन अगर हमने साथ काम किया हो, भरोसा हो, और मुझे पता हो कि वह मेरे समय का सम्मान करते हुए ऐसा कर रहा है, तो बात बिल्कुल अलग है

• जिस क्षण आप पहली बार कुछ बिगाड़ते हैं, यह आपदा की रेसिपी बन जाती है
  Yes या no मिलना कम-से-कम यह दिखाता है कि boss को जानकारी थी। जब कुछ गड़बड़ हो जाए और सवाल उठे “इसे approve किसने किया?”, तो सच्चा जवाब होगा: किसी ने नहीं

  • यह संगठन की संस्कृति और management की प्रभावशीलता पर बहुत निर्भर करता है
    अगर संगठन में कोई भी इस तरह काम नहीं कर सकता, तो यह संकेत है कि leadership team delegation में विफल हो रही है
  • यह boss के लिए नहीं, बल्कि उन दूसरे विभागों के सहकर्मियों के लिए ज़्यादा उपयुक्त तरीका है जिन्हें काम में शामिल होना चाहिए
    जैसे, Y टीम का X किसी काम का विरोध कर रहा हो
    अगर boss 1) कहता है कि कुछ किया जाना चाहिए और 2) किसी भी योजना को approve नहीं करता, तो बस मत कीजिए। उस स्थिति में काम को संभव बनाने का निर्देश देना boss की ज़िम्मेदारी है
  • अगर boss को हर काम approve करना पड़े, तो वह boss नहीं बल्कि micromanager है, और तब दोनों ही गलत कर रहे हैं
  • कम-से-कम software में तो ऐसा नहीं होना चाहिए कि कोई अकेले कुछ भी कर सके
    “मैं यह करूँगा” कहना ठीक है, लेकिन review और automated test जैसी प्रक्रिया के बिना production में नहीं जाना चाहिए
    बेशक, इससे bottleneck बनता है। अगर आपने merge request भेजी और किसी ने समय पर review नहीं किया, तो कुछ नहीं होगा। ऐसे में टीम लीड स्तर पर यह सहमति होनी चाहिए कि एक तय समय के भीतर देखा और review किया जाएगा
  • किसी चीज़ की ज़िम्मेदारी लेने का मतलब उसे बिगाड़ना और फिर ठीक करना भी है

• यह तरीका शायद केवल अमेरिकी कंपनियों या अमेरिकी business culture से परिचित boss पर ही काम करता है
  अगर boss को यह पसंद न आए, तो इसका बड़ा उल्टा असर हो सकता है। performance review में boss आसानी से आपको अवज्ञाकारी कह सकता है, और आप खुद ही ज़रूरी सबूत थाली में सजाकर दे रहे होंगे
  कभी-कभी अमेरिका में भी अनुमति माँगना ही सचमुच सबसे अच्छा होता है, और अगर बात resources से जुड़ी हो तो और भी ज़्यादा

  • “अवज्ञा” जैसा शब्द तो सेना के लिए ज़्यादा उपयुक्त है। यह विचार ही अजीब है कि पूरी तरह वयस्क लोग “अवज्ञा” कर सकते हैं
  • अमेरिकी शैली के अलावा भी काम करने के बहुत अलग-अलग तरीके हैं
    उदाहरण के लिए स्कैंडिनेवियाई सांस्कृतिक क्षेत्र में अक्सर management काफ़ी हद तक हाथ खींच लेता है, और कर्मचारियों से उम्मीद की जाती है कि वे कई फैसले स्वतंत्र रूप से या आपस में सलाह करके लें
  • जिन boss के साथ मैंने काम किया, उनमें बहुत कम ऐसे थे जिन्हें यह तरीका नापसंद आता। बेशक, शर्त यह है कि जो आप करने जा रहे हैं वह बेवकूफ़ी भरा न हो
    हालाँकि वे सभी boss अमेरिकी संस्कृति में गहरे डूबे हुए थे
  • अगर स्वतंत्र निर्णय-लेना अवज्ञा माना जाता है, तो फिर ऐसे manager delegation कैसे करते हैं और समाज भर में काम चलता कैसे है, यह सोचने वाली बात है
    प्रभावी सैन्य निर्णय-प्रक्रिया भी काफी हद तक इस बात पर निर्भर करती है कि मैदान में मौजूद इकाइयाँ हर बार मुख्यालय को फोन किए बिना परिस्थिति के अनुसार ढल सकें
  • गैर-अमेरिकी कंपनियों में, जहाँ boss की सचमुच निजी ज़िंदगी होती है और वे weekend में काम नहीं करते, या कई दिन/हफ़्ते की छुट्टी भी ले लेते हैं, वहाँ यह तरीका काम न करे

• मैं इसे तर्कसंगत default तय करना कहता हूँ
  हर छोटी-बड़ी बात पर लोगों से निर्णय माँगने के बजाय, यह दिखाना कि आप स्थिति को समझते हैं, कुछ तर्कसंगत default तय करना, और बताना कि आप उसी के अनुसार आगे बढ़ेंगे
  इससे भरोसा बनता है, और जब सचमुच ध्यान देने की ज़रूरत होती है, तो लोग ज़्यादा ध्यान देते हैं। क्योंकि उन्हें पता होता है कि आप सामान्य दिनों में उनका समय बर्बाद नहीं करते

  • “default” वाला framing अच्छा है। इससे सुझाव और बदलाव की गुंजाइश बनी रहती है

• यह communication शैली अच्छी है, लेकिन deadline वाला हिस्सा उतना अच्छा नहीं है
  अगर कोई अधीनस्थ ऐसा काम कर रहा है जिस पर मैं veto लगा सकता हूँ, तो मुझे बता देना चाहिए। क्योंकि मेरे पास शायद ज़्यादा context हो और मैं समझ सकूँ कि वह काम समय की बर्बादी है या प्राथमिकता नहीं है
  manager को deadline देना अजीब है, और हल्की-सी चिढ़ पैदा करने वाली धमकी जैसा लगता है
  GitHub Action जैसी छोटी चीज़ों के लिए मैं यह मानना चाहूँगा कि टीम के सदस्य को खुद निर्णय लेने लायक पर्याप्त autonomy दी गई है

  • No माँगने का तरीका, जैसे “अगर आगे नहीं बढ़ना चाहिए तो बताइए”, वास्तव में बहुत अच्छा है
    लेकिन अगर साथ में “मैं यह काम इस तारीख को करूँगा, यदि आप कुछ और न कहें” जोड़ दिया जाए, तो यह थोड़ा आक्रामक लगता है
    सिर्फ काम का समय बता कर “मुझे लगता है तब तक यह पूरा कर दूँगा” जैसा कहना भी काफ़ी है, और इससे यह गुंजाइश बनी रहती है कि शायद आगे न बढ़ना बेहतर हो
    फिर भी, बहुत पहले से मेरा लक्ष्य थोड़ा अधिक assertive होना रहा है। सिर्फ सिमट कर रहने की भी एक सीमा होती है
  • अगर आप यह न बताएं कि काम कब करेंगे, तो सामने वाला no कह रहा है या नहीं, यह कैसे पता चलेगा?
    अगर आपने सोचा कि एक दिन काफ़ी है और काम शुरू कर दिया, लेकिन सामने वाले ने दो दिन बाद जवाब दिया, तो तब तक आप पहले ही निर्देश के विरुद्ध काम कर चुके होंगे
    तारीख जोड़ने से यह समस्या टल सकती है: “मैं बुधवार (26 तारीख) को build system migrate करूँगा। अगर कोई चिंता हो तो बताइए”
  • नुकसान यह हुआ कि मूल लेख ने इसे deadline कहा
    उदाहरण पढ़ने के बाद ही बात समझ आई, लेकिन वास्तव में यह deadline नहीं बल्कि काम की नियोजित तारीख के ज़्यादा करीब है
  • अपने ही काम के लिए deadline बताना शिष्टाचार भी हो सकता है
    इससे सामने वाले को notice period पता चलता है, और जो लोग बाद में पुराना email पढ़ें, वे समझ सकते हैं कि यह अब भी प्रासंगिक है या नहीं
  • जिस चीज़ पर अभी सिर्फ़ विचार चल रहा हो, उस पर deadline ठोक देना अजीब और आक्रामक लगता है
    आम तौर पर deadline का मतलब होता है, “यह पहले ही तय हो चुका है, approval या सहमति भी मिल चुकी है, अब मैं सिर्फ़ execution की जानकारी दे रहा हूँ”

• “अगर कोई अलग निर्देश नहीं देता है, तो मैं यह करूंगा” जैसे तरीके का एक हिस्सा यह है कि इसे सवाल की तरह व्यक्त न किया जाए, ताकि संचार लागत कम हो
  इससे सामने वाले को जवाब लिखने की ज़रूरत नहीं पड़ती, और मुझे या CC में शामिल लोगों को भी अतिरिक्त ईमेल पढ़ने नहीं पड़ते
  इस मायने में GitHub या Google Docs के emoji reactions जैसी सुविधा अच्छी है, जहाँ पढ़कर सहमति जताने के लिए thumbs up दबाया जा सकता है। HN के कुछ हिस्सों में यह अजीब तरह से लोकप्रिय नहीं है, लेकिन यह हर बार “अच्छा है, बात समझ में आती है!” जैसी टिप्पणी लिखने की प्रक्रिया से गुज़रे बिना हल्के-फुल्के संचार का तरीका है। यह upvote जैसा है