【आपकी संगठनात्मक संरचना, आपके सॉफ़्टवेयर की नियति को पहले ही तय कर चुकी है】 कॉनवे का नियम — 56 वर्षों तक अवहेलित रही प्रबंधन की कानूनी वास्तविकता AI युग में सॉफ़्टवेयर इंजीनियरिंग का परिवर्तन — मैं धीरे-धीरे AI सीखता हूँ171

पहले कुछ बातें

• आपका सॉफ्टवेयर आर्किटेक्चर आपके टेक टीम द्वारा “डिज़ाइन” नहीं, बल्कि आपके ऑर्गनाइजेशनल आर्किटेक्चर द्वारा “उगा” जाता है। 1968 में प्रस्तावित यह नियम, AI युग में बार-बार साबित हो रहा है।
• हार्वर्ड बिजनेस स्कूल के प्रमाणित अध्ययनों ने साबित किया: ऑर्गनाइजेशनल दूरी, कोड की जटिलता से अधिक सटीकता से सॉफ्टवेयर दोष दर का पूर्वानुमान लगाती है। आप जिसे “टेक्निकल डेब्ट” समझते हैं, वह मूलतः “ऑर्गनाइजेशनल डेब्ट” हो सकता है।
• अमेज़न का माइक्रोसर्विस इम्पीयर, स्पॉटिफाई का स्मॉल टीम मॉडल, ऐपल का सिरी का संकट — तीन ट्रिलियन डॉलर की कंपनियाँ, अलग-अलग किस्मतों के साथ, एक ही नियम की व्याख्या करती हैं।
• AI एजेंट अब ऑर्गनाइजेशनल चार्ट में प्रवेश कर रहे हैं। जब टीम के “नोड्स” सिर्फ इंसान नहीं रह जाते, तो कॉन्वे का नियम आपकी कल्पना से अलग तरीके से फिर से लिखा जाएगा।

1968 में, एक अज्ञात प्रोग्रामर ने एक पेपर लिखा, जिसे हार्वर्ड बिजनेस रिव्यू ने “उसका तर्क साबित नहीं हुआ” कहकर खारिज कर दिया। 56 साल बाद, इस पेपर का केंद्रीय विचार पूरे सॉफ्टवेयर उद्योग की मान्यता प्राप्त “सार्वभौमिक गुरुत्वाकर्षण का नियम” बन गया — और 2026 में, जब AI हर कुछ को फिर से बदल रहा है, तो यह नियम पिछले किसी भी समय से अधिक महत्वपूर्ण है।

1. एक खारिज हुई पेपर कैसे सॉफ्टवेयर इंजीनियरिंग का “गुरुत्वाकर्षण का नियम” बन गया

HBR द्वारा खारिज किया गया प्रवक्ता

1968 अप्रैल में, मेल्विन कॉनवे ने Datamation पत्रिका में एक साधारण शीर्षक वाला लेख प्रकाशित किया: How Do Committees Invent? (समितियाँ कैसे आविष्कार करती हैं?)।
इस लेख का केंद्रीय दावा केवल एक वाक्य था, लेकिन यह किसी भी CTO के लिए रात भर नींद उड़ा सकता है:

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

विरोधाभासी रूप से, कॉनवे ने अपने इस पेपर को सबसे पहले हार्वर्ड बिजनेस रिव्यू में भेजा था, लेकिन संपादक ने इसे “अपने तर्क को साबित नहीं किया गया” के कारण खारिज कर दिया। सात साल बाद, फ्रेड ब्रूक्स ने अपनी क्लासिक किताब द मैन-मंथ लीजेंड में इस विचार को गंभीरता से संदर्भित किया और इसे आधिकारिक रूप से “कॉनवे का नियम” (Conway’s Law) नाम दिया।
इस तरह, एक ऐसी टिप्पणी जिसे शीर्ष व्यावसायिक पत्रिकाओं ने अस्वीकार कर दिया था, वह सॉफ्टवेयर इंजीनियरिंग के क्षेत्र में सबसे अधिक संदर्भित नियमों में से एक बन गई। ## मार्टिन फाउलर का “अंतिम निर्णय”
अगर कॉनवे एक अनुमान रखने वाला कोपरनिकस थे, तो पिछले बीस वर्षों के प्रमाणात्मक अध्ययन दूरबीन बन गए।
2022 में, ThoughtWorks के मुख्य वैज्ञानिक मार्टिन फाउलर ने एक ऐसा मूल्यांकन लिखा जिसे उद्योग भर में व्यापक रूप से साझा किया गया: “अगर सॉफ्टवेयर आर्किटेक्चर के क्षेत्र में एक ऐसा नियम है जिसे हर व्यावहारिक व्यक्ति स्वीकार करता है, तो वह कॉनवे का नियम है। यह इतना महत्वपूर्ण है कि मैंने जिन सभी सिस्टम को देखा है, उन सभी पर इसका प्रभाव पड़ा है; यह इतना शक्तिशाली है कि इसका विरोध करने वाला कोई भी व्यक्ति अनिवार्य रूप से असफल हो जाएगा।”
यह किसी शिक्षाविद् का एक विचारधारा के आधार पर निष्कर्ष निकालना नहीं है। Fowler ने दुनिया भर के सैकड़ों कंपनियों में अपने परामर्श अनुभवों में एक ही घटना को बार-बार देखा है: एक संगठनात्मक संरचना चित्र सॉफ्टवेयर के नक्शे की छाया होती है, चाहे प्रबंधन इसे समझता हो या नहीं।

यहाँ एक सूक्ष्म लेकिन महत्वपूर्ण बात है जो बहुत से लोग नज़रअंदाज़ कर देते हैं: फाउलर का कहना है कि “जो कोई भी इसका विरोध करने की कोशिश करता है, वह अनिवार्य रूप से असफल हो जाएगा”, न कि “जो कोई भी इसका उपयोग करने की कोशिश करता है”। इसमें क्या अंतर है? कॉन्वे के नियम का विरोध करने का मतलब है—संगठनात्मक संरचना को बिना बदले आर्किटेक्चर में बदलाव लाने की कोशिश करना; जबकि इसका उपयोग करने का मतलब है—पहले संगठन को समायोजित करना, ताकि आर्किटेक्चर “प्राकृतिक रूप से विकसित” हो सके।

यह अंतर, डिजिटल ट्रांसफॉर्मेशन प्रोजेक्ट्स की सफलता या असफलता तय करता है। हम अगले दूसरे लेख में Team Topologies पर चर्चा करते समय, “इनवर्स कॉन्वे मैनियूवर” (Inverse Conway Maneuver) नामक इस महत्वपूर्ण रणनीति को विस्तार से समझेंगे—जो मूलतः इस नियम का विरोध नहीं, बल्कि उपयोग करती है।

द्वितीय: प्रयोगशाला से युद्धक्षेत्र तक: तीन अध्ययनों ने इस नियम को साबित किया

हार्वर्ड बिजनेस स्कूल का “मिररिंग हाइपोथेसिस”

2012 में, हार्वर्ड बिजनेस स्कूल के मैककॉरमैक और उनके सहयोगियों ने एक महत्वपूर्ण अध्ययन प्रकाशित किया, जिसे शैक्षणिक समुदाय ने “मिररिंग हाइपोथेसिस” (Mirroring Hypothesis) के नाम से जाना।

इस अध्ययन की विधि बहुत चतुर थी: उन्होंने एक ही कार्य करने वाले व्यावसायिक सॉफ़्टवेयर और ओपन सोर्स सॉफ़्टवेयर की तुलना की। व्यावसायिक सॉफ़्टवेयर को स्तरीय संगठनात्मक टीमों ने विकसित किया, जबकि ओपन सोर्स सॉफ़्टवेयर को अनियमित रूप से वितरित समुदायों ने।

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

संगठनात्मक संरचना एक “गुरुत्वाकर्षण क्षेत्र” की तरह होती है — आप इसके खिलाफ अस्थायी रूप से लड़ सकते हैं, लेकिन समय के साथ, सिस्टम आर्किटेक्चर अपनी मूल संगठनात्मक संरचना के साथ समानांतर हो जाता है।

इस अध्ययन का उद्यमी निर्णय लेने वालों के लिए वास्तविक संदेश क्या है? जब आपकी तकनीकी टीम बार-बार कहती है “हमें रीफैक्टर करने की जरूरत है”, तो वास्तव में जिसे “रीफैक्टर” करने की जरूरत है, वह कोड नहीं, बल्कि संगठन हो सकता है। लेकिन यह कैसे पता चले कि यह “तकनीकी ऋण” है या “संगठनात्मक ऋण”? इसके लिए एक व्यवस्थित निदान विधि की आवश्यकता है — हम अपने 12वें लेख, “उद्यमिक AI विकास उपकरण अपनाने का निर्णय ढांचा” में एक पूर्ण मूल्यांकन मॉडल प्रदान करेंगे।

माइक्रोसॉफ्ट रिसर्च का “विंडोज विस्टा प्रयोग”

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

उम्मीदवार उत्तरों में शामिल थे: कोड की जटिलता, कोड की पंक्तियों की संख्या, कोड में परिवर्तन की आवृत्ति, विकासकों का अनुभव… और एक ऐसा चर जो “तकनीकी” से असंबंधित लगता था — संगठनात्मक दूरी (अर्थात्, संबंधित मॉड्यूल विकसित करने वाली टीमों के बीच संगठनात्मक संरचना में दूरी)।

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

इस खोज का उद्योग-स्तरीय अर्थ सतही दिखावे से कहीं अधिक गहरा है। इसका अर्थ है — आपकी QA रणनीति को संगठनात्मक संरचना के अनुसार बनाना चाहिए, कोड की जटिलता के अनुसार नहीं। अंतर-टीम सहयोग वाले मॉड्यूल्स के लिए अधिक कठोर टेस्ट कवरेज और समीक्षा प्रक्रियाएँ आवश्यक हैं, भले ही कोड स्वयं बहुत सरल दिखे। आज, जब AI द्वारा उत्पादित कोड की मात्रा तेजी से बढ़ रही है (Copilot अब उपयोगकर्ता द्वारा लिखे गए 46% कोड को उत्पन्न करता है), यह सिद्धांत और भी महत्वपूर्ण हो गया है — हम अगले अध्याय 8 में “उत्पादकता का विरोधाभास” पर Coinbase के मामले के साथ विस्तार से चर्चा करेंगे।

DORA अनुसंधान का “त्वरण” और “छिपा खतरा”

Google के अंतर्गत DevOps Research and Assessment (DORA) टीम, जिसकी नेतृत्व Nicole Forsgren, Jez Humble और Gene Kim द्वारा किया जा रहा है, ने अब तक की सबसे बड़ी सॉफ़्टवेयर डिलीवरी प्रदर्शन अनुसंधान रिपोर्ट जारी की है।

मुख्य खोज कॉनवे के नियम के साथ अत्यंत संगत है: “अगर हम एक सुव्यवस्थित, अच्छी तरह से एनकैप्सुलेटेड आर्किटेक्चर के साथ-साथ उसके अनुरूप संगठनात्मक संरचना लागू करते हैं, तो हम न केवल डिलीवरी गति और स्थिरता में सुधार कर सकते हैं, बल्कि इंजीनियरिंग टीम के बड़े पैमाने पर विस्तार के दौरान रैखिक या उससे अधिक उत्पादकता वृद्धि भी बनाए रख सकते हैं।” लेकिन DORA की 2022 की रिपोर्ट ने एक दिलचस्प अनुप्रतिफल भी पाया: सुव्यवस्थित आर्किटेक्चर ने डिलीवरी की दक्षता में सुधार किया, लेकिन टीमों में थकान की संभावना बढ़ा सकती है। कारण यह हो सकता है: जब टीमें अत्यधिक स्वायत्त और एक-दूसरे से अलग होती हैं, तो सदस्यों को समग्र अर्थ की अनुभूति खो जाती है, और उन्हें एक “मैं बस एक गियर हूँ” का एकाकी भाव होता है। यह एक महत्वपूर्ण स्मरण है—आर्किटेक्चर और संगठन का समन्वय एक चमत्कारिक उपाय नहीं है; यह कार्यक्षमता की समस्या को हल करता है, लेकिन संस्कृतिगत समस्याएँ उत्पन्न कर सकता है। एक गहरा विचार करने लायक निष्कर्ष: अगर सुव्यवस्थित आर्किटेक्चर + सुव्यवस्थित संगठन इंसानी डेवलपर्स को एकाकी महसूस करा रहा है, तो जब टीम में AI एजेंट शामिल हो जाएँ? AI “एकाकीपन” महसूस नहीं करता, लेकिन मनुष्य और अधिक एकाकी हो जाते हैं। यह पहलू कम चर्चा में आता है, लेकिन हमारे अध्ययन सामग्री में BCG की 2025 की एक रिपोर्ट ने “मध्यस्थ प्रबंधकों की व्यवस्थापन समस्या” का उल्लेख किया है—जो हमारी ग्रंथ 11 का केंद्रीय विषय भी है। # तीन: तीन ट्रिलियन डॉलर की कंपनियों के “कॉनवे के नियम क्षण” ## Amazon: एक ऐसा CEO का ईमेल जिसने सब कुछ बदल दिया

2002 के आसपास, जेफ बेजोस ने अमेज़ॉन के अंदर उस प्रसिद्ध “API Mandate” ईमेल भेजा—सभी टीमों को सेवा इंटरफ़ेस (API) के माध्यम से ही संचार करना अनिवार्य था, और किसी भी टीम को दूसरी टीम के डेटा स्टोरेज तक सीधा पहुँचने की अनुमति नहीं थी।
इस ईमेल की अंतिम पंक्ति कही जाती है: “इन नियमों का पालन न करने वालों को निकाल दिया जाएगा।”
अनेकों लोग अमेज़ॉन की माइक्रोसर्विस आर्किटेक्चर को एक तकनीकी निर्णय मानते हैं। लेकिन कॉन्वे के नियम के दृष्टिकोण से, बेजोस ने वास्तव में एक संगठनात्मक निर्णय लिया: उन्होंने पहले प्रबंधन के माध्यम से टीमों के बीच के “संक्षिप्त मार्गों” को जानबूझकर काट दिया, और फिर सॉफ़्टवेयर आर्किटेक्चर स्वतः ही एक-दूसरे से अलग सेवा मॉड्यूल में विकसित हो गया।
यही बाद में बेजोस द्वारा प्रस्तावित “दो पिज़्ज़ा टीम” (Two-Pizza Team) बनी—प्रत्येक टीम का आकार ऐसा होना चाहिए कि दो पिज़्ज़ा उसे पूरी तरह भर सकें (आमतौर पर 5-8 लोग), और प्रत्येक टीम के पास अपनी सेवा हो, जिसे स्वतंत्र रूप से डिप्लॉय किया जा सके और बाहरी दुनिया के साथ API के माध्यम से बातचीत की जा सके।
अमेज़ॉन का माइक्रोसर्विस साम्राज्य किसी आर्किटेक्ट द्वारा ड्राफ्ट नहीं किया गया, बल्कि इसकी संगठनात्मक संरचना ने खुद को विकसित किया। यह कॉन्वे के नियम का सबसे क्लासिक सकारात्मक उदाहरण है।

लेकिन यहाँ एक ऐसा पहलू है जिसकी बहुत सारी लेख चर्चा नहीं करते: अमेज़न की रणनीति सफल इसलिए है क्योंकि बेजोस ने कॉन्वे के नियम को समझा ही नहीं, बल्कि उन्होंने “इन्सेंटिव अलाइनमेंट” की समस्या को भी हल किया। प्रत्येक “दो पिज़्ज़ा टीम” के पास अपना P&L (लाभ-हानि विवरण) होता है; वे न केवल तकनीकी रूप से स्वायत्त होती हैं, बल्कि व्यावसायिक रूप से भी स्वायत्त होती हैं। इसका मतलब है कि टीमों के पास सेवा सीमाओं को स्पष्ट रखने का आंतरिक प्रेरणा होता है—क्योंकि सीमाओं का अस्पष्ट होना जिम्मेदारी के अस्पष्ट होने का कारण बनता है, और जिम्मेदारी का अस्पष्ट होना प्रदर्शन मापन के अस्पष्ट होने का कारण बनता है। संगठनात्मक संरचना + प्रेरणा संरचना + तकनीकी आर्किटेक्चर का त्रिकोणीय समन्वय, ही अमेज़न मॉडल का पूर्ण चित्र है। केवल संगठनात्मक संरचना को सीखने वाले, प्रेरणा डिज़ाइन को नहीं सीखने वाले उद्यम, अक्सर इसकी आकृति तो पकड़ लेते हैं, लेकिन इसकी आत्मा नहीं।

Spotify: आदर्श मॉडल और वास्तविकता का “एंट्रॉपी वृद्धि” संघर्ष

Spotify का “Squad मॉडल” एक समय सिलिकॉन वैली में संगठन डिज़ाइन की बाइबल माना जाता था: 5-8 लोगों की स्वायत्त टीमें (Squad), जो कई टीमों के समूह (Tribe) में एकत्रित होती हैं, और विभिन्न ट्राइब्स से तकनीकी विशेषज्ञ एक सभा (Chapter) बनाते हैं, जबकि रुचि-आधारित समुदाय गिल्ड (Guild) बनाते हैं।

इस मॉडल का डिज़ाइन विचार कॉन्वे के नियम के साथ अत्यधिक संगत है—छोटी और स्वायत्त टीम संरचना के माध्यम से, छोटी और स्वायत्त सॉफ़्टवेयर सेवाओं को प्रेरित किया जाता है।

लेकिन स्पॉटिफाई ने बाद में खुद ही स्वीकार किया कि वास्तविकता मॉडल से कहीं अधिक जटिल है। जब व्यवसाय एक निश्चित पैमाने तक बढ़ जाता है, तो छोटी टीमों के बीच निर्भरताएँ अपरिहार्य रूप से बढ़ जाती हैं, और पूर्ण स्वायत्तता अब समन्वय लागत पैदा करने लगती है। यह कॉन्वे के नियम का एक अक्सर नज़रअंदाज़ किया जाने वाला निष्कर्ष उजागर करता है: संगठनात्मक संरचना को एक बार डिज़ाइन करके स्थायी रूप से नहीं बनाया जा सकता; यह सॉफ़्टवेयर की तरह, “एंट्रॉपी बढ़ने” की प्रवृत्ति रखती है। जैसे-जैसे व्यवसाय की जटिलता बढ़ती है, संगठनात्मक सीमाएँ धीरे-धीरे धुंधली हो जाती हैं, संचार मार्ग लंबे होते जाते हैं, और सिस्टम आर्किटेक्चर धीरे-धीरे खराब होता जाता है। उत्कृष्ट तकनीकी संगठन “एक अच्छा आर्किटेक्चर डिज़ाइन करना” नहीं, बल्कि संगठन-आर्किटेक्चर अनुकूलन की निरंतर समायोजन क्षमता विकसित करना है। हम इस क्षमता की व्याख्या टीम टॉपोलॉजीज़ पर हमारी दूसरी पोस्ट में करेंगे—जो स्पॉटिफाई मॉडल की तुलना में अधिक व्यवस्थित और अधिक कार्यात्मक ढांचा प्रदान करती है। ## Apple: Siri को ChatGPT ने क्यों धूल चटाई? 2024-2025 में, Apple की Siri AI अपग्रेड योजना लगभग कॉन्वे के नियम की “विपरीत उदाहरण” बन गई।

समस्या की जड़ तकनीक में नहीं है। Apple के पास दुनिया के सर्वश्रेष्ठ AI अनुसंधान विशेषज्ञ और पर्याप्त वित्तीय संसाधन हैं। लेकिन Siri के विकास में दो ऐसी टीमें शामिल हैं जिनके बीच संगठनात्मक संरचना में एक संरचनात्मक दरार है: AI अनुसंधान टीम (जॉन जियानांड्रिया के नेतृत्व में) और उत्पाद विकास टीम (क्रेग फेडरिगी के नेतृत्व में)।

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

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

Apple का उदाहरण विशेष रूप से चीनी कंपनियों के निर्णय लेने वालों के लिए महत्वपूर्ण है। बहुत सी कंपनियाँ बिल्कुल इसी समस्या से गुजर रही हैं — AI टीम और व्यावसायिक टीम अलग-अलग VP के अधीन हैं, और AI लागू करने के प्रोजेक्ट्स “एक उत्पाद की सहयोगात्मक डिलीवरी” के बजाय “दो विभागों के राजनीतिक खेल” बन गए हैं।

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

चार: AI युग: कॉनवे का नियम फिर से लिखा जा रहा है

जब “संगठनात्मक नोड” सिर्फ मनुष्य नहीं रहे

2026 में, कॉनवे का नियम 1968 के बाद सबसे गहरी चुनौती का सामना कर रहा है। कॉनवे ने इस नियम की व्याख्या करते समय एक अंतर्निहित पूर्वधारणा रखी थी: संगठन में प्रत्येक “नोड” मनुष्य होता है। संचार संरचना मनुष्यों के बीच के संचार की होती है।

लेकिन आज, AI एजेंट संगठनात्मक आरेख में प्रवेश कर रहे हैं। Claude Code स्वतंत्र रूप से बहु-चरण विकास कार्यों को पूरा कर सकता है, Stripe का Minions सिस्टम हर सप्ताह 1000 से अधिक मर्ज PR उत्पन्न करता है, Cursor ने NVIDIA के 100% इंजीनियरों के कार्य शैली को बदल दिया है। Gartner की रिपोर्ट के अनुसार, 2025 तक उद्योग में बहु-एजेंट AI ऑर्केस्ट्रेशन पर परामर्श की मांग 1445% बढ़ गई है।

जब संगठन के कुछ नोड मनुष्य नहीं रह जाते, तो कॉनवे का नियम क्या बदल जाता है?

इस समस्या की विस्तृत चर्चा हमारी पूरी श्रृंखला के अगले आधे हिस्से में जारी रहेगी — अध्याय 10 में “वन मैन यूनिकॉर्न” घटना, अध्याय 11 में “कॉनवे का नियम और AI एजेंट”, अध्याय 14 में “एजेंटिक इंजीनियरिंग” — लेकिन यहाँ आपके विचार के ढांचे को स्थापित करने के लिए तीन प्रारंभिक निष्कर्ष दिए जा रहे हैं:

पहला, संचार संरचना रणनीति संरचना में बदल जाएगी। मनुष्यों के बीच संचार संस्कृति, अनौपचारिक समझ और अनियमित बातचीत पर निर्भर करता है। लेकिन मनुष्य और AI एजेंट के बीच कोई “अनौपचारिक समझ” नहीं होती — आपको इंटरैक्शन की सीमाओं को स्पष्ट रणनीतियों, नियमों और अधिकारों के माध्यम से परिभाषित करना होगा। प्रबंधन क्षमता, संचार क्षमता के स्थान पर संगठनात्मक डिज़ाइन का केंद्रीय चर बन जाएगी।

दूसरा, संगठनात्मक संरचना आरेख अधिकार आरेख में बदल जाएगा। पारंपरिक संगठनात्मक संरचना आरेख रिपोर्टिंग रिश्तों और कार्य विभाजन का वर्णन करते हैं। AI युग का “आरेख” एक निर्देशित अचक्रीय ग्राफ (DAG) की तरह होता है, जो क्षमताओं और सीमाओं को परिभाषित करता है — कौन सा एजेंट किन डेटा तक पहुँच सकता है, कौन से कार्य कर सकता है, और किन परिस्थितियों में मानवीय अनुमति की आवश्यकता होगी।

तीसरा, संस्थागत ज्ञान मनुष्यों से रणनीतियों में स्थानांतरित हो जाएगा। पिछले समय में, “जब अनुभवी कर्मचारी चले जाते थे, तो ज्ञान भी चला जाता था” — यह हर कंपनी की दर्द भरी समस्या थी। भविष्य में, महत्वपूर्ण ज्ञान AI एजेंट की रणनीतियों और संदर्भों में कोडित हो जाएगा — यह एक अवसर है (ज्ञान अब नहीं खोया जाएगा), साथ ही एक जोखिम भी (अगर रणनीति में त्रुटि होगी, तो वह प्रणालीगत रूप से बढ़ जाएगी)।

प्रत्येक निर्णय के पीछे व्यावसायिक अभ्यास और डेटा का विशाल आधार होता है। उदाहरण के लिए, “संस्थागत ज्ञान स्थानांतरण” के बारे में तीसरा बिंदु, Klarna का मामला एक भयानक और विपरीत उदाहरण प्रस्तुत करता है—उन्होंने 40% कर्मचारियों को निकाल दिया, लेकिन बाद में पाया कि AI प्रणाली उन कर्मचारियों द्वारा ले जाए गए अंतर्निहित ज्ञान को संभाल नहीं पा रही थी, और उन्हें फिर से लोगों को भर्ती करना पड़ा। हम इस कहानी को अगले नौवें लेख, “Klarna की सीख” में पूरी तरह से विस्तार से देखेंगे।

第一条和第二条判断，并非只有我们这么看。2026 年 7 月，a16z 播客《Software in the Age of Agents》中，a16z 企业团队合伙人 Seema Amble 和前微软 Windows 总裁 Steven Sinofsky，从一线投资观察中得出了高度一致的结论。Steven 一句话点透了判断一的要害——“企业软件最大的网络效应不在公司之间，而在公司内部”（The biggest network effect in enterprise software is inside of a company）：组织内部那张由人际、流程、系统织成的网，才是真正的粘性所在。agent 没法靠”默契”接入这张网，只能靠明确的策略和权限——这正是”沟通结构变为策略结构”的现实推力。Seema 则从 agent 访问企业系统的角度印证了判断二：当一个 agent 要去”执行”（写入系统记录、改动账务），它立刻撞上身份、凭证、计费席位、审批权限这一整套问题——组织架构图，正在被改写成一张”谁能访问什么、谁授权什么”的权限图。这两个判断不是预测，而是一线投资人正在投的项目里已经发生的事。（嘉宾为 a16z 合伙人 / 前微软高管，VC 立场。）

पाँचवाँ: अपने संगठन द्वारा कौन सी “कॉन्वे गलती” की जा रही है? अगर आप यहाँ तक पढ़ चुके हैं और अभी भी सोच रहे हैं “मुझे ये सब पता है”, तो मैं आपको एक अभ्यास करने के लिए कहना चाहूँगा।

नीचे हमने कॉन्वे के नियम और उसके विस्तारित अध्ययनों के आधार पर पाँच सामान्य “संगठन-आर्किटेक्चर असंगति” पैटर्न तैयार किए हैं। अपनी कंपनी के साथ इन्हें मिलाएँ और देखें कि कितने बिंदु आप पर लागू होते हैं:

• ❶ सतही माइक्रोसर्विसेज: कोड तो बंट गया, लेकिन 50 लोग अभी भी एक ही ग्रुप में झगड़ रहे हैं।
• ❷ मिडलेयर भ्रम: मिडलेयर सभी बिजनेस लाइनों के लिए संचार का बाधा बन गया है।
• ❸ AI द्वीप: AI टीम द्वारा विकसित मॉडल बिजनेस में एम्बेड नहीं हो पा रहे, क्योंकि संगठनात्मक रूप से “अलग रास्ते” पर हैं।
• ❹ दूरस्थ सहयोग का पतन: भौतिक अलगाव के कारण अनावश्यक सिस्टम विभाजन हुआ है।
• ❺ अधिग्रहण का पाचन विफलता: संगठनात्मक संस्कृति की असंगति के कारण तकनीकी एकीकरण विफल हो गया।

अगला कदम

यह “AI युग के सॉफ़्टवेयर इंजीनियरिंग परिवर्तन” श्रृंखला के 15 लेखों में से पहला है। हमने कॉन्वे के नियम से शुरुआत की और एक मूलभूत समझ विकसित की है: संगठनात्मक आर्किटेक्चर सिस्टम आर्किटेक्चर को निर्धारित करता है—यह रूपक नहीं, बल्कि प्रमाणित कारण-परिणाम संबंध है।

लेकिन इस नियम को जानना केवल शुरुआत है। वास्तविक सवाल यह है: क्या हम इसे उल्टा इस्तेमाल कर सकते हैं? इच्छित सिस्टम आर्किटेक्चर को निर्देशित करने के लिए जानबूझकर संगठनात्मक संरचना को डिज़ाइन करना — यही “इनवर्स कॉन्वे मैन्यूवर” (Inverse Conway Maneuver) का मूल विचार है।
अगले लेख में, टीम टॉपोलॉजीज — पोस्ट-एजाइल एपोच की संगठनात्मक डिज़ाइन मेथडोलॉजी, हम Matthew Skelton और Manuel Pais के काम को गहराई से देखेंगे, जिन्होंने इस विचार को चार बेसिक टीम टाइप्स, तीन इंटरैक्शन मॉडल्स, और एक गहराई से नज़रअंदाज़ किए जाने वाले अवधारणा — “कॉग्निटिव लोड” — के साथ एक पूर्ण, क्रियाशील मेथडोलॉजी में विकसित किया। Netflix, Adidas, Accenture जैसी कंपनियों के प्रैक्टिकल केसेस दिखाएंगे कि इनवर्स कॉन्वे मैन्यूवर किन परिस्थितियों में काम करता है और किन परिस्थितियों में असफल हो जाता है।

सीरीज़ नोट: यह सीरीज़ AI प्रोग्रामिंग टूल्स, संगठनात्मक संरचनाओं और सॉफ्टवेयर इंजीनियरिंग पैराडाइम्स के नवीनतम विकास का अनुसरण करती रहेगी, जैसे 2026 में AI एजेंट युग में कॉन्वे के नियम के नए रूप, या नवीनतम टूल इकोसिस्टम की परिपक्वता। इस सीरीज़ को फॉलो करें ताकि आपको निरंतर अपडेट्स और गहन अंतर्दृष्टि मिल सके।

इस सीरीज़ के बारे में

“AI युग में सॉफ्टवेयर इंजीनियरिंग का परिवर्तन” उद्योग तकनीकी निर्णय लेने वालों के लिए एक गहन अनुसंधान श्रृंखला है, जिसमें 15 लेख शामिल हैं। 200+ शोध पत्रों और उद्योग रिपोर्ट्स के व्यवस्थित अध्ययन के आधार पर, यह आपको साक्ष्य स्तर के साथ चिह्नित निर्णय संदर्भ प्रदान करता है। अधिक सामग्री के लिए कृपया प्रतीक्षा करें।

संदर्भ स्रोत:

• Conway, M. (1968). How Do Committees Invent? Datamation, 14 (4), 28-31.
• Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
• MacCormack, A., et al. (2012). Exploring the Duality between Product and Organizational Architectures: A Comparative Study of Commercial and Open Source Software. Harvard Business School Working Paper.
• Nagappan, N., et al. (2008). The Influence of Organizational Structure on Software Quality. ICSE ‘08 Proceedings.
• Forsgren, N., et al. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
• Fowler, M. (2022). Conway’s Law. Martinfowler.com/bliki/ConwaysLaw.html.
• Gartner (2025/26). Predicts 2026: AI Agents in Software Engineering.
• a16z (2026). Software in the Age of Agents. The a16z Podcast. (Steven का जुम्मा: “The biggest network effect in enterprise software is inside of a company” + Seema Amble का अवलोकन कि एजेंट्स उद्यम प्रणालियों तक पहुँचने पर प्राधिकरण/पासवर्ड/बिलिंग सीट्स से टकराते हैं — जो अनुच्छेद 4 के निष्कर्ष 1 और 2 को समर्थित करता है; प्राथमिक स्रोत — पॉडकास्ट का मूल ऑडियो। स्थिति चिह्नित: a16z पार्टनर / पूर्व माइक्रोसॉफ्ट एक्जीक्यूटिव, VC दृष्टिकोण। अतिथि पुष्टि किए गए: a16z एंटरप्राइज टीम पार्टनर Seema Amble, पूर्व माइक्रोसॉफ्ट Windows अध्यक्ष Steven Sinofsky (board partner), a16z लेखक Elena Burger; प्रसारण 2026 जुलाई।)