बड़े कंपनियों पर | मूल, AI द्वारा अनुवादित
बड़े कंपनियाँ बड़ी प्रोग्रामिंग की तरह ही होती हैं। 100,000 कर्मचारियों और 50,000 कॉन्ट्रैक्टर्स वाली एक बड़ी कंपनी 150,000 मेथड्स वाली एक बड़ी प्रोग्राम की तरह होती है।
डारियो अमोडी ने कहा कि टैलेंट डेंसिटी की संख्या से बहुत ज्यादा महत्वपूर्ण होती है। 200 बहुत टैलेंटेड लोग 1,000 टैलेंटेड लोगों और 800 साधारण लोगों को हरा सकते हैं।
डारियो अमोडी ने यह भी कहा कि बड़ी कंपनियों में इतनी प्रक्रियाएँ और प्रक्रियाएँ होती हैं क्योंकि वे अपने कर्मचारियों या कॉन्ट्रैक्टर्स पर भरोसा नहीं करते। इसलिए उन्हें बहुत सारी जांच और नियंत्रण करने की आवश्यकता होती है।
बड़ी कंपनियों के बारे में एक बात यह है कि वे गलतियों से डरते हैं। एक कारण यह है कि वे इतनी बड़ी हो गई हैं कि वे 300 बिलियन या 1 ट्रिलियन डॉलर की कीमत के हैं; उन्हें बहुत सारी गलतियाँ होनी चाहिए और वे उनसे सीखकर बढ़ी होंगी। हालाँकि, जब वे सफल होते हैं, तो वे जोखिम लेने और फिर से गलतियाँ करने से बचते हैं।
यह एक बड़ी प्रोग्राम की तरह है जो बग्स से नफरत करता है और विशेष रूप से सुरक्षा बग्स को खत्म करने की कोशिश करता है, विशेष रूप से बड़े बैंकों में।
स्टार्टअप तेज होते हैं, लेकिन स्टार्टअप के पास बहुत कम संसाधन होते हैं, और स्टार्टअप का ब्रांड स्थापित नहीं होता; उन्हें बड़ी कंपनियों का भरोसा नहीं होता।
चीन में, युवा टैलेंटेड लोग अभी भी स्नातक होने के बाद बड़ी कंपनियों में जाना चाहते हैं और इसके लिए संघर्ष करते हैं। सिलिकॉन वैली में बहुत सारे स्टार्टअप हैं, जिनमें से कुछ केवल विचार के साथ ही शुरुआत में अच्छा प्रदर्शन करते हैं।
कुछ कंपनियाँ 20 साल तक चलती हैं और अभी भी संघर्ष करती हैं, शायद स्टॉक मार्केट से हटाई गई हैं, और कुछ कंपनियाँ कुछ महीनों में ही 5 बिलियन या 10 बिलियन डॉलर की कीमत की होती हैं।
यह कहा गया है कि मिरा मुराटी की थिंकिंग मशीन्स लैब सीड राउंड में $12B की कीमत की है। और इलिया सुत्स्केवर की सेफ सुपरइंटेलिजेंस ने $32B की कीमत पर $2B जुटाए।
इसलिए, स्टार्टअप को मापने के लिए स्थापित समय का उपयोग करना एक अच्छा संकेतक नहीं है; यह बेहतर है कि इसे टीम के बारे में, फाउंडर्स के बारे में और वे किस क्षेत्र में हैं, इसके आधार पर मापा जाए।
मेरे सोलो स्टार्टअप में, मुझे बस 1 मिनट का समय लगता है अपने बैकएंड सर्वर को डिप्लॉय करने के लिए और 5 मिनट का समय लगता है एक छोटी सी बग को ठीक करने और डिप्लॉय करने के लिए। यह सीधा और तेज है। बड़ी कंपनियों के लिए, डिप्लॉयमेंट रिक्वेस्ट तैयार करने में 1 सप्ताह का समय लगता है, मैनेजर्स से अनुमोदन प्राप्त करने, आईटी टीम के साथ डिप्लॉयमेंट करना, और हेल्थ चेक करना।
हालाँकि, वास्तविक समय जो खर्च होता है वह 8 घंटे का होता है, अगर हम मापें, तो फिर भी डिप्लॉयमेंट की तैयारी से अंतिम हेल्थ चेक तक 1 सप्ताह का समय लगता है।
एक छोटी सी बग को ठीक करने और डिप्लॉय करने में 2 सप्ताह का समय लगता है। आपको टिकट मिलता है जांच करने के लिए, विश्लेषण और परीक्षण करना, फिर समीक्षा, कोड को मर्ज करना, टेस्ट टीमों को टेस्ट करने के लिए रिपोर्ट करना, और फिर डिप्लॉय करना।
बड़ी कंपनियाँ सभी टीमों या प्रोजेक्ट्स पर अपने नीतियों को लागू करने का प्रयास करती हैं। क्योंकि 200,000 लोगों वाली एक बड़ी कंपनी के लिए, वे नीतियाँ या आंतरिक प्रक्रियाएँ जो केवल 10,000 लोगों पर लागू होती हैं, उन्हें बहुत महत्व या परिणाम नहीं मिलता। कुछ आंतरिक प्रक्रियाओं के लिए, बड़ी कंपनियों को लोगों या पैसे में निवेश करना पड़ता है ताकि उन्हें समर्थन करने के लिए उपकरण विकसित किए जा सकें। इसलिए अगर यह केवल कर्मचारियों के एक छोटे अनुपात को सेवा देता है, तो निवेश का रिटर्न इसे न्यायोचित नहीं ठहराता।
बड़ी कंपनियों का एक और नुकसान यह है कि अक्सर कोई भी बड़ी गलतियों के लिए दंडित नहीं होता।
मेरे स्टार्टअप में, मुझे एक बार आधा मिलियन का निवेश मिला 9 लोगों को नियुक्त करने के लिए, और 2 महीने बाद मुझे उन्हें छोड़ना पड़ा और उस पैसे को खो दिया। मैंने 50 छोटे सॉफ्टवेयर प्रोजेक्ट्स पार्ट-टाइम इंजीनियर्स के साथ किए ताकि मैं उस पैसे को वापस कमा सकूं और निवेशक को दे सकूं।
यह बहुत तीव्र और दर्दनाक याद है। और यह मुझे हमेशा उस सबक को याद दिलाता है।
एक बड़े कॉर्पोरेशन के भीतर एक उल्लेखनीय मामले में, यह देखा गया कि उन लोगों के लिए कोई महत्वपूर्ण परिणाम नहीं हुआ। कुछ सीनियर मैनेजर्स और हाल ही में नियुक्त कर्मचारी को छोड़ दिया गया। यह स्पष्ट नहीं है कि क्या यह एक तेज और महत्वपूर्ण भर्ती स्प्री के साथ संबंधित था।
इस परिणाम का एक योगदान कारक बड़े कंपनियों में भारी और कई प्रक्रियाएँ हैं। जो इंजीनियर्स 6 महीने से 1 साल तक कंपनी में थे, वे महत्वपूर्ण योगदान नहीं कर पाए। समयरेखा आमतौर पर दो महीने के लिए बुनियादी बातों को समझने के लिए, तीन महीने के लिए प्रोजेक्ट्स से परिचित होने के लिए, तीन महीने के लिए थकाऊ प्रक्रियाओं या परीक्षणों से गुजरने के लिए, और अंत में, दो महीने के लिए उत्पादक काम करने के लिए, जो उपयोगकर्ताओं को प्रभावित करता है।
8 घंटे के काम के दिन के साथ, दो महीने के वास्तविक उत्पादक काम से महत्वपूर्ण परिणाम नहीं मिले। विभाग का बजट खत्म हो गया, और उपयोगकर्ता आधार जैसा कि उम्मीद थी, बढ़ा नहीं। इसके परिणामस्वरूप और छंटनी हुई।
लगता है कि इस अनुभव से कोई मूल्यवान सबक नहीं सीखा गया। शुरू में, एक समूह मैनेजर्स ने एक तेज और व्यापक भर्ती रणनीति पर विचार किया, जो उस समय अनावश्यक लग रहा था। पूरे समूह के मैनेजर्स को दोष देना संभव नहीं था, न ही यह व्यावहारिक था कि केवल उन लोगों को निकाल दिया जाए जिन्होंने कंपनी में कम समय बिताया था, विशेष रूप से जब अन्य मैनेजर्स और तकनीकी लीड्स 6 से 8 साल तक टीम का हिस्सा रहे हों।
मैनेजिंग डायरेक्टर ने इस स्थिति से बहुत कुछ नहीं सीखा, क्योंकि यह उनके तीन विभागों में से एक था, और उनका वेतन अपरिवर्तित रहा। टीम के भीतर, वे लोग जो सीधे जिम्मेदार नहीं थे, वे भी इस अनुभव से सीख नहीं पाए, जो स्टीव जॉब्स के कंसल्टिंग के बारे में टिप्पणियों को दोहराते हैं। परिणामस्वरूप, कोई भी वह सबक नहीं सीखा जो एक असाधारण टीम बनाने के लिए आवश्यक था जो उपयोगकर्ताओं के लिए उत्कृष्ट परिणाम दे सके।
स्टार्टअप के लिए, यह बहुत बेहतर लगता है। क्योंकि यह वास्तव में गंभीर है। कुछ फाउंडर्स जो हार जाते हैं या असफल हो जाते हैं, उन्हें वास्तव में मुश्किल समय गुजरना पड़ता है, विशेष रूप से ईमानदार लोगों के लिए।
इंटीग्रिटी वाले व्यक्तियों के लिए, बहुत सारे निवेश फंड्स को खोना, जो मिलियन से लेकर हजारों मिलियन डॉलर तक हो सकते हैं, और इसके लिए बहुत कम दिखाने के लिए, शायद एक बुनियादी उत्पाद या एक उपयोगकर्ता आधार जो, हालांकि बड़ा है, बहुत कम राजस्व उत्पन्न करता है, यह गहरा निराशाजनक हो सकता है।
पॉल ग्राहम ने पहले एक निबंध लिखा था, हायरिंग ओब्सोलेट।
लेकिन बड़ी कंपनियाँ अच्छी तरह से क्या करती हैं? एक है लॉन्ग-टर्मिज्म। वे लंबे समय के लिए चीजें करने की प्रवृत्ति रखते हैं। कुछ अच्छी बड़ी कंपनियों के प्रोजेक्ट डिजाइनों में माइक्रोसर्विसेज का उपयोग करके एक दशक बाद एक बड़ी मोनोलिथिक प्रोग्राम बनने की गलती से बचने के लिए बहुत अच्छी होती हैं। और उनके पास गवर्नेंस टीम होती है जो कुछ फाउंडेशनल फ्रेमवर्क्स बनाती है और पूरे टीम के लिए विकास प्रथाओं को एकीकृत करती है।
प्रक्रियाएँ या प्रक्रियाएँ स्वाभाविक रूप से बुरी नहीं होती हैं। लेकिन वे अक्सर चीजों को जटिल और धीमी बनाती हैं। हम जावा यूनिफाइड कोड फॉर्मेट को अप्रिय नहीं मानते क्योंकि एक स्पॉटलेस या चेकस्टाइल प्लगइन है जो मदद करता है। ये प्लगइन अच्छे डिजाइन के साथ होते हैं और उपयोग करने में आसान होते हैं।
एक और बात यह है कि बड़ी कंपनियाँ अक्सर कुछ उपकरण या प्रोजेक्ट्स बनाती हैं आंतरिक उपयोग के लिए, फ्रंट ऑफिसर्स के लिए। लेकिन वह उपयोगकर्ता आधार बस हजारों या 10,000 होता है। वह उपयोगकर्ता आधार बहुत सीमित होता है।
मुझे लगता है कि हम बेहतर तरीके से बाहरी उपकरणों का उपयोग कर सकते हैं। अगर एक उपकरण एक बैंक के लिए वास्तव में अच्छा है, तो यह 200 बैंकों के लिए भी अच्छा होगा। और यह उस कंपनी को एक यूनिकॉर्न बना सकता है।
टियांचेंग लू, पोनी.एआई के संस्थापक, कहते हैं कि कंपनियों को स्वतंत्र होने की आवश्यकता है क्योंकि यह अधिक कुशल है। यह सच है।
और बड़ी कंपनियाँ अक्सर अनुभव को कर्मचारियों को पुरस्कार देने के लिए उपयोग करती हैं। जबकि बाजार स्टार्टअप टीमों के परिणाम या कार्यान्वयन को पुरस्कार देता है। वे वास्तव में बहुत अलग हैं।
बड़ी कंपनियों में काम करना स्कूल में सीखने जैसा है। आप प्राइमरी स्कूल से मिडिल स्कूल, फिर विश्वविद्यालयों तक आगे बढ़ते हैं। स्टार्टअप में, अधिक उतार-चढ़ाव होते हैं, और एक विचार या बाजार से दूसरे में जाने के साथ अधिक लचीलापन होता है।
बड़ी कंपनियों का जोखिम से बचने का फायदा यह है कि उनके उत्पादों में कोई स्पष्ट बग या डाउनटाइम नहीं होता। यह अच्छा है।
लेकिन जैसे कि AI, वास्तव में, बहुत सारे उपयोगकर्ता उन उत्पादों के लिए तैयार होते हैं जो शुरुआत में इतना स्थिर नहीं होते हैं, जैसे कि डीपसीक। हम जानते हैं कि डीपसीक फरवरी-मार्च 2025 में बहुत डाउन हुआ जब यह बहुत ध्यान आकर्षित करता था। लेकिन कुछ समय बाद, यह बेहतर हो जाता है और कोई उपयोगकर्ता उस समस्या का सामना नहीं करता।
इसलिए यह निर्भर करता है। कभी-कभी, नवीन उत्पादों के लिए, हमें उन्हें तेजी से बाजार में लाना चाहिए, भले ही उनमें कुछ समस्याएँ हों। उपयोगकर्ता समझ सकते हैं।
अगर हम प्रक्रिया के बारे में सोचें, तो हम अधिक सावधान हो सकते हैं। हमें अपने डिप्लॉयमेंट प्रकारों को बेहतर तरीके से वर्गीकृत करना चाहिए। कुछ प्रकार के परिवर्तनों को तेजी से डिप्लॉय करने के लिए ठीक है, जबकि अन्य नहीं। परीक्षण के लिए, हमें यह निर्धारित करना चाहिए कि परिवर्तित कोड के लिए रिग्रेशन परीक्षण के लिए हमें किन भागों का परीक्षण करना चाहिए, और किन भागों का नहीं। सोनारक्यूब चेकिंग के लिए भी यही लागू होता है।
बड़ी कंपनियों में, यह निश्चित है कि बहुत सारी जांच, परीक्षण या अनुमोदन अनावश्यक हैं। हम इंजीनियर्स को अपना काम करने दें, और क्योंकि सिस्टम में सभी रिकॉर्ड हैं, हम कुछ को समीक्षा के लिए चुन सकते हैं।
हमें सभी मैनेजर अनुमोदनों को भी समाप्त करना चाहिए। मैनेजर्स के पास इंजीनियर्स के पास जो ज्ञान नहीं है? क्या यह ज्ञान कोड में लिखा जा सकता है ताकि अनुरोधों को स्वचालित रूप से स्वीकृत या अस्वीकृत किया जा सके?
क्योंकि वहां सब कुछ धीमा है, कर्मचारी या कॉन्ट्रैक्टर्स बदलने की संभावना कम है। एक दशक से चल रहे प्रोजेक्ट के लिए एक बड़ी मोनोलिथिक प्रोजेक्ट से माइक्रोसर्विसेज में परिवर्तन दो साल तक ले सकता है।
सॉफ्टवेयर के लिए, कोड और लॉजिक गहरे रूप से जुड़े होते हैं, विशेष रूप से अच्छी तरह से डिजाइन किए गए सिस्टम में। इसलिए, विकास, परीक्षण या सहयोग में शामिल हो सकता है।
इसलिए एक टीम को अचानक स्केल करना अक्सर काम नहीं करता। अगर एक माइक्रोसर्विस आर्किटेक्चर है जो लूज़ली कूपल्ड है, तो टीम का आउटपुट टीम सदस्यों की संख्या के अनुपात में हो सकता है। अगर एक मोनोलिथिक प्रोजेक्ट है जो टाइटली कूपल्ड है, तो टीम का आउटपुट केवल 30% बढ़ सकता है अगर हम उस पर काम करने वाली टीम की आकार को दोगुना कर दें।
अपनी धीमी गति के कारण, कभी-कभी यह मुश्किल हो सकता है कि पता चल सके कि एक कर्मचारी या कॉन्ट्रैक्टर्स असमर्थ है या नया जॉइनर के लिए सिस्टम बहुत जटिल और जटिल है। एक मामले में जो मैंने देखा, कोई चार महीने तक कंपनी में था और बहुत कम कुछ कर पाया, बस कुछ लाइनों को बदलकर एक पुल रिक्वेस्ट सबमिट किया। इसके अलावा, कोड की गुणवत्ता खराब थी क्योंकि वह इसे अच्छी तरह से नहीं समझता था। उसकी अंग्रेजी भी बहुत कमजोर थी, और वह केवल स्क्रीनशॉट्स पेस्ट करके और बुनियादी अंग्रेजी का उपयोग करके प्रश्न पूछकर संचार कर सकता था।
स्थिरता के बारे में, मैं देखता हूँ कि बड़ी कंपनियाँ अक्सर कई टीम सदस्यों को डुप्लिकेट टास्क्स पर काम करने के लिए करती हैं। उदाहरण के लिए, टास्क A और टास्क B के लिए, वे दो टीम इंजीनियर्स को टास्क A और टास्क B पर अलग-अलग काम करने के लिए नहीं असाइन करते। इसके बजाय, वे दोनों को टास्क A और टास्क B के हिस्सों पर काम करने के लिए करते हैं ताकि ये दो इंजीनियर्स जान सकें कि दूसरा क्या कर रहा है। यह टीम को अधिक स्थिर बनाता है, क्योंकि यह एक स्थिति को रोकता है जहां केवल एक ही व्यक्ति को कोड के बड़े हिस्सों के बारे में बहुत कुछ पता होता है और वह कई सालों से बिना सहयोग के उस पर काम कर रहा होता है। फिर, अगर वह व्यक्ति कंपनी छोड़ देता है, तो कोई और उस पर काम नहीं कर सकता।
बड़ी कंपनियाँ अच्छी तरह से कैश फ्लो और प्रॉफिट डिसिप्लिन बनाए रखती हैं। कारण यह है कि जैसे-जैसे वे बड़े होते हैं, वे अक्सर महत्वपूर्ण वित्तीय संकट का सामना करते हैं। यह शायद सबसे महत्वपूर्ण चीज है जिसे वे प्राथमिकता देती हैं। उन्होंने इसे कठोर तरीके से सीखा है और इसे अपने ऑपरेशंस में शामिल कर लिया है। यहां तक कि जब वे 10 बिलियन डॉलर या 30 बिलियन डॉलर प्रतिवर्ष का लाभ कमा रहे होते हैं, तो वे अपने वर्कफोर्स को अनुकूलित करने और छंटनी करने के लिए जारी रहते हैं।
मेरे एक सहकर्मी ने मुझे बताया कि बड़ी कंपनियाँ कुछ उत्पादों पर एकाधिकार करती हैं जो बहुत सारे श्रम या समय लेने वाले होते हैं। यह समझ में आता है। वे गति पर निर्भर नहीं करते, बल्कि अपने आकार, संसाधनों और ब्रांड पर निर्भर करते हैं।
बड़ी कंपनियों में कैसे जीवित रहें? एक है कि अधिक काम करें, कम बातें करें। यह मेरा डिलीवर मैनेजर एक आउटसोर्सिंग वेन्डर में मुझे बताया।
दूसरी बात यह है कि दूसरों के अनुसार चलें; यह सुरक्षित है। टीम में एक औसत इंजीनियर बनना सुरक्षित है, जैसे कि सड़क पर एक औसत व्यक्ति—न तो बहुत उभरकर, न ही बहुत नज़रअंदाज़, बल्कि ठीक बीच में।
मैं कहना चाहता हूँ कि बहुत सारी बड़ी कंपनियाँ हैं। कुछ के पास 200,000 से अधिक कर्मचारी होते हैं, जबकि अन्य के पास लगभग 20,000 होते हैं। अच्छी बड़ी कंपनियाँ और खराब प्रदर्शन करने वाली कंपनियाँ भी होती हैं। दिखावट या मार्केट कैप कभी-कभी बहुत कुछ नहीं बताता। वे कुछ सालों में काफी बढ़ सकते हैं, जैसे कि एनविडिया ने हाल ही में, या वे अचानक ढह सकते हैं, जैसे कि क्रेडिट सुइस।