इंजीनियर से मैनेजर तक: जो पसंद आया और जो नहीं

 (thoughtspile.github.io)
1 पॉइंट द्वारा GN⁺ 2024-02-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 7 साल तक frontend developer के रूप में काम करने के बाद team lead और फिर full-time engineering manager बनने पर, product और team पर असर बढ़ा, लेकिन काम की प्रकृति काफी बदल गई
  • Manager, tests लिखना, process सुधारना और team dynamics को ठीक करना जैसे उन मुद्दों में औपचारिक और अनौपचारिक अधिकार से दखल दे सकता है जिन्हें IC रहते बदलना मुश्किल था
  • लंबे career में compensation सामान्य engineer levels से बेहतर होता है, staff+ IC की तुलना में opportunities व्यापक होती हैं, और दूसरे technical domains, project management, product management या startup शुरू करने में काम आने वाली transferable skills मिलती हैं
  • दूसरी तरफ performance reviews, अवास्तविक deadlines और organizational policies जैसी corporate procedures लागू करनी पड़ती हैं, और conflicts, psychological anxiety और हमेशा उपलब्ध रहने के दबाव को सीधे झेलना पड़ता है
  • Management work के नतीजे एक महीने के भीतर दिखना मुश्किल होते हैं; team split या hiring जैसे सही बदलाव भी short term में स्थिति खराब कर सकते हैं, इसलिए लंबे feedback loops सहने पड़ते हैं

इंजीनियर से मैनेजर बनने की प्रक्रिया

  • लगभग 2 साल पहले team lead की भूमिका में गए, और team बढ़ने के बाद full-time engineering manager बने
  • उससे पहले 7 साल तक frontend developer के रूप में काम किया था; शुरुआत में senior individual contributor (IC) career track चुना था, फिर management में switch किया
  • transition ऊबड़-खाबड़ था, लेकिन दिलचस्प भी रहा; मौजूदा काम में पसंद और नापसंद दोनों तरह की चीजें हैं

Manager role में पसंद आने वाली बातें

  • Product और team को बदलने का अधिकार

    • Manager बनने पर product और team की overall स्थिति सुधारने का अधिकार मिलता है
    • IC रहते सुबह-सुबह standup, कम code quality, या समझने में मुश्किल नई features जैसी समस्याओं को बदलना मुश्किल हो सकता है
    • EM औपचारिक और अनौपचारिक authority के जरिए team और खुद को बेहतर तरीके से काम करने के लिए align कर सकता है
    • “हमें tests लिखने चाहिए” जैसी वही बात IC के मुंह से और EM के मुंह से अलग वजन रखती है, और EM की बात सच में tests लिखवाने तक पहुंच सकती है

  • ज्यादा व्यापक career opportunities

    • Engineering manager, सामान्य engineering track की तुलना में व्यापक career opportunities देता है
    • EM को आम तौर पर junior, middle, senior जैसे basic team-level engineer roles से ज्यादा compensation मिलता है
    • staff, principal जैसे ऊंचे IC levels भी EM या उससे ऊपर के compensation bands में होते हैं
    • लेकिन staff+ IC jobs आम तौर पर कठिन technical challenges वाली बड़ी tech companies में केंद्रित होती हैं, जबकि लगभग हर company की software team में leadership positions होती हैं
    • Management career ladder IC से ज्यादा ऊपर तक जाती है
    • CTO बनने की संभावना भले कम हो, लेकिन management experience के बिना pure IC के पास जो विकल्प नहीं होते, वे खुल जाते हैं
    • EM की demand staff+ engineers की demand से ज्यादा stable होती है, और career के बाद के हिस्से में भी ज्यादा opportunities देती है

  • दूसरे क्षेत्रों में जाना आसान बनाने वाली skills

    • Management skills किसी खास IC engineering role की तुलना में ज्यादा व्यापक रूप से इस्तेमाल होती हैं
    • React experience वाला frontend engineer किसी दूसरे frontend framework में जा सकता है, या थोड़े level loss को स्वीकार कर backend या mobile role में switch कर सकता है
    • Engineering manager experience होने पर mobile developers की team, infrastructure team, या ML engineers की team जैसी अलग focus वाली teams संभालना भी आसान होता है
    • नई team की बड़ी technical कठिनाइयों को समझने में समय लगेगा, लेकिन कई companies ऐसे transitions स्वीकार कर सकती हैं
    • अगर EM बने रहना नहीं चाहते, तो project management या product management roles में जाने के लिए अच्छी position में होते हैं
    • अगर पूरा tech market सुस्त भी हो जाए, तो कई management skills दूसरी industries में भी काम कर सकती हैं
    • लोगों और business decisions से जुड़ा experience startup शुरू करने से पहले की training के रूप में भी उपयोगी है

  • Knowledge इतनी जल्दी पुरानी नहीं होती

    • अगर latest frontend frameworks और tools के साथ बने रहने की थकान है, तो management role बोझ कम कर सकता है
    • “नई” agile, kanban, scrum methodologies 20–30 साल पुराने concepts हैं, और demos, dailies, 1:1 जैसी basic meeting types लंबे समय में विकसित हुई हैं
    • Management के मूल में teamwork और human interaction है, और ये मानव सभ्यता की शुरुआत से बहुत ज्यादा नहीं बदले हैं
    • Technology changes पर नजर रखना जरूरी है, लेकिन जल्दी-जल्दी गहराई में उतरने की जरूरत अपेक्षाकृत कम होती है

  • परिचित technical problems से बाहर नई challenges

    • किसी खास technical domain में 4–5 साल काम करने के बाद अधिकतर practical problems को पर्याप्त रूप से हल करना आ जाता है
    • अनुभवी engineers के लिए बड़ी चुनौतियां ढूंढने के तरीकों की सीमाएं होती हैं
    • नया frontend framework अपनाने जैसे stack को थोड़ा बदलने वाले तरीके लंबे समय तक दिलचस्पी बनाए रखना मुश्किल बनाते हैं
    • frontend से backend में जाने जैसा बड़ा switch कुछ सालों का मजा दे सकता है, लेकिन यह संयोग से हो सकता है या compensation पर असर डाल सकता है
    • नई library से सब कुछ दोबारा लिखना या future के लिए 9000 RPS handle करने जैसी समस्याएं खुद पैदा करना मजेदार हो सकता है, लेकिन अक्सर team और business के लिए नुकसानदायक होता है
    • अनुभवी engineer के लिए management में जाना compensation घटाए बिना सबसे ज्यादा नई सीखने की चीजें देता है

Manager role में नापसंद आने वाली बातें

  • Corporate procedures लागू करनी पड़ती हैं

    • Engineer रहते personal performance reviews, बेकार deadlines, और company द्वारा थोपी गई process या tech stack restrictions जैसी corporate BS से नफरत थी
    • Manager बनने पर, इन practices पर विश्वास हो या न हो, उन्हें लागू करने वाला व्यक्ति बनना पड़ता है
    • performance calibration वाले organizations में team leader को हर 6 महीने में ऐसे 1 व्यक्ति का नाम देना पड़ता है जिसने पर्याप्त मेहनत नहीं की
    • अगर आप sacrifice किए जाने वाले team member का नाम नहीं देते, तो बाद की process में किसी को random चुना जा सकता है, इसलिए process को हटाना मुश्किल होता है
    • कुछ procedures पर negotiation की जा सकती है या उन्हें bypass किया जा सकता है; उदाहरण के लिए “below expectations performance” को round-robin तरीके से assign किया जा सकता है
    • Team के नजरिए से manager कभी-कभी corporate monster जैसा दिख सकता है
    • Layoff, shutdown, reorg जैसी ज्यादा कठिन स्थितियों का अभी सामना नहीं किया है

  • लोगों के बीच तनाव संभालना पड़ता है

    • Engineering manager बनने की शुरुआत कुछ अच्छा बनाने की क्षमता से हुई थी, और उम्मीद थी कि technical decisions में मदद, career advice, process tuning और automation building करना होगा
    • असल काम का बड़ा हिस्सा लोगों के social tensions और psychological anxiety को debug करना है
    • उदाहरण स्थितियां:
      • Junior engineer ने feature preview deploy करने के लिए कुछ tests comment out कर दिए
      • QA प्रभारी व्यक्ति ने महसूस किया कि team QA role और उसकी value का सम्मान नहीं करती, और वह बहुत नाराज हो गया
      • Manager को trust वापस बनाना पड़ता है
    • एक और उदाहरण:
      • Project manager ने एक खराब joke कर दिया, और designer को चोट लगी और वह रो पड़ी
      • Manager को PM से apology करवानी पड़ती है
    • Psychologist नहीं हूं और लोगों से बहुत अच्छा deal करने वाला भी नहीं हूं, इसलिए यह हिस्सा कठिन है; यह अभ्यस्त होने तक टिके रहने जैसा है

  • Offline होना मुश्किल बनाने वाला work structure

    • Engineer की जिंदगी अपेक्षाकृत relaxed हो सकती है
    • अगर urgent काम नहीं है, तो आधा दिन बाहर रहकर project के future के बारे में सोच सकते हैं, और कुछ meetings अचानक miss कर देने पर भी बड़ा issue नहीं हो सकता
    • EM कुछ घंटों के लिए दूर हो जाए तो messenger में समस्याएं जमा हो जाती हैं
      • Intern npm install करना भूल गया और काम नहीं कर पा रहा
      • Senior manager potential feature पर चर्चा करना चाहता है
      • Release बिगड़ गया
    • जिन meetings को आपको चलाना या organize करना है, उन्हें बिना तैयारी के skip करना मुश्किल होता है
    • Team mature हो और processes बेहतर हों तो सुधार हो सकता है, लेकिन आम तौर पर managers office hours को ज्यादा तीव्रता से महसूस करते हैं
    • Work-life balance सीधे इस पर निर्भर करने लगता है कि आप अपना काम कितना अच्छे से कर पाते हैं

  • Feedback loops लंबे और non-linear होते हैं

    • अधिकांश engineering work के results अपेक्षाकृत जल्दी दिखते हैं
    • नई feature के results कुछ हफ्तों से कुछ महीनों में आ जाते हैं, और bug fix करने पर अगले दिन user response देखा जा सकता है
    • Refactoring में कुछ घंटों के भीतर complexity घटती दिख सकती है
    • Manager की actions शायद ही कभी एक महीने के भीतर दिखाई देने वाले results देती हैं
    • अगर team बहुत बड़ी हो गई है और उसे split करना है, तो कई steps से गुजरना पड़ता है
      • नई team के लिए engineers का सही mix तय करना
      • stakeholders से बदलाव को लेकर उनकी feelings पर बात करना
      • नई recurring meetings बनाना
      • process और communication सेट करना
      • Jira से जुड़ा काम संभालना
      • कुछ cases में sub-product के codebase को अलग करना
    • अगर लगता है कि यह सब एक हफ्ते में खत्म किया जा सकता है, तो यह गलत है
    • सही बदलाव भी बेहतर होने से पहले खराब लग सकते हैं
    • अगर staffing कम है और hiring का फैसला किया जाता है, तो short term में interviews में बहुत समय जाता है, और नए team members तुरंत speed नहीं पकड़ते, onboarding time चाहिए होता है
    • Management changes quick fixes से ज्यादा large-scale refactoring जैसे होते हैं, और immediate improvement न दिखना frustration पैदा कर सकता है

Transition पर विचार कर रहे engineers के लिए

  • IC engineer से management में जाना उजले और अंधेरे दोनों पहलुओं वाला rollercoaster अनुभव है
  • फायदे हैं product और team पर ज्यादा व्यापक असर, long-term career track के रूप में ज्यादा opportunities और flexibility, और technical field से boredom होने पर नई challenge मिलना
  • नुकसान हैं corporate policies लागू करना, social tension और psychological anxiety संभालना, offline होना मुश्किल बनाने वाला work structure, और बहुत delayed gratification तथा लंबे feedback loops
  • अगर challenges और responsibility पसंद हैं और मौका है, तो कोशिश करने लायक है
  • Management हर किसी के लिए सही नहीं है, लेकिन यह skills का दायरा बढ़ा सकता है और engineering work को नए angle से देखने का अनुभव दे सकता है
  • अगर बिल्कुल fit नहीं बैठता, तो coding में लौटने के लिए भी पर्याप्त समय होता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-02-19
Hacker News की राय

  • मैंने चार बार मैनेजर की भूमिका निभाई है, जिनमें दो बार FAANG में, लेकिन मूल लेख की कई बातों से सहमत नहीं हूँ
    मैनेजर की सीढ़ी वास्तव में कोई ऊँची नहीं होती, और ज़्यादातर engineering managers L6/स्टाफ इंजीनियर के बराबर स्तर पर ही रहते हैं। सीनियर मैनेजर से ऊपर प्रमोशन हालात पर बहुत निर्भर और दुर्लभ होते हैं, जबकि इंजीनियरिंग ट्रैक के साथी तैयार होते ही, सितारे एक लाइन में आने का इंतज़ार किए बिना, प्रमोट हो जाते हैं
    जो लोग सिर्फ engineering manager रहे और फिर नौकरी से निकाले गए, वे अब भी नौकरी ढूँढ रहे हैं और कई तो लगभग हार मानने की स्थिति में हैं, लेकिन जो IC में वापस जा सकते हैं उन्हें नौकरी पाने में आम तौर पर बड़ी दिक्कत नहीं होती। हर कंपनी की management culture बहुत अलग होती है, इसलिए उसे सीधे दूसरी जगह ले जाना आसान नहीं, और इस इंडस्ट्री में सबसे ज़्यादा transferable skill मुझे Linux internals लगती है
    यह सोचना भी अजीब है कि 5 साल के अनुभव के बाद आप ज़्यादातर समस्याएँ हल कर सकते हैं। 18 साल काम करने के बाद भी बहुत कुछ है जो मुझे नहीं पता, और बहुत कुछ है जिसमें बेहतर होना है, और 40 साल के अनुभवी शानदार इंजीनियर भी लगातार सीखते रहते हैं
    मैनेजर होने की सबसे अच्छी बात यह है कि आपको भविष्य के बारे में सोचने में बहुत समय मिलता है, और उस “कमरे” में जाने की संभावना बढ़ जाती है जहाँ C-level लोगों से बात होती है। साथ ही यह सबसे बुरी बात भी है, क्योंकि तब आपको बहुत साफ़ दिखने लगता है कि फैसले कैसे बनते हैं
    जिन हिस्सों को मूल लेखक ने नापसंद किया, उनसे मैं सहमत हूँ, लेकिन समय के साथ वे बेहतर हो जाते हैं। लेकिन अगर आप नए मैनेजर हैं, तो शायद आपने अभी तक वह हिस्सा नहीं देखा होगा जो सबसे बुरा लग सकता है: कई कंपनियों में ऊपरी प्रबंधन हाई स्कूल के गुटों की तरह व्यवहार करता है, और VP, C-level, कभी-कभी director स्तर के लोगों का ऐसा व्यवहार भी चलता रहता है जिसके लिए कोई सामान्य कर्मचारी होता तो निकाल दिया जाता

    • “इंजीनियरिंग ट्रैक के साथी तैयार होते ही प्रमोट हो जाते हैं” वाली बात confirmation bias और survivor bias मिली हुई एक कहानी जैसी लगती है
      ज़्यादातर software engineers सीनियर स्तर पर ही अटक जाते हैं, और Google में तो खासकर ऐसा ज़्यादा होता है, इसलिए L6 तक पहुँचना ही अपने आप में एक तरह का relative privilege है। L6 प्रमोशन बहुत दुर्लभ नहीं है, लेकिन यह भी नहीं कि आधे से ज़्यादा लोगों को मिल जाए, और L7 या उससे ऊपर पहुँचना कठिन है। अगर आपको लगता है कि आपके ज़्यादातर साथी सहज रूप से वहाँ तक पहुँच जाते हैं, तो शायद आपने उन लोगों को गिनती से बाहर कर दिया है जो प्रमोट न होने पर चले गए, या आपसे नीचे level के लोगों से घुलने-मिलने के मौके कम रहे हैं
      मैं इस बात से सहमत हूँ कि engineering manager का रास्ता उतने दरवाज़े नहीं खोलता जितना लोग पहले समझते थे, लेकिन यह IC की तुलना में प्रमोशन के मामले में ज़्यादा संकरा रास्ता भी नहीं लगता
    • यह बात भी अजीब लगी कि मूल लेखक ने engineering manager को founder बनने का अच्छा रास्ता माना
      0 से 1 बनाना engineering management से लगभग असंबंधित है। सबसे अहम चीज़ है जल्दी code लिख पाने की क्षमता और संभावित customers से सहजता से बात करना, और इन दोनों का engineering manager की भूमिका से सीधा संबंध नहीं है। यह भी कोई गारंटी नहीं कि आपको कभी manage करने के लिए लोग hiring करने पड़ेंगे
      management roles संरचनात्मक रूप से engineering roles की तुलना में काफ़ी कम होते हैं, और lead engineer व first-line manager के बीच की सीमा दोनों दिशाओं में काफ़ी धुंधली होती है, इसलिए वास्तविक competition pool उतना छोटा भी नहीं हो जाता
    • मैंने कभी big tech में काम नहीं किया, और staff level से ऊपर के ICs के साथ भी काम नहीं किया। principal या fellow प्रमोशन भी काफ़ी दुर्लभ लगते हैं, और ज़्यादातर “साधारण” कंपनियों में तो ऐसे grade होते ही नहीं
      transferable होने का मतलब है कि ऐसी skills जो big tech bubble के बाहर भी काम आएँ। हो सकता है कि पैसे अच्छे हों इसलिए आप बाहर जाना न चाहें, लेकिन यह जानना अच्छा है कि कंप्यूटर से beep-beep करवाने के अलावा भी आप बहुत कुछ कर सकते हैं
    • अच्छा लगा कि Linux internals को सबसे ज़्यादा transferable skill मानने वाला मैं अकेला नहीं हूँ
    • मेरी और मूल लेखक की राय में जो फ़र्क था, वह भूमिका के मूलभूत अंतर से ज़्यादा शायद उस जगह की विशेषताओं का नतीजा हो सकता है जहाँ वह व्यक्ति काम करता है
      उदाहरण के लिए, यह सोचना कि “हमें और testing करनी चाहिए” जैसी बात अगर IC की जगह engineering manager कहे तो उसे ज़्यादा गंभीरता से लिया जाएगा
      सच कहूँ तो, जब मैं अभी-अभी staff स्तर पर प्रमोट हुआ IC था, तब मुझे भी लगता था कि मेरी credibility कम है, इसलिए title के पीछे छिपना मददगार हो सकता है, और उसी वजह से management में जाने का मन हुआ था। हक़ीक़त में इसकी ज़रूरत नहीं थी, और अब दूसरी कंपनी में IC के रूप में मेरे विचार और feedback को संगठन स्तर पर और सहकर्मियों द्वारा गंभीरता से लिया जाता है
      हर आधे साल में forced ranking करके कम प्रदर्शन करने वाले लोगों को चुनने वाली व्यवस्था एक टूटी हुई प्रणाली है। कई जगह performance management की यही दुखद हक़ीक़त है, लेकिन यह कोई सार्वभौमिक सच नहीं कि मैनेजर होने का मतलब यही होगा। असली performance issues पर कठिन बातचीत से सांख्यिकीय रूप से बचना संभव नहीं, लेकिन ऐसी कंपनियाँ भी हैं जहाँ आपको यह नहीं कहना पड़ता कि “इस half में टीम के सभी लोग आपसे बेहतर थे” या “किसी एक को चुनना ही था, इसलिए इस बार आपकी बारी आ गई”

  • मुझे समस्या-समाधान और big picture पसंद है, और समाधान ढूँढ़कर रुकावटें दूर करना अच्छा लगता है। जो भूमिका मुझ पर सबसे अच्छी बैठी, वह “architect” थी, लेकिन लगता है कि यह title के रूप में धीरे-धीरे गायब हो रही है। फिर भी उस काम की ज़रूरत खत्म नहीं हुई है
    मैंने team lead/manager, Scrum Master, product manager की भूमिकाएँ भी की हैं, लेकिन एक अच्छे manager के लिए ज़रूरी skills engineer से बहुत अलग होते हैं। असली बात है बेहद कम neuroticism, यानी लंबे समय तक stress में भी अच्छे फ़ैसले लेने और बाहर से शांत व तर्कसंगत बने रहने की क्षमता
    lower management के 90% लोगों में यह गुण नहीं होता, और stress में वे team और company दोनों को नुकसान पहुँचाते हैं। अगर आप manager बनना चाहते हैं, तो आपको ईमानदारी से आँकना चाहिए कि लंबे समय तक रहने वाले stress पर आपकी प्रतिक्रिया कैसी होती है। क्या आप आसपास के लोगों पर गुस्सा निकालते हैं, छिप जाते हैं या freeze होकर फ़ैसला नहीं कर पाते, या दूसरों पर दोष डालकर अपनी reputation बचाने की कोशिश करते हैं—ऐसी दिखने में उबाऊ बातें ही असरदार manager और बाकियों के बीच असली फ़र्क बनाती हैं

    • यह summary सचमुच बहुत अच्छी है। इसलिए management मुझे बच्चों की परवरिश जैसा लगता है। एक अच्छे manager को adult की भूमिका निभानी आनी चाहिए
      आम तौर पर इसमें वे समस्याएँ सामने लाना शामिल होता है जिनसे सब बचते हैं, लोगों को मेरे फ़ैसलों पर मिलकर शिकायतें निकालने देना, और सामने वाला disengage होकर दूर धकेले तब भी जुड़े रहना—यानी काफ़ी unglamorous काम
      मुझे management ऐसा लगा जैसे मेरे पास जितने भी चम्मच हैं वे सब माँगे जा रहे हों, और फिर भी और माँगा जा रहा हो। लेकिन मैं इसे management की मूल प्रकृति से ज़्यादा मेरे साथ उसकी compatibility का मुद्दा मानता हूँ। इंटरनेट surveys के हिसाब से मेरा neuroticism मध्यम स्तर का है, लेकिन “काफ़ी अच्छा है” पर रुकने में मैं कमज़ोर हूँ, और management की फैली हुई responsibility emotionally scalability की समस्या पैदा करती है
    • जिन managers के साथ मैंने काम किया, उनमें सबसे प्रभावी लोग अक्सर शांत और low-stress देशों से थे, जहाँ काम की संस्कृति भी कुछ मिलती-जुलती थी
      शायद crunch और burnout का असली हल ऐसा regulatory environment बनाना है जहाँ कामगार की पूरी आजीविका—जैसे health, rent, public university student loan repayment—सिर्फ नौकरी बची रहने पर निर्भर न हो
    • मेरे अनुभव में ज़्यादातर “big picture देखने वाले” लोग अक्सर बिना यह समझे बोलते रहते हैं कि वे क्या कह रहे हैं, उसका मतलब क्या है, उसका नतीजा क्या होगा, उसे लागू कैसे करना है, या वह बुरा idea क्यों है
    • मैं भी उसी तरह का generalist problem solver हूँ, और एक साल से थोड़ा ज़्यादा management करने के बाद मैं भी उसी नतीजे पर पहुँचा हूँ। मुख्य skill है stress से उबरने की क्षमता
      अगर आप IC हैं, तो नई technology या domain सीखकर अपना career बढ़ा सकते हैं, लेकिन manager के लिए career development धीरे-धीरे maturity, perspective, और emotional resilience जैसे निजी विकास पर टिकने लगता है। शायद इसी वजह से seniority के साथ mindfulness meditation जैसी चीज़ों में रुचि भी बढ़ती है
      HN को यह पसंद नहीं आएगा, लेकिन मैं भी single होने के बावजूद सोचता हूँ कि क्या parents बेहतर manager बनते हैं। शायद इसलिए कि वे बड़े परिप्रेक्ष्य में कम महत्वपूर्ण चीज़ों पर perspective नहीं खोते और कम stress लेते हैं। अजीब तरह से, emotionally एक कदम पीछे हटे रहने पर ही management सबसे अच्छा होता दिखता है
      अब मुझे लगता है कि स्वभाव से मैं काफ़ी sensitive हूँ, इसलिए निजी तौर पर चिंता होती है कि कहीं constitutionally management role के लिए अनुकूल ही न हूँ। “लोगों को control नहीं, motivate करना” जैसी कभी-कभी पाखंडी लगने वाली प्रकृति भी मुश्किल लगती है। मैं तो बस organization में घूमते हुए समस्याएँ ठीक करना, process सरल बनाना, और work systems को फिर से design करना चाहता हूँ

  • मैं 12 साल से software engineer हूँ, लेकिन manager बनने की मेरी बिल्कुल इच्छा नहीं है। मैं बस कुछ बनाना चाहता हूँ, manage नहीं करना
    managers के साथ क़रीब से काम करके मैं देखता हूँ कि उनका काम कैसा है, लेकिन वह मुझे बिल्कुल आकर्षक नहीं लगता। senior engineer के रूप में मेरी बात का असर भी अक्सर होता है, और यह अच्छा लगता है कि manager के साथ आने वाली भारी जिम्मेदारियाँ मेरे ऊपर नहीं हैं। मैं अपनी ज़िंदगी में और stress नहीं बढ़ाना चाहता
    शायद आगे के 30 साल के career में भी मैं इसी तरह की भूमिका में रहूँगा

    • senior engineer की बात को कितना महत्व दिया जाता है, यह management layer पर बहुत निर्भर करता है। अभी आपकी स्थिति अच्छी हो सकती है, लेकिन यह बदल भी सकती है
      कुछ साल पहले मैं भी ऐसा ही सोचता था। मेरे boss मुझे पसंद करते थे और मेरे connections भी बहुत थे, इसलिए वे मेरे साथ सारी जानकारी साझा करते, मुझे decision-making meetings में बैठाते, दिशा पर राय पूछते, और ज़रूरत पड़ने पर कहते कि मैं उनकी या दूसरे managers की तरफ़ से बोल सकता हूँ और वे पीछे से support देंगे
      अब पूरी तरह नया management structure आ गया है, और यह बहुत top-down है, ego-driven है, और feedback लेने को तैयार नहीं है। अपनी आवाज़ उठाने वाले lower managers और engineers को लगातार किनारे किया गया, और जो autonomy और बोलने की जगह मेरे पास थी, वह लगभग गायब हो गई
      यहाँ तक कि कई बातें जिन्हें मैं engineering decisions समझता था, वे भी मुझसे छीन ली गईं। मेरी बनाई service में X की ज़रूरत थी, इसलिए मैंने एक automated solution बनाया जो अच्छी तरह काम कर रहा था, लेकिन कुछ महीनों बाद मुझे कहा गया कि X के लिए कुछ और plans थे, इसलिए मैं ग़लत था, और मुझे पूरी तरह automated solution हटाकर दूसरी team की manual enterprise process लगानी होगी। वह काम अक्सर छूट जाता है, जिससे मेरी service की reliability कम हो जाती है
      अच्छा है कि मैं उन लोगों से लड़ने वाला manager नहीं हूँ। अगर होता, तो शायद अब तक नौकरी से निकल चुका होता और मेरी जगह उनका कोई दोस्त आ गया होता। लेकिन senior engineer का प्रभाव एक ही company और team के भीतर भी लंबे समय में बहुत बदल सकता है
    • manager भी कुछ बनाते हैं। बस उनके tools engineer होते हैं
    • senior engineer काफ़ी नीचे की position है। कभी न कभी आप stagnant salary और लगातार निर्देश लेते रहने से थक सकते हैं
      इससे ऊपर भी ऐसे technical roles हैं जिनमें management responsibility नहीं होती या बहुत कम होती है। जैसे senior principal engineer, architect वगैरह, और यह इस पर निर्भर करता है कि company आपको कितना value देती है
      मैंने इसका सबसे अच्छा उदाहरण एक ऐसे engineer में देखा है जिसके पास PhD थी, दशकों का अनुभव था, वह research/architecture guru की तरह काम करता था, उसके पास न team थी न direct reports, वह Matlab बहुत इस्तेमाल करता था, और कुछ सौ लोगों की company में “VP of technology” था
    • मैंने 6 महीने तक अपनी team का manager बनकर देखा, और अंत में यह उतना बुरा नहीं था, लेकिन यह पूरी तरह अलग पेशा है। अगले महीने मैं फिर IC बन रहा हूँ, और 15 साल के career में यह मेरी पहली और शायद आख़िरी management भूमिका होगी
    • बेहतर निष्कर्ष यह नहीं है कि “कभी manager मत बनो”, बल्कि यह कि दूसरों के vision को manage करने वाले corporate manager मत बनो
      मुश्किल चीज़ सिर्फ़ सीखना या लोग नहीं हैं, बल्कि उसके आसपास की परिस्थितियाँ हैं। management का नज़रिया अपनाने पर यह समझने में बहुत मदद मिलती है कि क्या बनाया जा रहा है और क्यों, और काम इतना inefficient और टूटा-फूटा क्यों लगता है। इससे solutions और सही context के ठीक से communicate न होने पर भी insight मिलती है

  • मैं अभी एक senior developer हूँ और एक startup में team lead position के लिए इंटरव्यू दे रहा/रही हूँ। मुझे लगता है कि मेरी technical capability काफ़ी अच्छी है, लेकिन रोज़मर्रा में सबसे ज़्यादा निराशा team-work से जुड़ी समस्याओं से होती है
    जैसे भरोसे की कमी, टीम के सदस्यों का एक-दूसरे से बात करने से बचना, घटिया स्तर का काम होने पर भी दूसरे senior लोगों का उसे जाने देना, साफ़ टीम उद्देश्य और product vision का न होना, और common engineering practices पर सहमति की कमी। अगर आप people manager बनते हैं, तो अच्छा हो या बुरा, ये समस्याएँ आपके प्रभाव और ज़िम्मेदारी के दायरे में आ जाती हैं

    • मुझे यह बात समझ में आती है कि पिछली टीमों में जिन कई समस्याओं का सामना किया, वे management से हल हो सकती थीं
      लेकिन वास्तव में team lead बनने पर पता चला कि प्रभाव डालने की मेरी सीमा सोच से कहीं छोटी थी। मेरे बॉस सहित बहुत से लोग हर चीज़ खुद चलाना चाहते हैं, और मुझसे सिर्फ़ मुहर लगाने की उम्मीद करते हैं
      उल्टा, मुझे वे बातें उठानी पड़ती हैं जिन्हें टीम के लोग कहने से डरते हैं। उदाहरण के लिए, “story तैयार होने के लिए API define होना चाहिए।” जब यह भी नहीं पता कि क्या test करना है, तो QA parallel में automation tests कैसे बना सकता है?
      Scrum Master, product owner, manager, architect — सब लोग उस दिन अपने मतलब की बात को self-evident truth की तरह पेश करते हैं, और अगले दिन पूछते हैं कि testing देर से क्यों हुई
      आख़िरकार बात इस राजनीति तक पहुँच जाती है कि मौजूदा हालत की ज़िम्मेदारी किसकी है, और जिस दिशा व strategy को चुनने वाले लोग होते हैं, उनकी networking भी अच्छी होती है और blame shift करने की क्षमता भी
    • लोगों को सचमुच एक-दूसरे से बात करना बहुत मुश्किल लगता है। आख़िर में, शायद ऐसा करवाने के लिए kindergarten-जैसे खेलों का सहारा लेना पड़े
    • यह जानने की जिज्ञासा है कि आपको क्यों लगता है कि ऐसी समस्याएँ आपके प्रभाव-क्षेत्र में और ज़्यादा आ जाएँगी

  • बहुत पहले मैं अपने उस समय के बॉस के दफ़्तर में खड़ा/खड़ी था/थी, जब उन्होंने किसी दूसरे विभाग के व्यक्ति को काम के लिए सफलतापूर्वक फोन किया था
    बॉस ने अपनी मेज़ से ऊपर देखकर हल्की मुस्कान के साथ थोड़ा उलझे हुए अंदाज़ में कहा, “मेरी पदवी ‘Specialist’ से ‘Manager’ हो जाने से मैं ज़्यादा सुंदर तो नहीं हो गया, लेकिन काम निकलवाने में इससे काफ़ी मदद मिलती है।” यह title की ताकत के सच में काम करने का पल था

    • “हमें सच में tests लिखने चाहिए” यह कहना अच्छा लगता है, लेकिन यह पहले से understaffed और कम सक्षम टीम पर ऐसी roadmap के ऊपर एक और काम लादने जैसा है जो कल ही ख़त्म हो जानी चाहिए थी
    • हमारे team के senior IC के रूप में, मेरे case में तो manager मुझसे ही कहता है कि टीम के सामने कोई बात मैं रखूँ। क्योंकि टीम के लोग वास्तव में मेरी बात सुनते हैं
      manager को अक्सर तब तक नज़रअंदाज़ कर दिया जाता है जब तक वह वास्तविक नुकसान की धमकी न दे, और ऐसे cards बहुत संभालकर इस्तेमाल करने पड़ते हैं

  • कुछ साल पहले मैंने एक छोटे startup में CTO के रूप में engineering manager का काम शुरू किया, और मेरी ज़िंदगी बहुत बदल गई। मूल लेख में जिन बातों से प्यार और नफ़रत दोनों की बात है, मैं उन सबके बारे में वैसा ही महसूस करता/करती हूँ
    एक अतिरिक्त सलाह यह है कि सच में meditation करें। ऐसे महत्वपूर्ण और असरदार फ़ैसले लेने से पहले जो लोगों को नुकसान पहुँचा सकते हैं, आपको इतना शांत बैठना चाहिए कि दिमाग़ लगभग बंद सा हो जाए
    शुरुआत में रिश्ता कुछ parent-child genius जैसा हो जाता है। आपको लोगों को स्वीकार करना पड़ता है और उनका काम करने का तरीका समझना पड़ता है। जितना ज़्यादा control रखेंगे, उतना ही असली control कम होगा। लोग अनावश्यक bureaucracy को bypass करने और उसका विरोध करने लगेंगे, और सच कहूँ तो मैं भी ऐसा ही करूँगा/करूँगी
    दूसरी सलाह यह है कि हमेशा ऐसे व्यवहार करें जैसे आप कल ही जा रहे हों। इससे team और सहकर्मी तैयार रहते हैं, और आपकी अपनी life style भी बेहतर होती है

    • इसी तरह, मेरी ultimate management technique है छुट्टी पर जाना और अपने reportees को मेरी भूमिका सँभालने देना। कम से कम 2 हफ़्ते के लिए
      वे बहुत तेज़ी से grow करते हैं, और यह देखना अजीब तरह से सुकून देता है कि संगठन मेरे बिना भी चल सकता है। साथ ही, कभी-कभी लगता है कि मेरे न होने पर वे और तेज़ी से बढ़ते हैं, तो सोचता/सोचती हूँ कि क्या यह संकेत है कि मैं कुछ ग़लत कर रहा/रही हूँ
    • हाल ही में मैं parent बना/बनी हूँ, और engineering manager और parent के बीच skills की transferability बहुत ज़्यादा है
      कुछ दिनों में लगता है कि मैं काम पर सीखी हुई skills से अपने परिवार को manage कर रहा/रही हूँ

  • मेरा background उल्टा है। मैं एक साधारण software engineer हूँ, लेकिन लोगों को संभालने की क्षमता काफ़ी अच्छी है
    मेरे पास इतना अनुभव है कि समझ सकूँ किस चीज़ में कितना समय लगता है और system का कौन-सा हिस्सा ज़्यादा महत्वपूर्ण है। कुछ senior engineers हैं जो सच में सुनते हैं और बहुत भरोसा व अधिकार देते हैं
    design decisions मैं नहीं लेता/लेती, वे लेते हैं, और मैं अपनी राय जोड़ता/जोड़ती हूँ। असफलता होने पर मैं ज़िम्मेदारी लेता/लेती हूँ और सीखता/सीखती हूँ, और सफलता होने पर श्रेय team को देता/देती हूँ। विनम्रता से कहूँ तो manager की भूमिका सबसे बढ़कर लोगों के बारे में होती है

    • ईमानदारी से कहूँ तो मुझे लगता है कि वही engineering manager career path का सबसे अच्छा रास्ता है। अफ़सोस है कि कई कंपनियों में manager बनने के लिए कोई औपचारिक मध्यवर्ती चरण ही नहीं होता

  • coder/IC भूमिका से management track में जाने की मेरी सिर्फ़ एक ही वजह है। हर नौकरी बदलने पर फिर से देने पड़ने वाले whiteboard interviews
    यह लगभग यातनापूर्ण है कि हर बार फिर से शून्य से तैयारी करनी पड़ती है, और हालाँकि ऐसी भूमिकाएँ हैं जहाँ यह प्रक्रिया नहीं होती, वे बहुत दुर्लभ हैं। उस तैयारी के बारे में सोचते ही अक्सर दिमाग़ में आता है, “ओह, प्लीज़ फिर से?” और मैं बस उसी नौकरी में बना/बनी रहता/रहती हूँ

  • एक खराब engineering manager, एक खराब IC की तुलना में कहीं ज़्यादा नुकसान पहुँचा सकता है। मुझे लगता है इस पर जितनी बात होनी चाहिए उतनी नहीं होती
    लंबे career में मुझे 1 शानदार manager मिला, कुछ ठीक-ठाक managers मिले, और बहुत सारे बेहद ख़राब managers मिले। ख़राब managers काम को बहुत कठिन बना देते हैं, और कभी-कभी पूरी तरह दुःस्वप्न जैसा
    खराब engineering manager और junior IC का combination खास तौर पर बुरा हो सकता है। उम्र और अनुभव बढ़ने के साथ यह समझ आया कि खराब manager के साथ काम करते हुए भी स्थिति को बेहतर दिशा में ले जाया जा सकता है, या अगर उम्मीद न बचे तो वहाँ से निकला जा सकता है

    • यह जानने की जिज्ञासा है कि उस शानदार manager को आप कैसे परिभाषित करेंगे। कौन-से personality traits, behaviors, और skills उन्हें अलग बनाते थे?
      आजकल मेरी management responsibilities बढ़ रही हैं, इसलिए जानना चाहता/चाहती हूँ

  • एक समय मैंने PhD-स्तर के ICs से बनी टीम का नेतृत्व किया था। मुझे उनके लिए काम ढूँढना पड़ता था, dreamers को रोकना पड़ता था, और उन्हें खुश भी रखना पड़ता था
    मज़ाक नहीं, मैं कई बार एक-एक व्यक्ति से लगातार छह-छह घंटे बात करता/करती था/थी, career counselor और emotional support देने वाले की भूमिका निभाते हुए। मैंने कभी नहीं सोचा था कि यह मेरा काम होगा
    टीम के एक सदस्य ने अलग से दो 1 billion dollar contracts हासिल करने में मदद की, तो कम से कम इतना लगा कि मेरा समय वसूल हो गया