हाल ही में, मैं समान विषय साझा करने वाले दो विषयों पर चिंतन करता रहा। पहला विषय कैलिफ़ोर्निया की सार्वजनिक अवसंरचना की स्थिति से संबंधित है और पिछले कुछ वर्षों में यह कितना अक्षम हो गया है। दूसरी बड़ी टेक कंपनियों की स्टार्टअप इनकंबेंट्स की तुलना में अधिक तेजी से नया करने और निष्पादित करने में विफलता है। पहले आपको विचार करने के लिए दो उदाहरण देकर मैं कुछ दृष्टिकोण प्रदान करता हूं कि ये विषय क्यों संबंधित हैं:

• इन्फ्रास्ट्रक्चर : गोल्डन गेट ब्रिज को बनने में लगभग चार साल लगे (1933-1937) और इसकी कीमत आज के डॉलर में ~$500M है। इसके विपरीत, एसडीएस ( सुसाइड डिटरेंट सिस्टम ), जो मूल रूप से पुल के चारों ओर एक जाल जोड़ता है, को पूरा करने में हमें पांच साल लगेंगे (2017–2023) और हमें ~$217M खर्च करने का अनुमान है। यदि आप कैलिफ़ोर्निया में प्रमुख बुनियादी ढांचा परियोजनाओं की समीक्षा करते हैं, तो आप पाएंगे कि 1950 के दशक से पहले पूरी की गई परियोजनाओं के लिए काम तेजी से, सस्ता और उच्च गुणवत्ता के साथ किया गया था, जो कि आज कम से कम 5x परिमाण में किया जाता है, भले ही आज हमारे पास अधिक पूंजी, बेहतर तकनीक, बेहतर कच्चा माल, और सिविल इंजीनियरों और वास्तुकारों की उच्च निरपेक्ष संख्या है।
• टेक कंपनियाँ : Adobe, अपने सभी वित्तीय और मानव संसाधनों के बावजूद, खुद को $20B के लिए एक प्रतियोगी का अधिग्रहण करने के लिए पाता है। क्या फिग्मा के लिए एडोब ओवरपेड देखा जाना बाकी है, लेकिन अधिक दिलचस्प सवाल यह है कि 100x कर्मियों वाली कंपनी, डिजाइन टूलिंग में 100x गहराई का अनुभव, और 100x वित्तीय पूंजी जीतने में विफल क्यों रही?

इसी तरह, यदि आप कंपनियों के भीतर एक नज़र डालते हैं, तो आप पा सकते हैं कि जैसे-जैसे वे बढ़ते हैं, प्रक्रिया और किसी भी चीज़ में रेंगते हैं और वास्तविक काम और नवीनता को रोकते हैं। उस माहौल में, जो कर्मचारी चीजों को बनाने के लिए सबसे अधिक उत्सुक हैं, निर्माता, यह पाते हैं कि जहाज को एक छोटी सी जगह पर ले जाना अधिक आकर्षक है जहां उनके काम को अमल में लाने का एक आउटलेट है। इंफ्रास्ट्रक्चर विफलताओं और कंपनी नवाचार विफलताओं दोनों में कम से कम आंशिक रूप से ब्लोट और प्रोसेस रेंगने के कारण हैं।

प्रक्रिया रेंगना क्यों होता है?

हर प्रक्रिया अच्छे इरादों से शुरू होती है।

• "हम यह सुनिश्चित करना चाहते हैं कि सभी हितधारकों के पास अंतिम कार्य में एक इनपुट हो, इसलिए सभी सबमिट किए गए प्रोजेक्ट प्रस्तावों की कानूनी, डिज़ाइन, उत्पाद और इंजीनियरिंग टीमों द्वारा समीक्षा की जानी चाहिए।"
• "हम यह सुनिश्चित करना चाहते हैं कि बड़ी बुनियादी ढाँचे की परियोजनाएँ नुकसान न पहुँचाएँ, इसलिए हमें कोई भी काम शुरू करने से पहले पूरी तरह से पर्यावरण अध्ययन करने की आवश्यकता है।"
• "हम डेटा उल्लंघनों को कम करना चाहते हैं, इसलिए आईटी और सुरक्षा टीमों के माध्यम से डेटा के लिए कोई भी अनुरोध किया जाना चाहिए।"

पूर्णतावाद का मार्ग

मुझे याद है कि एक सुविचारित प्रबंधक ने अपनी सीधी रिपोर्ट को सॉफ्टवेयर लिखने के लिए कहा जैसे कि यह 100 साल तक चलेगा। हालाँकि यह टिप्पणी अतिशयोक्तिपूर्ण थी, सलाह कुछ ऐसी है जो मैंने टेक उद्योग में अक्सर "दो बार मापो और एक बार लिखो" या "यदि आपके पास इसे सही करने के लिए समय नहीं है, तो क्या आपके पास करने के लिए समय है" जैसे कहावतों के माध्यम से सुना है। यह दो बार? यह बुरी सलाह नहीं है। कुछ स्थितियों में, आपको कोड लिखना होगा जैसे कि यह 100 साल तक चलेगा, और योजना के बिना निष्पादन में सिर झुकाना बेकार है। बहरहाल, योजना पर अत्यधिक जोर देने से पक्षाघात हो सकता है और पुनरावृत्ति के माध्यम से सीखने के लाभों को पहचानने में विफलता हो सकती है। मैं ऐसी दुनिया में रहना पसंद करूंगा जहां सॉफ्टवेयर हर साल फिर से लिखा जाता है क्योंकि एक मजबूत मान्यता है कि पूर्णता मौजूद नहीं है और विकास के लिए पूर्व शर्त परिवर्तन है, ऐसी दुनिया के बजाय जहां चीजें " 50 साल पुराने कोडबेस " पर चलती हैं ।

बहुत ज्यादा गोंद

कई साल पहले मैंने तान्या रेली के ब्लॉग पोस्ट को ग्लू होने पर पढ़ा (अत्यधिक अनुशंसित पढ़ा, btw)। मेरे करियर के उस बिंदु पर, सामग्री वास्तव में प्रतिध्वनित हुई क्योंकि मैं कुछ सहयोगियों के साथ व्यवहार कर रहा था जो तकनीकी रूप से सक्षम होने के बावजूद सही चीजों पर काम नहीं कर रहे थे। ग्लू लोग तकनीकी नेतृत्व और सलाह की एक प्रक्रिया में संलग्न होते हैं जो टीम के अन्य लोगों को अधिक उत्पादक बनाने की ओर ले जाती है। कुछ मात्रा में गोंद आवश्यक है, फिर भी, मैंने पाया कि बहुत अधिक गोंद अन्य समस्याओं का एक सेट बनाता है:

• गोंद का काम करने वाले लोग दूसरे लोगों को अपने गैर-तकनीकी कौशल में सुधार करने से रोकते हैं। उदाहरण के लिए, एक टेक लीड जो अपनी टीम को अपने काम के बारे में बोलने नहीं देता है या अक्सर "बफर" के रूप में कार्य करता है, अनिवार्य रूप से आईसी से संघर्ष करने और अंततः अपने संचार कौशल में सुधार करने के अवसरों को दूर कर रहा है।
• गोंद व्यवहार के चरम और जहरीले संस्करण कभी-कभी अन्य लोगों के काम का श्रेय लेने या अत्यधिक अतिरंजित एट्रिब्यूशन उत्पन्न करने में प्रकट होते हैं ("उदाहरण के लिए, मेरे बिना मध्यस्थ के रूप में कार्य करना, परियोजना सफल नहीं होगी")। जबकि तान्या उन स्थितियों के बारे में बात करती हैं जहां ग्लू लोगों को अक्सर स्वीकार नहीं किया जाता है, मेरा अनुभव बिल्कुल विपरीत है। क्योंकि ग्लू लोग अच्छे संचारक होते हैं, वे जानते हैं कि अपने काम का विज्ञापन कैसे करना है और राजनीति को अच्छी तरह से कैसे खेलना है। बदले में, वे उच्च दृश्यता और अधिक पदोन्नति के अवसरों के साथ समाप्त होते हैं, जबकि कार्यान्वयन विवरण पर काम करने वाले इंजीनियर को अक्सर टोकन पावती या कोई क्रेडिट नहीं मिलता है।
• अंत में, बहुत अधिक गोंद वाले लोगों को जोड़ने से व्यक्तिगत इंजीनियरों के लिए स्वामित्व और जवाबदेही कम हो जाती है। एक तकनीकी रूप से सक्षम टीम का प्रबंधन करने के लिए गोंद लोगों को जोड़ने के बजाय, मैं केवल उन इंजीनियरों को जाने दूंगा जिनके पास कोई व्यावसायिक अंतर्ज्ञान नहीं है, संचार कौशल की कमी है, या एक पैराग्राफ को एक साथ नहीं रख सकते हैं जो बताते हैं कि वे जो काम करते हैं वह प्रभावशाली क्यों है। यह सुझाव देना कि इंजीनियरों को प्रबंधित करने के लिए आपको अधिक गोंद की आवश्यकता है, सामान्य पैटर्न को खारिज कर देता है कि जो लोग तकनीकी रूप से प्रतिभाशाली हैं, उनके पास उच्च स्तर की सामान्य बुद्धि भी होती है, बहुत पढ़ते हैं, आजीवन सीखने वाले होते हैं, और व्यवसाय में बहुत अच्छे होते हैं न कि केवल कोड।

जब मैं नोवेल में था, मैंने सीखा था कि ऐसे लोग थे जिन्हें मैं "ग्लू पीपल" कहता हूं। गोंद लोग अविश्वसनीय रूप से अच्छे लोग हैं जो समूहों के बीच अंतरालीय सीमाओं पर बैठते हैं, और वे गतिविधि में सहायता करते हैं। और वे बहुत, बहुत वफ़ादार हैं, और लोग उन्हें प्यार करते हैं, और आपको उनकी बिल्कुल भी ज़रूरत नहीं है।

नोवेल में, मैं इन गोंद लोगों से छुटकारा पाने की कोशिश करता रहा, क्योंकि वे रास्ते में आ रहे थे, क्योंकि उन्होंने सब कुछ धीमा कर दिया था। और हर बार जब मैं उन्हें एक समूह से हटाता हूं, तो वे दूसरे समूह में दिखाई देते हैं, और वे स्थानांतरित हो जाते हैं, और फिर से काम पर आ जाते हैं और वह सब।

एन्ट्रापी

जैसे-जैसे संगठन बढ़ते हैं, संस्थागत ज्ञान, हितधारकों की संख्या, कोडबेस और एंट्रॉपी में वृद्धि होती है। एन्ट्रापी बढ़ने से उच्च अपशिष्ट, उच्च संज्ञानात्मक भार, अव्यवस्था और अराजकता होती है।

सॉफ्टवेयर इंजीनियर के रूप में, मुझे लगता है कि हमने जटिलता को प्रबंधित करने में एक भद्दा काम किया है। उदाहरण के लिए, वर्षों से हमने सुना है कि मोनोलिथ खराब हैं क्योंकि वे फूले हुए कोडबेस उत्पन्न करते हैं, परिनियोजन को कठिन बनाते हैं, या स्केलेबिलिटी के साथ समस्याएँ पैदा करते हैं। फिर भी दूसरे चरम पर, जहां हमें माइक्रोसर्विसेज की दुनिया में काम करना है, मुझे लगता है कि बुनियादी चीजों को शिप करने के लिए मुझे अलग-अलग भाषाओं में लिखे गए कई कोडबेस में काम करने की जरूरत है, जिनमें से प्रत्येक में उनकी तैनाती की विचित्रताएं और आर्किटेक्चर पैटर्न हैं। प्रतिमान लैम्ब्डा स्पेगेटी में बदल रहा है । जो महत्वपूर्ण है उस पर रुकना और फिर से ध्यान केंद्रित करना एन्ट्रापी को कम करने पर बड़ा प्रभाव डालता है। निम्न, क्रिया-उन्मुख स्तर पर यह निम्नानुसार प्रकट हो सकता है:

• उत्पादन में निष्पादित नहीं किए गए मृत कोड को हटाना। मैंने इतने सारे कोडबेस के साथ बातचीत की है जहां >50% कोड मृत कोड था और सहयोगियों के लिए संज्ञानात्मक भार बनाया। काश देव उत्पादकता स्थान में कुछ ऐसा होता जो उत्पादन में निष्पादित लाइनों के आधार पर कोड कवरेज उत्पन्न करता। प्रत्येक तिमाही में आप रुकते हैं और उन रिपोर्टों की समीक्षा करते हैं और उन फ़ाइलों को हटा देते हैं जिनका निष्पादन शून्य था।
• उत्पाद प्रबंधकों के रूप में, हम इस बात पर पर्याप्त रूप से विचार नहीं करते हैं कि हमें किन विशेषताओं को खत्म करना चाहिए या वापस लाना चाहिए। फिर भी क्या हटाया जाना चाहिए पर रोकना और प्रतिबिंबित करना उपयोगकर्ता अनुभव को सरल बनाने और सुधारने में बहुत सार्थक हो सकता है। मैं खुद को टेक-सेवी मानता हूं, फिर भी मुझे लगता है कि आज बनाए गए कई उत्पाद मौजूदा उपयोगकर्ताओं के एक सेट पर हाइपर-अनुकूलित किए गए हैं, जिससे नए उपयोगकर्ताओं के लिए अव्यवस्थित और भ्रमित करने वाला UX अनुभव होता है। तिमाही के अंत में पूछना "हम किस सुविधा को अनशिप कर सकते हैं?" अव्यवस्था को कम करने में उपयोगी हो सकता है।

अहंकार शत्रु है

रेयान हॉलिडे ने अपनी पुस्तक एगो इज द एनीमी में सुझाव दिया है, एक मजबूत "प्रलोभन है जो हर किसी के लिए मौजूद है - बातचीत के लिए और कार्रवाई को बदलने के लिए प्रचार।" अहंकार एक बड़ा कारण है कि कई संस्थानों में प्रगति और नवाचार की कमी हो सकती है। यहाँ बताया गया है कि अहंकार कैसे प्रकट होता है:

• समान लोगों को अपने विचारों को समूह वार्तालाप में डालने के लिए खुजली करते हुए देखना, भले ही उनके विचारों में कोई या बहुत कम सीमांत मूल्य न हो।
• ऐसे लोगों का होना जो कभी भी सक्रिय रूप से अपने सहयोगियों को प्रायोजित करने में संलग्न नहीं होते हैं या जो दृश्यता को जमा करने का प्रयास करते हैं। यदि आप एक प्रबंधक या प्रबंधकों के प्रबंधक हैं, तो आप यह देख कर इसका पता लगा सकते हैं कि आपकी प्रत्यक्ष रिपोर्ट कितनी बार आपके 1:1 में अन्य लोगों की सफलताओं या योगदानों के बारे में बात करती है। अन्य लोगों की पावती या निस्वार्थ प्रायोजन का अभाव अस्वस्थ अहंकार का संकेत हो सकता है।
• समग्र कंपनी या संगठन के बजाय टीम के लिए अनुकूलित करना। मैंने तान्या रेली द्वारा स्टाफ इंजीनियर के पथ से आरेख उधार लिया और यह पूरी तरह से इस समस्या का उदाहरण देता है जहां टीमें स्थानीय अधिकतम के लिए अनुकूलन करती हैं। उदाहरण के लिए, यदि आप अपने डोमेन के भीतर रखरखाव मोड में प्रवेश कर रहे हैं, तो क्या आप अपनी टीम को भंग करने और कर्मचारियों को अन्य टीमों में पुनर्वितरित करने के लिए ठीक होंगे? अधिकांश प्रबंधक ऐसा कभी नहीं करेंगे क्योंकि इसका मतलब कंपनी के भीतर सामाजिक और राजनीतिक पूंजी को खोना होगा।

• आपकी भूमिका के आधार पर, आप बैठकों के मूल्य को कैसे देखते हैं, इस संदर्भ में एक बहुत मजबूत विरोधाभास है। " सबसे शक्तिशाली लोग प्रबंधक के कार्यक्रम पर हैं "। दुर्भाग्य से, बैठकों के मूल्य की उनकी धारणा एक सांस्कृतिक ओवरराइड बनाती है जो उन लोगों को प्रभावित करती है जो समस्या और समाधान के बारे में सोचने के लिए निर्बाध समय पसंद करते हैं। यहां तक ​​कि विचार-मंथन के उद्देश्यों के लिए भी, सबूत बताते हैं कि समूह विचार-मंथन समय की बर्बादी है । फिर भी इतने फूले हुए संगठन आईसी का आधा समय बैठकों में क्यों व्यतीत करते हैं?

निष्कर्ष

नवाचार का इंजन विकासवादी परिवर्तन पर निर्भर करता है। अंततः, यदि कोई संस्था कठोर हो जाती है और परिवर्तन के अनुकूल नहीं होती है, तो यह धीमी मौत मर जाएगी। मेरे अनुभव में, एक प्रक्रिया शुरू करने में अक्सर अनपेक्षित लागतें होती हैं जो कम वेग की ओर ले जाती हैं। इसके बजाय, मैं निम्नलिखित पर ध्यान केंद्रित करूंगा:

• पूर्णतावाद प्राप्त करने की कोशिश करने के बजाय पुनरावृत्ति का पक्ष लेना और गलतियों से सीखना।
• गोंद लोग आवश्यक हैं, लेकिन उनकी संख्या की एक सीमा होनी चाहिए, ताकि वे उच्च उत्तोलन के साथ कार्य कर सकें। बस ऐसे लोगों को काम पर रखना जो तकनीकी रूप से सक्षम हैं और जिनके पास अच्छा व्यावसायिक अंतर्ज्ञान है, गोंद भूमिकाओं के लिए ओवरहायरिंग की आवश्यकता को हल कर सकते हैं।
• अंत में मैं एन्ट्रापी को कम करने पर ध्यान केंद्रित करूंगा और लगातार पूछूंगा कि सादगी को बढ़ाने वाले व्यवहार के लिए लोगों को क्या छोड़ा जा सकता है और पुरस्कृत किया जा सकता है।