एंटरप्राइज़ अनुभव

• बड़ी कंपनी में 1 साल काम करते हुए पहले के startup, SME माहौल से बेहद स्पष्ट अंतर महसूस हुआ
• ज़िम्मेदारी किसकी है यह पता लगाना और आंतरिक प्रक्रियाएँ जटिल होने के साथ, जो बातें छोटे संगठनों में समस्या नहीं थीं वे असमाधेय चुनौतियों में बदल गईं
• संसाधनों की बर्बादी और hiring मानकों में असंतुलन के कारण संगठन की दक्षता और motivation पर असर पड़ता है
• संगठन के भीतर काम की urgency, security management जैसे प्रमुख विचार अपने वास्तविक अर्थ से हटकर औपचारिक और प्रक्रियात्मक व्यवहार में बदल जाते हैं
• कई समस्याओं के बीच भी कौशल विकास, career growth जैसे सकारात्मक अनुभव मिलते हैं

---

एंटरप्राइज़ अनुभव: 1 साल का पुनरावलोकन

बड़ी कंपनी और startup के बीच अंतर

• $ENTERPRISE में पहला 1 साल बिताते हुए पहले के startup और SME (छोटे एवं मध्यम व्यवसाय) से अंतर अनुभव किया।
• बाद में समझ आया कि इन-हाउस software development का अनुभव कम होना आलोचना नहीं, बल्कि उल्टा एक सकारात्मक संकेत था।
• देखी गई बातों को समेटते हुए बड़ी कंपनी के कार्य-परिवेश की वास्तविकता प्रस्तुत की गई है।

जो चीज़ें छोटी कंपनी में समस्या नहीं थीं, वे बड़ी कंपनी में बड़ी समस्या बन जाती हैं

• Tool से जुड़ी errors को हल करते समय, ज़िम्मेदार व्यक्ति या owner का पता लगाने में बहुत समय लगता है।
• संगठन में जानकारी साझा करने की कमी और ज़िम्मेदार लोगों के बदलने से inefficiency और लागत की बर्बादी होती है।
• अस्थायी समाधान local setting override है, लेकिन मूल रूप से यह संगठनात्मक संरचना की सीमा है।

संसाधन आवंटन की अव्यावहारिकता

• छोटे संगठनों में पर्याप्त budget के बिना काम करने के अनुभव के उलट, बड़ी कंपनियों में अत्यधिक resource waste अक्सर दिखता है।
• अल्पकालिक project failures, अनावश्यक cloud उपयोग आदि वित्तीय बर्बादी में बदल जाते हैं।
• वास्तविक ज़रूरतों से कटा हुआ budget और resource management काम के प्रति motivation कम करता है।

असंगत सहकर्मी और hiring संरचना

• startup में skill-based hiring अपेक्षाकृत एक समान मानक बनाए रखती है।
• बड़ी कंपनियों में कौशल से असंबंधित hiring और restructuring सामान्य बात है।
• कुछ पद ऐसे होते हैं जिनका वास्तविक कार्य-क्षमता से संबंध नहीं होता, या report की quality से अलग भी संगठन वैसे ही चलता रहता है।

काम की urgency की व्याख्या

• startup में स्पष्ट urgency ही मानक थी, लेकिन बड़ी कंपनी में काम की कई परतों वाले अर्थ समझने पड़ते हैं।
• वास्तविक आपात स्थितियों (जैसे service outage) के अलावा औपचारिक urgency भी अक्सर पैदा की जाती है।
• ऐसी प्रक्रियाओं में वास्तविक कार्य-प्राथमिकता पहचानने की क्षमता ज़रूरी होती है।

औपचारिक बन चुका security management

• security process संगठन में महत्वपूर्ण भूमिका निभाते हैं, लेकिन व्यवहार में वे अक्सर वास्तविक risk की तुलना में औपचारिक reporting पर अधिक केंद्रित हो जाते हैं।
• numeric targets या metrics हासिल करने के लिए अर्थहीन हो चुका security work रोज़मर्रा का हिस्सा बन जाता है।
• engineers और security staff के बीच communication inefficiency भी मौजूद रहती है।
• यह रेखांकित किया गया है कि जब सब लोग केवल numbers पर ज़ोर देते हैं तो वह संस्कृति ख़तरनाक होती है।

पदनामों का अर्थहीन हो जाना

• "Head of Architecture" जैसे दोहराए गए titles आम हैं, और उनकी भूमिकाएँ स्पष्ट नहीं होतीं।

ऐसी संगठनात्मक संस्कृति जो अनिश्चितता को कमजोरी मानती है

• बड़े पैमाने के organizational reshuffle और बार-बार होने वाली restructuring के बीच, leaders के लिए "मुझे नहीं पता" कहना लगभग वर्जित हो जाता है।
• domain की जटिलता के बावजूद leadership में तुरंत जवाब और आत्मविश्वास को ही प्राथमिकता दी जाती है।
• इसके कारण अतीत की गलतियों को दोहराने वाली संरचना और मजबूत हो जाती है।

silo में बँटी engineering teams

• हर engineering team (या एक तरह का 'साम्राज्य') अपने खुद के standards और culture रखती है।
• विभागों के बीच रुकावटें बढ़ जाती हैं, और standardization या best practices के प्रसार में कठिनाई होती है।
• हर विभाग की autonomy टीमों के बीच सहयोग पर सीमा लगा देती है।

सकारात्मक अनुभव

• engineer community में भागीदारी के ज़रिए software development को देखने का दायरा व्यापक हुआ।
• career growth, mentorship opportunities, बड़े पैमाने पर उपयोग का अनुभव जैसी नई संतुष्टियाँ भी मिलती हैं।
• विशेषज्ञता का गहराना, विविध सहकर्मियों के साथ सहयोग, training और skill development को सक्रिय रूप से प्रोत्साहित किया जाता है।
• नियमित वेतन भुगतान, job security जैसी स्थिरता भी एक लाभ के रूप में काम करती है।

निष्कर्ष

• आलोचनात्मक दृष्टि के बावजूद बड़ी कंपनियों का सकारात्मक मूल्य स्पष्ट है।
• आगे बहुत समय बीतने के बाद बदले हुए नज़रिए से इसे फिर से परखने की इच्छा व्यक्त की गई है।

[GN⁺]

Hacker News राय

• Remy's Law of Enterprise Software को हमेशा याद रखना चाहिए (संबंधित लिंक: https://thedailywtf.com/articles/graceful-depredations). अगर किसी सॉफ़्टवेयर को "enterprise" कहा जाता है, तो आमतौर पर वह खास अच्छा नहीं होता। मज़ाक अपनी जगह, लेकिन लेख के अंत में बताए गए सकारात्मक बिंदु दिलचस्प लगे। कुछ बातें समझ में आईं, लेकिन कुछ ऐसी भी लगीं जो असल में सिर्फ और समस्याएँ पैदा करती हैं। उदाहरण के लिए "वास्तविक करियर डेवलपमेंट के अवसर हैं" — अगर करियर डेवलपमेंट का मतलब सिर्फ ज़्यादा पैसे कमाना है, तो सीधा "ज़्यादा पैसा कमा सकते हैं" कहना चाहिए, ऐसा मेरा मानना है। और अगर मतलब वह नहीं है, तो अब तक बताई गई संगठनात्मक अक्षमताओं और समस्याओं के बीच करियर डेवलपमेंट का मतलब आखिर क्या है, यह जानने की जिज्ञासा होती है। और "लाखों लोगों द्वारा इस्तेमाल किया जाने वाला सॉफ़्टवेयर बनाना संतोषजनक है" — अगर वह सॉफ़्टवेयर अच्छा न हो या उपयोगकर्ताओं को नुकसान पहुँचाता हो, तो क्या तब भी वह संतोषजनक है, इस पर भी सवाल है

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

  • बड़ी कंपनी में करियर डेवलपमेंट का मतलब पैसे से कहीं ज़्यादा होता है। उदाहरण के लिए, बड़े पैमाने के प्रोजेक्ट्स को लीड करने का मौका मिल सकता है, या ऐसे उत्पाद को in-house पूरा बनाने का अवसर, जिसे पहले शायद कोई startup अकेले बनाता। कई वर्षों तक अलग-अलग प्रोजेक्ट्स में काम करने या बड़े पैमाने की टीमों को लीड करने का अनुभव भी बड़ी कंपनियों में तुलनात्मक रूप से आसानी से मिलता है। और अगर सॉफ़्टवेयर खराब या नुकसानदायक हो? तो startup और छोटी कंपनियाँ अपने-आप बेहतर नहीं हो जातीं; यह हर मामले पर निर्भर करता है

  • अगर आप data scientist researcher, developer evangelist जैसी भूमिकाओं का सपना देखते हैं, तो आपको ऐसी संस्था चाहिए जो उस काम को समर्थन दे सके। microservices architect जैसी भूमिका छोटे संगठन में फिट नहीं बैठेगी, लेकिन 3000+ लोगों वाली बड़ी कंपनी में उसका स्वागत होगा। जैसे engineering manager ट्रैक तभी सार्थक होता है जब टैलेंट पूल पर्याप्त बड़ा हो, वैसे ही scale से आने वाले करियर डेवलपमेंट के अवसर भी होते हैं। कुछ सॉफ़्टवेयर खराब या नुकसानदायक होते हैं, लेकिन हम जो बनाते हैं वह ज़रूरी नहीं कि enterprise software ही हो — बल्कि बेहतर होगा कि न हो

  • मुझे नहीं लगता कि enterprise software अपने स्वभाव से बुरा होता है। निश्चित रूप से अच्छा enterprise software बनाया जा सकता है, और जटिल requirements को पूरा करते हुए ऐसा कर पाना अपने-आप में बड़ी क्षमता की बात है। लेकिन व्यवहार में शायद ही कभी किसी संगठन में इस आधार पर आकलन होता है कि वह user experience की कितनी परवाह करता है। यहाँ तक कि मैं 7 साल से ज़्यादा समय से $ENTERPRISE में हूँ, और मैंने सीधे किसी user से सिर्फ एक बार मुलाकात की है

  • इस सवाल पर कि क्या सॉफ़्टवेयर खराब हो, नुकसानदायक हो, फिर भी संतोषजनक लग सकता है — बहुत से engineers सिर्फ बड़े scale पर काम करने से ही संतुष्टि महसूस करते हैं, या असहाय महसूस करके उसे अपने से असंबंधित मान लेते हैं। और सच में वह scale पाने के लिए अक्सर किसी बहुत बड़ी कंपनी का हिस्सा होना पड़ता है, इसलिए अंततः algorithmic dark patterns, shareholder value maximization जैसी पूँजीवादी संरचनाओं में फँसना लगभग तय हो जाता है

• एक बात छूट गई है: जब नई leadership आती है, तो वे पुराने लोगों को बाहर कर अपने लोगों को भर देते हैं। और हर साल टीम का नाम बदल दिया जाता है, जबकि असल काम वही रहता है — बस टीम के नाम में "Innovation", "Discovery", "Leadership" जैसे शब्द जोड़ दिए जाते हैं

  • अगर टीम का नाम इतनी बार बदलना ही है, तो बेहतर है कि उसे बस 'Pikachu' जैसा कोई नाम देकर हमेशा के लिए वही रहने दिया जाए। अगर सबको पता हो कि नाम से कोई फर्क नहीं पड़ता, तो शायद नाम बदलना बंद हो जाए। हर बार नाम बदलने पर दस्तावेज़ अपडेट करने और सबको बताने में बेवजह बहुत समय और मेहनत लगती है

  • हमारे संगठन में Terraform CDK से बनी internal infrastructure code library है। यह Datadog और Pagerduty में monitoring resources अपने-आप बना देती है। एक दिन मैंने देखा कि ज़रूरी team argument असल में हर 7 महीने में बदल ही जाता है, तो मैंने उसे हटा दिया

  • मेरा एक प्रतिद्वंद्वी हर नई कंपनी में जाते ही अपने पुराने सहकर्मियों — पूरे help desk और dev team तक — को धीरे-धीरे साथ ले आता है। वजह है loyalty। नतीजे अच्छे न हों, तब भी वे शिकायत नहीं करते, और ऊपर तक समस्या नहीं पहुँचाते। उस व्यक्ति की कंपनी में काम कर चुके पूर्व कर्मचारियों की बात सुनो तो कहानी हमेशा एक जैसी होती है:

    1. समस्या की पहचान (कहना कि नई Microsoft partner CRM न होने से समस्या है)
    2. समस्या सुलझाने के नाम पर पैसा खर्च (उस CRM partner और Microsoft की बदौलत साल में 3 बार Las Vegas यात्रा)
    3. CRM लागू करने में विफलता (कहना कि समस्या यह थी कि scope पर्याप्त बड़ा नहीं था)
    4. फिर से project scope बदलना (और अधिक perks मिलना)
    5. फिर एक और विफलता से पहले नई कंपनी में निकल जाना, और पीछे सिर्फ समस्याएँ छोड़ जाना

  • अगर किसी project के नाम में ‘Excellence’ जैसा शब्द हो, तो आमतौर पर भरोसा नहीं होता

• मूल लेख की ज़्यादातर बातें public sector संस्थानों पर भी लागू होती हैं। बस weekend work न होना, (तकनीकी) करियर डेवलपमेंट के अवसर होना, और skill development या training को प्रोत्साहन मिलना — इन बातों को छोड़कर बाकी सब काफ़ी मिलता-जुलता है

  • शुरुआत में मज़े और आर्थिक लाभ की जो बात कही गई थी, वह भी public sector पर बहुत लागू नहीं होती, ऐसा लगता है

• यह बहुत मज़ेदार और दिलचस्प लेख था। मैं लगभग 3 साल से enterprise में काम कर रहा हूँ। तकनीकी रूप से तो बढ़ रहा हूँ, लेकिन असल में ऐसा लगता है कि मैं लोगों, communication और bureaucracy के बारे में ज़्यादा सीख रहा हूँ। budget और mouse वाली टिप्पणियों से भी सहमति है। लेकिन $ENTERPRISE की financial stability की वजह से मैं बस अपना mouse खुद खरीद लेता हूँ। कोई बिना approval वाले mouse पर आपत्ति उठा सकता है, लेकिन... उसे अनदेखा भी किया जा सकता है, या mouse approval जैसी नकली urgency को गंभीरता से न लिया जाए

• मैं ऐसे संगठन में बिल्कुल नहीं टिक सकता। वेतन 3 गुना भी दे दें, तो भी कुछ महीनों में पूरी तरह टूट जाऊँगा

  • compensation असल में ज़रूरी काम की मात्रा के व्युत्क्रमानुपाती होता है

  • बस बहुत भारी मात्रा में psychiatric दवा (Zoloft) लेकर ही जैसे-तैसे टिक पाना संभव होगा

  • कभी-कभी सोचता हूँ कि पैसे को प्राथमिकता दूँ, $ENTERPRISE में ऊँचा वेतन लेकर अच्छी-खासी बचत करूँ, और फिर लंबी sabbatical पर निकल जाऊँ। लेकिन interview process ही इतना थकाऊ लगता है कि यह सोचकर ही उत्साह खत्म हो जाता है। अभी मैं $MIDSIZENOLONGERSTARTUP में हूँ, और यहाँ भी अपने ढंग की कई अजीब चीज़ें हैं जो मुझे थका देती हैं

• मैं भी ऐसे ही माहौल में काम कर रहा हूँ, और यह लेख दर्दनाक रूप से सटीक लगा। मैं सोचता था कि मेरा काम समस्याएँ हल करना और software deploy करना है, लेकिन हक़ीक़त में संगठन की ‘असली प्राथमिकताएँ (revealed preferences, संबंधित लिंक: https://en.wikipedia.org/wiki/Revealed_preference)’ बिल्कुल कुछ और हैं। लेखक ने जैसे छोटी कंपनी से बड़ी कंपनी में जाने का अनुभव बताया, वैसे ही क्या किसी ने उल्टा रास्ता तय किया है — बड़ी कंपनी से छोटी कंपनी में? और enterprise अनुभव को small-team interview में कैसे पेश करना चाहिए, यह भी जानना चाहूँगा

  • मेरे अनुभव में यह मानो दो शहरों की कहानी है। मैं भी $ENTERPRISE में अर्थहीन समय-बरबादी से थक चुका हूँ, और अब 20% वेतन छोड़कर भी किसी छोटी लेकिन ठीक-ठाक जगह पर जाकर कुछ हासिल करना चाहता हूँ। लेकिन पिछले 3 वर्षों में जो सीखा है, उसे बिना नकारात्मक लहजे के समझाने की कोशिश करूँ तब भी startup founders मेरी पृष्ठभूमि को कुछ बोझिल नज़र से देखते हैं। जैसे जंगल में ज़रूरी survival skills और चिड़ियाघर में ज़रूरी survival skills इतनी अलग हैं कि उनका सवाल यह होता है: क्या तुम बहुत लंबे समय से चिड़ियाघर में तो नहीं रहे? दूसरी ओर, बड़ी कंपनियाँ भी ऐसे लोगों को चाहती हैं जो उनके internal processes और hierarchy को समझते हों, इसलिए startup background वाले लोगों के लिए वहाँ interview देना भी आसान नहीं होता

  • मैं बड़ी कंपनी से छोटी कंपनी में गया हूँ, और मेरे अनुभव में कंपनी जितनी बड़ी होती जाती है, हल की जाने वाली समस्याएँ तकनीकी से ज़्यादा लोगों और internal politics से जुड़ी हो जाती हैं। बड़ी कंपनियाँ अक्सर golden handcuffs (संबंधित लिंक: https://en.wikipedia.org/wiki/Golden_handcuffs) जैसी compensation से core talent को रोके रखती हैं, और इसी वजह से लोग compensation छोड़ने तक संगठन की तमाम बकवास ज़्यादा समय तक सहते रहते हैं। अगर आप कहानी को इस तरह रखें कि "मैं बड़ी कंपनी छोड़कर वास्तविक बदलाव लाना चाहता था", तो छोटी टीमों में लोग आमतौर पर इसे समझ लेते हैं

• बड़ी कंपनियाँ बस अपने तरह के outputs को लगातार deliver करने की चिंता करती हैं। goals भी numbers hit करने, regulatory procedures, executive decisions जैसी कई वजहों से तय होते हैं। यह उस मानवीय तर्कशीलता से बिल्कुल अलग क्षेत्र है जिसकी हम कल्पना करते हैं

• मूल लेख में "और भी साम्राज्य हैं" वाली बात पर, मज़ाक में यह भी कहा जा सकता है कि UK (manual QA), Egypt (software pyramids) के अलावा Mongolia (एक दिन अचानक ढेर सारी requirements फेंककर गायब हो जाना), Spain (हर नियम को पूरी तरह लागू करने की कोशिश में और घर्षण पैदा करना), Japan (executive से डाँट खाकर करियर को आत्म-हानि जैसी दिशा में धकेल देना), China (meetings की भूलभुलैया में फँस जाना और communication का बेहद गुप्त हो जाना) जैसे रूपक भी हैं

  • यह लेख पढ़कर सच में बहुत मज़ा आया, खासकर Mongolia के साथ युद्ध वाली उपमा मज़ेदार थी। ऐतिहासिक रूप से भी Mongols से लड़ाई आसान नहीं थी

• office politics और management की भूमिका के महत्व को अच्छी तरह दिखाने वाला बढ़िया insight था

• $ENTERPRISE में 18 महीने से काम कर रहा हूँ। यह इतनी वास्तविक लगी कि दर्द हुआ