Big Companies Hi | मूल
audio: false generated: false image: false lang: hi layout: post title: बड़े कंपनियों पर translated: true —बड़े कंपनियाँ बड़ी प्रोग्रामों की तरह ही होती हैं। 100,000 कर्मचारियों और 50,000 कॉन्ट्रैक्टर्स वाली एक बड़ी कंपनी 150,000 मेथड्स वाली एक बड़ी प्रोग्राम की तरह होती है।
डारियो अमोडी ने कहा कि टैलेंट डेंसिटी की संख्या से बहुत ज्यादा महत्वपूर्ण होती है। दो सौ बहुत टैलेंटेड लोग 1,000 टैलेंटेड लोगों और 800 साधारण लोगों को हरा सकते हैं।
डारियो अमोडी ने यह भी उल्लेख किया कि बड़ी कंपनियों में इतनी प्रक्रियाएँ और प्रक्रियाएँ होती हैं क्योंकि वे अपने कर्मचारियों या कॉन्ट्रैक्टर्स पर भरोसा नहीं करते। इसलिए उन्हें बहुत सारी जांच और नियंत्रण की आवश्यकता होती है।
बड़ी कंपनियों के बारे में एक बात यह है कि वे गलतियों से डरते हैं। एक कारण यह है कि वे इतनी बड़ी हो गई हैं कि वे 300 बिलियन या 1 ट्रिलियन डॉलर के मूल्य के हैं; उन्हें तो बहुत सारी गलतियाँ करनी पड़ी होंगी और वे उनसे सीखकर बढ़ी होंगी। हालाँकि, जब वे सफल होते हैं, तो वे जोखिम लेने और गलतियाँ करने से बचते हैं।
यह एक बड़ी प्रोग्राम की तरह है जो बग्स से नफरत करता है और विशेष रूप से सुरक्षा बग्स को खत्म करने की कोशिश करता है, विशेष रूप से बड़े बैंकों में।
स्टार्टअप तेज होते हैं, लेकिन स्टार्टअप के पास संसाधन बहुत कम होते हैं, और स्टार्टअप का ब्रांड स्थापित नहीं होता; उन्हें बड़ी कंपनियों का भरोसा नहीं होता।
चीन में, युवा टैलेंटेड लोग अभी भी स्नातक होने के बाद बड़ी कंपनियों में जाना चाहते हैं और इसके लिए संघर्ष करते हैं। सिलिकॉन वैली में, बहुत सारे स्टार्टअप हैं, जिनमें से कुछ तो बस आइडियाओं के साथ ही शुरुआत में ही अच्छा काम कर रहे हैं।
कुछ कंपनियाँ 20 साल तक चलती हैं और अभी भी संघर्ष करती हैं, शायद स्टॉक मार्केट से हटा दी गई हैं, और कुछ कंपनियाँ तो बस कुछ महीनों में ही 5 बिलियन या 10 बिलियन डॉलर की कीमत की होती हैं।
यह कहा गया है कि Mira Murati’s Thinking Machines Lab को सीड राउंड में $12B का मूल्य है। और Ilya Sutskever’s Safe Superintelligence ने $2B जुटाए हैं और $32B का मूल्य है।
इसलिए स्टार्टअप को मापने के लिए स्थापित समय का उपयोग करना अच्छा संकेतक नहीं है; यह बेहतर है कि इसे टीम के बारे में, फाउंडर्स के बारे में, और वे किस क्षेत्र में हैं, इसके आधार पर मापा जाए।
मेरे सोलो स्टार्टअप में, मुझे बस 1 मिनट में अपना बैकएंड सर्वर डिप्लॉय करने की आवश्यकता होती है और 5 मिनट में एक छोटी सी बग को ठीक करने और डिप्लॉय करने की। यह सीधा और तेज है। बड़ी कंपनियों के लिए, डिप्लॉयमेंट रिक्वेस्ट की तैयारी करने में 1 सप्ताह लग जाता है, मैनेजर्स से अनुमोदन प्राप्त करना, आईटी टीम के साथ डिप्लॉयमेंट करना, और हेल्थ चेक करना।
हालाँकि वास्तविक समय जो खर्च होता है वह 8 घंटे का होता है, लेकिन अगर हम मापें, तो फिर भी डिप्लॉयमेंट की तैयारी से लेकर अंतिम हेल्थ चेक तक 1 सप्ताह का समय लगता है।
एक छोटी सी बग को ठीक करने और डिप्लॉय करने में दो सप्ताह लग जाते हैं। आपको टिकट मिलता है, जांच करना, विश्लेषण और परीक्षण करना, फिर समीक्षा करना, कोड मर्ज करना, टेस्ट टीमों को टेस्ट करने के लिए रिपोर्ट करना, और फिर डिप्लॉय करना।
बड़ी कंपनियाँ सभी टीमों या प्रोजेक्ट्स पर अपने नीतियों को लागू करने का प्रयास करती हैं। क्योंकि 200,000 लोगों वाली एक बड़ी कंपनी के लिए, वे नीतियाँ या आंतरिक प्रक्रियाएँ जो केवल 10,000 लोगों पर लागू होती हैं, उन्हें बहुत महत्व या परिणाम नहीं देतीं। कुछ आंतरिक प्रक्रियाओं के लिए, बड़ी कंपनियों को लोगों या पैसे का निवेश करना पड़ता है ताकि उन्हें समर्थन करने के लिए उपकरण विकसित किए जा सकें। इसलिए अगर यह केवल कर्मचारियों के एक छोटे अनुपात को सेवा देता है, तो निवेश का रिटर्न इसे न्यायोचित नहीं ठहराता।
बड़ी कंपनियों का एक और नुकसान यह है कि अक्सर कोई भी बड़ी गलतियों के लिए दंडित नहीं होता।
मेरे स्टार्टअप में, मुझे आधा मिलियन डॉलर का निवेश मिला था ताकि मैं 9 लोगों को भर्ती कर सकूं, और दो महीने बाद मुझे उन्हें छोड़ना पड़ा और वह पैसा गंवाना पड़ा। मैंने 50 छोटी सॉफ्टवेयर प्रोजेक्ट्स पार्ट-टाइम इंजीनियर्स के साथ कीं ताकि मैं उस पैसें को वापस कमा सकूं और निवेशक को दे सकूं।
यह एक बहुत ही तीव्र और दर्दनाक याद है। और यह मुझे हमेशा उस सबक को याद दिलाता है।
एक बड़े कॉर्पोरेशन के भीतर एक उल्लेखनीय मामले में, यह देखा गया कि उन लोगों के लिए कोई महत्वपूर्ण परिणाम नहीं हुए। कुछ सीनियर मैनेजर्स और हाल ही में भर्ती किए गए कर्मचारियों को छोड़ दिया गया। यह स्पष्ट नहीं है कि क्या यह एक तेज और महत्वपूर्ण भर्ती स्प्री के साथ संबंधित था।
इस परिणाम का एक योगदान कारक बड़े कंपनियों के भीतर कष्टदायक और कई प्रक्रियाएँ हैं। जो इंजीनियर्स छह महीने से एक साल तक कंपनी में रहे, वे कोई महत्वपूर्ण योगदान नहीं कर पाए। समयरेखा आमतौर पर दो महीने बुनियादी बातों को समझने के लिए, तीन महीने प्रोजेक्ट्स से परिचित होने के लिए, तीन महीने कष्टदायक प्रक्रियाओं या परीक्षणों से गुजरने के लिए, और अंत में, दो महीने उपयोगकर्ताओं को प्रभावित करने वाले उत्पादक काम के लिए होती थी।
आठ घंटे के कार्यदिवस की मान्यता के साथ, दो महीने के वास्तविक उत्पादक काम से महत्वपूर्ण परिणाम नहीं मिले। विभाग का बजट खत्म हो गया, और उपयोगकर्ता बेस जैसा कि उम्मीद थी, बढ़ा नहीं। इसके परिणामस्वरूप और अधिक छंटनी हुई।
लगता है कि इस अनुभव से कोई मूल्यवान सबक नहीं सीखा गया। शुरू में, एक समूह मैनेजर्स ने एक तेज और व्यापक भर्ती रणनीति पर सहमति व्यक्त की, जो उस समय अनावश्यक लग रही थी। पूरे समूह के मैनेजर्स को दोष देना संभव नहीं था, न ही यह व्यावहारिक था कि केवल उन लोगों को निकाल दिया जाए जो कंपनी में कम समय से थे, विशेष रूप से जब अन्य मैनेजर्स और तकनीकी लीड्स छह से आठ साल तक टीम का हिस्सा रहे हों।
मैनेजिंग डायरेक्टर को इस स्थिति से बहुत कम अंतर्दृष्टि मिली, क्योंकि यह उनके तीन विभागों में से एक था, और उनका वेतन अपरिवर्तित रहा। टीम के भीतर, जो लोग सीधे जिम्मेदार नहीं थे, वे इस अनुभव से सीख नहीं पाए, जो स्टीव जॉब्स के कंसल्टिंग पर टिप्पणियों को दोहराते हैं। परिणामस्वरूप, कोई भी उस सबक को नहीं सीखा जो एक असाधारण टीम बनाने के लिए आवश्यक था जो उपयोगकर्ताओं के लिए उत्कृष्ट परिणाम दे सके।
स्टार्टअप के लिए, यह बहुत बेहतर लग रहा है। क्योंकि यह वास्तव में गंभीर है। कुछ फाउंडर्स जो हार जाते हैं या असफल होते हैं, उन्हें वास्तव में बहुत कठिन समय गुजरना पड़ता है, विशेष रूप से ईमानदार लोगों के लिए।
इंटीग्रिटी वाले व्यक्तियों के लिए, यह बहुत निराशाजनक हो सकता है कि वे मिलियन से लेकर हजारों मिलियन डॉलर के निवेश को गंवा दें और अंत में कुछ भी नहीं हो, शायद बस एक बुनियादी उत्पाद या एक उपयोगकर्ता बेस जो, हालांकि बड़ा हो, कम राजस्व उत्पन्न करता हो।
पॉल ग्राहम ने पहले एक निबंध लिखा था, Hiring is Obsolete।
लेकिन बड़ी कंपनियाँ अच्छी तरह से क्या करती हैं? एक है लॉन्ग-टर्मिज्म। वे लंबे समय के लिए चीजें करने की प्रवृत्ति रखते हैं। कुछ अच्छी बड़ी कंपनियों के प्रोजेक्ट डिजाइन काफी अच्छे होते हैं; वे माइक्रोसर्विसेज का उपयोग करते हैं ताकि एक दशक बाद एक बड़ी मोनोलिथिक प्रोग्राम बनने की गलती से बचा जा सके। और उनके पास गवर्नेंस टीमें होती हैं जो कुछ फाउंडेशनल फ्रेमवर्क बनाती हैं और पूरे टीम के लिए विकास प्रथाओं को एकीकृत करती हैं।
प्रक्रियाएँ या प्रक्रियाएँ स्वाभाविक रूप से बुरी नहीं होती हैं। लेकिन वे अक्सर चीजों को जटिल और धीमी बनाती हैं। हम Java यूनिफाइड कोड फॉर्मेट को अप्रिय नहीं मानते क्योंकि Spotless या Checkstyle प्लगइन है जो मदद करता है। ये प्लगइन अच्छे डिजाइन के साथ होते हैं और उपयोग में आसान होते हैं।
एक और बात यह है कि बड़ी कंपनियाँ अक्सर कुछ उपकरण या प्रोजेक्ट्स बनाती हैं जो आंतरिक उपयोग के लिए होते हैं, फ्रंट ऑफिसर्स के लिए। लेकिन वह उपयोगकर्ता बेस बस हजारों या 10,000 होता है। वह उपयोगकर्ता बेस बहुत सीमित होता है।
मैं सोचता हूँ कि हम बेहतर तरीके से बाहरी उपकरणों का उपयोग कर सकते हैं। अगर एक उपकरण एक बैंक के लिए वास्तव में अच्छा है, तो यह 200 बैंकों के लिए भी अच्छा होगा। और यह उस कंपनी को एक यूनिकॉर्न बना सकता है।
टियांचेंग लू, पोनी.एआई के संस्थापक, कहते हैं कि कंपनियों को स्वतंत्र होने की आवश्यकता है क्योंकि यह अधिक कुशल है। यह सच है।
और बड़ी कंपनियाँ अक्सर अनुभव को कर्मचारियों को पुरस्कार देने के लिए उपयोग करती हैं। जबकि बाजार स्टार्टअप टीमों के परिणाम या कार्यान्वयन को पुरस्कार देता है। वे वास्तव में बहुत अलग हैं।
बड़ी कंपनियों में काम करना स्कूल में सीखने के समान है। आप प्राथमिक विद्यालय से मध्य विद्यालय, फिर विश्वविद्यालय तक आगे बढ़ते हैं। स्टार्टअप में, अधिक उतार-चढ़ाव होते हैं, और एक आइडिया या बाजार से दूसरे में जाने में अधिक लचीलापन होता है।
बड़ी कंपनियों का जोखिम से बचने का फायदा यह है कि उनके उत्पाद अपेक्षाकृत स्थिर होते हैं, जिनमें कोई स्पष्ट बग या डाउनटाइम नहीं होता। यह अच्छा है।
लेकिन जैसे कि AI, वास्तव में, बहुत सारे उपयोगकर्ता उन उत्पादों के लिए भी तैयार हैं जो शुरुआत में इतना स्थिर नहीं होते हैं, जैसे कि डीपसीक। हम जानते हैं कि डीपसीक फरवरी-मार्च 2025 के आसपास बहुत बार डाउन हो गया था जब इसे बहुत ध्यान मिला। लेकिन कुछ समय बाद, यह बेहतर हो गया और कोई उपयोगकर्ता इसके बारे में कोई समस्या नहीं दिखाई दी।
तो यह निर्भर करता है। कभी-कभी, नवीन उत्पादों के लिए, हमें उन्हें तेजी से बाजार में लाना चाहिए, भले ही उनमें कुछ समस्याएँ हों। उपयोगकर्ता समझ सकते हैं।
अगर हम प्रक्रिया के बारे में सोचें, तो हम अधिक सावधान हो सकते हैं। हमें अपने डिप्लॉयमेंट प्रकारों को बेहतर ढंग से वर्गीकृत करना चाहिए। कुछ प्रकार के परिवर्तनों को तेजी से डिप्लॉय करना ठीक है, जबकि अन्य नहीं। परीक्षण के लिए, हमें यह निर्धारित करना चाहिए कि परिवर्तित कोड के लिए रिग्रेशन परीक्षण के लिए हमें किन भागों का परीक्षण करना चाहिए, और किन भागों का नहीं। सोनारक्यूब चेकिंग के लिए भी यही लागू होता है।
बड़ी कंपनियों में यह निश्चित है कि बहुत सारी जांच, परीक्षण या अनुमोदन अनावश्यक हैं। हम इंजीनियर्स को अपना काम करने दें, और क्योंकि सिस्टम में सभी रिकॉर्ड हैं, हम कुछ को समीक्षा के लिए चुन सकते हैं।
हम सभी मैनेजर अनुमोदनों को भी समाप्त कर सकते हैं। मैनेजर्स के पास इंजीनियर्स के पास जो ज्ञान नहीं है? क्या यह ज्ञान कोड में लिखकर अनुरोधों को स्वचालित रूप से स्वीकृत या अस्वीकृत करने के लिए लिखा जा सकता है?
क्योंकि वहां सब कुछ धीमा है, कर्मचारी या कॉन्ट्रैक्टर्स बदलने की संभावना कम है। एक दशक से चल रहे प्रोजेक्ट के लिए एक बड़ी मोनोलिथिक प्रोजेक्ट से माइक्रोसर्विसेज में परिवर्तन दो साल तक लग सकता है।
सॉफ्टवेयर के लिए, कोड और लॉजिक एक दूसरे से गहराई से जुड़े होते हैं, विशेष रूप से अच्छी तरह से डिजाइन किए गए सिस्टम में। इसलिए, विकास, परीक्षण या सहयोग में शामिल हो सकता है।
इसलिए टीम को अचानक स्केल करने से अक्सर काम नहीं चलता। अगर एक माइक्रोसर्विस आर्किटेक्चर है जो लूज़ली कूपल्ड है, तो टीम का आउटपुट टीम सदस्यों की संख्या के अनुपात में हो सकता है। अगर एक मोनोलिथिक प्रोजेक्ट है जो टाइटली कूपल्ड है, तो टीम का आउटपुट केवल 30% बढ़ सकता है अगर हम उस पर काम करने वाली टीम की संख्या को दोगुना कर दें।
अपनी धीमी गति के कारण, कभी-कभी यह मुश्किल हो सकता है कि पता लगाना कि एक कर्मचारी या कॉन्ट्रैक्टर्स असमर्थ है या सिस्टम इतना जटिल और कष्टदायक है कि नए जॉइनर्स के लिए। एक मामले में जो मैंने देखा, कोई चार महीने तक कंपनी में रहा और बहुत कम कुछ किया, बस कुछ लाइनें बदलकर एक पुल रिक्वेस्ट सबमिट किया। इसके अलावा, कोड की गुणवत्ता भी खराब थी क्योंकि वह इसे अच्छी तरह से नहीं समझता था। उसका अंग्रेजी भी बहुत कमजोर था, और वह केवल स्क्रीनशॉट्स को पेस्ट करके और बुनियादी अंग्रेजी का उपयोग करके प्रश्न पूछ सकता था।
स्थिरता के बारे में, मैं देखता हूँ कि बड़ी कंपनियाँ अक्सर कई टीम सदस्यों को डुप्लिकेट टास्क्स पर काम करने के लिए करती हैं। उदाहरण के लिए, टास्क A और टास्क B के लिए, वे दो टीम इंजीनियर्स को टास्क A और टास्क B पर अलग-अलग काम करने के लिए नहीं असाइन करते। इसके बजाय, वे दोनों को टास्क A और टास्क B के हिस्सों पर काम करने के लिए करते हैं ताकि ये दो इंजीनियर्स जान सकें कि दूसरा क्या कर रहा है। यह टीम को अधिक स्थिर बनाता है, क्योंकि यह एक स्थिति को रोकता है जहां केवल एक ही व्यक्ति को कोड के बड़े हिस्सों के बारे में बहुत कुछ पता होता है और वह कई सालों से बिना सहयोग के उस पर काम कर रहा होता है। फिर, अगर वह व्यक्ति कंपनी छोड़ देता है, तो कोई और उस पर काम नहीं कर सकता।
बड़ी कंपनियाँ अच्छी तरह से कैश फ्लो और प्रॉफिट डिसिप्लिन बनाए रखती हैं। कारण यह है कि जैसे-जैसे वे बड़े होते हैं, उन्हें अक्सर महत्वपूर्ण वित्तीय संकट का सामना करना पड़ता है। यह शायद सबसे महत्वपूर्ण चीज है जिसे वे प्राथमिकता देती हैं। उन्होंने इसे कठोर तरीके से सीखा है और इसे अपने ऑपरेशंस में शामिल कर लिया है। यहां तक कि जब वे 10 बिलियन डॉलर या 30 बिलियन डॉलर प्रतिवर्ष का लाभ कमा रहे होते हैं, तो भी वे अपने कार्यबल को अनुकूलित करते रहते हैं और छंटनी करते रहते हैं।
मेरे एक सहकर्मी ने मुझे बताया कि बड़ी कंपनियाँ कुछ उत्पादों पर एकाधिकार करती हैं जिनके निर्माण में बहुत श्रम या समय लगता है। यह समझ में आता है। वे गति पर निर्भर नहीं करते, बल्कि अपने आकार, संसाधनों और ब्रांड पर निर्भर करते हैं।
बड़ी कंपनियों में कैसे जीवित रहें? एक तो अधिक काम करें, कम बातें करें। यह मेरा डिलीवर मैनेजर एक आउटसोर्सिंग वेन्डर में मुझे बताया।
दूसरी बात यह है कि दूसरों के अनुसार चलें; यह सुरक्षित है। टीम में एक औसत इंजीनियर बनना सुरक्षित है, जैसे कि सड़क पर एक औसत व्यक्ति—न तो बहुत उभरकर, न ही बहुत नज़रअंदाज़, बल्कि ठीक बीच में।
मैं कहना चाहता हूँ कि बहुत सारी बड़ी कंपनियाँ हैं। कुछ के पास 200,000 से अधिक कर्मचारी होते हैं, जबकि कुछ के पास लगभग 20,000 होते हैं। अच्छी बड़ी कंपनियाँ और खराब प्रदर्शन करने वाली कंपनियाँ भी हैं। दिखावट या मार्केट कैप कभी-कभी बहुत कुछ नहीं बताते। वे कुछ सालों में काफी बढ़ सकते हैं, जैसे कि एनविडिया ने हाल ही में, या वे अचानक ढह सकते हैं, जैसे कि क्रेडिट स्विस।