Big Tech कंपनियों में 'काम पूरा हो गया (Done)' का असली मतलब

• Big Tech में सचमुच काम पूरा करना का मतलब है ऐसे सिस्टम में, जिसे अनंत तक बेहतर बनाया जा सकता है, कंपनी के संतुष्ट होने तक उसे पूरा करके आगे बढ़ जाना
• सक्षम लेकिन पहल की कमी वाले इंजीनियर बार-बार छोटे-मोटे सुधार करते रहते हैं और असली उपलब्धि से चूक जाते हैं
• निर्णय लेने वालों को नज़र आने वाले, स्पष्ट परिणाम देने पर ही इसे "काम किया" माना जाता है
• हमेशा यह जांचते रहना चाहिए कि आप जो कर रहे हैं, वह ऊपरी प्रबंधकों द्वारा पढ़े और आंका जा सकने वाले रूप में है या नहीं
• हर चीज़ को पूरी तरह समेटा नहीं जा सकता; एक समय के बाद "जीत की घोषणा करके आगे बढ़ जाने की क्षमता" एक मुख्य कौशल बन जाती है

---

'काम' स्वभाव से कभी पूरी तरह समाप्त नहीं होता

• गणित के सवाल या असाइनमेंट से अलग, वास्तविक दुनिया का काम अनंत सुधार की संभावना वाला खुला सिस्टम है
• सेवा विकास पेड़ लगाने जैसा है; बाद में भी यह लगातार देखभाल मांगने वाली प्रक्रिया है

जाल में फंसा सक्षम इंजीनियर

• जो इंजीनियर खुद सब कुछ संभालते हुए बस छोटे और लगातार सुधार ही दोहराता रहता है, उसे लग सकता है कि वह अच्छा प्रदर्शन कर रहा है
• लेकिन ऊपरी प्रबंधकों की नज़र में "कंपनी के लिए दिखाई देने वाला मूल्य निर्माण" नहीं हुआ माना जा सकता है
• नतीजतन उसे ऐसा व्यस्त व्यक्ति समझा जा सकता है जिसके पास उपलब्धि नहीं है

'पूरा करना' का वास्तविक अर्थ

• कंपनी (निर्णय लेने वालों) के संतुष्ट होने की सीमा तक पहुंचाना और फिर अगले काम पर बढ़ जाना
• लगातार refactoring या छोटे सुधार दोहराते रहने के बजाय, स्पष्ट उपलब्धियों की सूची बनानी चाहिए
• "पूरा हो गया" घोषित करके अगले काम पर बढ़ने का निर्णयात्मक साहस महत्वपूर्ण है

काम की 'पठनीयता' सुनिश्चित करना

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

'पूरा करना' एक सामाजिक अवधारणा

• दार्शनिक रूप से 'पूरा हो गया' की अवधारणा भी एक सामाजिक संरचना है, लेकिन वास्तविक दुनिया में इसकी बहुत व्यावहारिक शक्ति है
• इसे नज़रअंदाज़ करने पर आपको मान्यता नहीं मिल सकती, और आखिरकार नौकरी भी जा सकती है

सारांश

• काम कर रहे होना, काम पूरा कर लेने के बराबर नहीं है
• ज़्यादातर काम वास्तव में कभी पूरी तरह खत्म नहीं होते और चलते रह सकते हैं
• माली नहीं, बल्कि उपलब्धि-केंद्रित रणनीतिकार बनना चाहिए
• "पूरा हो गया" का मानदंड कंपनी/मैनेजर की संतुष्टि है
• "जीत की घोषणा → आगे बढ़ना → अगले काम पर" यही मुख्य रणनीति है

[aer0700]

ऐसा लगता है कि ऐसी चीज़ चुन पाना भी एक अहम कौशल है, जिनके लिए आप जीत की घोषणा कर सकें।

[elbanic]

स्कोप को सीमित करना ही scoping कहलाता है। इस तरह scoping करना कि आप जीत सकें, वही असली क्षमता है।

[bakyeono]

हांशिन बनाम सोहा

[doolayer]

डिटेल्स नहीं, बल्कि मापे जा सकने वाले दृश्य परिणाम

[GN⁺]

Hacker News राय

• मैं इस लेख के तर्क से पूरी तरह असहमत नहीं हूँ, लेकिन Big Tech, कई startups और unicorn कंपनियों सहित अलग-अलग जगहों पर काम करने के अपने अनुभव के आधार पर यह मुझे बहुत व्यावहारिक सलाह नहीं लगती। पिछले 10 सालों में डेवलपर्स का काम इतना ज़्यादा specialized हो गया है कि वह decision makers और ग्राहकों की ज़रूरतों से कट गया है। यह स्थिति इसलिए बनती है क्योंकि Product Manager, engineers और कंपनी के बाकी हिस्से के बीच आ जाता है। मैं हमेशा meaningful outcome देना चाहता हूँ, लेकिन वास्तव में ऐसा करने के लिए लगातार तनाव झेलना पड़ता है। मेरा योगदान हमेशा उन लोगों के ego से होकर गुजरता है जो decision makers से बात करते हैं, और उसी के अनुसार बदल दिया जाता है। पिछले 5 सालों में मुझे सचमुच उपलब्धि का एहसास सिर्फ़ तब हुआ जब मैंने 9 महीनों तक अस्थायी Product Manager की भूमिका निभाई। उस दौरान हमारी टीम ने तीन ऐसे projects सफलतापूर्वक पूरे किए जिन्हें पहले दूसरी टीमें कई बार विफल कर चुकी थीं। उसका राज यह था कि मैंने stakeholders से सीधे बात करके उनकी ज़रूरतें समझीं, न कि चीज़ों को अपने तरीके से करने की कोशिश की। इसलिए आगे भी मैं शायद वही दूँगा जो मुझसे माँगा जाएगा, bugs के लिए दोष सुनूँगा, और features का श्रेय नहीं मिलेगा। कम से कम pay ठीक-ठाक है। फिर भी मैं अब भी ऐसी जगह खोज रहा हूँ जहाँ मैं सच में योगदान दे सकूँ

  • इस “pay ठीक-ठाक है” वाले हिस्से ने मुझे खास तौर पर छुआ। Big Tech में काम करते हुए मेरा अपना यह नज़रिया रहा है कि “stagnant” स्थिति भी इतनी बुरी नहीं होती। उदाहरण के लिए, अगर आप Google या MS जैसी जगह पर $300k salary लेकर 10 साल तक वही उबाऊ project करते रहें, तब भी वह अनुभव हर जगह मान्य माना जाएगा। पहले वाला महत्वाकांक्षी मैं इससे परेशान होता, लेकिन अगर आप वैसे हैं तो आप शायद किसी छोटी कंपनी में जाने की कोशिश करेंगे। उम्र बढ़ने के साथ मेरी प्राथमिकताएँ कंपनी से हटकर परिवार और दोस्तों की तरफ़ चली गई हैं। अगर कोई मुझसे कहे कि promotion नहीं मिलेगा, तो मैं कहूँगा, “तो क्या?” मैं अपने परिवार के लिए काफ़ी पैसा कमाता हूँ और work-life balance भी बनाए रखता हूँ। सच कहूँ तो कंपनी की सबसे अच्छी बात salary है और उससे मेरी बाकी ज़िंदगी बेहतर होती है
  • मैंने Product Manager role के बारे में भी यही अनुभव किया है कि वास्तविकता में यह वैसा नहीं होता जैसा आदर्श रूप में बताया जाता है; अक्सर वह बीच में फँसा रहता है और दोनों पक्षों का ठीक से प्रतिनिधित्व नहीं कर पाता। इसी वजह से मैंने खुद product management skills विकसित कीं, और वह skill बेकार मेहनत से बचने में बहुत काम आई। इसलिए सोचता हूँ कि क्या बड़े engineers के लिए product management भी एक ज़रूरी skill होनी चाहिए
  • एक और बात जिस पर ध्यान देना चाहिए, वह यह है कि अगर ऐसे ही चलता रहा तो यह burnout की सीधी राह है
  • मैंने समझा है कि communication किसी भी organization में सबसे बड़ा skillset है। सिर्फ़ 9 महीनों के अस्थायी काम से इसकी पूरी अहमियत समझ में नहीं आती। यह लेख वैसे ही लगता है जैसे कोई engineer, दूसरे engineers की तरह, बेहद चिढ़ा हुआ हो और उसे लगे कि वह organization के बाकी लोगों से ज़्यादा बुद्धिमान है। अक्सर ऐसा सच नहीं होता, और ऐसी mindset collaboration के लिए बुरी होती है
  • किसी भी अच्छी तरह चलने वाले web application के पीछे हमेशा कोई न कोई माली जैसा व्यक्ति होता है
  • यह जानने की जिज्ञासा है कि आपने Product Manager का काम जारी क्यों नहीं रखा
  • यह कंपनी पर बहुत निर्भर करता है। बहुत-सी जगहें ऐसी भी हैं जहाँ engineers का प्रभाव ज़्यादा होता है। यहाँ तक कि Big Tech में भी ऐसे उदाहरण हैं जहाँ लोग ग्राहकों से कटे हुए नहीं होते
  • क्या इसका मतलब है कि Product Managers को निकाल देना चाहिए?
  • मैं खुद Product Manager की भूमिका में रहा हूँ, यानी engineer और कंपनी के बीच मध्यस्थ के रूप में, और यह सच है कि मेरा योगदान भी मेरे ego से फ़िल्टर होकर आता था, लेकिन आपकी बात सुनकर तो लगता है कि आपको वह काम काफ़ी संतोषजनक लगा… सचमुच काफ़ी संतोषजनक रहा होगा

• मैं सफलता को सिर्फ़ power वाले लोगों को खुश करने से परिभाषित करने पर मूलभूत आपत्ति रखता हूँ। हम भले ही हास्यास्पद status structure में बँधे हों, लेकिन मेरा मानना है कि Jira में ticket को “done” करना या compiler warnings हटाना ही सब कुछ नहीं है। कोई भी यह नहीं कहता, “मैंने 40 साल हर बार अपने boss को खुश किया, इसलिए मुझे कोई पछतावा नहीं है”

  • मैं 40 में से 30 साल काम कर चुका हूँ, और boss तथा उसके ऊपर के bosses को संतुष्ट करने में निश्चित रूप से मूल्य था। भले ही cynical नज़रिया पूरी ज़िंदगी नहीं है, लेकिन इस cynical perspective को जानना आपको सच के थोड़ा और करीब लाता है
  • सच कहें तो “boss और boss के boss को खुश करना” ही नौकरी की परिभाषा है। कोई आपको जो करने को कहे, आप वह करें और उसके बदले पैसे लें

• कुल मिलाकर सहमत हूँ, लेकिन एक बात जोड़ना चाहूँगा: manager क्या चाहता है यह समझने के लिए कंपनी का business model समझना ज़रूरी है। कंपनी पैसा कैसे कमाती है और किसे मूल्यवान मानती है, यह आपको खुद समझना चाहिए। जब आप ऐसी जगह काम करते हैं जहाँ आपके काम का मेल कंपनी के values से होता है, तो compensation भी बेहतर होता है और satisfaction भी। ग्राहकों से, sales और marketing से, और जहाँ तक संभव हो executives से सीधे मिलना ज़रूरी है। भले ही आप केवल internal systems पर काम करें, यह जानना महत्वपूर्ण है कि वह system कहाँ value दे रहा है या किस चीज़ की रक्षा कर रहा है। अगर आपका विभाग साफ़ तौर पर value create नहीं कर रहा, तो किसी value-producing team में जाने पर विचार करना चाहिए। कंपनी की ज़रूरतों से मेल न खाने वाला काम करना मेरे लिए हमेशा बड़ी गलती साबित हुआ है

  • मुझे लगता है कि खुद को बढ़ई समझना ठीक है। development का काम spec के मुताबिक implementation करना है, लेकिन अगर spec बेतुका या असंभव हो तो उस समस्या को सीधे बताना चाहिए। अगर business side अपने काम को साफ़-साफ़ समझा नहीं सकती, तो इसका मतलब है कि उन्हें खुद भी ठीक से नहीं पता। और अगर developers को business भी अच्छी तरह समझना ज़रूरी है, तो उसके लिए compensation भी ज़रूर होना चाहिए। उतने समय में कोई तकनीकी रूप से और आगे बढ़ सकता है, इसलिए इसका opportunity cost भी है
  • यह मान लेना ही अक्सर गलत होता है कि “manager वास्तव में business को समझेगा और उसका ध्यान रखेगा”

• लेखक ने कहा कि “ऐसे परिणाम देने ज़रूरी हैं जो decision makers को दिखाई दें,” और मैं इस व्यक्ति की “business” mindset से सहमत हूँ। बहुत से developers इस बात को समझाने में संघर्ष करते हैं कि उनके काम का business benefit क्या है। refactoring भी इसी में आता है। code सुधारना short term में बिल्कुल बेकार लग सकता है, लेकिन कुछ परिस्थितियों में वह organization को बहुत बड़ा लाभ दे सकता है। आख़िरकार मूल बात यह है कि आप अपने काम को organization की revenue या cost savings से जोड़ सकें, और उसे communicate करने का तरीका भी सोचें

  • Developers को business language सीखनी चाहिए, और problems को इस तरह frame करना चाहिए कि business वाले लोग उन्हें समझें और उनकी परवाह करें। ज़्यादातर business decisions अंततः cost vs benefit ही होते हैं। वास्तव में बहुत से business लोग software को भी सिर्फ़ cost की तरह देखते हैं। यानी developers को यह बात स्वाभाविक लगती है कि “software revenue generation के केंद्र में है,” लेकिन business खुद software में दिलचस्पी नहीं रखता। अगर वे उसे मुफ़्त में बेच सकते, तो हर cost 0 होती और margin अनंत होता — business लोगों की असली सोच यही है। sales ऐसा क्षेत्र है जहाँ deals अक्सर logic से ज़्यादा माहौल, रिश्तों, यहाँ तक कि रिश्वत से भी बनती हैं। यह अव्यवहारिक लगे, फिर भी इसे समझना ज़रूरी है

• मेरे मन में सवाल है: “क्या यही mindset वजह है कि बहुत से engineers code quality, testing और documentation की परवाह नहीं करते?” अगर किसी को सिर्फ़ ऊपरी लोगों की तात्कालिक संतुष्टि की चिंता हो, तो कौन लंबे समय तक maintain किए जा सकने वाले code के लिए मेहनत करेगा? specification से ऊपर की quality ज़रूरी न भी हो, फिर भी न्यूनतम निवेश से ही अरबों बचाए जा सकते हैं

  • अब पहले से ज़्यादा लोग craftsmanship और quality की परवाह नहीं करते। “मैं उतना ही काम करता हूँ जितना salary के हिसाब से बनता है” जैसी आवाज़ें सुनाई देती हैं। पहले एक भावना थी कि वेतन चाहे जो हो, काम ईमानदारी से करना चाहिए; अब वह काफ़ी हद तक गायब लगती है
  • हर किसी के अपने role होने की वजह होती है। जैसे फ़िल्म निर्माण में अलग-अलग लोगों के अलग उद्देश्य होते हैं, वैसे ही engineers के भी अलग उद्देश्य हो सकते हैं। अगर आप engineers को अपना passion जीने नहीं देंगे, तो अंत में सिर्फ़ पैसे के पीछे चलने वाले लोग बचेंगे। यह जोखिम भरा है
  • मुझे नहीं लगता कि कोई जानबूझकर खराब code लिखता है। उदासीनता या burnout तब पैदा होती है जब बार-बार अतिरिक्त कोशिश का कोई reward नहीं मिलता। तब कोई भी extra effort नहीं लगाता। और बहुत से developers की बुनियादी क्षमता भी कमज़ोर होती है। यह actuarial profession जितना अत्यधिक competitive क्षेत्र नहीं है, इसलिए लगभग किसी भी background से लोग इसमें आ सकते हैं, और शुरू से ही सक्षम बनना आसान नहीं होता
  • बहुत से Product Managers सिर्फ़ speed चाहते हैं। हम testing और documentation चाहते हैं, लेकिन CFO इन्हें “feature नहीं है, इसलिए ज़रूरी नहीं” कहकर अनावश्यक समझते हैं
  • Engineers यह मानकर चलते हैं कि वे कंपनी में लंबे समय तक नहीं रहेंगे, इसलिए future responsibility लेने की भावना कम होती है। जब लोग बार-बार job change करते हैं, तो वे अपने पुराने workplace में लिखे code की समस्याएँ खुद झेलते ही नहीं, इसलिए failure से नहीं सीखते और वही गलती दोहराते हैं। मैं लगभग 20 साल से एक ही कंपनी में हूँ और वही गलतियाँ बार-बार होती देखी हैं। मूल समस्याओं को जस का तस छोड़कर सिर्फ़ ऊपर-ऊपर बदलाव करने वाली चीज़ों से मैं थक चुका हूँ। जब तक असली समस्या नहीं सुधरती, बदलाव का कोई मतलब नहीं। मेरा मकसद सचमुच समस्या हल करना है

• मैंने इस वास्तविकता और समस्याओं को बहुत बार देखा है, समझता भी हूँ, लेकिन फिर भी आपत्ति रखता हूँ। बहुत-से projects शुरू होते हैं, “समाधान हो गया, done!” कहा जाता है और team भंग कर दी जाती है। लेकिन product में अब भी issues बचे रहते हैं, features और चाहिए होते हैं, और कंपनी बदलती रहती है। नतीजतन खराब management के कारण सिर्फ़ technical debt जमा होता है। फिर नया manager आता है, पुराने project को नए नाम से फिर शुरू करता है, और वही गलतियाँ दोहराता है। यह तरीका अक्षम है। अगर air conditioner की मिसाल लें, तो तापमान को बार-बार बंद करके फिर नीचे लाने की बजाय उसे स्थिर रखना ज़्यादा efficient है। असल में मैंने जो management tool बनाया था, उसमें leadership की दिलचस्पी नहीं थी, लेकिन 500 से ज़्यादा internal users उसे इस्तेमाल करते थे क्योंकि उन्हें उसकी ज़रूरत थी। बिना maintenance में बहुत समय लगाए, भरोसा बनाए रखना ज़रूरी था। अगर उसे छोड़ दिया जाए, तो चीज़ें बिखर जाती हैं और tool की reliability भी खत्म हो जाती है। सिर्फ़ कुछ मिनट देकर भी consistency बनाए रखी जा सकती थी

  • air conditioner वाली मिसाल वास्तव में thermodynamics के हिसाब से गलत है। उसे बंद करके फिर ठंडा करना ज़्यादा efficient होता है

• मेरी भावनाएँ मिश्रित हैं। visibility और promotion के मामले में यह लेख सही है, लेकिन व्यवहार में यह managers-केंद्रित सलाह है कि बस manager को खुश करो। लेकिन अगर स्पष्ट दिशा ही न दी जाए और priorities लगातार बदलती रहें तो? तब meaningful result देना भी मुश्किल हो जाता है, और manager-subordinate रिश्ता पूरी तरह “yes-man” संरचना बन जाता है। यह अच्छा परिणाम नहीं है

  • जवाब सरल है। अगर आपको लगे कि आप किसी मूर्ख boss के नीचे काम कर रहे हैं, तो बस नौकरी छोड़ दें। तकलीफ़ अस्थायी होगी, लेकिन अंत में चीज़ें बेहतर होंगी। किसी बेवकूफ को अपना काम समझाने में समय बर्बाद करने से यह बहुत बेहतर है
  • उल्टा, अगर आप वाकई किसी अच्छे manager के साथ काम करें, तो सिर्फ़ “manager को संतुष्ट करने” से भी आपका career और output दोनों तेज़ी से बढ़ सकते हैं

• "unagentic engineer" का मतलब है कम स्वायत्तता वाला engineer। अगर engineers इस तरह काम करें, तो यह inefficiency और गंभीर समस्याओं तक ले जा सकता है, जैसे अत्यधिक cloud cost, security incidents, customer complaints आदि। कभी ख़त्म न होने वाले कामों के उदाहरण हैं: security patching, गलतियों को ठीक करना, cost optimization, और customer feedback का जवाब देना। अगर कंपनी इस value को नहीं समझती, तो job change करना ही जवाब है

  • लेख का सार यही है। कुछ organizations reality-centered होती हैं और कुछ status-centered। reality-centered organizations लंबे समय में अधिक rational होती हैं, जबकि status-centered organizations में सिर्फ़ boss को खुश करना ही उद्देश्य होता है। product quality या customer relationship से ज़्यादा hierarchy मायने रखती है। ज़रूरी नहीं कि ऐसी organizations तुरंत ढह जाएँ, लेकिन कभी न कभी वे अचानक गिर भी सकती हैं
  • “Unagentic” से मतलब ऐसे employee से है जिसमें agency, यानी खुद पहल करने की क्षमता, नहीं होती। आप चाहते हैं कि वह खुद ownership ले, लेकिन व्यवहार में developer इस जाल में फँस जाता है कि उसका अपना अस्तित्व ही अदृश्य हो जाए
  • ऐसा होना ज़रूरी नहीं, लेकिन अगर executives ध्यान नहीं देते, तो डिफ़ॉल्ट रूप से ऐसी culture बन जाती है। उदाहरण के लिए, मुझे interface design की बारीकियों पर ध्यान देना पसंद है। लेकिन उसका reward तभी मिलता है जब organization उसे value माने। बहुत-सी जगहों पर किसी को इसकी परवाह ही नहीं होती
  • “unagentic engineer” से आशय ऐसे व्यक्ति से है जिसमें proactive decision-making और नेतृत्व करके आगे बढ़ाने की कमी होती है; वह बस flow के साथ बहता रहता है
  • यानी ऐसा engineer जो autonomous नहीं है, जिसे निर्णय लेने का अधिकार कम है
  • “high agency” का उल्टा — यानी कोई व्यक्ति जो smart और capable दिखता है, लेकिन हमेशा निर्देश का इंतज़ार करता है और खुद पहल नहीं कर पाता

• मुझे "alignment(अलाइनमेंट)" जैसे buzzwords से बहुत चिढ़ है। फिर भी यह मूल रूप से एक महत्वपूर्ण अवधारणा है। आदर्श रूप में, मुझे, मेरे manager को, और उसके ऊपर के leadership को इस बात पर सहमत होना चाहिए कि सबसे महत्वपूर्ण काम क्या है। अगर ऐसा नहीं है, तो मेरे जैसे organization member के लिए यही समस्या है। यह सही है या न्यायपूर्ण, यह अलग बात है, लेकिन हमें उसी के अनुसार जीना पड़ता है। अंततः ऊपर से जो कहा जाता है, वही करने के लिए हमें पैसे मिलते हैं। बहुत कम लोगों को ऊपर की दिशा को प्रभावित करने का विशेषाधिकार मिलता है। उसी को so-called "managing up" कहते हैं

• मूल लेख उपयोगी है, लेकिन लगता है कुछ और भी महत्वपूर्ण बातें छूट गई हैं:

  • सही काम करने से भी ज़्यादा महत्वपूर्ण है सही team में काम करना
  • अच्छे PM और manager, अच्छे काम से भी ज़्यादा महत्वपूर्ण हैं
  • अच्छी reporting structure, परिणाम के value से भी ज़्यादा महत्वपूर्ण है
  • leadership goals से मेल खाने वाला काम, वास्तविक business operations को support करने वाले काम से कहीं ज़्यादा सराहा जाता है
  • हमेशा सब कुछ खुद कर लेने के लिए तैयार रहना चाहिए, और बड़ी कंपनियों की politics में collaboration के खिलाफ़ disincentives हमेशा मौजूद रहते हैं

[heal9179]

यहाँ की रायें ही असल में मुद्दे के केंद्र पर चोट कर रही हैं।

[roxie]

सही कहा हाहा