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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.