आपकी 'सौहार्दपूर्ण' टीम क्यों असफल हो रही है

• मनोवैज्ञानिक सुरक्षा का मतलब संघर्ष से बचना नहीं, बल्कि ऐसा माहौल है जहाँ ideas को challenge करके टीम को और मज़बूत बनाया जाता है
• सिर्फ इसलिए कि टीम के सभी सदस्य ऊपर से शांत मीटिंग्स और सहज माहौल दिखाते हैं, इसका मतलब यह नहीं कि वह एक प्रभावी टीम है
• जिन टीमों में उत्पादक असहमति संभव होती है, वे समस्याओं को जल्दी सामने लाती हैं और मतभेदों को जगह देती हैं
• critical thinking के लिए कुछ friction ज़रूरी होता है, और जिन टीमों में ईमानदार communication की कमी होती है वे संभावित समस्याओं को अनदेखा छोड़ देती हैं
• लीडर अपनी vulnerability दिखाकर, चर्चा के नियम बनाकर, और challengers को प्रोत्साहित करके स्वस्थ बहस की संस्कृति बना सकते हैं

---

सबके साथ अच्छा चलने वाले माहौल और मनोवैज्ञानिक सुरक्षा के बीच अंतर

• मनोवैज्ञानिक सुरक्षा को अक्सर इस गलतफहमी के साथ देखा जाता है कि टीम बिना टकराव के सौहार्दपूर्ण स्थिति में है
• कई लीडर ऐसी टीम पर गर्व करते हैं जहाँ सदस्य कभी ऊँची आवाज़ में बात नहीं करते, सभी सहमत रहते हैं, और मतभेद दिखाई नहीं देते
• लेकिन मनोवैज्ञानिक सुरक्षा का असली सार संघर्ष से बचना नहीं, बल्कि ऐसा माहौल बनाना है जहाँ ideas को खुलकर चुनौती दी जा सके और उन पर चर्चा हो सके
• Harvard Business School की प्रोफेसर Amy Edmondson मनोवैज्ञानिक सुरक्षा को “यह विश्वास कि ideas, सवालों, चिंताओं और गलतियों के लिए आपको सज़ा या शर्मिंदगी का सामना नहीं करना पड़ेगा” के रूप में परिभाषित करती हैं

उच्च मनोवैज्ञानिक सुरक्षा वाली टीमों की विशेषताएँ (जहाँ रचनात्मक संघर्ष मौजूद होता है)

• लोग खुलकर बोलते हैं, तीखी बहस भी स्वीकार्य होती है, और उसके परिणामस्वरूप टीम और मज़बूत होती है
• “मुझे लगता है यह गलत है” कहने पर भी बाहर कर दिए जाने का डर नहीं होता
• “मेरी सोच गलत हो सकती है” यह बात सहजता से कही जा सकती है; चर्चा और मूल्यांकन का विषय व्यक्ति नहीं बल्कि idea की सामग्री होती है, और प्रस्ताव रखने वाले की हैसियत से अलग उसे चुनौती दी जा सकती है
• गलतियों को भी सीखने के अवसर की तरह इस्तेमाल किया जाता है, और अलग-अलग perspectives को प्रोत्साहित करने वाली संस्कृति होती है

उत्पादक चर्चा को व्यवहार में उतारने वाली टीमों की ठोस विशेषताएँ

• समस्याओं की शुरुआती पहचान: engineer समस्या गंभीर होने से पहले ही मुद्दा उठा देता है
• ideas पर सक्रिय चर्चा: दो senior developers अगली सुबह सहयोग में कोई समस्या आए बिना एक दिन पहले architecture पर तीखी बहस कर सकते हैं
• समस्या पर केंद्रित रवैया: जैसे “इस approach में scalability की समस्या हो सकती है”, यानी ध्यान व्यक्ति पर नहीं बल्कि समस्या पर होता है
• गलतियाँ सीखने का अवसर हैं: outage होने पर गलती करने वाला engineer खुद postmortem लीड करता है

'अच्छी' टीमों से छूट जाने वाली छिपी हुई लागत

• ऊपर से शांत दिखने वाली टीमें अक्सर सिर्फ औसत दर्जे का output देती हैं
• क्योंकि critical thinking के लिए एक सीमा तक friction ज़रूरी होता है
• ऊपर-ऊपर सहमति दिखने के बावजूद असली टकराव भीतर छिपा रह सकता है; मीटिंग में सब सहमत दिखते हैं, लेकिन असल काम में हर कोई अलग दिशा में चलता है
• communication की कमी मूल समस्या होती है, और रचनात्मक बहस की कमी अंतिम परिणाम को कमजोर कर देती है

मनोवैज्ञानिक सुरक्षा और संघर्ष के बीच संतुलन बनाना

• माहौल बनाने के लिए तीन प्रमुख व्यावहारिक तरीके
  • यह ईमानदारी से स्वीकार करना कि आपको भी सब कुछ नहीं पता (अपनी vulnerability दिखाना)
  • बहस के लिए स्पष्ट नियम तय करना (व्यक्ति नहीं, idea पर ध्यान; चर्चा और निर्णय को अलग रखना)
  • मुद्दा उठाने या कठिन सवाल पूछने वाले सदस्यों की औपचारिक रूप से सराहना करना (एक boundary signal की तरह)

निष्कर्ष: स्वस्थ टकराव ही वास्तविक विकास और innovation का आधार है

• वास्तव में जो टीमें टकराव को खुलकर सामने आने देती हैं, उनमें लंबी अवधि में टकराव की गुणवत्ता बेहतर रहती है
• छोटे-छोटे मतभेद जमा नहीं होते, बल्कि तुरंत सुलझा लिए जाते हैं, जिससे भरोसा और सहयोग मजबूत होता है
• बेहतरीन engineering teams शांत नहीं होतीं; वे technical debate और अलग-अलग नज़रियों का स्वागत करती हैं
• टीम के भीतर खुलकर चर्चा करना और एक-दूसरे का सम्मान करना ही असली मनोवैज्ञानिक सुरक्षा है
• जैसे बिना परखे गए code और ideas समस्या पैदा करते हैं, वैसे ही बिना बहस वाले ideas भी असफलता लाते हैं

[chipmunk]

मनोवैज्ञानिक सुरक्षा हो या रचनात्मक बहस, आखिरकार ये सब ‘execution’ के लिए ईंधन हैं।
किसी idea को सच में जीवंत बनने के लिए आखिर किसी न किसी को उसे आगे बढ़ाना पड़ता है, और वही कार्रवाई बार-बार दोहराई जाए तभी भरोसा बनता है।
अगर execution के बिना सिर्फ बहस ही दोहराई जाती रहे, तो माहौल कितना भी सुरक्षित क्यों न हो, टीम वहीं की वहीं रहती है।
अच्छी संस्कृति वही है, जो शब्दों से नहीं बल्कि actions से साबित होती है.

[chipmunk]

जिन लोगों के पास execution की क्षमता होती है, उनके बीच constructive बहस होना लगभग तय है।

[mhj5730]

अक्सर... अगर टीम लीडर रूढ़िवादी हो, ज़िम्मेदारी से बचने वाला हो, और सारा काम बस दूसरों को सौंप देता हो, तो बाकी सब लोग अपने-आप चुपचाप अच्छे बन जाते हैं।

[kaydash]

ईमानदार फ़ीडबैक क्यों महत्वपूर्ण है

[ndrgrd]

राय रखने की बाधा जितनी कम हो, उतना अच्छा है। बस मानदंड और संतुलन खोजना मुश्किल होता है।

[GN⁺]

Hacker News राय

• IT इंडस्ट्री में 20 साल से ज़्यादा काम करने के मेरे अनुभव में, कई लोग 'तीखी बहस' को गलतफ़हमी में high-performing team का संकेत मान लेते हैं। ऐसा नज़ारा अक्सर बहुत conflict वाली low-performing teams में भी दिखता है। मैनेजर खुलेआम नकारात्मक feedback देते थे, या veteran developer नए लोगों से कहते थे कि पसंद नहीं है तो निकल जाओ—ऐसी टीमों में अंदरूनी विभाजन काफ़ी गहरा था। बहुत प्रशिक्षित, तर्क में निपुण लोग 'strong opinions, loosely held' वाला रवैया दिखाते हुए कमज़ोर ideas को भी आख़िर तक आक्रामक तरीके से धकेलते रहते थे, जब तक बाकी सब थककर हार न मान लें। असल में real-time में इनका खंडन करना लगभग नामुमकिन होता है, इसलिए बहुत से मैनेजर इनके आत्मविश्वास या जुनून को skill या correctness समझ बैठते हैं। इस नज़रिए से, गरमागरम बहस अपने आप में high performance की गारंटी नहीं है
  • मेरे अनुभव में, ऊपर के उदाहरण की असली समस्या real-time proof की कमी नहीं, बल्कि यह है कि जो लोग अच्छा बोलते हैं वे अक्सर अच्छा सुनते नहीं। कोई बात भले ही अनगढ़ तरीके से कही गई हो, उसके सार को पकड़ पाना एक अहम क्षमता है; सिर्फ़ delivery कमज़ोर होने के कारण उसे नज़रअंदाज़ करना अहंकार है। अगर आप खुद ठीक से सुनते नहीं, तो खुद को 'strong opinions, loosely held' नहीं कह सकते। केवल वही बातें स्वीकार करना जिनके सबूत मुश्किल से निकाले जा सकें, दरअसल 'strong opinions, tightly held' है। आख़िरकार अगर बार-बार गरम बहस हो रही है, तो वही अपने आप में team dysfunction का संकेत हो सकती है। ईमानदार और शांत चर्चा टीम के लिए ज़्यादा productive होती है
  • लेखक भी अपने talk में इसी बात पर ज़ोर देता है कि फोकस समस्या पर होना चाहिए। जैसे, 'इस approach की scalability सीमित है'—अगर चर्चा इस तरह दिशा ले, तो ठीक है; लेकिन जैसे ही किसी व्यक्ति के idea को ही नीचा दिखाया जाता है, बातचीत तुरंत toxic बन जाती है
• मेरे पास 25 साल तक high-performance C++ image-processing pipeline development team लीड करने का अनुभव है। मैं एक international और interdisciplinary large team का हिस्सा था, और दुनिया-प्रसिद्ध imaging company में काम करता था। कई अलग-अलग क्षेत्रों के experts के साथ collaboration था, इसलिए सबके साथ हमेशा सहज रहना आसान नहीं था। हर किसी को लगता था कि सही जवाब उसी के पास है, और हर कोई बेहतरीन नतीजा देने को लेकर बेहद passionate था। इसलिए तीखी बहसें होना स्वाभाविक था। लेकिन ज़्यादातर बार नतीजे बहुत अच्छे रहे, और समस्याओं की जड़ टीम के अंदरूनी conflict नहीं थी। मेरे अनुभव में creative, passionate और highly capable teams काफ़ी chaotic हो सकती हैं, और उन्हें manage करना सचमुच बहुत कठिन काम है
  • जिज्ञासा है कि 25 साल जैसी लंबी अवधि तक यह कैसे manage किया गया—कौन-से ठोस rules, workflow, और team culture थे? Team member turnover कितना था? और बहुत तेज़-तर्रार प्रतिभाओं के टकराव वाली टीम को संभालने के practical तरीके क्या थे? कोई जादुई समाधान तो नहीं होगा, लेकिन असली उदाहरण बहुत मददगार होंगे
• इस लेख में शायद 'तीखी बहस का न होना' और 'constructive critical discussion का अभाव'—इन दोनों को मिला दिया गया है। मेरे अनुभव में high-trust mature teams में गरमागरम बहस इसलिए नहीं होती क्योंकि किसी को यह डर नहीं होता कि उसकी बात अनसुनी कर दी जाएगी। सभी को भरोसा होता है कि उनकी बात सुनी जाएगी और उस पर गंभीरता से विचार होगा, इसलिए उत्तेजित होने की ज़रूरत नहीं पड़ती। 'जिस code पर किसी ने सवाल नहीं उठाया, वह production में ज़रूर समस्या करेगा'—इस बात का मतलब मुझे साफ़ नहीं लगा
  • शायद मतलब यह है कि जिस code की किसी ने आलोचना नहीं की, वह आख़िर में फटेगा। लेकिन यह हर बार सच नहीं होता
  • High-trust teams में बहस का कम गर्म होना तब ज़्यादा दिखता है जब risk और uncertainty काफ़ी कम हों। अगर स्थिति ऐसी हो जहाँ हर किसी को अपनी intuition और logic को आख़िरी हद तक धकेलना पड़े, तो team के अलग-अलग nodes के बीच communication की मात्रा असंतुलित हो जाएगी। ज़िम्मेदारी leadership को जन्म देगी, और कई perspectives बारी-बारी से उभरेंगे और फीके पड़ेंगे। अगर चर्चा का तापमान हमेशा ही कम रहे, तो शायद यह भी सोचना चाहिए कि कहीं team खुद को पर्याप्त चुनौती तो नहीं दे रही
  • लगता है लेख इसी नज़रिए का सीधा जवाब दे रहा है। 'ऊपरी तौर पर शांत team' असल में conflict से बचने के लिए वास्तविक मतभेदों से ही बच रही हो सकती है। ऊपर से consensus दिखे या न दिखे, बुनियादी समस्याएँ दबकर रह जाती हैं
  • सच में, कभी-कभी ऐसा code या architecture जिसे किसी ने call out नहीं किया, पूरी तरह बिखरा हुआ निकलता है
• दोबारा पढ़ने पर समझ आया कि शुरू में लेख का tone गलतफ़हमी क्यों पैदा कर सकता था। लेखक जिस psychological safety को परिभाषित कर रहा है, वह सही है, लेकिन वह इस बात की ओर इशारा कर रहा है कि बहुत लोग 'nice team' को ही psychologically safe समझ लेते हैं। अगर सब सिर्फ़ सिर हिलाते रहें, तो उससे कोई सुरक्षित महसूस नहीं करता। Conflict और safety एक-दूसरे के विरोधी नहीं हैं। असली psychological safety का मतलब है ऐसा माहौल बनाना जहाँ हर कोई productive conflict में शामिल होने के लिए तैयार हो। हर conflict productive नहीं होता, और हर agreement भी नहीं। Psychological safety का मतलब है ऐसी team culture बनाना जहाँ सहमति और असहमति—दोनों को खुलकर व्यक्त किया जा सके
  • ऐसी टीम जहाँ सब हर बात पर सहमत हों, उतनी ही ख़तरनाक team होती है। इसी वजह से ऐसा होता है कि बॉस कुछ कहे और सब तुरंत हाँ में हाँ मिलाने लगें
• क्या कोई सचमुच इस बात से बहुत प्रभावित हुआ है कि 'ideas को वक्ता नहीं, बल्कि idea के आधार पर evaluate किया जाना चाहिए'? पूरा लेख कुछ-कुछ Don Quixote के windmill से लड़ने जैसा लगता है। यानी शायद यह उन engineers को target करता है जो ज़मीन पर पहले से स्थापित साधारण समझ वाली बातों पर भी असंतोष रखते हैं। या फिर यह authoritarian dictator-जैसे leaders को लक्ष्य बना रहा हो सकता है, लेकिन क्या ऐसे लोग यह लेख सुनेंगे? 'मेरी सबसे बेहतरीन teams कभी शांत नहीं थीं। वे उत्साही बहसों, अलग-अलग viewpoints के स्वागत, और respectful disagreement से भरी थीं...'—आख़िर कौन कहेगा कि वह diverse perspectives के सम्मान के ख़िलाफ़ है? सच कहूँ तो, पिछली चर्चा ने इससे ज़्यादा सोचने की सामग्री दी थी
  • 'क्या यह बहस कोई ख़ास insight देती है'—इस सवाल पर, हाँ, यह बात काफ़ी बुनियादी है, लेकिन पहले भी checklist से जानें बची हैं, या Toyota में कर्मचारियों को शक होने पर production line रोकने का अधिकार दिया गया था—ऐसे उदाहरण इसकी अहमियत दिखाते हैं। IT में भी teams और दूसरे लोगों, खासकर DEV/TEST के बीच, एक-दूसरे को कमतर समझना बहुत आम है। हो सकता है समस्या पैदा करने वाला व्यक्ति यह लेख कभी न पढ़े, लेकिन टीम का कोई दूसरा सदस्य कभी यह समझ जाए कि यह सामान्य नहीं है, और फिर काम करने का तरीका बदले या बदलाव शुरू हो। ऊपर-ऊपर कोई यह नहीं कहेगा कि वह 'दूसरे perspectives के सम्मान' के ख़िलाफ़ है, लेकिन व्यवहार में लोग दूसरी teams को मन ही मन 'वे बेवकूफ़ लोग' कहकर देखते हैं, और ऐसी मानसिकता productive debate को शुरू होने से पहले ही रोक देती है
  • पहले यह समझना ज़रूरी है कि आप किस तरह की team में हैं। जो team 'शांत consensus' को मूल्य बताती है, वह अक्सर ऐसी होती है जहाँ कुछ लोगों ने पहले ही स्वार्थी फ़ैसले कर लिए होते हैं, और full meeting में कोई नया मत सामने आए, यह उन्हें नहीं चाहिए होता
• यह समझ बनी कि एक दयालु लेकिन आलोचनात्मक दोस्त का feedback, बिना आलोचना करने वाले दोस्त की तुलना में ज़्यादा सीख देता है
• जैसे हर रिश्ते में, वैसे ही यहाँ भी लक्ष्य 'जीतना' नहीं, बल्कि ऐसा माहौल बनाना है जहाँ सबकी ज़रूरतें पूरी हों
• जब team के ज़्यादातर लोग बहुत ज़ोर से बोलते हों लेकिन हर बार ग़लत राय ही आगे बढ़ाते हों, तब सही नज़रिया रखने वाला अकेला व्यक्ति कैसे टिके—इस पर विचार
  • सबसे तेज़ समाधान है पूरी तरह disengage हो जाना। अगर वे सच में लगातार ग़लत हैं, तो मेरे बिना भी उनकी हालत और तेज़ी से बिगड़ेगी। या फिर उनकी ताक़त को उनके ख़िलाफ़ मोड़कर, ग़लत idea को खुद ही self-destruct करने दिया जा सकता है
  • अगर आप leader नहीं हैं, तो सही होना भी बहुत मायने नहीं रखता, और 'मैं सही था' यह तथ्य भी reward नहीं होता। कुछ projects में सिर्फ़ दिखावा ज़रूरी होता है, productivity नहीं। अगर आपने उद्देश्य ही गलत समझ लिया, तो आपने 'सही' ढंग से काम नहीं किया। तब आप बस पैसे लेकर काम जारी रखने या वहाँ से निकल जाने का फ़ैसला कर सकते हैं
  • अगर सड़क पर सब लोग उल्टी दिशा में भाग रहे हों, तो कभी-कभी यह भी शक करना चाहिए कि कहीं गलती मेरी ही दिशा में तो नहीं है
• एक समय ऐसा भी था जब CTO (co-founder) बेहद toxic इंसान था, इसलिए team के भीतर खुशी का एक बुलबुला बन गया था। उस समय वह सबसे बेहतरीन team लगती थी, लेकिन जब वह बुलबुला अचानक फूटा, तब असल में बहुत भयावह स्थिति सामने आई

[techiemann]

"ऐसे मामले होते हैं जब लोग मन ही मन दूसरी टीम को 'वे बेवकूफ लोग' कहकर बुलाते हैं, और ऐसी मानसिकता में productive बहस अपने-आप रुक जाती है

पहले यह समझना ज़रूरी है कि आप किस तरह की टीम में हैं। जो टीमें 'शांत सहमति' को मूल्य बताती हैं, उनमें अक्सर हक़ीक़त यह होती है कि कुछ गिने-चुने लोगों के स्वार्थी फ़ैसले पहले से आपस में तय कर लिए जाते हैं, और पूरी मीटिंग में वे नई राय सामने आना नहीं चाहतीं"

हमें द्वितीय विश्व युद्ध के जापानी सेना के Imperial General Headquarters जैसी बैठकों से बचना चाहिए। यह भी समस्या है कि कहीं कोई मुझे अलग-थलग करके अंक न ले जाए, प्रमोशन न पा ले, या सफल न हो जाए—इस डर से अपने group के भीतर और बाहर मन ही मन शत्रुतापूर्ण और असहयोगी संस्कृति पनपती है।