- बड़ी टेक कंपनियों का उत्पाद-केंद्रित कल्चर अल्पकालिक परिणाम और 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 शायद मौजूद ही नहीं होता
“न” की ताक़त
- 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 होता है
- लेखक खुद दूसरे प्रकार के हैं और गहरा तकनीकी संदर्भ और लंबी अवधि की जिम्मेदारी को प्राथमिकता देते हैं
- यह दृष्टिकोण आमतौर पर लाभकारी बड़े कॉर्पोरेट वातावरण में ही संभव होता है, जहाँ नसीब और चुनाव दोनों काम करते हैं
- अच्छी टीम मिलना किस्मत हो सकता है, लेकिन लंबे समय तक रुककर नेता के रूप में विकसित होना एक चुना गया विकल्प है
- ऐसी टीमें बाहर से अधिक प्रसिद्ध नहीं होतीं, लेकिन वे सतत मिशन और स्थिर इंजीनियरिंग संस्कृति बनाए रखती हैं
निष्कर्ष
- टेक इंडस्ट्री “जल्दी चलो” का नारा बार-बार दोहराती है, लेकिन गहराई और धैर्य का रास्ता भी मौजूद है
- स्पॉटलाइट का पीछा किए बिना भी अर्थपूर्ण और प्रभावी करियर बनाया जा सकता है
- समस्या के क्षेत्र में लंबे समय तक टिके रहकर सतत सिस्टम बनाना शायद सबसे महत्वाकांक्षी विकल्प है
अभी कोई टिप्पणी नहीं है.