लोगों की बात सुनने के काम से इंजीनियरिंग के जरिए बचने की कोशिश न करें

• सॉफ़्टवेयर के कामकाजी माहौल की मुख्य कठिनाई बातचीत की कमी से ज़्यादा सुनने की कमी है, और इसे framework या system जैसे शब्दों में बदलकर हल करने की कोशिश वास्तव में ज़रूरी सुनने से बच निकलती है
• किसी के अनुरोध को जस का तस पूरा करना, उसकी वास्तविक ज़रूरत समझने से अलग है, और विशेषज्ञता प्रभाव तथा technical/non-technical द्विभाजन सामने वाले के ज्ञान और संदर्भ को नज़रअंदाज़ कर देते हैं
• अगर यह मान लिया जाए कि सभी के पास समान ऊर्जा, कौशल और धन है, या किसी एक व्यक्ति की विशेषता को पूरे समूह पर लागू कर दिया जाए, तो हर व्यक्ति की अलग बाधाओं और निर्णय मानदंडों को ठीक से पकड़ा नहीं जा सकता
• लोग और संगठन समय, भूमिका, तनाव और समूह गतिशीलता के साथ बदलते रहते हैं, और जो कहा जाता है वह हमेशा असली सोच से मेल नहीं खाता, इसलिए स्थिर requirements अक्सर सॉफ़्टवेयर निर्माण से आसानी से असंगत हो जाते हैं
• सुनने में विफलता सबसे मूल्यवान insights को खो देती है, और इससे राजस्व अवसर तथा प्रतिस्पर्धी बढ़त का नुकसान होता है, साथ ही गलतफहमियों के जमा होने से tech debt भी बढ़ता है

---

मुख्य तर्क

• सॉफ़्टवेयर के कामकाजी माहौल में लोगों के बीच बातचीत की कमी से भी बड़ा मुद्दा सुनने की कमी है, और इसे framework या system जैसे शब्दों में बदलकर हल करने की कोशिश वास्तव में आवश्यक काम से बचने का तरीका है
• डिज़ाइनर और product से जुड़े लोग अक्सर लोगों के साथ बातचीत को engineering के लिए अधिक स्वीकार्य अभिव्यक्ति में बदलने की कोशिश करते हैं, लेकिन बेहतर व्यवस्था से ज़्यादा ज़रूरी है लोगों की बात सही तरह से सुनना
• इस आधार पर कि लोगों से बात करने की तुलना में लोगों की बात सुनना अधिक कठिन है, वास्तव में सुनने में बाधा बनने वाले प्रमुख जालों को व्यवस्थित किया गया है

सुनने में बाधा डालने वाले प्रमुख जाल

• जो कहा गया है वही कर देना और सुनना अलग बातें हैं

  • किसी ने जो चाहा है उसे वैसा ही कर देना और वास्तविक ज़रूरत को सुनना एक ही बात नहीं है
  • इस विषय से जुड़े पुराने तरीकों के रूप में Jobs To Be Done, Outcome Driven Innovation, और UX क्षेत्र की empathy mapping का उल्लेख है

• विशेषज्ञता प्रभाव के कारण अपनी दृष्टि को कम आंकना

  • किसी क्षेत्र में लंबे समय तक सीखने पर आसानी से यह मान लिया जाता है कि "इतना तो सभी जानते होंगे"
  • सामने वाला उस क्षेत्र का विशेषज्ञ हो तब भी यह ज़रूरी नहीं कि वह वही ज्ञान जानता हो, बल्कि वह अलग तरह का ज्ञान जान सकता है
  • सही तरह से सुनने के लिए यह अधिक समझना ज़रूरी है कि सामने वाला क्या जानता है

• technical को एक ही श्रेणी मान लेना

  • यह सॉफ़्टवेयर डेवलपर्स में खास तौर पर आम जाल है; technical कोई एक गुण नहीं बल्कि अलग-अलग ज्ञान क्षेत्रों का बहुत व्यापक स्पेक्ट्रम है
  • अगर लोगों को "technical / non-technical" द्विभाजन में देखा जाए, तो insights छूट जाते हैं और सही तरह से सुन न पाने की संभावना बढ़ती है

• यह मान लेना कि सभी के पास समान संसाधन हैं

  • अगर यह मान लिया जाए कि सभी के पास समान ऊर्जा, समान कौशल और समान अतिरिक्त धन है, तो गलत निर्णय होते हैं
  • समान स्वास्थ्य वाले लोग भी उसे संभालने के तरीके या वास्तव में कर सकने वाले कामों में अलग हो सकते हैं
  • कोई गणित में मजबूत हो सकता है, कोई दूसरी क्षमताओं में, और किसी के पास धन या अतिरिक्त गुंजाइश कम होने के कारण वह अधिक risk-averse तरीके से व्यवहार कर सकता है

• एक व्यक्ति की विशेषता को पूरे समूह पर लागू कर देना

  • किसी एक विशेषता वाले व्यक्ति से मिलने का मतलब यह नहीं कि बाकी सब भी वैसे ही होंगे
  • उदाहरण के तौर पर यह रवैया कि बुज़ुर्ग लोग कंप्यूटर नहीं समझते
  • पूरे महिला समुदाय को व्यक्तिगत पारिवारिक संबंधों की छवि में समेट देना भी इसी तरह की गलती है

• यह मान लेना कि लोग और संगठन स्थिर हैं

  • व्यापक स्तर पर व्यक्तित्व समय के साथ बदलता है
  • सूक्ष्म स्तर पर कार्यस्थल की persona और घर की छवि अलग हो सकती है, और तनाव या कुछ विशेष स्थितियों में निर्णय भी बदल जाते हैं

• यह मान लेना कि कही गई बात और सोच एक ही है

  • कुछ लोग वही मतलब रखते हैं जो वे कहते हैं, लेकिन कुछ नहीं रखते
  • बहुत से लोग खुद को ईमानदार मानते हैं, जबकि वास्तव में ऐसा नहीं होता

• लोगों का निर्णय करना

  • खराब तरीके से documented चीज़ को गलत समझने वाले व्यक्ति से नफ़रत करना या उसे dismiss कर देना, सही तरह से सुनने की संभावना को बहुत कम कर देता है
  • यह मान लेना कि सामने वाला अपना काम नहीं जानता या जीवन गलत तरीके से जी रहा है, सुनने में बाधा बनता है

• 80 लोगों को 80 अलग इंसानों की जगह एक ही समूह मानना

  • B2B, B2C की तुलना में अक्सर और भी ज़्यादा मानवीय पहलू रखता है, जहाँ संबंध, dynamics, और org chart के बाहर की soft power जैसी चीज़ें काम करती हैं
  • समूह गतिशीलता जुड़ने पर व्यक्तिगत स्तर से भी अधिक जटिल चर सामने आते हैं

स्थिर requirements और सॉफ़्टवेयर के बीच असंगति

• लोग और संगठन बदलते हैं, इसी वजह से fixed project management सॉफ़्टवेयर निर्माण के लिए उपयुक्त नहीं है
• शुरुआत में requirements तय कर देने पर भी इस बीच लोग बदल जाते हैं, और जब परिणाम आता है तो वह अधिकतम शुरुआत के समय किए गए अनुरोध से ही मेल खाता है
• रिलीज़ के समय तक संभव है कि वही चीज़ अब वांछित न हो, और इंतज़ार के दौरान लोग अपनी-अपनी अपेक्षाएँ जोड़ लेते हैं, इसलिए वास्तविकता उन सब अपेक्षाओं से मेल नहीं खाती

परिणाम और प्रभाव

• लोगों की बात सही तरह से न सुन पाने पर सबसे मूल्यवान insights छूट जाते हैं, और इससे राजस्व अवसर तथा प्रतिस्पर्धी बढ़त खो जाती है
• गलतफहमियाँ जितनी जमा होती जाती हैं, उतना ही बाद में साथ काम किए जाने वाले कोड में नए तत्व जुड़ते जाते हैं, और कुछ tech debt के कारणों को कम करने का संबंध भी सुनने से है
• जितना अधिक हम उन क्षणों को पहचानते हैं जब हम सुन नहीं पा रहे होते, उतनी अधिक संभावना होती है कि हम बेहतर सुन पाएँ

[GN⁺]

Hacker News की राय

• मैं शब्दों को काफ़ी सटीकता से चुनता हूँ, और अगर मैंने कोई खास अभिव्यक्ति इस्तेमाल की है तो मेरा सचमुच वही मतलब होता है। लेकिन बहुत से लोग, मेरी नज़र में, tone poem की तरह बोलते हैं—हाथ लगने वाले शब्दों के आसपास मंडराते हुए, और उम्मीद करते हैं कि कोई साझा nuance समझ ली जाएगी, इसलिए उनकी बात की व्याख्या करना अपने आप में थकाऊ होता है। जब मैं लिखता हूँ, तो हर शब्द जानबूझकर चुनता हूँ, लेकिन नौकरी में भी मेरी बात का ऐसे अर्थ निकाल लिया जाता है मानो मेरी अभिव्यक्ति ही ग़लत या अस्पष्ट थी, और यह लगभग हमेशा दोहराया जाता है, जो काफ़ी पीड़ादायक है। शायद मैं spectrum पर हो सकता हूँ, लेकिन कभी diagnosis नहीं हुआ। करीब छह महीने पहले मैंने एक छोटा RPC बनाया और उसका documentation लिखा ताकि दूसरा विभाग एक लंबा काम शुरू कर सके। वह एक पेज से भी छोटा था, लेकिन पूरा, सटीक और संक्षिप्त था। फिर मेरे manager ने बिना कोई वजह बताए उस document को AI से गुज़ारकर आगे भेज दिया, और मुझे इसकी ख़बर भी नहीं थी। एक दिन के भीतर बेहूदा feedback आने लगा, और जब मैंने असली request examples देखे तो endpoint manipulation हुआ था। वह typo नहीं था; पूरा address गढ़ लिया गया था। document में endpoint और required parameters सब ग़लत थे, और जो feature था ही नहीं वह भी invent कर दिया गया था। मैं आम तौर पर शांत रहता हूँ, लेकिन जितना गुस्सा मुझे तब आया, उतना शायद कभी नहीं आया, और अब भी गुस्सा है। अगर job market ऐसी न होती, तो शायद मैं तुरंत resign कर देता। लोगों के लिए बनी भाषा—जिसे उन्हें खुद पढ़कर समझना चाहिए—उसे AI पर छोड़ देना मुझे कठोर भाषा की मृत्यु जैसा लगता है, और मैं कई महीनों से गंभीरता से सोच रहा हूँ कि क्या generative AI सभ्यता को नष्ट करने वाला कोई Great Filter हो सकता है

  • मुझे यह नज़रिया थोड़ा अपरिचित लगता है। यह मानना मुश्किल है कि भाषा विचार की सीमाओं को बिल्कुल साफ़ काटकर समेट लेती है; भाषा दुनिया और अपनी-अपनी समझ को व्यक्त करने का एक tool है, इसलिए मिलते-जुलते concepts को अलग-अलग शब्दों में समझाना स्वाभाविक है। जिसने विचार को शब्दों में बदला है, उसे वह ज़्यादा साफ़ लगे, लेकिन सुनने वाले को ज़रूरी नहीं कि ऐसा लगे। इसलिए व्याख्या के श्रम को हल्के में नहीं लिया जा सकता। शायद अगर आप उस स्थिति के दूसरी तरफ़ वाले लोगों से बात करें, तो वे भी आख़िरकार यही कहेंगे कि आपकी बात समझना उनके लिए कठिन था
  • यह setup इतना तीखा लगा कि मेरे मन में तुरंत एक उपन्यास आया। Great Filter और generative AI को जोड़ने का विचार बहुत अच्छा है; यह वैसी कहानी लगती है जो Cory Doctorow को अभी लिखनी चाहिए
  • मुझे लगता है, सबसे पहले यह पूछना चाहिए कि manager ने उस document को AI में डाला ही क्यों। कभी-कभी precision बढ़ने के साथ readability घट जाती है, और भाषा जितनी compressed होती है, पाठक को हर शब्द पर उतना अधिक cognitive cost लगाना पड़ता है। पढ़ना, लेखक के दिमाग़ के model को पाठक के model में translate करने की प्रक्रिया है; यह केवल शब्दों से अपने-आप नहीं हो जाता, इसमें interpretation की क्रिया चाहिए। अगर चीज़ बहुत concise हो, तो पाठक की मदद करने वाले सहारे ग़ायब हो सकते हैं। संभव है कि एक पेज का document आम पाठक के लिए इतना छोटा था कि समझने में मदद नहीं कर पाया, इसलिए AI summary जैसी bypass हुई। पाठक के लिए लिखना और high-context reader के लिए सटीक memo लिखना बिल्कुल अलग काम हैं, और खासकर जब आप अनिश्चित, व्यापक audience के लिए लिख रहे हों, तो repetition, आसान examples, परिचित context, steps का subdivision, और कभी-कभी humor व background explanation भी जोड़नी चाहिए ताकि समझ आसान हो
  • मेरे साथ भी हाल ही में ऐसा ही हुआ। मैंने 4-पेज की spec लिखी थी, लेकिन जिसने उसे पाया उसने पढ़ने की बजाय LLM से कुछ bullet summaries निकलवा लीं, और नतीजे में एक ऐसा proposal वापस आया जो requirements से मेल ही नहीं खाता था। जब मैंने आपत्ति की, तो उसने कहा कि वह बात original spec में होनी चाहिए थी, जबकि सच यह था कि वह पहले से spec में थी—बस उसकी LLM summary में नहीं थी। मैं हर शब्द पर अटकने वाला इंसान नहीं हूँ, लेकिन 4-पेज document की जानकारी 10 bullets में पूरी की पूरी आ सकती है, ऐसा मुझे नहीं लगता
  • मुझे तो उल्टा लगता है कि यह एकदम ऐसा case है जहाँ इसे normie speak में बदलने वाला dedicated prompt या custom LLM ठीक बैठेगा

• मुझे तो सिर्फ़ इस comment thread को देखकर ही विडंबना महसूस होती है, क्योंकि यहाँ भी लोग वही समस्या दोहरा रहे हैं जिसकी ओर लेख इशारा करता है। मैं इसमें कुछ और जोड़ना चाहता हूँ। पहला, चाहे कितना भी knowledge और discussion जमा कर लो, अगर सामने वाला कुछ स्वीकार ही नहीं करना चाहता, तो वह आसानी से उसे स्वीकार नहीं करेगा। दूसरा, सचमुच सुनना मानसिक और शारीरिक दोनों स्तर पर खुद को vulnerable स्थिति में रखना है। क्योंकि तब आपको ऐसी बातें सुननी पड़ती हैं जो आपके अनुभव, विश्वास और worldview से टकरा सकती हैं; और लोगों को judge करने की प्रवृत्ति अक्सर self-protection mechanism होती है, जो उल्टा अच्छी तरह सुनने से रोकती है। तीसरा, सुनना कई बार तुरंत solution पर कूद जाना नहीं, बल्कि सामने वाले के दर्द को absorb करके उसे process करना होता है। उदाहरण के लिए, Product manager के लिए किसी बात को तुरंत नए feature या ticket में बदल देना आसान है, लेकिन असल में उसे use case सुनकर pain point पहचानना और उसका समाधान करना चाहिए; केवल user ने जिस feature का नाम लिया, उसी को समझ लेना काफ़ी नहीं है

  • मुझे लगता है कि इस proposition को पहले से premise मान लेना ख़तरनाक है। ज़्यादातर चीज़ों में negotiation की गुंजाइश होती है, और अगर सही तरह negotiate करना आ जाए तो बहुत कुछ बदल सकता है
  • मुझे खासकर दूसरा बिंदु बहुत गहरा लगा। मैं यह बात किसी प्रिय व्यक्ति को ज़रूर भेजना चाहता हूँ, और दिल से चाहता हूँ कि वह सचमुच listen करे
  • मैं भी इस बात से सहमत हूँ कि सुनना vulnerable होना है, लेकिन अगर यह भरोसा हो कि उस vulnerability का हर बार दुरुपयोग नहीं होगा, तो मैं ख़ुशी-ख़ुशी हमेशा समय निकालकर ठीक से सुनना चाहूँगा
  • मुझे सच में जिज्ञासा है—दूसरे के दर्द को absorb करना व्यवहार में असल में क्या होता है, और वहाँ से feature definition या ticket writing तक स्वाभाविक रूप से कैसे पहुँचा जाता है?
  • मुझे लगता है कि यही व्याख्या असल में presales discovery का सार है। यह सच कहें तो technology से ज़्यादा art के क़रीब है

• मैं मूल समस्या-चेतना से सहमत हूँ, लेकिन यह सूची कुछ हद तक शिकायतनामा जैसी लगी। effective communication लगभग पूरी मानवता की केंद्रीय समस्या है, और इस लेख का लहजा कुछ ऐसा लगा जैसे developers को सुनना न आने पर डाँटा जा रहा हो, इसलिए यह थोड़ा ऊपर से बोलने वाला लगा। असली समस्या यह है कि लोगों को यह तक नहीं पता होता कि वे क्या नहीं जानते। सबसे अच्छे communicators translators जैसे होते हैं; जब message सामने वाले की समझ में self-evident हो जाता है, तभी लोग वास्तव में सुनते हैं। मुझे नहीं लगता कि यह बस इसलिए ढह जाता है कि सब लोग कान बंद किए बच्चों की तरह व्यवहार कर रहे हैं। इसलिए हम systems और engineering solutions खोजते हैं—ताकि system के भीतर gap detection और translation framework ही built-in हों। यह perfect नहीं है, लेकिन लोगों को बस बेहतर सुनो कहकर समझाने से ज़्यादा ज़रूरी मुझे यह लगता है कि team, company और system level पर environment बदला जाए

  • मुझे एक बुज़ुर्ग की बात याद आती है जिन्होंने इसे Noisy system की तरह देखने को कहा था। signal हमेशा noise से कमज़ोर होता है, और उसके भीतर सीमित इंसान होते हैं। हर व्यक्ति की अपनी capacity की सीमा है, इंसानी thought model के update होने की speed की भी सीमा है, और समूह की सीमा व्यक्ति से भी कम होती है। खासकर बड़ी organizations में तो reality पूरी तरह बदल जाने पर भी पुराने models बदलने में दशकों लग सकते हैं। इसलिए इन constraints को स्वीकार करने के बाद यह तय करना ज़रूरी है कि मैं अपना समय और ऊर्जा कहाँ लगाऊँ
  • मुझे यह लेख बस एक साधारण self-help post जैसा लगा, बल्कि examples की कमी के कारण उससे भी थोड़ा कमज़ोर
  • मैं developer भी हूँ और दूसरे तरह का काम भी काफ़ी कर चुका हूँ, इसलिए communication की अहमियत और उसमें developers कितनी बार कमज़ोर पड़ते हैं, यह मैं अच्छी तरह जानता हूँ। एक आम pattern यह है कि developers खराब doctor की तरह सुनने का अभिनय करते हैं और बहुत जल्दी diagnosis पर पहुँच जाते हैं। सामने वाला अपनी ज़रूरी बात पूरी करे, उससे पहले ही वे घोषित कर देते हैं कि उन्हें पता है क्या चाहिए। software में, customer जो चाहता है उससे भी ज़्यादा महत्वपूर्ण अक्सर वह होता है जिसकी उसे वास्तव में ज़रूरत है। बहुत कम customers ऐसे होते हैं जो software से समस्या elegantly कैसे हल होगी, यह जानते हों; आम तौर पर कोई ऐसा व्यक्ति idea लेकर आता है जिसने software के बारे में गहराई से सोचा ही नहीं होता। इसका यह मतलब नहीं कि उसका idea बेकार है, बल्कि यह कि requirements shaping और solution derivation का काम अभी पूरा नहीं हुआ। उसे पूरा करने का तरीका observation, explanation और conversation है। मेरे अनुभव में बहुत से developers सचमुच अच्छा नहीं सुनते, और doctors या दूसरे technical professions में भी यही दिखता है। वे जल्दी से सक्षम दिखना चाहते हैं, इसलिए यह दिखाने लगते हैं कि वे कितना जानते हैं, और सामने वाले को पहले से देखी हुई समस्या-श्रेणियों में डाल देते हैं। कभी-कभी यह काम कर जाता है, लेकिन एक समय ऐसा ज़रूर आता है जब नहीं करता
  • मज़ाक में कहूँ तो, अगर communication सच में मानवता की केंद्रीय समस्या है, तो Bible में भी इस पर कोई न कोई verse तो होना चाहिए था

• मेरा मानना है कि लोग जो कहते हैं और जो वास्तव में सोचते हैं, दोनों को एक जैसा मान लेना आसान नहीं होना चाहिए। उल्टा, बोलने वाला भी आसानी से यह मान बैठता है कि सुनने वाला भी वही चीज़ imagine कर रहा है और उसी तरह समझ रहा है। इसलिए जितना हो सके विस्तार से और बिना अस्पष्टता के लिखना ज़रूरी है। अगर किसी meeting में कोई 6 शब्दों की bullet से goal समझाने की कोशिश कर रहा हो, तो यह असल में इस बात का संकेत है कि किसी को भी goal समझ नहीं आया है। अगर कोई एक पेज का document तक लाए बिना meeting में आ गया है, तो वह खुद भी अभी उसे पर्याप्त रूप से नहीं समझता; और अगर मेरी progress उस outcome पर निर्भर करती हो, तो मैं ज़्यादा साफ़ तस्वीर की माँग करूँगा

  • मुझे अक्सर colleagues से दिन में कई बार about what? पूछना पड़ता है। कौन-सा customer, कौन-सा feature, कौन-सा product—जब तक वे ठोस नहीं होते, तब तक मुझे 4–5 बार वापस पूछना पड़ता है। कभी-कभी तो तब भी, जब मुझे ठीक-ठीक पता होता है कि वे किसकी बात कर रहे हैं
  • मुझे लगता है कि requirements की वैधता भी ज़रूर परखनी चाहिए। क्योंकि असली ज़रूरत न जानने की स्थिति छिपाने का सबसे आसान तरीका अतिरिक्त माँगें करना होता है। मेरे अनुभव में ज़रूरत से 10 गुना ज़्यादा माँगना आम है, और एक बार तो मैंने यह तक सुना कि भविष्य की चिंता से बचना है तो 500x cost difference वाली options में से सबसे महँगी ले लो
  • मुझे लगता है कि विस्तार से और बिना ambiguity के लिखना गहरे mutual understanding की पूर्वशर्त तो हो सकता है, लेकिन पिछले कुछ वर्षों में लोग messages, tickets या emails में पहली पंक्ति से आगे सचमुच कम ही पढ़ते हैं। इसलिए अक्सर जानकारी को बहुत छोटे-छोटे टुकड़ों में तोड़कर खिलाना पड़ता है, और यह मुझे काफ़ी नापसंद है
  • मुझे लगता है कि असल दुनिया में यह बहुत बार होता है। अगर मैं कहूँ production के लिए तैयार नहीं, तो management अक्सर उसे इस अर्थ में सुन लेती है कि इसे customer को acceptance testing के रूप में बेचा जा सकता है
  • मुझे अचानक सोवियत दौर की फ़िल्म Kin-dza-dza याद आ गई। उसमें एक किरदार दूसरे के बारे में कहता है कि वह वह बातें कहता है जो वह सोचता नहीं, और वह वही सोचता है जो वह सोचता भी नहीं; इस बातचीत की गड़बड़ी को बयान करने के लिए यह काफ़ी सटीक लगता है

• मेरी भूमिका ज़्यादातर customer relationship management की रही है, इसलिए मैं मानता हूँ कि सबसे महत्वपूर्ण काम customer की expectation alignment को reality से मिलाना है। क्या संभव है, कितना समय लगेगा, कितना ख़र्च आएगा, और कब production में जा सकेगा—अगर यह सब customer expectations से align हो जाए, तो भले ही start date या cost उन्हें पसंद न आए, आख़िर में वे खुश customer बनते हैं। खासकर cost अक्सर deal-breaker होती है, इसलिए उसका rough range मैं शुरू में ही set करना पसंद करता हूँ। आप कितना भी अच्छे से सुनें और empathize करें, reality तो reality है, और customer को भी उन constraints को मानना या स्वीकार करना होता है। जो customer-facing व्यक्ति बस हर बात में हाँ मिलाता जाता है, वह आख़िर में customer को और दुखी करता है; एक अच्छा interface role दोनों तरफ़—customer और internal team—की बात सुनता है और यह सुनिश्चित करता है कि वास्तव में जो deliver किया जा सकता है वही customer expectation से मेल खाए

• मुझे कभी-कभी लगता है कि शायद हम communication पर बहुत ज़्यादा समय खर्च कर रहे हैं। जब समय ज़रूरत से ज़्यादा allocate होता है, तो focus ढीला पड़ जाता है, और लोग यह सोचकर बात टाल देते हैं कि अगली बार फिर clarify कर लेंगे। अगर हम अनावश्यक meetings कम करें और सिर्फ़ minimum viable time दें, तो शायद सब लोग उल्टा बेहतर सुनेंगे

  • मैंने वास्तविक जीवन में यह pattern लगभग कभी नहीं देखा। ज़्यादातर meetings असल में communication नहीं बल्कि निर्देश और announcements के क़रीब होती हैं, और सुनने की क्षमता meeting की लंबाई से अलग एक skill है। attentive listening एक ऐसी क्षमता है जो practice से निखरती है; meeting time घटाने भर से यह अपने-आप पैदा नहीं होती
  • मैं बहुत ऐसी meetings में बैठ चुका हूँ जिनका result सिर्फ़ अगली meeting schedule करना होता है। यहाँ तक कि ज़्यादा लोगों को खींच लाना, बड़े headcount वाली teams का decision को अपने पक्ष में मोड़कर political influence हासिल करना, और फिर उसी से और ज़्यादा अनावश्यक hiring व meetings पैदा होना—यह pattern भी देखा है। इससे निकलने का रास्ता communication बढ़ाना नहीं, बल्कि single vision बनाना और teams के बीच dependencies घटाना है ताकि हर team स्वतंत्र रूप से काम कर सके
  • software architecture के काम में मैंने बार-बार देखा है कि एक diagram 60 मिनट से ज़्यादा की discussion और कई rounds की meetings बचा देता है। वह बहुत सुंदर बना हो, यह ज़रूरी नहीं; अगर वह facts के प्रति ईमानदार है, तो काफ़ी है। complex या non-obvious logic को समझाने में diagram शब्दों से कहीं ज़्यादा साफ़ होता है। remote meeting हो तो AI agent और Mermaid.js से जल्दी बनाया जा सकता है, और in-person हो तो whiteboard या काग़ज़-कलम भी काफ़ी हैं
  • communication पर समय खर्च करना और वास्तव में communication करना—ये दोनों बिल्कुल अलग बातें हैं
  • मुझे लगता है कि असली समस्या यह नहीं कि हम communication पर बहुत समय लगाते हैं, बल्कि यह कि हम communication का नाटक करने में बहुत समय लगाते हैं। quorum भी पूरा न हो ऐसी meetings ज़बरदस्ती बुलाई जाती हैं, बिना prerequisites के चीज़ें शुरू हो जाती हैं, लोग बेधड़क बनाए गए AI slop document फेंक देते हैं, और जब लोग समझ नहीं पाते तो उल्टा पढ़ने वालों को ही बेवकूफ़ जैसा दिखाया जाता है। meeting के पहले 30 मिनट gaslighting जैसे बीतते हैं, और आख़िरी 10 मिनट में सब मानते हैं कि समय बर्बाद हुआ और damage control करते हैं। आदर्श रूप में meeting वह जगह होनी चाहिए जहाँ अच्छी तरह पके हुए विचार और consistent direction साझा हों, और स्पष्ट assertions पर meaningful feedback मिले; लेकिन व्यवहार में अक्सर यह किसी एक व्यक्ति की अपनी job को stone soup-style group project में बदलने की कोशिश को सब मिलकर संभालने जैसा होता है। अगर शुरुआत में ही पूछ लिया जाए कि इस meeting का goal क्या है, तो अक्सर पता चल जाता है कि आयोजक ने बस एक study group खोल रखा है। ऊँचे-level के managers अक्सर समझते हैं कि काम meetings में होता है, लेकिन अच्छी meeting से पहले जो गहरा सोचने का काम ज़रूरी है, वह उन्हें दिखता नहीं। विचार साफ़ होने से पहले communication के लिए दबाव डालो, तो meeting बस noise बन जाती है। ऐसी स्थिति में सबसे प्रभावी response है—चलो अभी साथ में पता लगाते हैं। मैं Why, What, How, Who, When के dependency order का पालन करवाता हूँ। पहले वाले हिस्से खाली हों तो बाद वाले पर नहीं बढ़ते; intern हो या VP, आसान गोलमोल जवाब नहीं चलते। अगर problem को तोड़कर, मौके पर सोचकर भी team नहीं बदलती, तो अंत में दूसरी team ढूँढना ही सही होता है

• मुझे लगता है कि इस लेख का specialism effect वाला point काफ़ी undervalued है। मुझे भी कभी frustration हुई कि user वह नहीं समझता जो मैं कई सालों में अंदर तक सीख चुका हूँ, लेकिन जल्द ही मुझे समझ आया कि समस्या यह नहीं कि उसके पास knowledge नहीं है, बल्कि यह कि उसकी knowledge कहीं और जमा है। उसने भी वही समय किसी बिल्कुल दूसरी चीज़ में गहराई से लगाया है

• मैं इस बात से पूरी तरह सहमत नहीं हूँ कि मूल कारण बस इतना है कि लोग बोलते नहीं और सुनते नहीं। एक cartoon analogy लें तो मुझे लगता है कि बहुत से लोग शुरू से सड़क से ज़्यादा ribbon-cutting चाहते थे, और आख़िर में उन्हें वही मिल गया—इसलिए यह सब हो रहा है

• मुझे यह काफ़ी मज़ेदार अनुभव हुआ है कि लोग कहते हैं कि वे ठीक वही मतलब रखते हैं जो वे कहते हैं, लेकिन वास्तव में ऐसा नहीं होता। मैंने सामने वाले की बात लगभग उसी रूप में paraphrase करके understanding confirm करनी चाही, और प्रतिक्रिया में बहुत ज़ोरदार इनकार मिला कि नहीं, वह तो बिल्कुल भी यह कहना नहीं चाह रहे थे

• मुझे लगता है कि non-technical लोगों से बात करते समय आने वाली बहुत-सी समस्याओं की जड़ यह है कि वे cost context के बिना बस कहते हैं X जोड़ दो, Y बदल दो। बेशक, कहा जाए तो लगभग सब कुछ किया जा सकता है, लेकिन हर request की एक cost होती है, और अगर यह समझ न हो तो reliable product delivery के साथ उसे reconcile करना मुश्किल हो जाता है

  • मुझे लगता है कि यह प्रतिक्रिया उल्टा लेख के मुख्य बिंदु को ही साबित करती है। बात यह नहीं कि वे cost नहीं समझते, बल्कि बस context अलग है; technical व्यक्ति की भूमिका यह उम्मीद करना नहीं कि वे पहले से cost समझकर आएँ, बल्कि यह है कि वह उन्हें जानकारी-आधारित tradeoff करने में मदद करे
  • मुझे लगता है कि ऐसी स्थिति में क्यों की whys पूछना महत्वपूर्ण है। अगर non-technical process को समझ लिया जाए, तो हो सकता है कि वह addition या change असल में ज़रूरी ही न हो। और मैं इस बात से भी सहमत हूँ कि अगर हर चीज़ जोड़ते गए, तो आख़िर में Turing complete Excel/Email clone जैसा राक्षस बन जाएगा
  • मुझे लगता है कि ऐसे मामलों में asymmetry यह होती है कि non-technical लोग cost नहीं जानते, और technical लोग benefit नहीं जानते। आख़िरकार दोनों तरफ़ communication होना चाहिए ताकि cost बनाम benefit का ठीक-ठाक संतुलन मिल सके
  • मुझे यह काफ़ी सुलझाई जा सकने वाली समस्या लगती है। हर request पर बस यह estimate देकर जवाब दो कि इसमें कितने महीने लगेंगे और कितने dollars लगेंगे
  • बस, मुझे यह भी लगता है कि आजकल AI code thing को काफ़ी हद तक संभाल लेने लगा है, इसलिए implementation cost वास्तव में काफी घट भी गई है। पसंद हो या न हो, इस बदलाव को मानना पड़ेगा