सॉफ्टवेयर टीमों की अर्थशास्त्र: ज़्यादातर इंजीनियरिंग संगठन वित्तीय रूप से ‘आंखों पर पट्टी बांधे’ क्यों चलते हैं

• ज़्यादातर इंजीनियरिंग संगठन टीम-स्तर की लागत और वैल्यू क्रिएशन को संख्यात्मक रूप से समझे बिना काम कर रहे हैं, और इससे वित्तीय अक्षमता पैदा होती है
• 8 लोगों की टीम की वार्षिक लागत लगभग €10.4 लाख (मासिक €87,000, दैनिक €4,000) होती है, इसलिए फीचर डेवलपमेंट या सुधार में देरी जैसी हर निर्णय का स्पष्ट आर्थिक प्रभाव होता है
• आंतरिक प्लेटफ़ॉर्म टीम और ग्राहक-उन्मुख प्रोडक्ट टीम, दोनों के लिए break-even और 3~5x वैल्यू क्रिएशन मानक निकाले जा सकते हैं, लेकिन वास्तव में इन्हें ट्रैक करने वाले संगठन बहुत कम हैं
• पिछले 20 वर्षों की कम ब्याज दर और growth-first संस्कृति ने वित्तीय अनुशासन को कमजोर किया, जिससे बड़े संगठन और जटिल codebase asset नहीं बल्कि liability में बदल गए
• LLM के आगमन ने इस संरचनात्मक अक्षमता को उजागर किया है, और टीम-दर-टीम लागत, वैल्यू और लाभप्रदता को मात्रात्मक रूप से मापने वाले संगठन लंबी अवधि का प्रतिस्पर्धात्मक लाभ हासिल करेंगे

---

सॉफ्टवेयर टीमों की अर्थशास्त्र: ज़्यादातर इंजीनियरिंग संगठन वित्तीय रूप से ‘आंखों पर पट्टी बांधे’ क्यों चलते हैं

• सॉफ्टवेयर डेवलपमेंट की लागत संरचना और टीम-स्तर की आर्थिक व्यवहार्यता का संख्यात्मक विश्लेषण करने पर पता चलता है कि ज़्यादातर संगठन इस डेटा को समझे बिना ही काम कर रहे हैं
• 8 लोगों की टीम के आधार पर सालाना लगभग €10.4 लाख (मासिक €87,000) खर्च होता है, जो प्रतिदिन लगभग €4,000 के बराबर है
• आंतरिक प्लेटफ़ॉर्म टीम और ग्राहक-उन्मुख प्रोडक्ट टीम, दोनों के लिए break-even पार करने के लिए आवश्यक वैल्यू क्रिएशन निकाला जा सकता है, लेकिन वास्तव में इसे ट्रैक करने वाले संगठन लगभग नहीं के बराबर हैं
• पिछले 20 वर्षों के कम ब्याज दर वाले माहौल और growth-first संस्कृति ने वित्तीय अनुशासन को कमजोर किया, जिससे बड़े इंजीनियरिंग संगठन और जटिल codebase को गलती से ‘asset’ समझ लिया गया
• LLM (large language model) के आगमन ने इन संरचनात्मक अक्षमताओं को उजागर कर दिया है, और जो संगठन हर टीम की लागत और वैल्यू क्रिएशन को साफ़ तौर पर मापते हैं, वे प्रतिस्पर्धात्मक बढ़त हासिल करेंगे

वास्तविक टीम लागत संरचना

• पश्चिमी यूरोप के आधार पर एक सॉफ्टवेयर इंजीनियर की प्रति व्यक्ति वार्षिक कुल लागत €120,000~€150,000, औसतन €130,000 है
  • इसमें वेतन, social security, pension, उपकरण, management overhead, office space आदि शामिल हैं
• 8 लोगों की टीम की कुल वार्षिक लागत €1,040,000, मासिक €86,667, दैनिक €4,000 है
• ज़्यादातर इंजीनियर और मैनेजर भी इन संख्याओं को नहीं जानते, और प्राथमिकता तय करने की प्रक्रिया में लागत की समझ शामिल नहीं होती
• फीचर डेवलपमेंट, सुधार में देरी, प्लेटफ़ॉर्म का पुनर्निर्माण—हर निर्णय के साथ स्पष्ट आर्थिक लागत जुड़ी होती है
  • उदाहरण: 3 हफ़्तों तक 2% users के लिए फीचर बनाना लगभग €60,000 का निर्णय है

आंतरिक प्लेटफ़ॉर्म टीम का break-even कैलकुलेशन

• मान लें कि 8 लोगों की प्लेटफ़ॉर्म टीम 100 इंजीनियरों को सपोर्ट करती है
  • मासिक लागत €87,000 है, और इसे उचित ठहराने के लिए उतनी ही वैल्यू पैदा करनी होगी
• प्रति इंजीनियर मासिक लागत €10,800 (प्रति घंटा €65) है
  • 100 लोगों के स्तर पर हर महीने 1,340 घंटे की बचत (प्रति व्यक्ति प्रति सप्ताह 3 घंटे) होने पर break-even हासिल होता है
• सिर्फ समय बचत ही नहीं, बल्कि incidents में कमी से सीधे revenue protection का असर भी हो सकता है
• लेकिन ज़्यादातर टीमें इन संख्याओं को न तो मापती हैं और न ही निर्णयों में शामिल करती हैं
• वास्तविक वित्तीय स्वास्थ्य के लिए मानक 3~5x वैल्यू क्रिएशन (मासिक €260,000~€430,000) होना चाहिए
  • इसमें सिस्टम maintenance/replacement cost और failure rate (50~70%) को ध्यान में रखना होगा
  • केवल ‘break-even’ नहीं, बल्कि सस्टेनेबल लाभप्रदता ज़रूरी है

ग्राहक-उन्मुख प्रोडक्ट टीम पर भी यही तर्क लागू होता है

• ग्राहक-उन्मुख 8 लोगों की टीम की भी मासिक लागत €87,000 है
  • यदि प्रति user मासिक revenue €50 है, तो break-even के लिए 1,740 users के बराबर वैल्यू चाहिए, और 3~5x मानक के लिए 5,000~8,700 users के बराबर वैल्यू चाहिए
• churn में सुधार सबसे सीधा lever है
  • उदाहरण: 50,000 users में मासिक 2% churn (1,000 users, €50,000 नुकसान) → यदि कारण दूर कर दिया जाए तो break-even का बड़ा हिस्सा पूरा हो सकता है
• activation rate में सुधार भी महत्वपूर्ण है
  • मासिक 10,000 नए users में केवल 30% activate होते हैं → 5%p सुधार होने पर 500 अतिरिक्त conversion, €25,000 अतिरिक्त revenue
• conversion rate में बढ़ोतरी का असर भी वैसा ही है
  • 20,000 trials में 4%→4.5% conversion होने पर 100 अतिरिक्त paid users, €5,000 अतिरिक्त revenue
• कई metrics में छोटे-छोटे सुधार मिलकर बड़ा वित्तीय असर पैदा कर सकते हैं, लेकिन ज़्यादातर टीमें इन metrics और वित्तीय परिणामों के बीच का संबंध नहीं मापतीं

वित्तीय मापन क्यों नहीं किया जाता

• कई टीमें सिर्फ velocity, टिकट की संख्या, फीचर्स की संख्या, NPS, CSAT जैसे activity और sentiment metrics को ट्रैक करती हैं
  • ये वित्तीय metrics के विकल्प नहीं, बल्कि पूरी तरह अलग श्रेणी हैं
• activity metrics बेहतर होने पर भी वित्तीय प्रदर्शन खराब हो सकता है
  • फीचर्स की संख्या बढ़ी → हो सकता है गलत फीचर्स बने हों
  • engagement बढ़ा → हो सकता है revenue देने वाले users घट गए हों
• इन metrics को इसलिए चुना जाता है क्योंकि इन्हें मापना, रिपोर्ट करना और performance को आकर्षक दिखाना आसान है
  • वित्तीय metrics असहज सच सामने ला सकते हैं
• ज़्यादातर संगठन पारदर्शी वित्तीय मापन की संस्कृति जानबूझकर नहीं बनाते

पिछले 20 वर्षों की पृष्ठभूमि

• 2002~2011: ब्याज दरें कम थीं, लेकिन निवेशकों की risk aversion के कारण वित्तीय अनुशासन बना रहा
• 2011~2022: zero interest rates, risk appetite की वापसी, और SaaS growth logic एक साथ आए
  • 11 वर्षों तक कंपनियों को तेज़ growth के कारण तेज़ hiring, कम efficiency और गलत priorities के बावजूद माफ़ किया जाता रहा
• इस दौर में बनी leadership generation ऐसे माहौल में पली-बढ़ी जहाँ वित्तीय प्रदर्शन की सख़्त मांग नहीं थी
  • इसलिए 2022 के बाद capital cost बढ़ने पर भी व्यवहार अपने-आप नहीं बदला

‘asset’ समझे गए इंजीनियरिंग संगठनों का debt

• बड़े codebase और इंजीनियरिंग संगठन पारंपरिक रूप से asset माने जाते रहे हैं
  • संचित business logic, तकनीकी आधार, संगठनात्मक क्षमता आदि के कारण
• लेकिन वास्तव में ये maintenance burden, coordination cost और decision delay जमा करते हुए liability जैसी संरचना बन जाते हैं
  • जटिलता बढ़ने से productivity घटती है, लागत बढ़ती है और revenue ठहर जाता है
• पहले कम ब्याज दर वाला माहौल इस debt को छिपाए रखता था

• LLM ने जो वास्तविकता उजागर की

  • डेवलपर Nathan Cavaglione ने LLM agent का उपयोग करके 14 दिनों में Slack की मुख्य functionality का 95% कॉपी कर लिया
  • Slack को हज़ारों इंजीनियरों ने 10 साल से अधिक समय तक बनाया, और उस पर अरबों यूरो का निवेश हुआ
  • Nathan ने संगठनात्मक जटिलता, मौजूदा architecture और coordination cost के बिना कम समय में समान प्रोडक्ट पूरा कर लिया
  • यह दिखाता है कि बड़े संगठनों का scale, complexity और accumulated code ही competitive advantage हैं—यह धारणा अब वैध नहीं रही
  • LLM-जनित code की maintainability से जुड़ी समस्याएँ मौजूद हैं, लेकिन agent-to-agent माहौल में यह मानवीय maintenance की तुलना में लागत और गति दोनों में बेहतर हो सकता है

आगे बढ़ने वाले संगठनों की शर्तें

• प्रतिस्पर्धा का मूल तकनीक नहीं बल्कि analytical capability है
  • जो संगठन हर टीम की cost, value और profitability threshold को स्पष्ट रूप से समझते हैं, वे संरचनात्मक बढ़त में रहेंगे
• ऐसे संगठन निम्न काम कर सकते हैं
  • Build vs Buy का निर्णय वास्तविक economics के आधार पर लेना
  • लाभप्रदता सीमा से नीचे चल रही टीमों की पहचान करना
  • देरी से होने वाले value loss को मात्रात्मक रूप से मापकर priorities बदलना
• ज़्यादातर संगठनों के पास अभी measurement infrastructure, data flow और habits नहीं हैं
  • इन्हें बनाना असुविधाजनक है, लेकिन ज़रूरी है
  • इससे यह पता चल सकता है कि टीम ने पूरी तिमाही ऐसे काम में खर्च कर दी जिसका कोई वित्तीय संबंध ही नहीं था
• पहले कम ब्याज दर और growth-first logic इसे सहन कर लेते थे, लेकिन AI से डेवलपमेंट कॉस्ट तेजी से गिरने और निवेशकों द्वारा वित्तीय नतीजे माँगने वाले माहौल में यह टिकाऊ नहीं है
• जिन संगठनों में टीम-स्तर की economics को स्पष्ट रूप से पूछने और मापने की आदत होती है, वे समय के साथ compound होने वाला प्रतिस्पर्धात्मक लाभ जमा करते जाते हैं

[GN⁺]

Hacker News की राय

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

  • मुझे नहीं लगता कि यह बात हमेशा सही है। कुछ प्रोजेक्ट्स में क्या बनाना है यह साफ़ होता है, लेकिन engineering की कठिनाई ही बेहद ज़्यादा होती है
    अगर सिर्फ framework जोड़ने हों तो आसान हो सकता है, लेकिन जटिल systems वाले माहौल में प्रोग्रामिंग खुद ही सचमुच कठिन काम है
  • बहुत सा software वास्तव में value create नहीं करता, बल्कि उसे कम कर देता है
    मैंने अक्सर देखा है कि एक साधारण request एक बहुत बड़े system में बदल जाती है। लेकिन Google की तरह अगर infrastructure में समझदारी से निवेश किया जाए, तो competitive advantage मिल सकता है
  • यह concept engineering के बाहर भी मौजूद है। इंटरनेट पर जैसा कहा जाता है, “गलत जवाब पोस्ट करो तो सही जवाब जल्दी मिलता है”, वैसे ही गलत कोशिशें कभी-कभी बेहतर insight देती हैं
    लेकिन ऐसा approach अक्सर अलाभकारी दिखता है, या लोगों को लगता है कि आप “गलत बात कहने वाले” व्यक्ति हैं
  • प्रोग्रामिंग सबसे कठिन चीज़ न भी हो, फिर भी यह आसान काम नहीं है, यह नहीं भूलना चाहिए
  • नए developers के लिए यह बात सही हो सकती है, लेकिन अनुभवी engineers पहले से जानते हैं कि चीज़ें efficiently कैसे बनानी हैं
    बहुत से developers को लगता है कि उनका प्रोजेक्ट खास है, जबकि अक्सर पहले से validated design को copy करना ही काफ़ी होता है

• लेख में जैसा कहा गया है, अगर code तेज़ी से generate हो तो उसे manage करना मुश्किल होगा—यह चिंता सही है, लेकिन अगर इंसान उसे maintain नहीं कर रहे हों तो यह कम महत्वपूर्ण हो जाता है
  लेकिन मुझे लगता है कि यही logic “agile coach LLM” पर भी लागू हो सकता है। LLM पहले से ही ज़्यादातर insights बहुत सस्ते में दे सकता है
  आख़िरकार इंसान शायद pool के किनारे आराम कर सकें

  • अगर AGI मेरा काम replace कर दे, तब भी verification और accountability मेरी ज़िम्मेदारी रहेगी। अगर management layers ख़त्म हो जाएँ, तो शायद चीज़ें और शांतिपूर्ण हो जाएँ
  • आजकल LLM पर ज़्यादातर लेख ऐसे लगते हैं जैसे LLM ने ही लिखे हों। बिक रहे training materials भी शायद एक prompt line से replace किए जा सकते हैं
  • अब हम ऐसे दौर में हैं जहाँ सीखने की लागत लगभग शून्य है, और instructor की भूमिका बस सीखने के लिए मजबूर करना रह गई है

• मैं इस दावे से सहमत नहीं हूँ कि “messy codebase में कई agents डाल दो, सब ठीक हो जाएगा”
  वास्तव में बहुत सा code बाहर से perfect दिखता है, लेकिन अंदर से foam से बनी इमारत की तरह structurally गलत होता है
  ऐसा code समय के साथ बढ़ाया नहीं जा सकता और आख़िर में ईंट की तरह सख़्त हो जाता है

  • अगर पर्याप्त architecture design और guardrails हों तो agents भी अच्छे से काम कर सकते हैं। वरना इंसानी बारीक निगरानी ज़रूरी है
  • अगर agents बहुत “smart code” लिखें, तो फिर debugging कौन करेगा, यह सवाल उठता है
  • “कला ही भार को सहारा देती है” वाली अभिव्यक्ति सचमुच प्रभावशाली थी
  • management का यह मान लेना कि AI सब कुछ हल कर देगा, खतरनाक भ्रम है। सिर्फ computing power से सब हल नहीं होता
  • अगर ऐसी समस्या आती है, तो क्या testing system में ही कुछ missing नहीं है?

• मेरे साथ भी AI द्वारा बनाए गए दो प्रोजेक्ट पूरी तरह फेल होने का अनुभव रहा है
  और agents जोड़ने पर भी कोई प्रगति नहीं हुई, और बने हुए नतीजे ज़्यादातर ग़लत दिशा में थे

  • मेरा भी ऐसा ही अनुभव है। मैंने 40,000 से ज़्यादा lines का code delete किया। AI द्वारा लिखा code लगभग हमेशा गलत abstraction इस्तेमाल करता है
  • यह कुछ हद तक Mythical Machine Month जैसा phenomenon लगता है। इंसानों की जगह मशीनें बढ़ाने से productivity नहीं बढ़ती
  • AI के साथ काम करते हुए अक्सर इंसानी attention failure जैसे patterns दिखते हैं। आख़िरकार यह context और focus की समस्या है
  • code की ownership अब भी इंसानों की ही है। AI के बनाने से उसकी ज़िम्मेदारी ख़त्म नहीं होती
  • AI भी technical debt में इंसानों से अलग नहीं फँसता। बस इसमें rewrite आसान करने वाले tool के रूप में संभावना है

• मैं इस बात से सहमत हूँ कि “software development एक capital-intensive activity है”, लेकिन हर industry का context अलग होता है
  power companies या manufacturers के लिए IT की तुलना में physical infrastructure maintenance cost कहीं ज़्यादा होती है
  फिर भी SaaS contracts इतने बढ़ गए हैं कि कई कंपनियाँ सोच रही हैं कि LLM developers को hire करना ज़्यादा किफ़ायती होगा या नहीं

  • transport authority जैसी public institutions में भी SaaS spending को लेकर यह समझ बनने लगी है कि वह ज़रूरत से ज़्यादा है। आख़िरकार जब management को पता चलेगा, तो बहुत से अनावश्यक contracts हटा दिए जाएँगे
  • लेकिन SaaS पूरी तरह ग़ायब नहीं होगा। क्योंकि accountability और legal risk संभालने वाला ढाँचा चाहिए
  • pharmaceutical plants की construction cost ही कई billions of dollars होती है। ऐसे industries में software cost बहुत मामूली होती है

• लेख दिलचस्प लग रहा था, लेकिन Slack clone उदाहरण पर मेरा भरोसा उठ गया
  यह दावा Slack की असली scale, reliability और functionality को बिल्कुल नहीं समझता

  • Slack ऐसा product नहीं है जिसे बस copy कर लिया जाए। यह countless trial-and-error और product sense का नतीजा है
  • “95% clone” वाली बात पर ही भरोसा टूट गया
  • college students भी Twitter clone बना लेते हैं, लेकिन असली competition code नहीं, बल्कि market और ecosystem है
  • मैं भी 2 हफ़्तों में Slack clone बना सकता हूँ, लेकिन सिर्फ legal hold feature को ठीक से implement करने में ही कई महीने लग जाएँगे
    enterprise product में ऐसे सैकड़ों detailed features ज़रूरी होते हैं। साधारण cloning competition नहीं है
  • Slack बनाना सिर्फ coding नहीं था, बल्कि क्या बनाना है यह खोजने की प्रक्रिया थी

• जो लेख सिर्फ numbers और graphs फेंकता है, वह बहस जीतने की कोशिश करने वाले व्यक्ति का लेख लगता है
  Rory Sutherland के शब्दों में, “Finance People” certainty और predictability पर अटके रहते हैं
  लेकिन दुनिया इतनी सरल नहीं है

  • precise calculation का side effect यह है कि वह problem decomposition में मदद करती है। लेकिन आख़िर में market पर कब्ज़ा गहरी समस्या-समझ और vision से होता है
  • उसकी math वास्तविकता से मेल नहीं खाती। product की success unpredictable है, और investment खुद एक जुआ है
  • सच हमेशा बीच में कहीं होता है। numbers और instinct के बीच संतुलन चाहिए
  • जिन teams के पास सही measurement tools और metrics होते हैं, वे लंबे समय में बेहतर परिणाम देती हैं
  • फिर भी कम-से-कम यह hypothesis तो बनानी ही चाहिए कि कोई feature revenue पर क्या असर डालेगा, तभी sustainable business बन सकता है

• लेख के details से ज़्यादा, मैं इस बात से जुड़ा महसूस करता हूँ कि engineering culture cost बनाम value पर सोचती ही नहीं
  meetings या incident response के दौरान अक्सर cost-effectiveness देखे बिना ज़रूरत से ज़्यादा कदम उठा लिए जाते हैं
  technical debt में भी यही बात लागू होती है—अगर cost पता ही न हो, तो ज़िम्मेदार चुनाव नहीं किए जा सकते

  • meetings से भी बड़ा waste है गलत project या feature। वह maintenance और complexity को अंतहीन रूप से साथ घसीटता है

• “platform team को समय बचत के ज़रिए अपनी value साबित करनी चाहिए” वाला सीधा हिसाब ग़लत है
  platform team सिर्फ समय नहीं बचाती, बल्कि business risk कम करती है और core quality सुनिश्चित करती है

  • platform team के होने का कारण दोहराए गए प्रयासों को centralize करना और security व operations के विभाजन को बनाए रखना है
    यह सिर्फ साधारण economic logic नहीं, बल्कि organization की essential infrastructure का सवाल है

• आख़िर में सबसे महत्वपूर्ण बात यह है कि क्या team सच में product की परवाह करती है
  जो team अल्पकालिक career से ऊपर product को रखती है, वही metrics या management techniques से आगे जाकर सचमुच परिणाम देती है
  लेकिन कुछ projects की संरचना ही ऐसी होती है कि उनसे लगाव पैदा करना मुश्किल होता है, इसलिए productivity की सीमा साफ़ दिखती है