- James C. Scott की “Seeing Like A State(राज्य की तरह देखना)” का मुख्य विचार यह है कि संगठन सिस्टम की “legibility” बढ़ाकर हर चीज़ को मापने और रिपोर्ट करने योग्य बनाना चाहते हैं
- लेकिन वास्तविकता में, ट्रैक या predict न किए जा सकने वाले “illegible work” अनिवार्य होते हैं, और केवल legibility पर ज़ोर देने से उल्टा efficiency घट सकती है
- खासकर बड़ी कंपनियां quarterly planning, OKR, Jira जैसे processes के जरिए काम को legible बनाती हैं, लेकिन विडंबना यह है कि इससे efficiency कम हो सकती है, और छोटी कंपनियां बड़ी कंपनियों से 20 गुना अधिक efficient हो सकती हैं
- संगठन आपात स्थितियों से निपटने के लिए "tiger team" जैसे अस्थायी illegible क्षेत्रों को अनुमति देते हैं, और engineers के बीच backchannel के जरिए होने वाला अनौपचारिक collaboration आधिकारिक process जितना ही महत्वपूर्ण भूमिका निभाता है
- तकनीकी कंपनियों की सफलता legible processes और illegible execution के बीच संतुलन बनाए रखने पर निर्भर करती है; इनमें से किसी एक के सहारे संगठन ठीक से काम नहीं कर सकता
प्रस्तावना: “Seeing Like A State” का मुख्य विचार
- James C. Scott की किताब “Seeing Like A State(राज्य की तरह देखना)” का सार नीचे दिए गए तीन बिंदुओं में समेटा जा सकता है
- आधुनिक संगठन सिस्टम को “legibility” अधिकतम करने वाले रूप में बदलते हैं, ताकि हर हिस्सा measurable और reportable रहे
- लेकिन ये संगठन एक विशाल “illegible” कामकाज पर निर्भर रहते हैं। यानी बहुत सा ऐसा काम मौजूद होता है जिसे ट्रैक या plan नहीं किया जा सकता, फिर भी वह अनिवार्य होता है
- legibility बढ़ाने से अक्सर efficiency कम होती है, लेकिन इसके अलावा मिलने वाले फायदे—जैसे control, planning, transparency—को बड़ा लाभ माना जाता है
- legibility का मतलब है ऐसा काम जो predictable हो, जिसका output trace किया जा सके, और जो किसी खास व्यक्ति पर निर्भर न हो। उदाहरण: schedule management, OKR, Jira आदि
- illegibility का मतलब है ऐसा काम जो improvisation या tacit knowledge पर आधारित हो, यानी ऐसा collaboration या अचानक बदलाव, जिसे लिखित या formal रूप नहीं दिया जा सकता, या ऐसा काम जो मानवीय संबंधों पर निर्भर हो
“Seeing like a state” का उदाहरण
- Scott 19वीं सदी के जर्मनी के “well-ordered forest” का उदाहरण देकर समझाते हैं कि संगठन efficiency के लिए control और standardization की कोशिश कैसे करते हैं
- जंगल के हर पेड़ को एक नज़र में समझ आने लायक तरीके से manage करने पर यह उम्मीद थी कि planning, trade, और resource allocation ज्यादा efficient हो जाएंगे
- लेकिन वास्तव में जंगल की diversity और निचली वनस्पतियों की भूमिका को नज़रअंदाज़ कर दिया गया, जिससे productivity घटी और बीमारी व parasites के प्रति संवेदनशीलता बढ़ गई
- यानी efficiency और transparency दोनों पाने की कोशिश की गई, लेकिन legibility का अतिरेक उल्टा efficiency को नुकसान पहुंचाने लगा
software कंपनियों में legibility और illegibility
- software कंपनियों में भी यही बात लागू होती है; छोटी teams या individual contributors ज्यादा efficient हो सकते हैं
- एक अकेला engineer कभी-कभी team के हिस्से के रूप में काम करने की तुलना में ज्यादा efficient हो सकता है—यह software engineers के बीच लगभग सामान्य समझ है
- engineer-driven काम ऊपर से assign किए गए काम की तुलना में बहुत तेजी से आगे बढ़ता है, क्योंकि उसे किसी अर्थपूर्ण रूप में translate करने या हर दिशा में सक्रिय communication करने की जरूरत नहीं होती
- छोटी software कंपनी बड़ी कंपनी से software delivery में इसलिए बहुत बेहतर हो सकती है, क्योंकि अगर बड़ी कंपनी 10 गुना ज्यादा engineers लगाए और फिर भी छोटी कंपनी 20 गुना ज्यादा efficient हो, तो बड़ी कंपनी मुश्किल में पड़ जाती है
- बड़ी कंपनियों में engineers के काम को “legible” बनाने के लिए अलग-अलग procedures और tools लाए जाते हैं
- इससे planning, measurement, और reporting में सुविधा होती है, लेकिन वास्तविक software productivity घट सकती है
- छोटी कंपनियां तुरंत समस्या का जवाब दे सकती हैं या बदलावों को जल्दी अपना सकती हैं—यह उनकी illegible क्षमता है
- बड़ी कंपनियां यह efficiency छोड़कर जटिल प्रक्रियाएं क्यों बनाए रखती हैं, इसका कारण बड़े enterprise contracts हैं। बड़े ग्राहक vendors से predictability और reliability की मांग करते हैं
- ऐसे ग्राहकों के साथ काम करने के लिए long-term planning, feature commitments, progress documentation जैसी legibility अनिवार्य होती है
- process इसलिए टिके रहते हैं क्योंकि legibility जो value देती है (डॉलर में) वह software को ज्यादा efficiently बनाने की क्षमता से भी बड़ी होती है
बड़ी कंपनियों के लिए legibility का वास्तविक मूल्य
- बड़े software organizations में legibility का मतलब है
- individual engineer तक इस समय चल रहे सभी projects को समझ सकता है
- पिछली quarter में पूरे हुए projects की सूची तुरंत निकाली जा सकती है
- कम से कम एक quarter पहले से (या उससे भी ज्यादा) काम की planning की जा सकती है
- emergency में department के पूरे resources को mobilize करके तुरंत काम में लगाया जा सकता है
- छोटी software कंपनियां तुरंत लचीले ढंग से प्रतिक्रिया देने की क्षमता के अलावा इन अपेक्षाओं को शायद ही पूरा कर पाती हैं
- बड़ी कंपनियां record-keeping, classification, और long-term planning में मजबूत होती हैं, लेकिन तेज प्रतिक्रिया क्षमता—यानी तुरंत organizational resources झोंक देने की शक्ति—उल्टा कमजोर पड़ सकती है
- यह legibility खास तौर पर enterprise customers के साथ trust, contracts, और long-term collaboration में केंद्रीय भूमिका निभाती है
legibility हासिल करने के लिए की गई धारणाएं और उनकी सीमाएं
- legibility को आगे बढ़ाते समय बड़ी कंपनियां अक्सर कुछ सरल धारणाएं बना लेती हैं
- एक ही level के सभी engineers लगभग समान प्रदर्शन करते हैं
- engineers को reassign या reorganize करने पर productivity loss नहीं होता
- अगर team में engineers की संख्या समान रहे तो समय के साथ productivity भी समान बनी रहती है
- projects का पहले से estimation किया जा सकता है और उसके error margins होते हैं
- लेकिन असलियत में
- एक ही level के लोगों में भी skill gap बड़ा होता है, और expertise व interest के आधार पर project productivity में बड़ा फर्क पड़ता है
- team size और productivity के बीच केवल कमजोर संबंध होता है
- project estimation लगभग एक भ्रम जैसा होता है, और कई बार estimation schedule से मेल बिठाने के लिए काम करने का तरीका ही बदल दिया जाता है
- फिर भी, ये धारणाएं कंपनी के भीतर communication, बाहरी बड़ी कंपनियों के साथ agreements, और business planning में उपयोगी रहती हैं
अस्थायी रूप से अनुमति दिए गए illegibility के क्षेत्र
- बड़ी कंपनियों में legibility बनाने वाली processes गंभीर delays पैदा करती हैं
- product idea → product organization का planning phase → engineering organization की technical review → VP और senior managers के बीच team allocation negotiation → team planning backlog में entry → team ticket backlog → sprint में entry → वास्तविक काम की शुरुआत
- यह संरचना ऐसे काम के बिल्कुल अनुकूल नहीं है जिसे तुरंत करना जरूरी हो
- इस समस्या को हल करने के लिए "virtual team", "strike team", "tiger team" जैसे अस्थायी illegible क्षेत्रों को अनुमति दी जाती है
- ये संगठन द्वारा भरोसा किए गए चुने हुए engineers से बनाए जाते हैं
- अक्सर इनमें कोई manager assign नहीं होता और कोई बहुत senior engineer project चलाता है
- इन्हें एक ढीला-ढाला mission दिया जाता है और goal हासिल करने के लिए मूलतः कुछ भी करने की छूट होती है
- यह पूर्ण illegibility और पूर्ण legibility के बीच एक समझदार समझौता है
- यह आधिकारिक process को bypass करता है, लेकिन स्थायी रूप से नहीं चलता और केवल अस्थायी रूप में बना रहता है
- अनुमति प्राप्त illegibility भी बाकी संगठन के साथ असहज रूप से सह-अस्तित्व रखती है, और दूसरे engineers process के बोझ के बिना काम करने की इस आजादी को देखकर ईर्ष्या कर सकते हैं या इसे जोखिमभरा मान सकते हैं
स्थायी और बिना अनुमति वाले illegibility के क्षेत्र
- Team A का engineer अगर Team B से काम करवाना चाहता है, तो आधिकारिक तरीका यह है कि "planning" backlog में issue बनाया जाए, 12-step process से गुज़रा जाए, और sprint में आने तक इंतज़ार किया जाए—जिसमें कई हफ्तों से लेकर कई महीने लग सकते हैं
- आधिकारिक समाधान यह है कि Team A को planning process के दौरान Team B के काम का पहले से अनुमान लगाना चाहिए, लेकिन code लिखे जाने से कई महीने पहले हर बदलाव की भविष्यवाणी करना बेतुका है
- असली समाधान है illegible backchannel
- Team A का engineer, Team B के engineer से पूछता है: "क्या आप यह one-line change कर सकते हैं?"
- Team B का engineer उसे तुरंत कर देता है, और ticket बनाना वैकल्पिक रहता है
- यह engineers के बीच व्यक्तिगत संबंधों पर निर्भर करता है, इसलिए यह illegible है
- backchannel कंपनी के हर स्तर पर लगातार मौजूद रहता है
- engineers के बीच cross-team backchannel, team के भीतर backchannel, managers के बीच, product managers के बीच
- जब आधिकारिक जगह पर कोई सवाल उठाया जाता है, तो अक्सर जवाब देने वाले के साथ वह पहले ही निजी तौर पर rehearse और review किया जा चुका होता है
- backchannel गलत भी जा सकता है, और कभी-कभी इसका इस्तेमाल किसी भोले engineer की कीमत पर खुद को फायदा पहुंचाने के लिए किया जाता है
sociopaths, clueless लोग, और losers
- Venkatesh Rao का "Gervais principle" संगठनों को तीन समूहों में बांटता है
- सबसे ऊपर के "sociopaths" संगठन के नियमों का अपनी भलाई के लिए निंदक ढंग से उपयोग करते हैं
- मध्य प्रबंधन के "clueless" लोग संगठन के आधिकारिक नियमों पर विश्वास करते हैं और यह नहीं समझ पाते कि उसके ऊपर कोई गहरा खेल भी चल रहा है
- उनके नीचे के "losers" समझते हैं कि खेल चल रहा है, लेकिन उसमें हिस्सा नहीं लेना चाहते
- इन श्रेणियों को legibility के नज़रिये से भी पढ़ा जा सकता है
- sociopaths और losers, दोनों संगठन की illegible दुनिया में शामिल रहते हैं
- "clueless" लोग केवल legible processes से ही जुड़े रहते हैं, और जब वे promotion चाहते हैं तो आधिकारिक job ladder देखते हैं और योजना बनाते हैं कि अगले level की हर value को कैसे प्रदर्शित करें
- उन्हें "clueless" कहना कुछ ज्यादा ही cynical है
- legible processes अब भी बहुत महत्वपूर्ण हैं और संगठन जो करता है उसका बड़ा हिस्सा वही हैं
- आधिकारिक process को बेहतर बनाना अब भी बहुत high-leverage काम है
- लोगों को इन श्रेणियों में सोचने से यह समझने में मदद मिलती है कि software कंपनियों में बार-बार दिखाई देने वाले conflict zones अक्सर इन समूहों के बीच घर्षण से पैदा होते हैं
अंतिम विचार
- संगठन के भीतर मौजूद illegible दुनिया को पहचानना और उसका उपयोग करना महत्वपूर्ण है
- मैंने tech कंपनियों में illegibility को पहचानने और इस्तेमाल करने पर बहुत लिखा है
- illegible processes पर सलाह देना "dangerous advice" के दायरे में आता है
- अगर आप सार्वजनिक रूप से यह घोषित करें कि आप आधिकारिक process की बजाय backchannel के जरिए काम पूरा करते हैं, तो संगठन आपको दंडित करेगा
- भले ही management chain वास्तव में यही चाहती हो, तब भी दंड मिलेगा
- मुझे अक्सर ऐसा नकारात्मक feedback मिलता है कि आधिकारिक process को कभी bypass नहीं करना चाहिए, लेकिन लेखक इस दृष्टिकोण को भोला मानते हैं
- हर संगठन में legible और illegible, दोनों पक्ष होते हैं
- legible पक्ष एक निश्चित scale के बाद महत्वपूर्ण हो जाता है और long-term planning, दूसरी बड़ी organizations के साथ coordination आदि को संभव बनाता है
- illegible पक्ष भी उतना ही महत्वपूर्ण है; यह high-efficiency work को संभव बनाता है, मौजूदा स्थिति से मेल न खाने वाले process के लिए safety valve देता है, और gossip तथा सहज सहमति की मानवीय आवश्यकता को पूरा करता है
1 टिप्पणियां
Hacker News राय
मैं ज़्यादातर बातों से सहमत हूँ, लेकिन इस धारणा पर आपत्ति है कि leadership अपने-आप मान ले कि 'legibility' हर कीमत चुकाने लायक है। अगर CEO को हर बारीक काम (जैसे unit test parallelization) तक देखना पड़े, तो यह वैसा होगा जैसे दिमाग़ उंगली हिलाने भर पर भी सचेत रहे — फिर कुछ हो ही नहीं पाएगा। वास्तविकता में CEO, यानी कंपनी का प्रमुख, पूरी व्यवस्था का शायद सिर्फ़ 7% ही नियंत्रित कर सकता है। बाक़ी हिस्सा हर कर्मचारी भरता है; वह सिर्फ़ दिमाग़ की भूमिका में है, पूरा शरीर नहीं। लेकिन leaders अक्सर यह भ्रम पाल लेते हैं कि वही सबसे महत्वपूर्ण हैं, और जिन क्षेत्रों के लिए उनके पास समय कम हो या expertise न हो (जैसे MIT से निकले बेहतरीन engineer और bootcamp से निकले औसत engineer के बीच का फ़र्क), उन्हें वे सतही तौर पर निपटा देते हैं। Google की सफलता की बात करते समय भी, दर्जनों शानदार practitioners की तुलना में दो founders या CEO को ही ज़्यादा श्रेय देने की प्रवृत्ति रहती है
यहाँ कुछ बातें सही हैं, लेकिन क्या यह कुछ ज़्यादा ही extreme नहीं है? मैं लगभग 5000 लोगों की कंपनी में काम करता हूँ (छोटी नहीं, लेकिन Amazon जितनी भी नहीं)। ज़्यादातर rules के पीछे काफ़ी अच्छे कारण होते हैं। उदाहरण के लिए, दो code reviewers की ज़रूरत गलती रोकने के लिए है। Review rejection बहुत ज़्यादा नहीं होते, लेकिन अगर बिना review deploy करें तो incidents ज़्यादा होंगे। ऐसे rules कम-से-कम मजबूर करके checklist पूरी करवाते हैं। हाँ, कभी ऐसा समय आ सकता है जब rule तोड़ना पड़े (जैसे टीम के ज़्यादातर लोग incident में फँसकर तुरंत हट गए हों)। तब rule की मंशा के अनुरूप exception देना उचित है। लेकिन अगर कोई जगह सिर्फ़ समझ से बाहर bureaucratic rules से भरी हो (जहाँ कोई अपना process थोपकर बस "तुम्हारा तरीका ग़लत है" कहता रहे), तो वहाँ से निकल जाना चाहिए। जहाँ process या किसी व्यक्ति का ego, असली progress और outcomes से ज़्यादा अहम हो, वहाँ job change ही जवाब है
TDD के बाद से "अगर test नहीं कर सकते, तो implementation भी पूरा नहीं हुआ" वाली सोच का आकर्षण बढ़ गया है। इसे समझाने के लिए 'legibility' शब्द काफ़ी सटीक है। Tritium में हमने सैकड़ों unit tests रखे, लेकिन असल में blog बनाते समय ही वे qualitative bugs सामने आए जिन्हें unit tests पकड़ नहीं पाए (और जिन्हें test से verify करना भी कठिन है)। देखें https://tritium.legal/blog/eat. शायद यही वजह है कि indie game development बाज़ार की ताकतों के सामने बेहतर टिकता है। Game developers अपना product खुद इस्तेमाल करते हैं (Food-dogging) और इस तरह qualitative improvements करते हैं। उन्हें बड़े enterprise software जैसी अत्यधिक surface-level legibility की ज़रूरत नहीं होती। असली बात यह है कि qualitative और quantitative, दोनों तरह के metrics चाहिए
Tests, खासकर unit tests, 'streetlight effect' के प्रति संवेदनशील होते हैं। जितना तुच्छ या कम महत्वपूर्ण हिस्सा होगा, उसे test करना उतना आसान होगा, और इसीलिए अक्सर आसान चीज़ें ही test होती हैं। अगर कोई organization सिर्फ़ line coverage जैसे आसानी से मापे जाने वाले metrics पर अटक जाए, तो वास्तव में सार्थक (और कठिन) validation छूट सकता है। अनुभवी engineer की review जैसी qualitative evaluation भी महत्वपूर्ण है
Game development में feedback loop दूसरे software domains की तुलना में बहुत छोटा होता है। उदाहरण के लिए, memory leak हो तो हर सेकंड सैकड़ों बार समस्या सामने आ जाती है। Slow code तुरंत visual stutter के रूप में महसूस होता है, इसलिए cache coherence, GC के उपयोग जैसे performance पहलुओं पर भी ध्यान देना पड़ता है
मुझे TDD पसंद है, लेकिन अंततः manual testing भी ज़रूरी है। अगर आप खुद test नहीं करते, तो अनपेक्षित समस्याएँ अक्सर निकलती हैं। ख़ासकर usability जैसी चीज़ें असल इस्तेमाल में ही अच्छी तरह सामने आती हैं
मैं Sean की लिखी चीज़ें पसंद करता हूँ, और यह लेख भी product क्षेत्र में काफ़ी relatable लगा। उदाहरण के लिए, लगभग एक साल पहले कई product लोग और engineers ऐसा कुछ बनाना चाहते थे जो दूसरी teams के भी काम आए। उसे औपचारिक चैनल (legible channel) से approval दिलाना उस समय की संरचना में व्यावहारिक नहीं था, इसलिए भरोसे और सम्मान के आधार पर अनौपचारिक (illegible channel) रूप में आगे बढ़ाया गया। यह grassroots तरीके से चला, और उल्टा जल्दी ही कंपनी के भीतर word of mouth से traction भी मिल गया। अब स्थिति यह है कि management इस case को अपनी success story की तरह पेश कर रही है, लेकिन दूसरी तरफ़ जैसे ही सब कुछ formal process (legible channel) और बाद में justification जुटाने में डाला गया, प्रक्रिया काफ़ी painful हो गई। फिर भी failure का जोखिम बहुत कम हो चुका था, इसलिए यह कुछ आसान भी था। पिछले कुछ सालों में यह मेरे लिए सबसे rewarding और मज़ेदार projects में से एक रहा
जितना लंबे समय तक corporate life और office politics में रहते हैं, उतना यह geopolitics या diplomacy जैसा लगने लगता है। और आगे बढ़ें तो social relationships, romantic relationships तक में भी समानताएँ दिखती हैं। शायद यह मेरी abstract models बनाने वाली mathematical प्रवृत्ति के कारण है
राजनीति मेरा सबसे पसंदीदा विषय है। मैं किताबें, magazines और तरह-तरह की सामग्री पढ़ना पसंद करता हूँ, और सच कहूँ तो office politics से भी मुझे ख़ास परेशानी नहीं होती। मूल बात यह है कि इंसान, इंसान की तरह ही व्यवहार करते हैं। हर व्यक्ति (और organization भी) कुछ चाहता है और कुछ से डरता है; इन्हें संतुलित करना ही एक तरह का मज़ा है। यह engineering problem solve करने जैसा ही है, बस requirements 'लोग' हैं। इस तरह की problems solve करना अपने-आप में दिलचस्प है
हाल ही में मुझे यह बात समझ आई। पहले मैं diplomacy को सैकड़ों diplomats द्वारा बने किसी complex system का परिणाम मानता था, लेकिन असल में यह कुछ शक्तिशाली लोगों के उलझे हुए मानवीय रिश्तों से ज़्यादा कुछ नहीं है। इसे daycare में होने वाली बातों की तरह भी समझा जा सकता है
यह सहज रूप से काफ़ी natural phenomenon है। Social relationships (जैसे romantic relationships) की तुलना में, बड़ी कंपनियों और governments के बीच समानता और भी स्पष्ट है। कंपनियाँ अक्सर कहीं ज़्यादा autocratic या feudal होती हैं। फ़र्क भी बहुत हैं, लेकिन जैसे-जैसे scale बढ़ता है, वे governments जैसी लगने लगती हैं। उन्नत bureaucracy भी उसी का हिस्सा है
Game theory wiki
आज के बहुत से politicians पहले सामान्य office jobs से आए हैं, तो यह phenomenon कोई अजीब बात भी नहीं लगती
मैं IT security में काम करता हूँ, और यहाँ यह स्थिति और भी ज़्यादा स्पष्ट दिखती है। जब हमें "ऐसी requests" लेनी पड़ती हैं जो हमारी team के सीधे metrics में मदद नहीं करतीं, तो सोचता हूँ कि unofficial तरीकों (back channel) के अलावा कोई दूसरा विकल्प है क्या। अगर किसी को पता हो तो बताइए
अच्छी पोस्ट है, लेकिन मैं एक ऐसी बात उठाना चाहता हूँ जिस पर अक्सर चर्चा नहीं होती। मूल लेख में software engineers (SWE) को पेड़ की पत्तियों, यानी assembly line worker जैसी भूमिका में दिखाया गया है, जो थोड़ा निराशाजनक है। लेकिन जैसा "Legible assumptions" हिस्से में भी आता है, engineers वास्तव में organization structure में 'code' के ज़रिए connections बढ़ाने वाला एक 'managerial role' भी निभाते हैं। फ़र्क बस इतना है कि उनका लागू होने वाला क्षेत्र अलग है; समस्याएँ काफ़ी मिलती-जुलती हैं
लेख में जो बात थी — "छोटी कंपनियों में यह क्षमता ज़रूरी नहीं लगती, लेकिन बड़ी software companies में यह क्यों अनिवार्य हो जाती है? यह मेरा क्षेत्र नहीं, लेकिन शायद enterprise projects की वजह से होगा" — क्या कोई इससे सहमत है? राय जानना चाहता हूँ
मेरा मानना है कि यह enterprise deals से ज़्यादा, अंदरूनी 'communication at scale' की समस्या है। m कर्मचारियों वाली organization को m*m communication matrix की तरह समझा जा सकता है। जब लोग कम होते हैं, तो लगभग हर cell 1 होता है (घनिष्ठ संवाद), लेकिन scale बढ़ने पर ज़्यादातर cells 0 (disconnect) या 0.5 (informal communication) बन जाते हैं। लेकिन information आख़िरकार कंपनी ही है। इसलिए managers और formal processes के ज़रिए information के 'flow' की ज़िम्मेदारी लेने वाली संरचना ज़रूरी हो जाती है। Planning, promotion, reviews — सब इसी legibility को सुरक्षित करने के लिए हैं
मैं एक छोटी कंपनी में बड़े enterprise projects संभालता हूँ, लेकिन deal बंद करने के लिए अंदर तक सख़्त legibility लागू करना ज़रूरी नहीं होता। ग्राहक के सामने project management की legibility चाहिए, पर वे हमारी internal development practices तक बारीकी से दख़ल नहीं देते। निष्कर्षतः बड़ी कंपनियाँ legibility की दीवानी इसलिए होती हैं क्योंकि वे पहले से बड़ी हैं, या बड़ी बनना चाहती हैं
मैं medical imaging क्षेत्र में काफ़ी समय रहा हूँ, और अधिकांश business owners को ठीक से समझ ही नहीं होता कि वे असल में IT services/solutions industry में हैं। सफलता का असली कारण IT service capability था। Diagnosis से ज़्यादा, non-radiology staff ने platform की usability और efficiency बढ़ाने में जो काम किया, वह कहीं अधिक महत्वपूर्ण था
कोई भी organization चाहे कितनी बड़ी हो, उसे बार-बार होने वाले internal और external audits के लिए हमेशा तैयार रहना पड़ता है। Auditors आमतौर पर जितना हो सके उतना process documentation देखना चाहते हैं। उदाहरण के लिए, इस case में, सबसे बुरे हाल में auditor ने अपने client को ही 'निकाल' दिया
वह हिस्सा (कि यह enterprise deals की वजह से है) मुझे भी कुछ अजीब लगता है। Startup background से आने वाला और अभी mid-sized company में middle manager होने के नाते, मेरा मानना है कि organization का आकार बढ़ने पर काम करने का तरीका बताने वाली न्यूनतम संरचना हमेशा चाहिए। चाहे आपको process कितना भी नापसंद हो, Dunbar’s Number पार करने के बाद empathy और informal communication से काम नहीं चलता। एक चरम अपवाद Steam है, लेकिन वहाँ भी सिर्फ़ खास तरह की प्रतिभा चुनी जाती है और internal politics बहुत तीखी है
'legibility' शब्द का चुनाव अपने-आप में दिलचस्प है। यह formal और informal processes की द्वैधता जैसा लगता है। जब कंपनी छोटी होती है, तो informal तरीके अच्छे से काम करते हैं, लेकिन एक threshold के बाद formal rules और processes लाने ही पड़ते हैं। लंबे समय में rules कठोर हो जाते हैं और बदलाव के साथ चल नहीं पाते। धीरे-धीरे उद्देश्य से ज़्यादा प्रक्रिया खुद महत्वपूर्ण बन जाती है। इस तरह routine से बाहर रहकर novelty बनाए रखना आसान नहीं है। कंपनियों में अक्सर कहा जाता है कि पैसा खून की तरह है, लेकिन असल में पैसा कम ही मौकों पर मूल प्रेरक होता है। पैसा ज़रूरी शर्त है, लेकिन अस्तित्व का अंतिम कारण नहीं
बात हमेशा balance की ही होती है। मैं 25 साल तक engineering manager रहा हूँ, और एक बहुत process-driven company में काम किया है। घुटन होती थी, लेकिन world-class hardware को लगातार deliver करने में इसके फ़ायदे भी थे (software के लिए नहीं)। Documentation वगैरह ज़रूरी है, लेकिन ज़्यादा कठोरता project को जड़ बना सकती है। Communication overhead सबसे गंभीर समस्या है। इसलिए जब कुछ सक्षम लोग लंबे समय तक साथ काम करते हैं, तो वे असाधारण productivity दे सकते हैं, और 'tribal knowledge' वास्तव में बहुत महत्वपूर्ण accelerator है। मैंने Concrete Galoshes नाम का लेख भी इन्हीं structural और rigidity वाले पहलुओं पर लिखा था। सबसे बड़ा सबक यही है: "हर project पर एक ही तरह का ढाँचा नहीं थोपना चाहिए।" हर project को अलग structure और अलग overhead चाहिए