- बड़ी टेक कंपनियों का उत्पाद-केंद्रित कल्चर अल्पकालिक परिणाम और visibility को प्राथमिकता देता है, जबकि इंफ्रास्ट्रक्चर और डेवलपर टूलिंग में सततता और सिस्टम स्टेवर्डशिप प्रमुख मूल्य के रूप में काम करते हैं
- लेखक Google की डेवलपर टूल्स और इंफ्रास्ट्रक्चर टीम में हैं, और वे leadership की visibility से ज्यादा इंजीनियर ग्राहक का भरोसा और दक्षता को प्राथमिकता देते हैं
- दीर्घकालिक सिस्टम स्टेवर्डशिप से जमा हुआ context और अनुभव Bigtrace जैसे बड़े पैमाने के प्रोजेक्ट की innovation में बदल गया
- अल्पकालिक स्पॉटलाइट का पीछा करने की बजाय भरोसा और तकनीकी प्रभाव को पूँजी बनाकर, जरूरत पड़ने पर “नहीं” कह सकने वाला राजनीतिक पूँजी हासिल की
- तेज़ी से बदलती टेक इंडस्ट्री के बावजूद भी, गहराई और स्थायित्व पर आधारित करियर path मौजूद है और यह दीर्घकालिक प्रभाव पैदा करने का एक वैकल्पिक मॉडल है
इंजीनियरिंग की अलग-अलग दुनिया
- Product टीम बाहरी ग्राहकों के लिए काम करती है और revenue, MAU (Monthly Active Users) जैसे अल्पकालिक metrics से performance को नापती है
- इस environment में leadership का ध्यान खींचने के लिए agility और visibility (spotlight) दोनों आवश्यक हैं
- इसके विपरीत, इंफ्रास्ट्रक्चर/डेवलपर टूल टीमें internal engineers को ग्राहक मानकर उत्पाद की performance और debugging में मदद करने वाले tools और systems बनाती हैं
- leadership का ध्यान कम होता है और PM hiring कठिन होने की संरचना के कारण टीम रनिंग engineer-केंद्रित होती है, यानी top-down नहीं बल्कि bottom-up मॉडल में
- टीम खुद यह define करती है कि किस समस्या का प्रभाव सबसे अधिक होगा और उसे solve करती है, जबकि leadership उस impact का सत्यापन करती है
स्टेवर्डशिप का चक्रवृद्धि प्रभाव
- Product वातावरण में speed मुख्य मुद्रा है, जबकि इंफ्रास्ट्रक्चर वातावरण में context मुख्य संपत्ति है
- अगर इंजीनियर को replaceable resource की तरह treat करें तो context चला जाता है और सिस्टम का tacit knowledge खो जाता है
- लंबी अवधि की स्टेवर्डशिप का पहला लाभ pattern recognition से आने वाली दक्षता है
- किसी एक domain में लंबे समय तक रुकने से नए requests को पुराने मामलों से जोड़कर तेज़ी से solve किया जा सकता है
- दूसरा लाभ है system-level innovation
- केवल लंबी अवधि की observability से ही दिखने वाली समस्याओं को इसी तरह हल किया जा सकता है, और इसका परिणाम था Bigtrace
- 2023 की शुरुआत में Google की कई टीमों ने performance trace data (TB~PB स्केल) को handle करने में समस्या देखी
- 1 साल के prototype research और feedback collection के बाद 2024 की शुरुआत में Bigtrace बनाया गया
- आज यह महीने में 2 अरब से अधिक traces process करता है और 100+ engineers इसका उपयोग करते हैं
- अगर मैं short-term प्रोजेक्ट बदलता रहता, तो Bigtrace शायद मौजूद ही नहीं होता
- केवल लंबी अवधि की observability से ही दिखने वाली समस्याओं को इसी तरह हल किया जा सकता है, और इसका परिणाम था Bigtrace
“न” की ताक़त
- High-visibility प्रोजेक्ट संसाधन और ध्यान लाते हैं, लेकिन साथ में political volatility और quality गिरने का risk भी लाते हैं
- लंबी अवधि की स्टेवर्डशिप से बना ट्रस्ट कैपिटल spotlights के लालच को ठुकराने की ताकत देता है
- उदाहरण: AI wave के बीच Perfetto में LLM integrate करने का दबाव आया, लेकिन हमने precision को core value मानकर सटीक तरीके से प्रतिक्रिया दी
- kernel debugging जैसे मामलों में accurate timestamps ज़रूरी हैं, इसलिए hallucination स्वीकार्य नहीं है
- लेकिन यह “सदैव मना करना” नहीं, बल्कि “जब तक सही तरीके से implement न हो, तब तक hold पर रखना” वाला दृष्टिकोण है
प्रभाव की वैकल्पिक मुद्रा
- स्पॉटलाइट से बाहर काम करने पर leadership visibility कम हो सकती है, लेकिन बदले में तकनीकी भरोसा और usefulness जैसी दूसरी currency मिलती है
- Shadow Hierarchy
- इंफ्रास्ट्रक्चर संगठन में अपने सीधे बॉस से ज्यादा अहम होता है कि ग्राहक संगठन के बॉस आपको मान्यता दें
- उदाहरण: अगर Pixel टीम कहे कि “Perfetto के बिना debugging संभव नहीं,” तो उसका प्रभाव सीधे leadership लाइन तक पहुँचता है
- यह राजनीति नहीं, बल्कि technical trust-based advocacy है, और promotion reviews में इसका strong evidence मिलता है
- Utility Ledger
- Utility: जब bug fix के दौरान कोई tool इस्तेमाल होता है, तभी उसकी शुद्ध utility प्रमाणित होती है
- Criticality: मुख्य product टीमों की सफलता से सीधा जुड़ा प्रभाव
- Ubiquity: कई संगठन एक ही traces साझा करके collaborate करते हैं
- Scale: PB-scale डेटा process करके architecture की मजबूती साबित करना
- इन metrics के संयोजन से संगठनात्मक बदलावों में भी अटल रहने वाला सतत प्रभाव बना रहता है
स्टाफ़ इंजीनियर के प्रकार और विकल्प
- Will Larson की किताब 『Staff Engineer』 के अनुसार स्टाफ इंजीनियर कई रूपों में होते हैं, जैसे Solver/Right Hand और Architect/Tech Lead
- पहला type management intent को execute करने वाला problem-solver है, दूसरा किसी specific domain का दीर्घकालिक owner होता है
- लेखक खुद दूसरे प्रकार के हैं और गहरा तकनीकी संदर्भ और लंबी अवधि की जिम्मेदारी को प्राथमिकता देते हैं
- यह दृष्टिकोण आमतौर पर लाभकारी बड़े कॉर्पोरेट वातावरण में ही संभव होता है, जहाँ नसीब और चुनाव दोनों काम करते हैं
- अच्छी टीम मिलना किस्मत हो सकता है, लेकिन लंबे समय तक रुककर नेता के रूप में विकसित होना एक चुना गया विकल्प है
- ऐसी टीमें बाहर से अधिक प्रसिद्ध नहीं होतीं, लेकिन वे सतत मिशन और स्थिर इंजीनियरिंग संस्कृति बनाए रखती हैं
निष्कर्ष
- टेक इंडस्ट्री “जल्दी चलो” का नारा बार-बार दोहराती है, लेकिन गहराई और धैर्य का रास्ता भी मौजूद है
- स्पॉटलाइट का पीछा किए बिना भी अर्थपूर्ण और प्रभावी करियर बनाया जा सकता है
- समस्या के क्षेत्र में लंबे समय तक टिके रहकर सतत सिस्टम बनाना शायद सबसे महत्वाकांक्षी विकल्प है
1 टिप्पणियां
Hacker News राय
25 साल से ज़्यादा काम करते हुए मैंने यह सीखा है कि, अगर आप अपनी कहानी और उपलब्धियों का मालिकाना खुद नहीं लेते तो कोई और उसका श्रेय ले जाएगा
खासकर बड़ी कंपनियों में, लोकप्रिय लोग अक्सर श्रेय ले जाते हैं
ज़रूरी नहीं कि आप स्पॉटलाइट में आएँ, लेकिन रिकॉर्ड छोड़ना महत्वपूर्ण है
आंतरिक दस्तावेज़ों या बाहरी प्रस्तुतियों के ज़रिए अपने योगदान को स्पष्ट रूप से दर्ज करना चाहिए
अगर आप लोकप्रिय नहीं हैं, तो बेसबॉल टीम में भी बेंच पर बैठना पड़ता है, और graduate school admissions या ML community में भी यही बात लागू होती है
दुनिया किसी तरह की लोकप्रियता-प्रतिस्पर्धा प्रणाली की तरह चलती है
अगर केवल काम करके उसका पुरस्कार पाने की बजाय self-promotion अनिवार्य है, तो मुझे लगता है कि अपना काम खुद own और control करना बेहतर है
मेरा मानना है कि कंपनी के भीतर विश्वास सबसे महत्वपूर्ण मुद्रा है
अगर आप लंबे समय तक कई सफल प्रोजेक्ट्स में शामिल रहते हैं, तो आख़िरकार leadership उस समानता को पहचान लेती है
प्रमोशन भले धीमा हो, लेकिन प्रतिष्ठा और नेटवर्क बनते जाते हैं और उससे स्थिर विकास मिलता है
आप पहले ही काफ़ी कमा चुके होते हैं, इसलिए credit में दिलचस्पी कम रह जाती है
अभी मेरे लिए संतुलन बना हुआ है, लेकिन लगता है ज़्यादातर लोगों के लिए ऐसा नहीं होता
यह सचमुच बहुत अच्छी तरह लिखा गया लेख है
सिर्फ़ “मुझे राजनीति पसंद नहीं” वाली भावना पर मत रुकिए, Infra और DevEx की राजनीतिक संरचना को समझना ज़रूरी है
मैंने Slack में 5 साल तक infrastructure PM के रूप में काम किया, लेकिन product launch process मुझे चौथे साल में जाकर समझ आया
असली बात internal customers (product engineers) की सफलता में मदद करना था, और ‘Shadow Hierarchy’ feedback प्रमोशन की कुंजी था
अगर आप इस तरह की internal success को optimize करते हैं, तो stability और career दोनों में उसका लाभ मिलता है
लेकिन यह business की बुनियादी सच्चाई को नज़रअंदाज़ करने वाला कोई cheat code नहीं है
लेखक ने product engineering और infrastructure engineering के मूल्यांकन के अंतर को अच्छी तरह पकड़ा है
लेकिन Google जैसे विशेष वातावरण पर आधारित यह सामान्यीकरण थोड़ा भोला लग सकता है
अगर market conditions या leadership priorities बदल जाएँ, तो आपने जो value बनाई है उसकी परिभाषा भी फिर से तय करनी पड़ती है
उसने ज़ोर देकर कहा कि उसका लेख सार्वभौमिक सफलता-मार्गदर्शिका नहीं है, और अलग माहौल में अलग रणनीति की ज़रूरत होती है
बड़ी कंपनियों में लोकप्रियता-मतदान जैसी समीक्षा आम है
कई बार लोगों का मूल्यांकन “community leadership” जैसे अस्पष्ट मानकों पर होता है
लेकिन मेरा मानना है कि चुपचाप अच्छा काम करना और दूसरों की मदद करना ही असली मूल्य है
इंजीनियर के सामने मज़बूत code और self-promotion में से एक चुनने की दुविधा खड़ी हो जाती है
अंततः सही incentive design ही संगठन संचालन का मुख्य बिंदु है
25 साल के करियर में मैंने ज़्यादातर हर 2 साल में कंपनी बदली, लेकिन मौजूदा कंपनी में 4 साल से हूँ
मैं एक internal platform बना रहा हूँ और वास्तविक customer problems हल कर रहा हूँ, और राजनीति से परे यही चीज़ मुझे रोज़ काम करने के लिए प्रेरित करती है
infrastructure और tooling engineer के रूप में मैं लंबे समय तक एक ही टीम में रहा हूँ, और इस लेख की बातें ज़मीन से जुड़ी लगती हैं
कभी-कभी आसान उपलब्धियाँ मिलती हैं, लेकिन ज़्यादातर काम शांत, संतोषजनक, रोज़मर्रा का technical work होता है
मैं भी product team की तुलना में infrastructure team में काम करना पसंद करता हूँ
वहाँ leadership के मूड-स्विंग्स से ज़्यादा आज़ादी मिलती है, और technical excellence पर ध्यान दिया जा सकता है
अभी मैं एक mid-sized company में चुपचाप दूसरी टीमों के infrastructure को बेहतर बनाने का काम enjoy कर रहा हूँ
अपने मूल्य की रक्षा के लिए इस तरह का लेख लिखना पड़े, यह स्थिति अपने आप में अच्छा संकेत नहीं है
हाँ, self-promotion और charisma प्रमोशन में मदद करते हैं, लेकिन दुनिया को और बदतर बनाकर ऐसा करना ज़रूरी नहीं है
Wozniak जैसे चुपचाप काम करने वाले लोग भी ज़रूरी हैं
लेखक स्पॉटलाइट से बच सका क्योंकि वह पहले से Staff Engineer था
startup के दिनों में उसने भरोसा बना लिया था, इसलिए खुद को ज़ाहिर करने की ज़रूरत नहीं पड़ी, लेकिन BigTech में राजनीति ज़्यादा थी
मैं अल्पकालिक लक्ष्य के तौर पर पैसा कमाकर निकल जाना चाहता था, लेकिन अपने से जूनियर intern को पहचान दिलाने में मदद करना उससे भी मुश्किल निकला
अब मेरे प्रोजेक्ट्स खुद ही visibility देते हैं, इसलिए अलग से प्रचार करने की ज़रूरत नहीं पड़ती
उसका कहना था कि Google में L3 के समय से ही, स्पॉटलाइट का पीछा किए बिना भी साथी इंजीनियरों के साथ sharing और collaboration के ज़रिए पर्याप्त पहचान मिल जाती थी
अगर आपके पास पर्याप्त पूंजी (चाहे सामाजिक हो या आर्थिक) हो, तो आप 3 साल तक टिक सकते हैं, और अगर दूसरे साल में नतीजे आ जाएँ, तो शुरुआती गलतियाँ भुला दी जाती हैं
असली समस्या गलत साबित होने के जोखिम की है
bug-free release के लिए मेहनत करने पर भी, आख़िर में तारीफ़ उसी व्यक्ति को मिलती है जिसने रात भर जागकर समस्या ठीक की
बेशक किस्मत की भी भूमिका होती है, लेकिन मेरा मानना है कि मौक़ा उसी को मिलता है जो तैयार हो