100 लोगों के बाद Flat संरचनाएँ: hierarchy पहले से मौजूद है, बस लिखी नहीं गई

सौ लोगों से आगे की flat संरचनाएँ शायद ही flat होती हैं। आमतौर पर उनके पास एक ऐसी hierarchy होती है जिसे न किसी ने design किया और न कोई देख पाता है: वे कुछ लोग जिनसे हर कोई कुछ करने से पहले पूछता है, जिनकी मंज़ूरी किसी ने लिखी नहीं और जिनके job description में इसका कोई ज़िक्र नहीं। इसलिए बढ़ती कंपनी के लिए ईमानदार सवाल यह नहीं है कि hierarchy हो या नहीं, बल्कि यह कि उसे लिखा जाए या नहीं। लिखित hierarchy पर सवाल उठाया जा सकता है, उसका भुगतान किया जा सकता है और उसे बदला जा सकता है, जबकि अलिखित hierarchy बस जमा होती जाती है।

Flat संरचना का सवाल हमें सबसे ज़्यादा उन कंपनियों में मिलता है जिन्होंने शुरुआत में कुछ सही किया। तीस लोगों पर managers न होने का मतलब था गति, सीधापन और एक founder जो हर किसी का काम जानता था। एक सौ बीस पर वही design भीतर से अलग महसूस होता है, और leadership आमतौर पर इसे सबसे आख़िर में महसूस करती है, क्योंकि founders ही वह एक समूह हैं जिनकी पहुँच नहीं बदली।

“हर कोई product को report करता है”

रियाद की एक fintech कंपनी के founders ने हमें बताया कि सौ लोगों से आगे बढ़ते हुए उन्होंने जान-बूझकर management की परत से परहेज़ किया। उनका वाक्य था कि हर कोई product को report करता है। Teams समस्याओं के इर्द-गिर्द बनती थीं, समस्याएँ हल होने पर बिखर जाती थीं, और दोनों founders साल में दो बार पूरी कंपनी की performance बातचीत करते थे।

ज़मीन से तस्वीर अलग थी। फ़ैसले मुट्ठी भर messaging groups में होते थे जिनमें नए लोग नहीं थे। दो senior engineers ऐसे लोग बन गए थे जिनसे हर कोई कुछ भी merge करने या शुरू करने से पहले पूछता था, इसलिए वे दिन दूसरों की रुकावटें हटाने में और शामें अपना काम करने में बिताते थे। उस भूमिका के लिए उनके पास न कोई title था, न वेतन, न ना कहने का अधिकार। एक ही तिमाही के भीतर दोनों ने इस्तीफ़ा दे दिया, और कंपनी को पता चला कि उसका कितना समन्वय दो लोगों से होकर चल रहा था।

बाद में एक founder ने इसे साफ़ शब्दों में कहा: “हमें लगा था हमने hierarchy हटा दी है। हमने बस उसका भुगतान करना बंद कर दिया था।”

Four Jobs Test

Flat संरचनाओं पर बहस गोल-गोल घूमती है क्योंकि वह hierarchy को एक ही चीज़ मानती है। असल में यह चार काम हैं जिन्हें management की परत संयोग से एक साथ बाँध देती है। कोई कंपनी सौ लोगों के बाद तभी flat रह सकती है जब चारों में से हर काम किसी न किसी चीज़ से हो रहा हो, और जो काम नहीं हो रहे, उनके लिए उसे managers जोड़ने चाहिए।

ऊपर वाली fintech ने चार में से एक हल किया था। Teams समस्याओं के इर्द-गिर्द बनती थीं, जो एक तरह का समन्वय तंत्र है। फ़ैसला करना वापस founders पर आ गया था, लोगों की देखभाल साल में दो बार दो लोगों से एक सौ बीस के लिए होती थी, और जो समन्वय होता था वह दो बिना वेतन, बिना title वाले engineers से होकर चलता था। यह एक बहुत खड़ी अनौपचारिक hierarchy के ऊपर रखा एक flat chart है।

और यह रही उलटी बात

इस विषय पर ज़्यादातर लेखन flat को hierarchical के सामने रखता है। जो अंतर मायने रखता है वह है लिखित बनाम अलिखित। लगभग सौ लोगों से आगे की हर कंपनी में hierarchy होती है, यानी कुछ फ़ैसलों पर कुछ लोगों की राय दूसरों से ज़्यादा वज़न रखती है। एकमात्र चुनाव यह है कि वह वज़न दिखाई दे, सोच-समझकर हो, और उसके साथ उसे अच्छी तरह इस्तेमाल करने का समय और अधिकार हो। Jo Freeman ने 1970 के दशक की शुरुआत में activist groups के बारे में The Tyranny of Structurelessness में यही बात कही थी: जो समूह औपचारिक संरचना से इनकार करता है वह सत्ता ख़त्म नहीं करता, वह सत्ता अनौपचारिक network को सौंप देता है, जहाँ उसे चुनौती नहीं दी जा सकती।

दूसरी बात founders को चौंकाती है। पहले managers नियंत्रण के लिए नहीं, लोगों की देखभाल के लिए जोड़िए। Founders तब managers लाते हैं जब मंज़ूरियाँ bottleneck बन जाती हैं, और इसलिए पहले managers मंज़ूरी देने वालों के रूप में आते हैं, जो ठीक वही नौकरशाही है जिससे कंपनी बचना चाह रही थी। जो काम आमतौर पर सबसे पहले टूटता है वह लोगों की देखभाल है, क्योंकि वह सबसे बुरी तरह scale होता है: दो founders एक सौ बीस लोगों के लिए आश्चर्यजनक रूप से लंबे समय तक फ़ैसले ले सकते हैं, पर वे एक सौ बीस लोगों की महत्वाकांक्षाएँ नहीं जान सकते। Management की परत वहीं से शुरू कीजिए, spans चौड़े रखिए, और decision rights बाद में और सोच-समझकर सौंपिए।

यह क्यों काम करता है

प्रमाण की कई धाराएँ एक ही दिशा में इशारा करती हैं। मानवविज्ञानी Robin Dunbar का काम बताता है कि स्थिर, भरोसे पर टिके रिश्ते लगभग डेढ़ सौ लोगों पर अपनी सीमा पर पहुँचते हैं, जो मोटे तौर पर वहीं है जहाँ अनौपचारिक समन्वय बिना सहारे के काम करना बंद कर देता है। W. L. Gore, जो पारंपरिक बॉस के बिना अपने lattice organization के लिए प्रसिद्ध है, लंबे समय से अपनी अलग-अलग sites को छोटा रखती आई है, उस आकार के आसपास जहाँ लोग अब भी एक-दूसरे को जान सकें, जो इसी सीमा का संरचनात्मक जवाब है, उसका अपवाद नहीं।

Managers को ग़ैर-ज़रूरी साबित करने की कोशिशें भी शिक्षाप्रद हैं। Google का Project Oxygen, कंपनी के अपने बयान के अनुसार, यह दिखाने के प्रयास के रूप में शुरू हुआ था कि engineering संस्कृति में managers मायने नहीं रखते, और इस निष्कर्ष पर ख़त्म हुआ कि अच्छे managers team के performance और retention में मापने योग्य अंतर लाते हैं। फिर काम इस पहचान की ओर मुड़ा कि वे managers क्या करते थे, और उसमें से ज़्यादातर नियंत्रण के बजाय लोगों की देखभाल और समन्वय था। Holacracy जैसे प्रयोग, जैसे 2010 के दशक के मध्य में Zappos का, दूसरा पक्ष दिखाते हैं: managers की जगह स्पष्ट भूमिकाएँ और नियम रखना काम कर सकता है, पर सिर्फ़ इसलिए कि यह किसी पारंपरिक कंपनी से कहीं ज़्यादा संरचना लिख डालता है, जो संरचनाहीनता का ठीक उलटा है।

हमारे अपने काम में ढर्रा एक-सा है। जो कंपनियाँ सौ लोगों के बाद भी प्रभावी रूप से flat रहती हैं, उनके पास असामान्य रूप से स्पष्ट decision rights और असामान्य रूप से अनुशासित समन्वय रिवाज़ होते हैं, जैसे जिनकी चर्चा हम daily huddle वाले लेख में करते हैं। जो कंपनियाँ संघर्ष करती हैं उनके पास वही flat chart होता है और यह ढाँचा बिल्कुल नहीं, और यही कारण है कि org chart और organizational structure एक ही कंपनी के बारे में बिल्कुल अलग कहानियाँ सुना सकते हैं।

एक व्यावहारिक checklist

• पहले अनौपचारिक hierarchy का नक़्शा बनाइए। दस लोगों से पूछिए कि किसी अहम फ़ैसले से पहले वे किससे पूछते हैं। जो नाम बार-बार आते हैं, वही आपकी मौजूदा management परत है।
• Four Jobs Test चलाइए। फ़ैसला करना, समन्वय करना, लोगों की देखभाल और जवाबदेही, हर एक के लिए उस तंत्र का नाम लिखिए जो आज यह करता है, या लिखिए “कोई नहीं”।
• जो लोग पहले से यह काम कर रहे हैं, उन्हें पहचान दीजिए। अगर कोई समन्वय या लोगों की देखभाल का बोझ उठा रहा है, तो उसे title, समय और वेतन दीजिए, या बोझ हटा लीजिए।
• पहले managers को लोगों की देखभाल से शुरू कराइए, चौड़े spans के साथ, मंज़ूरी का अधिकार देने से पहले।
• क्षेत्र के हिसाब से decision rights लिखिए, सीमाओं के साथ, ताकि managers जोड़ने का मतलब मंज़ूरी के क़दम जोड़ना न हो।
• नए लोगों पर नज़र रखिए। किसी नए व्यक्ति को यह समझने में कितना समय लगता है कि किससे पूछे, यह छिपी hierarchy के सबसे अच्छे संकेतों में से एक है।

ख़ुद से पूछिए

• वे तीन लोग कौन हैं जिनसे हर कोई कुछ करने से पहले पूछता है, और क्या उनके role description में यह लिखा है?
• हमारी कंपनी में हर व्यक्ति ने आख़िरी बार अपने विकास पर सार्थक बातचीत कब की थी?
• कौन से फ़ैसले अब भी founders तक सिर्फ़ इसलिए पहुँचते हैं कि किसी और के पास उन्हें लेने का लिखित अधिकार नहीं है?
• अगर हमारे दो सबसे ज़्यादा पूछे जाने वाले लोग इस तिमाही इस्तीफ़ा दे दें, तो कौन सा समन्वय रुक जाएगा?
• क्या हम managers से इसलिए बच रहे हैं कि हम स्वायत्तता में यक़ीन करते हैं, या इसलिए कि हम यह तय नहीं करना चाहते कि वे कौन हों?

निष्कर्ष

सौ लोगों के बाद चुनाव flat और hierarchical के बीच नहीं, बल्कि उस hierarchy के बीच है जिसे आप लिखते हैं और उसके बीच जिसके न होने का आप दिखावा करते हैं। पता लगाइए कि management के चार कामों में से कौन से नहीं हो रहे, उनके लिए managers जोड़िए, मंज़ूरी के बजाय लोगों की देखभाल से शुरू करते हुए, और बाक़ी सब कुछ उतना flat रखिए जितना काम अनुमति दे। इसी तरह वे कंपनियाँ, जैसी हमने startup को scale करने की असली चुनौतियों में बताई, अपने सबसे अच्छे लोगों पर एक अदृश्य बोझ डाले बिना अपनी गति बनाए रखती हैं।