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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

पुनः लेबल किया गया साइलो। किसी विभाग का नाम बदलकर उत्पाद टीम रख दिया जाता है, इसके सदस्य अपनी कार्यात्मक रिपोर्टिंग लाइनें, अपने उद्देश्य और अपना प्रबंधक बरकरार रखते हैं, और नाम-पट्टिका के अलावा कुछ नहीं बदलता। संचार की संरचना अछूती रहती है, इसलिए Conway के नियम के अनुसार काम की संरचना भी अछूती रहती है। यह सबसे आम विफलता है क्योंकि इसे करना सबसे सस्ता है और इसे प्रगति समझ लेना सबसे आसान, और यह हर किसी को यह दावा करने देकर कि बदलाव पहले ही हो चुका है, संगठन को असली बदलाव के प्रति प्रतिरक्षित कर देती है।

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

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

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

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

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

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

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

पूरे दौरान, हम आपकी टीमों के इर्द-गिर्द नहीं, बल्कि उनके साथ काम करते हैं। जो ज्ञान किसी टिकाऊ टीम को तेज़ बनाता है वह मौन और स्थानीय होता है; इसे बाहर से स्थापित नहीं किया जा सकता या किसी दस्तावेज़ में सौंपा नहीं जा सकता। हमारी भूमिका तर्क, प्रतिमान और अनुशासन लाना है, और पीछे एक ऐसा संगठन छोड़ना है जो अपने संदर्भ के बदलने पर स्वयं को पुनः डिज़ाइन कर सके, जो कि अवश्य बदलेगा।

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

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

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

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