1.13 मार्गदर्शन, कोचिंग, और ज्ञान साझाकरण

अवलोकन और प्रेरणा

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

यह अध्याय उन प्रथाओं के बारे में है जो लोगों को बढ़ाती हैं और विशेषज्ञता फैलाती हैं: कैसे एक वरिष्ठ इंजीनियर एक कनिष्ठ इंजीनियर को विकसित करता है, कैसे किसी शिल्प के इर्द-गिर्द समुदाय बनते हैं, कैसे शिक्षण को बाद में जोड़ने के बजाय दैनिक कार्य में ही निर्मित किया जाता है। यह कई पड़ोसी अध्यायों के करीब है। अध्याय 1.3 उस करियर सीढ़ी को परिभाषित करता है जिसे चढ़ने में ये प्रथाएँ लोगों की मदद करती हैं, अध्याय 1.8 उस भर्ती और ऑनबोर्डिंग को कवर करता है जो आपको विकसित करने के लिए एक नया सहकर्मी सौंपता है, अध्याय 1.10 उस प्रभावशीलता को मापता है जिसकी रक्षा स्वस्थ ज्ञान प्रवाह करता है, और अध्याय 1.11 उस प्रबंधन शिल्प को कवर करता है जो इस काम को वित्तपोषित और पुरस्कृत करता है। तकनीकी पक्ष पर, अध्याय 2.5 की कोड समीक्षा और अध्याय 2.7 का दस्तावेज़ीकरण आपके पास मौजूद सबसे शक्तिशाली शिक्षण माध्यमों में से दो हैं।

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

मुख्य सिद्धांत

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

सिफारिशें

मार्गदर्शन, कोचिंग, और प्रायोजन में अंतर करें

ये तीन शब्द परस्पर विनिमय के रूप में उपयोग किए जाते हैं, और यह भ्रम लोगों को उनके करियर की कीमत चुकाता है। मेंटरिंग अनुभव और सलाह साझा करना है: एक अधिक अनुभवी व्यक्ति कम अनुभवी व्यक्ति को तकनीकी और करियर प्रश्नों को नेविगेट करने में मदद करता है, ऐसा दृष्टिकोण देकर जो मेंटी ने अभी तक अर्जित नहीं किया है। कोचिंग अलग है। एक कोच आपको उत्तर नहीं थमाता; एक कोच ऐसे प्रश्न पूछता है जो आपको अपना खुद का उत्तर खोजने में मदद करते हैं, जिससे आपकी वह क्षमता बनती है कि आप बिना उनके अगली समस्या हल कर सकें। मेंटरिंग कहती है “उस स्थिति में मैंने यह किया था।” कोचिंग कहती है “आपको कौन से विकल्प दिखते हैं, और यदि आप हर एक को आज़माएँ तो क्या होगा?”

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

संरचित ऑनबोर्डिंग बडी बनाएं

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

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

अभ्यास समुदाय (कम्युनिटी ऑफ़ प्रैक्टिस) और गिल्ड विकसित करें

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

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

आंतरिक टेक टॉक, ब्राउन बैग, और लाइटनिंग टॉक चलाएं

एक नियमित आंतरिक वार्ता श्रृंखला सबसे सस्ते, सबसे उच्च-प्रतिफल वाले ज्ञान निवेशों में से एक है जो आप कर सकते हैं। एक ब्राउन बैग सत्र लंच के दौरान एक अनौपचारिक वार्ता है जहाँ कोई बताता है कि उसने क्या सीखा। एक लाइटनिंग टॉक एक सख्ती से समय-सीमित पाँच-मिनट की प्रस्तुति है, जो बार को इतना नीचे कर देती है कि पहली बार बोलने वाले भी स्वेच्छा से आगे आते हैं। ये प्रारूप विशिष्ट ज्ञान फैलाते हैं (नई कैशिंग परत कैसे काम करती है) और कुछ और सूक्ष्म भी: वे शिक्षण को सामान्य बनाते हैं, वे छिपे हुए विशेषज्ञों को सामने लाते हैं, और वे लोगों को उन प्रस्तुति कौशलों को बनाने के लिए एक कम-जोखिम वाला मंच देते हैं जिन पर उनका प्रमोशन निर्भर करता है।

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

दस्तावेज़ीकरण को शिक्षण मानें और ज्ञान निरंतरता की रक्षा करें

दस्तावेज़ीकरण एक फ़ाइलिंग कार्य नहीं है; यह शिक्षण है जो पल और लेखक से आगे तक पैमाने पर काम करता है। रनबुक, आर्किटेक्चर अवलोकन, “हमने इसे इस तरह क्यों बनाया” नोट, ये वे तरीके हैं जिनसे आप किसी ऐसे व्यक्ति को सिखाते हैं जिससे आप कभी नहीं मिलेंगे, जिसमें आपकी अपनी टीम का वह संस्करण भी शामिल है जो तीन साल बाद मौजूद होगा। अध्याय 2.7 बताता है कि दस्तावेज़ीकरण अच्छी तरह कैसे लिखें; यहाँ का मुद्दा प्रेरक है। हर टुकड़ा टिकाऊ लेखन आपके बस फैक्टर को कम करता है, क्योंकि एक अच्छे दस्तावेज़ में कैद ज्ञान ऐसा ज्ञान है जिसे कोई भी एकल प्रस्थान छीन नहीं सकता।

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

ज्ञान स्थानांतरण के रूप में पेयरिंग और मॉबिंग का उपयोग करें

पेयर प्रोग्रामिंग, जहाँ दो इंजीनियर एक कीबोर्ड पर एक समस्या पर काम करते हैं, दो लोगों के बीच ज्ञान स्थानांतरित करने के सबसे तेज़ तरीकों में से एक है, क्योंकि स्थानांतरण वास्तविक समय में और संदर्भ में होता है। मॉब प्रोग्रामिंग (जिसे एन्सेंबल प्रोग्रामिंग भी कहा जाता है) इसे एक पूरे छोटे समूह तक विस्तारित करती है जो एक साथ एक चीज़ पर काम करता है। इनमें से कोई भी केवल उत्पादित कोड के बारे में नहीं है। इनका शांत लाभ यह है कि विशेषज्ञता, परंपराएं, और निर्णय क्षमता काम करने के एक स्वाभाविक उपोत्पाद के रूप में एक व्यक्ति से दूसरे व्यक्ति तक फैलती हैं, बिना किसी को अलग प्रशिक्षण सत्र निर्धारित किए।

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

स्टाफ़-प्लस इंजीनियरों को फ़ोर्स मल्टीप्लायर के रूप में विकसित करें

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

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

इसे सीढ़ियों, समय बजट, और मीट्रिक में स्पष्ट बनाएं

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

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

दूरस्थ और वितरित ज्ञान साझाकरण के लिए डिज़ाइन करें

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

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

समझौते: फ़ायदे और नुकसान

मेंटरिंग और ज्ञान साझाकरण में निवेश करना वह समय खर्च करता है जो फ़ीचर्स में जा सकता था, और वह तनाव वास्तविक है। तालिका मुख्य विकल्पों को ईमानदारी से प्रस्तुत करती है।

प्रथा	फ़ायदे	नुकसान
पेयर और मॉब प्रोग्रामिंग	तेज़, संदर्भगत ज्ञान स्थानांतरण; कम दोष	एक कार्य पर दो या अधिक लोग; अल्पावधि में धीमा लगता है
अभ्यास समुदाय / गिल्ड	क्षैतिज ज्ञान प्रवाह; साझा मानक	मीटिंग में सड़ सकते हैं; जीवित रहने के लिए वास्तविक अधिकार चाहिए
आंतरिक वार्ताएं और ब्राउन बैग	सस्ती, विशेषज्ञों को सामने लाती है, वक्ता बनाती है	आयोजन चैंपियन को थका देता है; उपस्थिति गिर सकती है
शिक्षण के रूप में दस्तावेज़ीकरण	लेखक से आगे तक पैमाने पर काम करता है; बस फैक्टर कम करता है	स्वामित्व के बिना बासी हो जाता है; लेखन में वास्तविक समय लगता है
संरचित ऑनबोर्डिंग बडी	तेज़ रैंप, मज़बूत अपनापन, बडी भी बढ़ता है	बडी का अपना काम धीमा होता है; गुणवत्ता व्यक्ति के अनुसार भिन्न होती है
स्पष्ट सीढ़ी और समय बजट	शिक्षण को निष्पक्ष और पुरस्कृत बनाता है	प्रक्रिया जोड़ता है; मोटे तौर पर मापे जाने पर बॉक्स-टिकिंग बन सकता है

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

अपनी टीम के साथ चर्चा करने के लिए सवाल

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

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

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

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

5. जब अगली कठिन समयसीमा आती है, तो हम सबसे पहले क्या काटते हैं, और क्या वह ज्ञान-साझाकरण समय है जिसे सुरक्षित रखने की हमने कसम खाई थी? शिक्षण, दस्तावेज़ीकरण, गिल्ड, और पेयरिंग सभी वह समय खर्च करते हैं जो आज दृश्यमान है बनाम एक प्रतिफल जो बाद में आता है, जो इन्हें किसी भी दबाव का प्रतिवर्ती पहला शिकार बनाता है। एक बड़े संगठन के लिए, यदि हर टीम दबाव में चुपचाप ज्ञान साझाकरण को कम-वित्तपोषित करती है, तो समग्र प्रभाव एक ऐसी संस्था है जो ठीक तब सीखना बंद कर देती है जब वह सबसे अधिक दबाव में होती है। पिछले दो डिलीवरी क्रंच लाएं और ईमानदारी से ट्रेस करें कि उनके दौरान मेंटरिंग घंटों, वार्ता श्रृंखला, और दस्तावेज़ीकरण का क्या हुआ। प्रतिस्पर्धी विचार वास्तविक है: कभी-कभी एक समयसीमा को वास्तव में जीतना ही चाहिए, और अन्यथा दिखावा करना विश्वसनीयता जलाता है। जो आप परख रहे हैं वह यह है कि क्या समय ऑन-कॉल की तरह सुरक्षित है (डिफ़ॉल्ट रूप से बचाव किया गया, केवल स्पष्ट, जवाबदेह निर्णय से त्याग किया गया) या केवल स्लाइड डेक में सुरक्षित है। एंटरप्राइज़ और सरकारी संदर्भों में जहाँ सिस्टम वर्षों तक चलते हैं, तिमाही तारीख हासिल करने के लिए ज्ञान निरंतरता काटना एक टिकाऊ दायित्व को एक अल्पकालिक जीत से बदलना है, और किसी को उस व्यापार पर अपना नाम हस्ताक्षरित करना चाहिए, न कि इसे बहाव से होने देना चाहिए।

6. क्या हमारे अभ्यास समुदाय वास्तव में किसी चीज़ के मालिक हैं, या ये ऐसी मीटिंग हैं जो हम शिल्प में निवेश महसूस करने के लिए करते हैं? एक गिल्ड जिसके पास वास्तविक अधिकार है (टेस्टिंग मानक का स्वामित्व, कंपोनेंट लाइब्रेरी चुनना, स्वीकृत पैटर्न को संकलित करना) ज्ञान को टीमों में क्षैतिज रूप से फैलाता है जिन्हें संगठन चार्ट कभी नहीं जोड़ता; बिना अधिकार वाला गिल्ड एक कैलेंडर इवेंट में सड़ जाता है जिसे लोग अस्वीकार करते हैं। एक बड़ी टीम के लिए, यह मुख्य तंत्र है जिससे एक बार मिला हुआ समाधान सबको मिलता है बजाय इसके कि इसे दर्जनों बार बुरी तरह से फिर से आविष्कार किया जाए, इसलिए इसका स्वास्थ्य एक सीधा दक्षता सवाल है। हर समुदाय का चार्टर, उसके पिछले तीन निर्णय, और उसकी उपस्थिति प्रवृत्ति लाएं, और पूछें कि यदि यह कल मिलना बंद कर दे तो वास्तव में क्या टूटेगा; यदि ईमानदार उत्तर कुछ नहीं है, तो आपके पास एक ज़ोम्बी है। प्रतिस्पर्धी विचार यह है कि वास्तविक अधिकार का मतलब वास्तविक जवाबदेही और धीमे, अधिक विवादित निर्णय है, जिसे कुछ नेता एक क्रॉस-कटिंग समूह को सौंपने का विरोध करते हैं। कई टीमों, विक्रेताओं, और दीर्घकालिक प्लेटफ़ॉर्मों वाली एंटरप्राइज़ और सरकारी सेटिंग्स में, एक चार्टर्ड समुदाय जिसका खोजने योग्य निर्णय रिकॉर्ड हो, वह भी है जिससे आप संगठनात्मक और संविदात्मक सीमाओं के आर-पार मानकों को सुसंगत और ऑडिट योग्य रखते हैं, जो तदर्थ समन्वय नहीं कर सकता।

क्षेत्र लेंस

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

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

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

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

उदाहरण

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

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

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

व्यावसायिक मामला: प्रेरणाएं, ROI, और TCO

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

प्रतिधारण वह जगह है जहाँ संख्याएं बड़ी हो जाती हैं। एक इंजीनियर को बदलने की लागत भर्ती, ऑनबोर्डिंग, और खोई हुई उत्पादकता में उनके वार्षिक वेतन का एक पर्याप्त हिस्सा है, और लोग उन संगठनों को छोड़ देते हैं जहाँ वे बढ़ना बंद कर देते हैं। मेंटरिंग, कोचिंग, और प्रायोजन आपके पास मौजूद सबसे मज़बूत प्रतिधारण लीवरों में से हैं, क्योंकि वे लोगों को महसूस कराते हैं कि उनमें निवेश किया गया है और उन्हें आगे का एक दृश्यमान रास्ता देते हैं। अपनाने की लागत ज़्यादातर सुरक्षित समय और हल्की संरचना है: बजट किए गए घंटे, एक वार्ता श्रृंखला, गिल्ड चार्टर, एक बडी चेकलिस्ट। उपेक्षा की लागत चुपचाप जमा होती है क्योंकि ज्ञान केंद्रित होता है, दस्तावेज़ीकरण सड़ता है, और आपके सबसे अच्छे संभावित मेंटर उन संगठनों के लिए चले जाते हैं जो उन्हें बढ़ाएंगे। नेतृत्व को मामला समझाने के लिए, ज्ञान साझाकरण को उन मीट्रिक से जोड़ें जिन्हें वे पहले से देखते हैं: ऑनबोर्डिंग समय, प्रतिधारण, जब कोई विशेषज्ञ अनुपलब्ध हो तब घटना पुनर्प्राप्ति, और अध्याय 1.10 के प्रभावशीलता उपाय।

एंटी-पैटर्न और नुकसान

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

परिपक्वता मॉडल

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

चर्चा के लिए विचार

1. आपकी टीम में एक ऐसा सिस्टम क्या है जिसका बस फैक्टर एक है, और इस महीने इसे दो बनाने के लिए सबसे छोटा ठोस कदम क्या है?
2. क्या आपकी करियर सीढ़ी वास्तव में वरिष्ठ तक पहुँचने के लिए दूसरों को विकसित करना आवश्यक करती है, या यह केवल इसे गुज़रते हुए ज़िक्र करती है?
3. आपकी टीम में कौन अदृश्य मल्टीप्लायर काम कर रहा है जिसे आपके अंतिम समीक्षा चक्र ने पहचानने या पुरस्कृत करने में विफल रहा?
4. आखिरी बार कब एक दूरस्थ या नए-नए शामिल हुए सहकर्मी ने ऐसा ज्ञान गँवाया जिसे दफ़्तर में मौजूद, कार्यकाल वाले लोगों ने रोमांच से सोख लिया?
5. क्या आपके वरिष्ठ इंजीनियर लोगों को प्रायोजित करते हैं (उन पर वास्तविक विश्वसनीयता खर्च करते हैं), या वे सिर्फ़ सलाह देने पर रुक जाते हैं?
6. अगर आपका सबसे अच्छा मेंटर कल चला जाए, तो क्या सिखाने की प्रथा जीवित रहेगी, या यह पूरी तरह उसी एक व्यक्ति में रहती है?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

• Etienne Wenger, Communities of Practice: Learning, Meaning, and Identity
• Will Larson, Staff Engineer: Leadership Beyond the Management Track
• Tanya Reilly, The Staff Engineer’s Path: A Guide for Individual Contributors Navigating Growth and Change
• Camille Fournier, The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change
• Sylvia Ann Hewlett, Forget a Mentor, Find a Sponsor: The New Way to Fast-Track Your Career
• Andrew Hunt and David Thomas, The Pragmatic Programmer: Your Journey to Mastery
• Kenneth S. Rubin, Essential Scrum: A Practical Guide to the Most Popular Agile Process
• Woody Zuill and Kevin Meadows, Mob Programming: A Whole Team Approach