सहयोग बकवास है

• द्वितीय विश्व युद्ध के दौरान वास्तव में गोली चलाने वाले सैनिकों की संख्या सिर्फ 15~20% थी—इस तरह के शोध की तरह, संगठनों में भी अधिकांश वास्तविक नतीजे कुछ ही लोग बनाते हैं
• टेक इंडस्ट्री ने इस समस्या के समाधान के रूप में "सहयोग" को आगे रखा, लेकिन व्यवहार में सिर्फ काम के समन्वय के टूल बढ़े और आउटपुट लगभग नहीं के बराबर रह गया
• जैसे-जैसे समूह बड़ा होता है, communication cost और coordination cost विस्फोटक रूप से बढ़ते हैं, और ज़िम्मेदारी के बिखराव की वजह से मीटिंग से मीटिंग पैदा होने का चक्र दोहराया जाता है
• पारदर्शिता को प्रगति समझ लिया जाता है, और visibility को accountability मान लिया जाता है, जिससे सहयोग की संस्कृति व्यक्तिगत ज़िम्मेदारी को पतला करने वाले तंत्र की तरह काम करती है
• वास्तव में जटिल और उच्च-गुणवत्ता वाला काम अधिकतर स्पष्ट अधिकार और ज़िम्मेदारी वाले व्यक्ति या छोटे समूह ही करते हैं, और सहयोग सिर्फ उसे पैक करने की भाषा बनकर रह जाता है
• वास्तव में ज़रूरत सहयोगी इन्फ्रास्ट्रक्चर की नहीं, बल्कि व्यक्ति के स्वायत्त निर्णय और ज़िम्मेदारी (ownership) की है, और संगठन को इसी पर भरोसा करने की दिशा में बदलना चाहिए

---

सहयोग नाम का भ्रम

• सहयोग (collaboration) को आधुनिक संगठनों में productivity के प्रतीक की तरह देखा जाता है, लेकिन वास्तव में यह ज़िम्मेदारी से बचने और अक्षमता की संरचना की तरह काम करता है
  • द्वितीय विश्व युद्ध के दौरान S.L.A. Marshall के शोध के अनुसार, लड़ाई के बीच वास्तव में गोली चलाने वाले सैनिक सिर्फ 15~20% थे
  • IBM ने 1960s में जो पैटर्न पाया—"80% उपयोग 20% फीचर्स से आता है"—उसी तरह कुछ ही सदस्य अधिकांश परिणाम पैदा करते हैं
  • बाकी लोग सिर्फ “structural support” देते हैं, और संगठन के भीतर मेहनत का असंतुलन बार-बार दिखाई देता है
• टेक उद्योग ने इस समस्या को हल करने के लिए ‘सहयोग’ की अवधारणा का लगभग आस्था की तरह पीछा करना शुरू कर दिया
  • Notion, ClickUp, Slack, Jira, Monday, Teams जैसे अनगिनत collaboration tools आए, लेकिन output से ज़्यादा activity बढ़ी
  • पारदर्शिता और visibility को ही प्रगति या ज़िम्मेदारी मान लिया जाता है, और “किसी thread में शामिल होना” को “किसी परिणाम का मालिक होना” के बराबर समझ लिया जाता है
  • इसके कारण सहयोग, वास्तविक नतीजों के बजाय भागीदारी के simulation में बदल गया
• ज़िम्मेदारी का बिखराव (diffusion of responsibility) बहुत पहले से देखा गया है
  • 1913 का Ringelmann effect दिखाता है कि जैसे-जैसे समूह का आकार बढ़ता है, व्यक्ति के प्रयास का अनुपात घटता है
  • Frederick Brooks ने 1975 में IBM System/360 के उदाहरण से यह नियम दिया कि किसी देर से चल रहे प्रोजेक्ट में लोगों को जोड़ने से वह और देर से पूरा होता है
  • लोगों की संख्या बढ़ने पर communication cost और coordination cost ज्यामितीय रूप से बढ़ते हैं, और मीटिंग से मीटिंग पैदा होने का दुष्चक्र बनता है
• सहयोग उद्योग ने इस संरचनात्मक समस्या को छिपाने के लिए भारी संसाधन झोंके, लेकिन वास्तविक high-quality काम कुछ व्यक्तियों या छोटे टीमों ने ही किया
  • Dostoevsky ने 『The Brothers Karamazov』 अकेले लिखा, और Apollo Guidance Computer को MIT की एक छोटी टीम ने स्पष्ट ज़िम्मेदारी की संरचना के तहत विकसित किया
  • असली उपलब्धि स्पष्ट अधिकार और व्यक्तिगत ज़िम्मेदारी से आती है, और सहयोग सिर्फ उन परिणामों को पैक करने की भाषा की तरह काम करता है
  • इसके विपरीत, आधुनिक संगठनों ने social management के लिए जटिल collaboration infrastructure तो बना लिया, लेकिन असली काम पीछे छूट गया
• वास्तविक ownership वह स्थिति है जिसमें व्यक्ति स्वयं निर्णय लेता है और उसके परिणामों को स्वीकार करता है
  • लेकिन जहाँ सहयोग सांस्कृतिक मानक बन चुका हो, वहाँ अकेले लिया गया निर्णय असहयोगी व्यवहार माना जाता है
  • सहयोग की विचारधारा ने ज़िम्मेदारी और पहल को लगभग असामाजिक व्यवहार जैसा महसूस कराना शुरू कर दिया है, और इससे उत्पादन का मूल तंत्र कमज़ोर पड़ता है
  • मीटिंग, दस्तावेज़, retrospective, kickoff आदि अंतहीन चलते रहते हैं, लेकिन अंत में सिर्फ कार्यान्वयन से कटा हुआ ‘अत्यधिक समन्वय’ बचता है

व्यक्तिगत ज़िम्मेदारी की ओर लौटने की ज़रूरत

• अधिकांश प्रोजेक्ट अब coordination time > execution time वाली संरचना में बदल चुके हैं, और विफलता होने पर समाधान फिर “और ज़्यादा सहयोग” ही बताया जाता है
  • लेकिन असली सवाल यह है: “हम वास्तव में क्या बना रहे हैं, और उसकी ज़िम्मेदारी कौन लेता है?”
  • किसी भी काम के लिए अंतिम ज़िम्मेदार एक ही व्यक्ति होना चाहिए, भले ही सहयोग की संरचना उसकी मौजूदगी को धुंधला कर दे
• व्यक्ति पर भरोसे की बहाली ज़रूरी है
  • हर ज़िम्मेदारी पर पूरे संगठन की निगरानी ज़रूरी नहीं है
  • अत्यधिक प्रबंधन और metrics-केंद्रित संस्कृति की जगह, व्यक्ति को अपना काम खुद संभालना चाहिए और उसका मूल्यांकन परिणामों से होना चाहिए
  • विफलता की स्थिति में उसकी ज़िम्मेदारी स्पष्ट रूप से उसी व्यक्ति को सौंपी जानी चाहिए
• सामूहिक प्रयास के भ्रम को छोड़कर, हमें ऐसे वातावरण में लौटना होगा जहाँ वास्तव में काम करने वाले व्यक्ति की पहचान हो सके
  • हर व्यक्ति अपना काम खुद संभाले और उसी के परिणामों पर उसका मूल्यांकन हो—ऐसी सरल संरचना में वापसी
  • जब हम “सहयोग” नाम की इस गर्मजोशी भरी लेकिन महंगी कल्पना को छोड़ देंगे, तब यह साफ़ दिखेगा कि वास्तव में ट्रिगर कौन दबा रहा है

[propecia]

ऐसा लग रहा है कि बस 'मैं collaboration नहीं कर सकता' वाली घोषणा को लंबा करके लिखा गया है। बड़े संगठनों में collaboration की अवधारणा कभी-कभी बाधा बन सकती है, लेकिन वह भी आखिरकार collaboration ठीक से न कर पाने से पैदा होने वाली स्थिति है, collaboration खुद उसकी समस्या नहीं है।

[khris]

लगता है लेखक का स्वभाव कुछ खास अच्छा नहीं है।

[skageektp]

हाहाहाहाहाहाहाहाहा अरे, ज़ोर से हँसी छूट गई हाहाहा

[laeyoung]

"द्वितीय विश्व युद्ध के दौरान वास्तव में गोली चलाने वाले सैनिक केवल 15~20% थे"

मार्शल के "15~20% firing rate" दावे का सीधे खंडन और विश्लेषण करने वाले बाद के शोध और पेपर सैन्य इतिहास के क्षेत्र में काफ़ी महत्व के साथ देखे गए हैं। 1980 के दशक के बाद कई इतिहासकारों और सैन्य विशेषज्ञों ने मार्शल के शोध अभिलेखों का पीछा किया, और इस निष्कर्ष पर पहुँचे कि यह आँकड़ा वास्तव में गढ़ा गया था या गंभीर रूप से बढ़ा-चढ़ाकर पेश किया गया था।

रॉबर्ट एंगन (2010) ने द्वितीय विश्व युद्ध के दौरान अमेरिकी सेना जैसी परिस्थितियों में लड़ने वाले कनाडाई सेना के इन्फैंट्री अधिकारियों के सर्वेक्षण और युद्ध अभिलेखों का विश्लेषण किया। उन्होंने साबित किया कि कनाडाई सेना की वास्तविक firing rate मार्शल के दावे वाले 15~20% से बहुत अधिक थी, और इस आधार पर तर्क दिया कि मार्शल का दावा पूरे पश्चिमी मित्र-राष्ट्र बलों पर लागू नहीं किया जा सकता और यह गंभीर generalization error है।

---

शुरुआत की बात से ही कुछ अजीब लगा, इसलिए खोजकर देखा तो यह शायद ग़लत तरीके से फैली हुई जानकारी लगती है। नीचे Hacker News की टिप्पणियों में जो कहा गया है, वह भी ऐसा ही दिखता है।

[GN⁺]

Hacker News की राय

• मैंने 30 साल से ज़्यादा इस काम में जो देखा है, वह यह है कि "तारीख (date)" को हमेशा डिलीवर किए जाने वाले परिणाम से ज़्यादा महत्वपूर्ण माना जाता है
  हकीकत में उस तारीख तक पहुँचना लगभग असंभव होता है, लेकिन संगठन फिर भी उसी को एकमात्र मीट्रिक मानते हैं
  सॉफ़्टवेयर डेवलपमेंट मूल रूप से अनुमान से परे जाने वाली गतिविधि है, इस बात पर लगभग कोई ध्यान नहीं दिया जाता
  जब Agile manifesto पहली बार आया था तब उम्मीद थी, लेकिन वह जल्दी ही "हर चरण में कितना समय लगेगा, यह ठीक-ठीक बताओ" वाली मैनेजमेंट शैली में बदल गया

  • मेरे अनुभव में असली मुद्दा तारीख नहीं बल्कि बजट है
    थोड़ा देर होना माफ़ किया जा सकता है, लेकिन अगर आप ज़्यादा पैसे माँगें तो हमेशा के लिए नापसंद किए जाते हैं
    Agile तभी अच्छी तरह काम करता है जब अच्छा Product Owner सही बजट और निर्णय लेने का अधिकार सुरक्षित कर ले
  • "तारीख हमेशा ज़्यादा महत्वपूर्ण होती है" इस विचार से मैंने Date-bound delivery नाम की एक नई पद्धति के बारे में सोचा
    टीम तय समय के भीतर जितना संभव हो उतना ही डिलीवर करे, और डेडलाइन पास आने पर फीचर घटाती जाए
    यह आउटपुट की सामग्री से ज़्यादा डिलीवरी को सुनिश्चित करने का तरीका है
    अगर तारीख सच में इतनी महत्वपूर्ण है, तो क्या ऐसा अप्रोच आज़माने लायक नहीं है?
  • Spolsky के उद्धरण को आगे बढ़ाएँ तो बात कुछ ऐसी है: "अगर कोई और आपकी jeans का पैसा दे रहा हो, तो कहानी अलग होती है"
    छोटे संगठनों में असली stakeholder मौजूद होते हैं, लेकिन बड़े संगठनों में परफॉर्मेंस और करियर अलग-अलग हो जाते हैं
    मैं hardware में काम करता हूँ, और अपने साल के अंत का लक्ष्य इस तरह परिभाषित करता हूँ कि "मेरे द्वारा सीधे लिखे गए कोड से demo किया जा सके"
  • आजकल LLM भी इंसानों की तरह बढ़ा-चढ़ाकर estimate बताते हैं
    कहते हैं "इसमें कुछ हफ्ते लगेंगे", लेकिन असल में 30 सेकंड में लागू कर देते हैं

• मुझे लगता है कि लेखक ने बात कुछ ज़्यादा ही तीखे ढंग से कही है
  शायद उसने बहुत खराब सहयोग वाले टीम में काम करने का ट्रॉमा झेला हो
  लेकिन अच्छी तरह चलने वाली टीमें निश्चित रूप से मौजूद हैं, और समूह कभी-कभी व्यक्ति से बड़ा परिणाम दे सकता है
  पिरामिड, Linux kernel, और AWS किसी एक व्यक्ति ने नहीं बनाए

  • मैं भी पहले high-performance टीम में काम करता था, लेकिन अब अकेले काम करता हूँ
    टीम जितनी बड़ी होती है, communication overhead उतना बढ़ता है, और उसका बड़ा हिस्सा मैनेजमेंट की visibility की इच्छा से आता है
    अच्छी टीमें अंदरूनी तौर पर अच्छा संवाद करती हैं, लेकिन मैनेजमेंट को भी कुछ हद तक visibility चाहिए होती है
    अंत में अच्छी टीम + अच्छा manager का संयोजन ज़रूरी है
  • मेरे हिसाब से लेख का मुख्य बिंदु यह है कि "सहयोग एक विचारधारा बन गया है और ज़िम्मेदारी गायब हो गई है"
    ज़्यादातर संगठन सहयोग ठीक से कर ही नहीं पाते, लेकिन उसकी विफलता को भी "सहयोग" शब्द से ढक देते हैं
    फिर भी "सिर्फ छोटी टीमें ही काम करती हैं" वाला दावा कुछ हद तक अतिरंजित है
    पिरामिड निर्माण जैसे उदाहरण आधुनिक अर्थों में collaboration से ज़्यादा कड़े command structure के करीब हैं
  • लेखक का नज़रिया कुछ ज़्यादा ही नकारात्मक है
    Apollo computer program छोटे टीम ने बनाया था, लेकिन चाँद तक पहुँचने के लिए उससे कहीं अधिक सहयोग की ज़रूरत थी
    सहयोग वास्तव में प्रभावी होता है, इसके सबूत बहुत ज़्यादा हैं
  • समूह की उपलब्धि और व्यक्ति की उपलब्धि रैखिक नहीं होती
    अकेला व्यक्ति Assassin’s Creed जैसी बड़ी कृति नहीं बना सकता, और कोई committee Stardew Valley जैसा गेम नहीं बना सकती
    ये अलग-अलग तरह की क्षमताएँ हैं
  • Linux kernel में वास्तव में व्यक्तिगत ज़िम्मेदारियाँ साफ़-साफ़ बँटी हुई हैं

• मैं भी लेखक के अनुभव से खुद को जोड़ पाता हूँ
  startup से निकाले जाने के बाद मैं एक बड़ी कंपनी में गया, और शुरुआत में टीमवर्क बहुत अच्छा बैठा, इसलिए नतीजे भी अच्छे थे
  लेकिन फिर Agile coach आया और "सहयोग" के नाम पर अपना एजेंडा थोपना शुरू कर दिया
  8 महीनों तक बेकार workshops और अधिकार की खींचतान चलती रही, और अंत में सक्षम टीम को निष्क्रिय टीम के पीछे घसीटा गया
  अयोग्य लोगों को न निकालने वाली संस्कृति ही समस्या है
  असली सहयोग तभी संभव है जब लोग अपना अहं नीचे रखें, एक-दूसरे को सुनें, और मिलकर काम करें

• अकेले काम करने पर आप ज़्यादा काम कर सकते हैं, लेकिन समस्या को गलत परिभाषित करने का जोखिम बढ़ जाता है
  सहयोग अलग-अलग दृष्टिकोणों के ज़रिए उसे रोकता है

  • लेकिन बड़े संगठनों में सहयोग कभी-कभी ऐसी स्थिति बन जाता है जहाँ कोई भी समस्या हल नहीं होती
    जो लोग काम नहीं करते, वही काम करने वालों को बाधित करते हैं

• हाल में मैंने McEntire का पेपर "The Organizational Physics of Multi-Agent AI" पढ़ा, जो काफ़ी दिलचस्प था
  AI agent भी इंसानी संगठनों की राजनीतिक अक्षमता को ज्यों का त्यों दोहराते हैं
  आख़िर में, अगर संगठन खराब हो तो लोग सिर्फ "काम के बारे में काम (work about work)" ही करते रह जाते हैं
  छोटी और जवाबदेह टीमें कहीं ज़्यादा सुखद होती हैं, लेकिन उन्हें दोहराना आसान नहीं है
  मेरी ब्लॉग पोस्ट Where to Cut में भी यह विषय आता है

  • मैं भी हाल में Team Topologies फिर से पढ़ रहा हूँ
    जब भूमिकाएँ और संरचना स्पष्ट हों, तभी orchestration ठीक से काम करता है — यह बात महसूस हुई
  • अच्छी टीमें fungible नहीं होतीं
    लोगों को बदलने या टीमों को इधर-उधर करने पर context switching cost पैदा होती है और टीम की एकजुटता टूट जाती है
  • तुम्हारी पोस्ट मूल लेख से कहीं ज़्यादा स्पष्ट है
    मूल लेख आखिर कहना क्या चाहता था, यह समझना मुश्किल था
  • यह बात दिलचस्प है कि "ईश्वर ने मनुष्य को अपनी छवि में बनाया" जैसी पंक्ति training data में जानबूझकर डाली गई थी, या यह बस बिना सोचे-समझे किए गए data collection का उप-उत्पाद है

• ऐसी संस्कृति जहाँ नतीजे देने वालों को पहचान नहीं मिलती, संगठन को भीतर से खोखला कर देती है
  अतिरिक्त बोझ उठाने वाले 20% लोग बस पहचाने जाना चाहते हैं
  अगर उन्हें यह नहीं मिलता, तो कंपनी बहुत जल्दी खाली हो जाती है

  • मेरे लिए पहचान से ज़्यादा टीम की camaraderie और compensation महत्वपूर्ण है
    जो लोग यह तक नहीं जानते कि मैं क्या करता हूँ, उनके प्रशंसा-शब्दों में मेरी कोई दिलचस्पी नहीं
  • ज़्यादातर white-collar नौकरियाँ मूल रूप से ऐसी संरचना में चलती हैं जहाँ योगदान को ठीक से मान्यता नहीं मिलती

• यह लेख संगठन से आगे बढ़कर 'लेखनाधिकार और कर्तृत्व' के सामाजिक अर्थ तक फैलाया जा सकता है
  जटिल और उच्च-गुणवत्ता वाला काम आख़िरकार छोटी टीमों या व्यक्तियों की स्पष्ट जवाबदेही से ही निकलता है
  जैसे Dostoevsky या Apollo computer टीम
  दूसरी ओर, "सब योगदान दें लेकिन किसी को पुरस्कार न मिले" वाली सहयोगी यूटोपिया वास्तविकता से काफ़ी दूर है
  इंसान उस रचना के लिए ज़्यादा प्रेरित होते हैं जिस पर उनका अपना नाम जुड़ा हो

  • लेकिन हम सब पिछली पीढ़ियों की उपलब्धियों पर खड़ी सहयोगी संरचना के भीतर ही हैं
    जटिल supply chain भी collaboration का ही एक दूसरा रूप है

• "80% सैनिकों ने गोली नहीं चलाई" वाला दावा संदिग्ध लगा, इसलिए खोजा तो पता चला कि वह काफ़ी पहले से खंडित किया जा चुका डेटा था
  2011 के पेपर में भी कहा गया है कि उसका आधार कमजोर है

  • संभव है कि logistics personnel को भी इसमें शामिल कर लेने से भ्रम पैदा हुआ हो
    अमेरिकी सेना के tooth-to-tail ratio को देखें तो वास्तविक लड़ाकू बल सिर्फ 4~10% के आसपास होता है
    इसलिए संभव है कि संख्या को लेकर यही भ्रम वजह हो
  • किताब On Killing का विश्लेषण है कि training में सुधार से firing rate 90% से ऊपर चला गया
    लेकिन उसके साथ PTSD की दर भी बढ़ी

• पूरा लेख ऐसा लगता है जैसे सैनिकों के उदाहरण को जबरन white-collar मॉडल पर चिपकाने की incoherent कोशिश हो
  लेकिन लेखक के लिए अच्छी खबर है — आप भी individual creator बन सकते हैं
  Notch या Stardew Valley के डेवलपर की तरह
  शिकायत करने के बजाय खुद कुछ बनाइए

  • फिर भी, "अगर मरना नहीं है तो दुश्मन पर गोली चलानी ही होगी, है न?" इस नज़रिए से देखें तो
    80% लोगों ने गोली नहीं चलाई, यह बात अब भी दिलचस्प लगती है
  • जैसे-जैसे समूह बड़ा होता है, ज़िम्मेदारी के फैल जाने की घटना पहले से ही अच्छी तरह जानी-पहचानी है

• लेखक ने परफॉर्मेंस के लिए incentive design को बिल्कुल ध्यान में नहीं रखा
  Munger की बात याद आती है: "incentive को देखो, नतीजा समझ आ जाएगा"
  सहयोग की कठिनाई से भी ज़्यादा महत्वपूर्ण है ऐसी संरचना बनाना जो प्रदर्शन करने वालों को पुरस्कृत करे और free rider को दंडित करे

  • लेकिन वास्तविक tech संगठनों में जो incentives दिए जा सकते हैं, वे ज़्यादातर salary raise या bonus तक ही सीमित होते हैं
    और वह भी बहुत ज़्यादा नहीं
  • यह भी सवाल है कि क्या incentives को बड़े पैमाने पर align करना वास्तव में संभव है
    अगर यह संभव होता, तो शायद हम अब तक यूटोपिया में जी रहे होते

[reedids]

पहली ही पंक्ति का आधार तथ्य से अलग है, यह बात छोड़ भी दें तो युद्ध में बंदूक चलाने का मुद्दा (किसी इंसान की जान जा सकती है, युद्ध के समय सैनिकों की ट्रेनिंग का स्तर... आदि कई बातें इसमें मिली हुई हैं) को development में collaboration की समस्या से जोड़कर सोचना ही अजीब लगता है। क्या यह ऐसा लेख है जो साबित करता है कि शुरुआत कितनी महत्वपूर्ण होती है...

[loegnah]

प्रतिक्रियाएँ देखकर लगता है कि सच में बहुत से लोग इस लेख के मुताबिक गलतफ़हमी में जी रहे हैं।

[caniel]

अगर 1 + 1 = 1.1 ही हो, तब भी कोई कितना ही अधिक उत्पादक व्यक्ति क्यों न हो, वह 1,000 अक्षम लोगों से बड़ा आउटपुट नहीं बना सकता।
सॉफ्टवेयर डेवलपमेंट में हस्तशिल्प जैसी कारीगरी का पहलू भी है, लेकिन फैक्ट्री में बनने वाले उत्पाद जैसा पहलू भी होता है।

[zxcv123]

चतुर लोगों का एक छोटा-सा समूह चीज़ों को अच्छी तरह व्यवस्थित कर देता है ताकि बेवकूफ़ लोग भी समझ सकें और ठीक से काम कर सकें। वे बेवकूफ़ लोग फिर यह गलतफ़हमी पाल लेते हैं कि वे खुद collaboration कर रहे हैं, हाहा

[m00nlygreat]

यह सच है कि सहयोग ज़्यादातर असफल होता है, लेकिन जीवन के जन्म सहित हर महान काम सहयोग से ही आया है।

[linusjeh]

सचमुच का टॉप-टियर जीनियस न हो, तो कोई कितना भी अच्छा हो, अकेले काम नहीं कर सकता। बाकी 80% लोग भले सिर्फ cheerleader की भूमिका ही निभाएँ, फिर भी बगल में बैठकर हौसला बढ़ा दें तो भी आधा हिस्सा तो पड़ ही जाता है, और aces 2~3 लोगों का काम करते हुए कंपनी चलती है। अकेले काम करो तो मान्यता मिलने का एहसास भी नहीं होता, और इंसान अकेलेपन से टिक नहीं पाता।

[mhj5730]

काफ़ी हद तक सहमत हूँ।

खासकर जब असल output से ज़्यादा collaboration tools में होने वाली visibility और transparency के लिए की जाने वाली activities ही बेवजह लंबी खिंचती रहती हैं...
अपनी ज़िम्मेदारी हल्की करने के लिए यह-वह सब notes छोड़ते रहने वाले planners को देखता हूँ, तो developer होने के नाते बस अस्तित्वगत झटका ही लगता है।

[qodot]

लगता है जैसे कोई हाई स्कूल का छात्र पहली बार बड़ों की दिखावटी औपचारिकताओं को पहचानकर उन पर गुस्सा करना शुरू कर रहा हो। किसी वजह से लगता है कि लेखक को The Catcher in the Rye का Holden Caulfield पसंद होगा...

[sinbumu]

प्रोजेक्ट के आकार के हिसाब से कभी-कभी ऐसा हो सकता है कि एक व्यक्ति का पहल करके लीड करना पूरी टीम के योगदान से भी ज़्यादा अहम हो.... लेकिन आकार के मुताबिक यह बात हमेशा सही नहीं होगी

[princox]

• क्या लोगों की संख्या जितनी बढ़ती है, काम उतना ही अक्षम हो जाता है? O
• लेकिन क्या इसका मतलब है कि सब कुछ अकेले किया जा सकता है? X
• क्या सही छोटे आकार की टीम को सुचारु communication के साथ product बनाना चाहिए? O

शायद बात यही है..

[roxie]

अच्छा है

[vk8520]

यह 2 pizza rule है।

[carnoxen]

सहयोग बेकार है

लगता है मैंने यही शीर्षक पहले भी कहीं देखा है...

[nottiger]

मुझे लगता है कि पहली ही पंक्ति में दिए गए स्रोत का सत्यापन नहीं हुआ है।

[kimjoin2]

जितना संगठन बड़ा होता है, उतना ही लगता है कि इस वक्ता की बात सही है
और जितना संगठन छोटा होता है, उतना ही लगता है कि इस वक्ता की बताई दिशा पहले से ही लागू है lol

[koreacglee]

मुझे लगता है कि AI tools के वास्तविक हो चुके इस समय में, यह ऐसा काफ़ी व्यावहारिक और समझदारी भरा लेख है जो किसी व्यक्ति की man power को अधिकतम करने पर केंद्रित है.
आगे चलकर हर चीज़ में लगातार हल्कापन और तेज़ गति की मांग बढ़ेगी, इसलिए अब तक चले आ रहे सहयोग के पुराने विचार रीसेट हो जाएंगे। लेकिन enterprise-grade solution development के लिए सहयोग अनिवार्य है.