नए Principal Engineer के लिए सलाह
(eugeneyan.com)- Amazon के पूर्व इंजीनियर ने Principal (वरिष्ठ) Engineer/Scientist भूमिका के बारे में role models से देखी और सीखी गई बातों को 31 सलाहों में संक्षेपित किया है
- Principal वास्तव में product, design, engineering और culture—सभी को संभालने वाला बहु-भूमिका वाला व्यक्ति होता है, जो अपने judgment के आधार पर व्यापक काम करता है
- मुख्य बात coding से अधिक technical vision, design feedback और organizational alignment है; पिछली भूमिका में जो काम सबसे महत्वपूर्ण था, वह अब द्वितीयक हो जाता है
- जिन चीजों को संगठन अभी महत्व नहीं देता, उनमें मूल्य दिखाना काम का बड़ा हिस्सा है, और सिर्फ सही निर्णय लेने से अधिक दूसरों को सहमत कर कार्रवाई के लिए प्रेरित करने की क्षमता महत्वपूर्ण है
- उन कामों की श्रेणियों पर ध्यान दें जो Principal के बिना नहीं होंगी, और खुद करने से अधिक दूसरों को जोड़ना और विकसित करना अधिक मूल्यवान हो सकता है
- autonomy और accountability साथ-साथ आती हैं; संगठन को किन समस्याओं पर ध्यान देना चाहिए यह खुद पहचानना पड़ता है, और critical path से हटकर उससे सटे स्थान पर जाना लंबी अवधि में अधिक प्रभावी होता है
1-3. भूमिका का सार और शैली
- 1: हर Principal की शैली अलग होती है
- कोई एक क्षेत्र में बहुत गहराई तक जाने वाला प्रकार होता है, तो कोई horizontal influence में बहुत मजबूत होता है
- कोई technical pioneer होता है, कोई complexity को स्पष्ट करने वाला, तो कोई कई संगठनों को एक साझा vision पर align करने वाला
- अपनी strengths के अनुसार अपनी शैली खोजनी चाहिए, और कोई भी शैली दूसरी से अधिक महत्वपूर्ण नहीं है
> Amazon में Principal से hands-on होकर काम करने की स्पष्ट अपेक्षा की जाती है, और लंबे समय तक hands-on न रहने पर असफलता की संभावना बढ़ती है
- 2: पिछली भूमिका में जो मुख्य काम था, वह अब सहायक काम बन जाता है
- खुद code लिखना समय का सबसे अच्छा उपयोग न हो, लेकिन काम से जुड़े रहने के लिए coding अभी भी ज़रूरी है
- मुख्य भूमिका है technical vision, design feedback, sponsorship, business/product/technical context देना, नई समस्याएँ खोज निकालना और connections बनाना
> L7+ भूमिकाओं के बारे में एक प्रसिद्ध बात: चाहे 80% समय coding में जाए, सबसे बड़ा impact फिर भी सभी को अधिक प्रभावी बनाना होता है
> mindset को एक project पर coding-केंद्रित काम से बदलकर इस दिशा में ले जाना कि सभी builders बेहतर build कर सकें
> सिर्फ repository में high-quality code देना और code को अपने-आप बोलने देना ही नहीं, बल्कि design proposals पर feedback, technical guides लिखना, long-term vision को आगे बढ़ाना जैसी कोशिशें अधिक प्रभावी हो सकती हैं
- 3: tech के लिए part-time PM, और वास्तव में हर चीज़ के लिए part-timer
- product, design, engineering, science, QA, hiring, finance, culture—हर क्षेत्र में
- "ऐसी कोई चीज़ नहीं जो आपकी जिम्मेदारी से बाहर हो"
- उच्च स्तर का judgment आपको अपनी विशेषज्ञता के बाहर भी जाने में सक्षम बनाता है
4-7. communication और influence
- 4: आपकी भूमिका में अधिक communication, influence और सही लोगों को जोड़ना शामिल है
- projects आम तौर पर बड़े scope वाले होते हैं और Director से VP स्तर तक की टीमों को शामिल करते हैं
- प्रभावी alignment और collaboration के बिना सफलता संभव नहीं
- ध्यान रखें कि org chart ग्राहक तक न पहुँचे
- 5: सिर्फ सही होना आधे से भी कम काम है
- आपको दूसरों को यह यकीन दिलाना होता है कि आप सही हैं, और उससे भी महत्वपूर्ण, उन्हें इतना जुड़ाव महसूस कराना होता है कि वे कार्रवाई करें
- momentum बनाना, sponsors ढूँढ़ना और काम को पूरा कराने का तरीका समझना ज़रूरी है
> कभी-कभी यह पाने के लिए project शुरू करके उसका मूल्य दिखाना पड़ता है
> Principal को उदाहरण बनना चाहिए; लोग committee का इंतज़ार किए बिना समस्याएँ सुलझाने में सक्रिय हों, यही अपेक्षा है
> "Principal ही तो committee है, फिर आप किसका इंतज़ार कर रहे हैं :)"
- 6: जिन चीज़ों को संगठन महत्व नहीं देता, उनमें मूल्य सिखाना काम का बड़ा हिस्सा है
- आपका audience executives से लेकर individual contributors तक होता है
- यह सबसे कठिन कामों में से एक है और अक्सर असफल भी होता है, लेकिन भविष्य देखने और व्यापक दृष्टि रखने वाले व्यक्ति के रूप में इसे करना फिर भी ज़रूरी है
- एक mentor के अनुसार, 10 document proposals में से लगभग 3 लागू हो जाएँ तो वह बहुत अच्छा परिणाम माना जाता है
> रोज़मर्रा के team-level काम करने वाले ICs के विपरीत, L7+ भूमिकाओं के पास कंपनी को अधिक व्यापक और दीर्घकालिक दृष्टि से देखने की जगह होती है
> impact का अधिक वस्तुनिष्ठ आकलन किया जा सकता है, और उसी स्तर पर योगदान देना सबसे अधिक मूल्य जोड़ता है
- 7: ऐसे कामों की एक category होती है जो Principal के बिना नहीं होती
- आम तौर पर यह आपकी वास्तविक रुचि और आपकी उत्कृष्टता के intersection पर होती है
- तेज़ prototyping करके leadership के साथ नए customer experiences साझा करना, teams या industry practitioners के बीच पुल बनाना, 3-year vision लिखना आदि
- इसी category के कामों पर ध्यान देना चाहिए
- करियर आगे बढ़ने के साथ यह और गहरी तथा संकरी होती जाती है
8-11. दूसरों के माध्यम से scale करना
- 8: सबसे मूल्यवान काम अक्सर खुद करना नहीं, बल्कि जोड़ना होता है
- जो team किसी काम को करने जा रही है, उसे उस team से जोड़ना जिसने वह काम पहले किया हो, ताकि reuse या learning हो सके
- इसमें ऐसे सही लोगों की पहचान भी शामिल है जो वह काम कर सकें और उस प्रक्रिया में grow भी करें
- 9: आप अकेले जो कर सकते हैं, उसकी सीमा है
- दूसरों को coach और mentor करके अधिक प्रभावी बनाना, उसमें समय लगाना संगठन के लिए अधिक उपयोगी है
- हर सप्ताह कुछ घंटे दें, जैसे office hours या नियमित syncs
- 1-2 ऐसे ICs चुनें जिन्हें आप विकसित करना चाहते हैं, और तय करें कि उनकी मदद कैसे करनी है
> दूसरों के माध्यम से scale करना ही मूल बात है: PE (Principal Engineer) की सफलता तब है जब संगठन PE जैसे निर्णय खुद लेने लगे
> PE फिर किसी दूसरी अस्पष्ट समस्या पर जा सकता है और सही outcomes पाने वाली culture स्थापित कर सकता है
>
> आप सबकी मदद करना चाहते हैं, लेकिन लंबी अवधि में अपनी ही जगह ले सकने वाले लोगों को तैयार करने में ऊर्जा केंद्रित करनी चाहिए
> जिनमें ऐसी क्षमता दिखे, उन पर focused time लगाना चाहिए, ताकि वे आगे चलकर उन लोगों की मदद कर सकें जिनमें अभी कम potential दिखता है
- 10: दूसरों को काम में शामिल करने से आगे बढ़कर काम को उनका अपना बनाना
- किसी को वह काम करने का अवसर देना, जिसने आपको आज की स्थिति तक पहुँचाया
- support देना और उनकी सफलता के लिए setup तैयार करना
- customers के लिए महत्वपूर्ण समस्याओं और रोचक opportunities की backlog अंतहीन है, इसलिए चिंता की ज़रूरत नहीं
> सप्ताह में 1-2 घंटे किसी के साथ बिताकर उन्हें अपनी insights के सहारे 40 घंटे का काम करने योग्य बनाना, यही असली Principal scale है
- 11: जब आप किसी को काम देते हैं, तो वह अब उनका काम है
- आप context और guidance दे सकते हैं, लेकिन अंततः direction तय करना उनकी जिम्मेदारी है
- इसमें यह भी शामिल है कि वे ऐसा approach चुनें जो आप खुद शायद न चुनते
- अगर गलत हुआ, तो सब सीखेंगे; अगर सही हुआ, तो आप भी कुछ सीख सकते हैं
- लेकिन यदि project किसी high-risk one-way door की ओर जा रहा हो जो उल्टा असर डाल सकता है, तो हस्तक्षेप करना चाहिए
12-15. meetings और भागीदारी का प्रबंधन
- 12: meetings में दूसरों के लिए जगह बनाएँ
- कभी-कभी room सबसे senior व्यक्ति की राय या निर्णय की प्रतीक्षा करता है; आप सवाल पूछकर दूसरों के लिए जगह बना सकते हैं
- यदि कोई व्यक्ति भाग नहीं ले रहा, तो उसकी strengths से मेल खाने वाले विषय पर उसे सहज ढंग से बातचीत में शामिल करें
- यदि meeting में किसी ज़रूरी व्यक्ति को भूल गए हों, तो अगली meeting में उसे जोड़ें
- 13: हर समय अपना मूल्य साबित करना ज़रूरी नहीं है
- सबसे प्रभावी Principals कभी-कभी पूरी meeting में शांत रहते हैं या document review में बहुत कम comments देते हैं
- अगर team और discussion अच्छी तरह चल रहे हैं, तो यह बहुत अच्छी बात है
- आप workflow से एक कदम पीछे हटकर अपनी ऊर्जा कहीं और लगा सकते हैं
> सावधानी: अगर आप उपस्थित हैं और चुप हैं, तो इसे implicit approval माना जा सकता है; multitasking और सिर्फ मौजूद रहने के अर्थ को समझें
- 14: executives के साथ meeting में agenda के हर विषय को छूना ज़रूरी नहीं
- अगर executives किसी विषय में गहराई से जुड़ें, meaningful questions पूछें, और ऐसे निर्णय लें या बाधाएँ हटाएँ जो सिर्फ वही कर सकते हैं, तो meeting सफल है
- 15: इतनी व्यापक भूमिका में आपका पूरा सप्ताह आने वाली चीज़ों से भर सकता है
- reviews, escalations, emails, help requests आदि
- संगठन में जितना अधिक समय बिताते हैं, यह उतनी बड़ी समस्या बन सकती है, क्योंकि आप बहुत कुछ जानते हैं या trusted "go-to" व्यक्ति बन जाते हैं
- नतीजतन, आप हर meeting के "must-have" attendee बन जाते हैं
- अगर आपने अपने समय की रक्षा करना नहीं सीखा, तो जिन ideas में आपकी सचमुच रुचि है उन्हें आगे बढ़ाने का समय नहीं बचेगा
- आपको हर meeting में होने या हर idea पर राय देने की ज़रूरत नहीं, सिर्फ महत्वपूर्ण चीज़ों पर
> एक mentor की साझा की हुई बात: सोचने का समय अनिवार्य है; अगर आप meeting से meeting तक भागते रहेंगे, तो न process कर पाएँगे, न आगे देख पाएँगे
> अगली बड़ी चीज़ खोजने के लिए high-quality thinking time schedule करें और meetings से disconnect होना सीखें
>
> delegation का रास्ता ढूँढ़ना होगा: किसी और को उस भूमिका में तैयार करके समय बचाएँ; इससे न सिर्फ आप मुक्त होते हैं, बल्कि नए व्यक्ति के growth के लिए भी scope बनता है
16-19. impact और communication
- 16: अगर आप यह नहीं समझा सकते कि किसी काम पर Principal की आवश्यकता क्यों है, तो संभव है आप गलत चीज़ पर काम कर रहे हों (यह L6 पर भी लागू हो सकता है)
- 17: कभी-कभी आपकी position के कारण अपेक्षाकृत कम effort से परिणाम बेहतर किए जा सकते हैं
- title संगठनात्मक privilege देता है और relationships व context तक अधिक पहुँच प्रदान करता है
- experience के साथ मिलकर यह आपको मोड़ के आगे देखने में मदद करता है
- इसलिए अपेक्षाकृत कम effort लगाकर भी आप project की success probability और outcome को अर्थपूर्ण रूप से बेहतर बना सकते हैं
- यह high ROI है; ऐसी opportunities दिखें तो कार्रवाई करें
- 18: title कभी-कभी वहाँ भी credibility की आभा दे देता है जहाँ नहीं देनी चाहिए
- कभी-कभी लोग आपकी casual comments को ज़रूरत से ज़्यादा गंभीरता से ले लेते हैं, खासकर जब उन्हें विषय की पूरी जानकारी न हो
- नतीजतन, आपकी एक casual टिप्पणी की वजह से बहुत-सा काम शुरू हो सकता है
- इससे समय और effort की बर्बादी हो सकती है
- इसलिए आप क्या जानते हैं, क्या नहीं जानते, क्या request कर रहे हैं, और क्या सिर्फ टिप्पणी कर रहे हैं—इसे स्पष्ट रखें
- 19: सिर्फ "क्या" न कहें, यह भी बताएँ कि आप ऐसा "क्यों" सोचते हैं
- इससे दूसरे लोग बेहतर निर्णय ले पाते हैं
- इससे यह भी कम होता है कि लोग सिर्फ "Principal <नाम> ने ऐसा कहा, इसलिए हम..." कहकर बिना पूरी समझ के अनुसरण करें
> जिन समस्याओं में L7 input चाहिए होता है, उनमें अक्सर काफी uncertainty के बीच लिए जाने वाले निर्णय शामिल होते हैं
> एक महत्वपूर्ण लेकिन कठिन बात: अपने mental model को साफ़-साफ़ व्यक्त करना — बिना सारी जानकारी के आप निर्णय तक कैसे पहुँचे, और कुछ खास knowledge दूसरे data points से अधिक महत्वपूर्ण क्यों है
20-24. संगठन से जुड़े रहना
- 20: teams से जुड़े रहने के लिए mechanisms खोजें
- design reviews, weekly demos, पास बैठकर सुनना, team lunches, casual hallway conversations आदि
- इससे संगठन की pulse बनी रहती है और यह समझने में मदद मिलती है कि मुख्य समस्याएँ या opportunities कहाँ हैं
- 21: team को बड़ी तस्वीर देखते रहने में मदद करें
- जब execution level पर लोग रोज़मर्रा की delivery और काम के सबसे घने हिस्से में व्यस्त होते हैं, तो वे कभी-कभी बड़े और long-term problems/opportunities चूक सकते हैं और local optimum में फँस सकते हैं
- आपके पास मौजूद context के आधार पर आप team को यह याद दिलाने में मदद कर सकते हैं
- 22: practical रहें; big picture और local solutions को स्वीकार करने के बीच संतुलन रखें
- details पर execution-level लोगों से सलाह लें और ध्यान से सुनें; वही ground-level experts हैं
- 23: आपसे ऐसे व्यक्ति के review या promotion feedback की भी माँग हो सकती है जिसके साथ आपने सिर्फ एक-दो घंटे काम किया हो
- पूरे व्यवहार के बहुत छोटे sample के आधार पर low-quality feedback देने के बजाय आप मना कर सकते हैं
- 24: interns और mentors के साथ बातचीत के लिए समय निकालें
- internship के दौरान कुछ touchpoints भी transformative हो सकते हैं
- इसमें शुरुआती check-in (ज़रूरत हो तो दिशा सुधारने के लिए) और demo day में भाग लेना शामिल है
- mentor और intern के साथ मिलकर ऐसे outcomes पर काम करें जो internship के बाद भी मूल्यवान रहें
- जैसे product 1-pager, working software, technical documentation
25-28. Principal के रूप में transition और responsibility
- 25: Principal बनने के लिए आपको खुद को critical path पर रखना पड़ता है। Principal के रूप में प्रभावी होने और उससे आगे बढ़ने के लिए आपको सक्रिय रूप से खुद को वहाँ से हटाना पड़ता है
- पहले आप "go-to" व्यक्ति रहे होंगे, लेकिन अब essential से adjacent की ओर shift करना ज़रूरी है
- संगठन को आपसे लगातार अधिक लाभ मिलना चाहिए, लेकिन प्रभावी होने के लिए उसे आप पर निर्भर नहीं होना चाहिए
- सोचें कि आप जो योगदान देते हैं, उसे दूसरे लोग भी कैसे दे सकें
> critical path projects में खुद को inject करने से सावधान रहें: आपका focus दूसरी priorities से आसानी से खिंच सकता है; इसलिए critical path से बाहर रहें, या अगर उसमें हों तो बहुत सख्ती से स्थिर रहें
- 26: अगर आपको Principal के रूप में promote किया गया है, तो इसका मतलब है कि आप पहले से कुछ समय से Principal की तरह काम कर रहे थे
- आम तौर पर एक साल या उससे अधिक समय से
- इसलिए title बढ़ने के बाद की बढ़ी हुई expectations को लेकर ज़्यादा चिंतित होने की ज़रूरत नहीं
- जो कर रहे थे, वही करते रहें; दूसरे Principals से जुड़ें, अपनी शैली समझें, और leadership के साथ मिलकर focus areas पहचानें
- 27: बड़ी स्वतंत्रता के साथ बड़ी जिम्मेदारी आती है
- आपके पास यह autonomy होती है कि आप किस पर काम करें, लेकिन accountability और impact की अपेक्षा भी होती है
- यह स्वतंत्रता मनचाहा करने की नहीं, बल्कि सबसे high-leverage समस्याएँ खोजकर हल करने की ownership की बात है
- यह उम्मीद न करें कि कोई बताएगा क्या करना है, या कोई स्पष्ट guide देगा
- आपसे अपेक्षा की जाती है कि आप समझें संगठन को किस पर ध्यान देना चाहिए
- 28: leadership के साथ charter को define और align करें
- एक तरीका है काम को तीन buckets में बाँटना — (i) owner, (ii) sponsor, (iii) consultant
- consultant: reviews में भाग लेना, guidance देना, system या product intent की high-level समझ रखना
- sponsor: ऊपर की चीज़ों के अलावा ideas को organizational priority बनाना, alignment और decision-driving के लिए काम करना, stakeholders से जुड़ना
- owner: ऊपर की सब चीज़ों के अलावा system expert होना, पहला contact point होना, और design, execution, impact की सफलता के प्रति लगभग obsessive स्तर की प्रतिबद्धता रखना
- लेखक आम तौर पर 1-2 projects own करते हैं (>50% समय), 2-3 projects sponsor करते हैं (~20% समय), और बाकी समय consulting में लगाते हैं
29-31. व्यक्तिगत विकास और sustainability
- 29: Principal बनना अकेलापन ला सकता है
- आप हर team का हिस्सा भी होते हैं, और किसी एक team का पूरा हिस्सा भी नहीं
- ऐसे peers का network बनाएँ जिनसे खुलकर बात की जा सके
- यह ज़रूरी नहीं कि वे उसी company या domain में हों
- 30: अपनी ज़रूरतों को नज़रअंदाज़ न करें
- learning, growth और well-being को support करने वाले projects के लिए समय और जगह बनाएँ
- अल्पकाल में यह स्वार्थी लग सकता है, लेकिन संगठन के भीतर burnout होने से यह कहीं बेहतर है
- अगर आप खुद को स्वस्थ, खुश और विकसित बनाए रखने वाले काम सक्रिय रूप से खोजते हैं, तो संगठन को भी उसका लाभ मिलता है और संगठन के लिए आपको बनाए रखना आसान होता है
- balance कैसे रखना है, यह समझने के लिए manager के साथ काम करें
- 31: सीखते रहिए; industry बहुत तेज़ी से बदलती है
- अगर आप ऐसे project पर जाते हैं जो आपको कुछ नहीं सिखाता, या कम से कम आपके काम से संबंधित कुछ नहीं सिखाता, तो आप पीछे जा रहे हैं
- कभी-कभी यह टाला नहीं जा सकता; ऐसे project आएँ तो उन्हें timebox करें
- learning सिर्फ job से ही आए, यह ज़रूरी नहीं
- कुछ PEs papers और technical textbooks पढ़ते हैं, और weekends पर prototypes hack करके नए ideas और technologies को बेहतर समझते हैं
अन्य resources
- Amazon Principal Engineering Community Tenets
- Staff Engineer: Leadership Beyond the Management Track
- The Staff Engineer's Path: A Guide for ICs Navigating Growth and Change
- The job behind the job [of a high level IC]
संदर्भ: Amazon/Google में Principal Tech IC का अर्थ "management के समकक्ष रणनीतिक भूमिका निभाने वाला शीर्ष तकनीकी नेता" है, इसलिए यह भारत/कोरिया में सामान्यतः समझे जाने वाले "वरिष्ठ इंजीनियर" से कहीं अधिक वरिष्ठ अवधारणा है
1 टिप्पणियां
"बिना सारी जानकारी के किसी निष्कर्ष तक कैसे पहुँचना है, और क्यों कुछ खास ज्ञान अन्य डेटा पॉइंट्स की तुलना में अधिक महत्वपूर्ण है" यह तय कर पाना वाकई शानदार बात लगती है।