VP of Engineering बनने का रास्ता
(honeycomb.io)- Honeycomb के पहले VP of Engineering को फरवरी 2020 में Director of Engineering से प्रमोट किया गया था, और यह रास्ता किसी योजनाबद्ध executive career से ज्यादा कंपनी के बढ़ने के साथ पैदा हुई खाली जगहों को संभालने की प्रक्रिया जैसा था
- शुरुआती Honeycomb में co-founder Charity Majors लगभग सभी को मैनेज करती थीं, और management philosophy मिलती-जुलती होने के बावजूद अलग background और style वाले दो लोगों ने R&D management की जिम्मेदारी बांटी
- promotion कोई एक बड़ा transition नहीं था, बल्कि छोटे-छोटे scope expansion का जमा हुआ नतीजा था, और startup में नए process और responsibilities बनाते जाना ही इसका मुख्य रास्ता बना
- role के लिए तैयार होने में पूरी कंपनी को देखने वाली सोच, generalist tendency, abstraction के कई levels के बीच आ-जा सकने की क्षमता, ownership, systems thinking, team members की growth support करना, और व्यापक relationships जरूरी थे
- अच्छे VP of Engineering की परिभाषा किसी standard template से ज्यादा कंपनी की मौजूदा समस्याओं, existing leadership और IC structure, technical challenges, और growth stage पर निर्भर करती है
योजनाबद्ध executive career नहीं रहा शुरुआती बिंदु
- Honeycomb के पहले VP of Engineering को फरवरी 2020 में Director of Engineering से प्रमोट किया गया
- Honeycomb में शुरुआत में जुड़ने का लक्ष्य engineer के रूप में काम करना था, और यह समझ थी कि जरूरत पड़ने पर वे फिर management role में लौट सकते हैं
- जुड़ते समय वे करीब 12वें employee थे, और शुरुआती startup में यह पता था कि कंपनी जितनी सफल होगी, अलग-अलग stages पर तरह-तरह के काम संभालने पड़ेंगे
- किसी खास job role से बहुत ज्यादा चिपके रहना व्यक्ति और कंपनी दोनों के लिए मददगार होने से ज्यादा बाधा बन सकता है, ऐसा उनका मानना था
- Honeycomb चुनने की वजह यह थी कि team smart और kind दिखती थी, सीखने के लिए बहुत कुछ दिख रहा था, और product वैसा लग रहा था जैसा वे पिछली नौकरी में चाहते थे लेकिन ढूंढ नहीं पाए थे
- किसी खास role में तेजी से grow करना हो तो Series B के बाद वाले startup में जुड़ना ज्यादा efficient हो सकता है, लेकिन वे Honeycomb में Series A stage पर जुड़े
management responsibility कैसे shift हुई
- शुरुआती दिनों में co-founder और उस समय की CEO Charity Majors executives से लेकर individual engineers तक लगभग सभी को मैनेज करती थीं
- दोनों की management philosophy काफी हद तक match करती थी, लेकिन background और strengths अलग थे
- Charity Majors को infrastructure, operations, databases, backend engineering का गहरा experience था
- प्रमोट हुए व्यक्ति ने design, frontend, product engineering से शुरुआत की थी और product management तथा UX design के साथ collaboration enjoy करते थे
- metrics और monitoring technology का experience दोनों के पास था, लेकिन attitude अलग था
- Charity Majors को ये चीजें पसंद नहीं थीं
- प्रमोट हुए व्यक्ति को इनसे गहरा लगाव था
- काम करने के styles में भी बड़ा फर्क था
- प्रमोट हुए व्यक्ति rules और processes को महत्व देते हैं, और daily work व hobbies में भी planning और risk management बहुत करते हैं
- Charity Majors intuitive और spontaneous style वाली हैं, crisis situations में खास तौर पर shine करती हैं, checklists पसंद नहीं करतीं, और rules या processes कब मददगार नहीं हैं, यह जल्दी पहचान लेती हैं
- Honeycomb के बढ़ने के साथ R&D management work बढ़ा, और दोनों ने अपनी-अपनी background के ज्यादा उपयुक्त areas के हिसाब से responsibilities धीरे-धीरे बांटनी शुरू कीं
promotion छोटे scope expansions का accumulation था
- VP बनने के रास्ते में किसी साफ single milestone से ज्यादा बहुत सारे छोटे steps थे
- बीच-बीच में title changes पीछे मुड़कर देखने पर progress दिखाने वाले markers के रूप में उपयोगी थे, लेकिन आम तौर पर नई meetings जुड़ने के अलावा work scope में बड़े बदलाव का signal नहीं थे
- growing startup में processes और responsibilities की gaps लगातार बनती हैं, और छोटी leaks जैसी दिखने वाली समस्याएं समय और attention का बड़ा हिस्सा खाने वाली समस्याओं में बदल सकती हैं
- नई problem संभालकर level up करने का opportunity हमेशा रहता है, लेकिन company उसे new title और role के रूप में recognize करती है या नहीं, यह अलग बात है
- Honeycomb के दोनों co-founders ने न सिर्फ उनके लिए बल्कि अन्य members के लिए भी internal promotions और influence की recognition को actively support किया
- वे कहते हैं कि अगर भविष्य में कोई दूसरा startup खोजेंगे, तो ऐसी executive team या founding team खोजेंगे जिसके पास high performers को internally promote करके grow करने के examples हों और जो अपने role scope से आगे already impact डाल रहे लोगों को जल्दी recognize और reward करे
IC management से managers को manage करने तक का transition
- पूरे journey में सबसे दिलचस्प transition वह समय था जब वे सिर्फ ICs को manage करने से managers को भी manage करने लगे
- जो लोग यह transition चाहते हैं, उनके लिए उनका मानना है कि इसे किसी नई company में try करने के बजाय उस company में करना बेहतर है जहां वे पहले से team, technology और business problems जानते हों
- existing line management skills का बड़ा हिस्सा transfer हो गया, लेकिन additional management layer के जरिए पूरे organization को effectively “देखना” सीखने में समय लगा
- खासकर organization में friction वाले points या ज्यादा support की जरूरत वाले points पहचानना मुश्किल था
- engineering organization के लोगों और समस्याओं को सीधे experience करने के कारण वे managers के साथ मिलकर team situation evaluate करने की practices और skills बनने तक टिक सके
external VP candidates की खोज और internal promotion
- company की दिशा कुछ डगमगा रही थी, उस समय बाहर से VP of Engineering hire करने का विकल्प भी विचार में आया
- Charity Majors ने इसे honestly share किया और suitable person खोजने और चुनने की process में उन्हें भी शामिल किया
- कुछ बेहतरीन engineering leaders से बातचीत हुई, लेकिन कुछ उस समय Honeycomb के लिए fit नहीं थे और कुछ ने Honeycomb को अपना next step नहीं चुना
- इसके बाद company में नई problems पैदा हुईं, और पहले असंभव लगने वाली समस्याएं ज्यादा manageable हो गईं
- उस समय तुरंत promotion नहीं हुआ, लेकिन external hiring search रोक दी गई
- leadership promotion किसी स्तर से ऊपर व्यक्ति के बारे में नहीं बल्कि company को क्या चाहिए इसके आधार पर होनी चाहिए, और Honeycomb के लिए सही VP of Engineering कैसा होगा, इसकी कल्पना साथ मिलकर करना मददगार रहा
role के लिए उपयुक्त व्यक्ति बनने में मदद करने वाली विशेषताएं
- holistic thinking एक महत्वपूर्ण trait के रूप में काम आई
- सिर्फ team नहीं, बल्कि Honeycomb नाम की पूरी company ज्यादा सफल कैसे हो, इस पर स्वाभाविक focus रहा
- department, team, individual से ज्यादा पूरी company के हित में काम करना reward होने वाले environment में वे अच्छी तरह काम करते हैं
- generalist tendency भी मददगार रही
- software company के अंदर लगभग हर business problem और domain में उन्हें interest महसूस होता है
- startup में सभी pieces कैसे fit होते हैं, यह देख पाना उन्हें पसंद है
- जरूरत पड़ने पर spotlight में न आने वाला unglamorous काम लेने में भी झिझक नहीं होती
- वे कई abstraction levels पर काम कर सकते थे
- lower layers को पूरी तरह समझे बिना भी higher-layer concepts जल्दी grasp कर सकते हैं
- जरूरत पड़ने पर details में उतरना भी उन्हें पसंद है
- strong ownership startup में मददगार होता है, लेकिन constraints भी जरूरी हैं
- startup में जहां important work cross-functional gaps में गिर जाता है, वहां यह उपयोगी है
- हालांकि काम pile up न हो या team की growth न रुके, इसके लिए काम खत्म करना या दूसरों को hand off करना लगातार जरूरी है
- people और technical systems दोनों में interest रखने वाली systems thinking भी important list में शामिल थी
- team members को grow होते देखकर सच में आनंद लेना भी महत्वपूर्ण था
- अगले level के लिए ready व्यक्ति को उसकी capability की edge पर मौजूद important problem से जोड़ना उनके लिए energy source था
- company के हर हिस्से में अच्छे relationships भी जरूरी थे
- company के अंदर और बाहर के लोगों को किसी external candidate से ज्यादा इस व्यक्ति के role संभालने को लेकर excited होना चाहिए था
मददगार रहे work experiences
- कई stages और sizes के startups, खासकर B2B SaaS startups का experience मददगार रहा
- B2C और B2B startups अपेक्षाकृत अलग problem categories deal करते हैं, और दोनों ने अपने-अपने problem-solving techniques विकसित किए हैं
- दोनों areas को देखना अच्छा है, लेकिन B2B या B2C में से किसी एक में expertise बनाना भी valuable है
- go-to-market approach, organization structure, engineering problems, scaling challenges B2B और B2C में अलग हो सकते हैं
- पूरे stack में काम करने का experience भी मददगार रहा
- सबसे गहरा engineering experience frontend technologies में था
- pair programming करने और DevOps mindset अपनाने वाले कई organizations में शुरुआती experience मिला
- backend, infrastructure, platform, operations engineers से सीखते हुए समझा कि वे कैसे सोचते हैं और किन problems को important मानते हैं
- सभी engineering areas का expert होना जरूरी नहीं, लेकिन कई teams के प्रति empathy और high-level domain understanding बहुत मदद करती है
- developer tools और monitoring area का experience भी role के लिए fit था
- लगातार तीन developer tools companies में काम किया
- Honeycomb product उन्हें सच में पसंद था, और observability, monitoring, developer tools area के कई products से भी लगाव था
- domain knowledge और tools के प्रति passion colleagues के लिए मददगार होता है, और निराश कर सकने वाली situations में energy source बन सकता है
luck और team composition से बनी fit
- role के लिए suitable person बनने में luck ने भी बड़ी भूमिका निभाई
- Charity Majors के साथ complementary skills और experience होना ही काफी नहीं था; शुरुआती senior ICs का core engineering challenges को अच्छी तरह handle कर पाना भी महत्वपूर्ण था
- frontend background वाला VP of Engineering अपेक्षाकृत rare है, क्योंकि startups की सबसे urgent technical challenges आम तौर पर scaling, reliability, backend architecture में होती हैं
- अगर लगातार incidents, scaling problems, query और storage engine की बड़ी architecture problems चल रही होतीं, तो शायद ज्यादा गहरे backend और operations experience वाले व्यक्ति को चुना जाता
- Ben Hartshorne, Ian Wilkes, अन्य उत्कृष्ट ICs, और founding team के मजबूत design decisions की वजह से technical breathing room था, और उस समय leadership की top priority product strategy execution और user experience improvement थी
- executive team में go-to-market functions में पहले से experienced external hire executives थे
- company के अंदर grow हुई leaders मानी जा सकने वाली Christine और Charity के पास भी पिछली companies में founder या leadership experience था, और Charity Honeycomb शुरू करने से पहले से ही बेहतरीन manager के रूप में जानी जाती थीं
- अगर executive team नए executives या internal promotees की तरफ और ज्यादा झुकी होती, तो शायद एक और executive को grow करने की गुंजाइश नहीं होती
VP of Engineering company context के हिसाब से बदलता है
- सबसे अहम सीख यह थी कि अच्छे VP of Engineering की परिभाषा context-dependent है
- पहले लगता था कि बेहतरीन VP of Engineering बनाने वाली standard traits की list बनाई जा सकती है, लेकिन हर company में basic template लगभग एक जैसा होता है, यह सोच कम सही निकली
- अधिकांश software companies में किए जाने वाले basic काम समान होते हैं, लेकिन इन्हें lead करने वाले executive का रूप organization की current problems और पहले से मौजूद executives, managers, ICs के composition पर काफी निर्भर करता है
- role में आने के बाद भी requirements fixed नहीं रहतीं
- growing company में, दूसरे startup roles की तरह VP of Engineering role भी समय के साथ अपना आकार बदल सकता है
1 टिप्पणियां
Hacker News की राय
यह हिस्सा दिलचस्प लगा: “Charity ज़्यादा intuitive और spontaneous स्टाइल की है, संकट में सबसे ज़्यादा चमकती है, और checklist से नफ़रत करती है” — यह लगभग यूँ ही निकल गई एक स्वीकारोक्ति जैसा लगता है
दूसरे शब्दों में, इसका मतलब है कि संस्थापक के पास वे योग्यताएँ या विशेषताएँ नहीं हैं जिन्हें उनके अधीन काम करने वाले लोग leadership position के लिए ज़रूरी मानते हैं
कंपनी शुरू करते ही कोई अपने-आप CEO, CTO वगैरह बन जाता है, और जो कंपनियाँ आज बड़ी कॉरपोरेशन बन चुकी हैं उनके संस्थापक भी ऐसे ही थे
संस्थापक को अपने title को सही ठहराने के लिए किसी खास योग्यता की ज़रूरत नहीं होती; वह पहले खुद leader बनता है और फिर अपने दोस्तों को शुरुआती employees के रूप में चुनता है
hiring बहुत बाद में औपचारिक होती है, और hierarchy को हम चाहे कितना भी meritocracy मानना चाहें, उसकी शुरुआत साफ़ तौर पर अराजकता से हुई थी
hierarchy और आज्ञाकारिता पर आधारित सोच मुझे हमेशा अजीब लगी है, और मैंने कभी यह नहीं सोचा कि मेरे पुराने managers मुझसे “बेहतर” थे
कॉरपोरेट सीढ़ी चढ़ना मूलतः राजनीति के काफ़ी क़रीब है, और “senior engineer क्या होता है” जैसे अंतहीन लेख भी hierarchy को सही ठहराने वाली corporatized thinking से निकले हुए लगते हैं
लेकिन समय के साथ आपको कंपनी को डुबोए बिना सफल बनाकर उस जगह को सही ठहराना पड़ता है
कई बार यह किसी भी evaluation से कहीं ज़्यादा ईमानदार और कठोर merit measurement होता है
Google जैसी बड़ी कंपनियाँ किसी एक अयोग्य और आलसी VP की वजह से दिवालिया नहीं होतीं, इसलिए वहाँ evaluation system की ज़रूरत पड़ती है
https://gwern.net/backstop से तुलना की जा सकती है
मैं पूरी तरह execution type हूँ, लेकिन मैंने जल्दी ही सीख लिया कि co-founder के लिए आदर्श गुण मेरे उलट होते हैं, और यहाँ भी वही अंतर दिख रहा है
जिस व्यक्ति का वर्णन किया गया है, वह एक典型 unconventionल leader है—spontaneous, इधर-उधर कूदने वाला और बिखरा हुआ हो सकता है, लेकिन साथ ही शानदार innovator और लोगों को प्रेरित करने वाला motivator भी
सफल startup को unconventional व्यक्ति और execution type व्यक्ति, दोनों चाहिए
Rocket Fuel की सिफारिश करता हूँ: https://www.amazon.com/Rocket-Fuel-Essential-Combination-Bus...
यह दो अलग-अलग styles के अस्तित्व की एक ईमानदार और दोस्ताना स्वीकारोक्ति लगती है, और ऐसे अंतर को मानना स्वस्थ बात है, hierarchy की कोई छिपी हुई अपील नहीं
बल्कि “subordinate”, “boss” जैसे शब्दों का इस्तेमाल करना और कंपनी की स्थापना को hierarchy की स्थापना के बराबर मान लेना—यह सब, hierarchy पर शक जताने की बात के बावजूद, पूरे comment को hierarchy मज़बूत करने वाला बना देता है
knowledge industry में manager leader नहीं बल्कि support staff होता है
सबसे अच्छे software managers और executives जानते हैं कि असली leaders और experts—यानी काम करने वाले individual contributors—को आसानी से काम करने देना ही उनकी भूमिका है
management की support functions में से एक यह भी है कि वह ऐसी expectations को अपने व्यवहार से स्थापित करे
जब कोई startup किसी बड़ी कंपनी को बिकता है, तो यह सामने आना काफ़ी दिलचस्प होता है कि उस startup के लोगों में से किसी को भी उस कंपनी के HR standards के हिसाब से शायद hire ही नहीं किया जाता
और फिर अचानक वही startup team के लोग, HR-approved अच्छे शैक्षणिक background वाले बड़े कॉरपोरेट कर्मचारियों से पहले promote भी हो जाते हैं
बहुत से लोग अमेरिकी कॉरपोरेट chain of command से conditioned हैं, और अगर किसी के पास कोई title है तो मान लेते हैं कि उसके पास सचमुच उस title के मुताबिक़ योग्यता भी होगी
title inflation हर जगह है, और अनुभव से लगता है कि titles अक्सर skill की recognition नहीं, बल्कि salary बढ़ाने और tenure को मान्यता देने के साधन के रूप में इस्तेमाल होते हैं
मेरा इरादा इसे सिर्फ़ अमेरिका तक सीमित बात के रूप में कहने का नहीं था
मेरे अनुभव में internal promotion के उदाहरण ढूँढना बहुत ही दुर्लभ रहा है
ज़्यादातर startups में जब hierarchy में नया स्तर चाहिए होता है या किसी के जाने से जगह खाली होती है, तो default विकल्प external hiring होता है
तर्क शायद यह होता है कि अगर हर कोई ज़रूरी काम ठीक कर रहा है तो बेवजह छेड़ना नहीं चाहिए, लेकिन सच कहूँ तो इससे बहुत motivation गिरता है
किसी colleague के promote होकर मुझे पीछे छोड़ देने से भी ज़्यादा हतोत्साहित करने वाली बात यह है, क्योंकि अगर promotion और growth की culture हो तो कम-से-कम यह भरोसा रहता है कि अगली बार मुझे fair chance मिल सकता है
लेकिन अगर हमेशा बाहर से ही लोग लाए जाएँ, तो इस कंपनी में मेरा career वहीं का वहीं रहेगा जहाँ से मैंने join किया था
तर्क कुछ ऐसा लगता है कि title से बेहतर प्रदर्शन कर सकने वाले smart लोगों को जितना सस्ता हो सके उतने में रोके रखा जाए
job switch करने की असली cost employee के लिए होती है, और मंदी या मुश्किल market में यह और बढ़ जाती है
फिर भी कुछ लोग छोड़कर चले जाते हैं, कुछ quietly हाथ खींच लेते हैं, और कुछ बस टिके रहते हैं
मेरे अनुभव में वे अक्सर बदलाव के साथ ढलने से इनकार करते हैं, और फिर या तो चले जाते हैं या निकाल दिए जाते हैं
सिर्फ़ इसलिए कि आप 10 लोगों की team manage कर सकते हैं, इसका मतलब यह नहीं कि आप 100 लोगों का संगठन, और 1000 लोगों का संगठन तो बिल्कुल भी, manage कर सकते हैं
ज़रूरी नहीं कि यह मामला वैसा ही हो, लेकिन कुछ मामलों में यह Peter Principle से बचने की एक वैध वजह बनता है
क्योंकि promote वही लोग होते हैं जिन्होंने उन कमियों को सहा हो, या उन्हें देखा ही न हो
और अगर कोई बाहरी hire उन कमियों को पहचानने का अनुभव रखता हो, तो उसके लिए समय काफ़ी कठिन गुजरने की संभावना होती है
वहाँ की ज़्यादातर top leadership internal promotion से ऊपर आई है, और कभी-कभी individual contributor से VP तक पहुँचे लोग भी हैं, और उसका असर दिखता है
लेकिन अगर कोई ऐसा व्यक्ति आए जिसे कई संगठनों में उस scale का अनुभव हो, तो उससे संगठन को निश्चित रूप से फ़ायदा होगा
असल में उन्होंने क्या किया था, और अभी VP की भूमिका में क्या करते हैं, यह समझना मुश्किल था
अच्छी-अच्छी बातें बहुत हैं, लेकिन अभी उनके दिन का ज़्यादातर समय किस पर जाता है, यह साफ़ नहीं है
“design, frontend, product engineering background” जैसी बात भी बहुत जानकारी नहीं देती
मैं भी लगभग वैसा ही व्यक्ति हूँ जो sketch से लेकर Figma layout, SvelteKit frontend·middle layer, और FastAPI API बनाना—सब करता है, लेकिन यह समझ नहीं आता कि कौन-सी चीज़ अच्छी करके वे VP बने, अब hands-on काम से हटकर क्या कर रहे हैं, और किस चीज़ की सबसे ज़्यादा कमी महसूस करते हैं
लेख बहुत लंबा है, लेकिन कहना क्या चाहता है यह ठीक से समझ नहीं आता
आज के समय में FAANG से छोटी कंपनियों में इस role से क्या उम्मीद की जाती है, और engineers management track पर कैसे ऊपर जाते हैं, यह देखने के लिए “The Manager's Path” देखना उपयोगी हो सकता है
मेरा सोचना था कि executive leadership की ओर जाते-जाते काम कहीं ज़्यादा strategic हो जाता है और सीधे execution के मामले बहुत कम रह जाते हैं, लेकिन इस लेख में उन्होंने उन tactical अनुभवों और गुणों की लंबी सूची दी है जिन्हें वे खुद को अच्छा VP बनाने वाला बताते हैं
tech के आसपास के गरीब तबके का आदमी होने के नाते, मैंने कंपनी में लोगों को कुछ लिखने के लिए मजबूर किए जाने के कई उदाहरण देखे हैं, और वे हमेशा ऐसे ही होते थे
campus hiring के समय search results में हाल की posts दिखें, इसके लिए कंपनी के लोग ऐसी एक-दो चीज़ें लिखते हैं
इससे एक साथ दो मकसद पूरे होते हैं: हल्की-सी खुशामद और संभावित applicants को खुश करना
https://www.honeycomb.io/blog/becoming-vp-of-engineering-pt2
यह लेख मूल रूप से survivorship bias और उसके rationalization का उदाहरण है
जो बात गायब है, वह VP पद तक पहुँचने में internal move और external hiring के बीच का statistical नज़रिया है
startup हो या बड़ी कंपनी, अंदर से VP तक पहुँचना बेहद मुश्किल होता है
startup को सफल होना पड़ता है, और बड़ी कंपनी में वर्षों टिककर अच्छे political संबंध बनाने पड़ते हैं
सबसे आसान रास्ता यह है कि खुद को नीचे से शुरू करने वाला न समझें, बल्कि जीवन की शुरुआत में ही ऊँची भूमिकाओं को लक्ष्य बनाकर लगातार उसी दिशा में बढ़ें
अगर मौजूदा कंपनी में ऊपर तक नहीं पहुँच सकते, तो खुद बना लें
अगर आप नीचे से शुरू करते हैं, तो अक्सर वहीं रह जाते हैं, क्योंकि top leadership roles में उस तरह की skills की कोई value नहीं होती
कोशिश की गई थी, लेकिन बात वहाँ तक पहुँची नहीं, और उसमें कोई value judgment भी नहीं था
ऐसा लगता है कि अच्छे candidates नहीं मिले, और आखिर में लेखक को ही promote कर दिया गया
मेरे पिछले startup में भी VP ढूँढा जा रहा था, लेकिन अंत में internal promotion कर दिया गया, और आँकड़ों के हिसाब से ऐसी चीज़ें निश्चित ही कभी-कभी होती हैं
मुझे लगता है लेखक “नीचे से शुरू करो तो वहीं रह जाओगे” वाली आख़िरी पंक्ति से सहमत नहीं होंगे
उनका कहना है कि कंपनी का infrastructure scale होने के दौरान भी स्थिर रहा, क्योंकि “नीचे के लोगों” ने अपना काम अच्छी तरह किया, और इसी वजह से उन्हें strategy पर ज़्यादा सोचने की गुंजाइश मिली
यह ऊपर-नीचे की बात से ज़्यादा इस बात के करीब लगता है कि आप किस तरह की समस्याएँ अच्छी तरह हल करते हैं
अगर आपको planning, management, strategy पसंद है, तो ऊपर, बीच या नीचे—किसी भी भूमिका में उन क्षमताओं का इस्तेमाल करने वाली जगह ढूँढना बेहतर है
उदाहरण के लिए, अगर आपको बेहतरीन बनना है तो JavaScript roles में आराम से मत बैठे रहिए; खुद को किसी competitive space में धकेलिए, और सचमुच अच्छा programmer बनने के लिए OCaml में अभिशप्त code लिखना चाहिए
venture funding पाने वाले startup के CTO के नज़रिये से देखें तो, ऊँचे पदों पर बैठे लोग आम तौर पर smart होते हैं, और मैं चालाकी को भी उसी दायरे में रखूँगा
लेकिन उतने ही smart होकर भी बहुत से लोग ऊँचे पदों पर नहीं होते, क्योंकि उन्हें मौका नहीं मिला
अगर आप खुद business शुरू करते हैं तो मौके बेहतर हो जाते हैं; कोई भी किसी दूसरी कंपनी में VP पद पाने के लिए startup शुरू नहीं करता, लेकिन यह एक अच्छा alternative path बन जाता है
या फिर सही लोगों को जानने वाली networking चाहिए, और आम तौर पर यह ऊपर बताए गए startup path के साथ ही चलती है
एक तरीका यह भी है कि Google जैसी मशहूर कंपनी में काम करने के बाद किसी छोटी जगह जाएँ और वहाँ big fish बन जाएँ
या फिर आपको अपने boss और उनके boss—दोनों की नज़र में आना होगा, ताकि direct boss के इस्तीफ़ा देने पर अगली नियुक्ति आप हों
मैंने एक बात सीखी: जब आप देखते हैं कि कंपनी executives को merit के अलावा दूसरे कारणों से promote और hire करती है, तो नई नौकरी ढूँढना शुरू कर देना चाहिए
interview के समय मुझे यह पता नहीं था, लेकिन मेरी पिछली कंपनी में VP और उससे ऊपर के पद लगभग पूरी तरह CEO से जुड़े लोगों के कब्ज़े में थे, चाहे उनकी qualification कुछ भी हो
कुछ लोग अपनी क्षमता से promote हुए थे या acquisition process के कारण स्वाभाविक रूप से ऊपर आए थे, लेकिन समय के साथ उन्हें लगातार replace या demote किया गया ताकि C-level executives के दोस्तों और यहाँ तक कि परिवार वालों के लिए जगह बनाई जा सके
एक C-level executive जिनके साथ काम करना अच्छा लगता था, उन्हें VP बना दिया गया, और CEO के पुराने दोस्त ने उनका C-level पद ले लिया
demote किए गए executive ने इस industry की शीर्ष कंपनियों में वर्षों तक करियर बनाया था और इस पद के लिए परिवार सहित देश के एक छोर से दूसरे छोर तक जाकर बस गए थे, लेकिन उनके उत्तराधिकारी के पास इस industry का कोई अनुभव नहीं था
उस VP से कहा गया कि वे तब तक बने रहें ताकि CEO का पुराना दोस्त काम सीखकर पद संभाल सके, और उन्हें अपने stock options बनाए रखने की “इजाज़त” दी गई
इससे मेरी आँखें खुलीं कि कुछ कंपनियों में nepotism और loyalty कैसे काम करते हैं
यह उद्धरण खास तौर पर ध्यान खींचने वाला था
कि frontend पृष्ठभूमि से आने वाले engineering VP अपेक्षाकृत कम इसलिए होते हैं क्योंकि startup की सबसे तात्कालिक तकनीकी समस्याएँ आमतौर पर scalability, reliability और backend architecture में होती हैं
मैं पहले ऐसी कंपनियों में काम कर चुका हूँ जहाँ सभी नेता backend·infra पृष्ठभूमि से थे और frontend को कमतर आँका जाता था, और वहाँ ऐसे backend डेवलपर्स का code quality काफ़ी भयानक भी देखा है
सोचता हूँ कि leadership representation और engineering talent के बीच कहीं उल्टा सहसंबंध तो नहीं है
मैं frontend engineer से tech lead बना हूँ, और मेरा मानना है कि डेवलपर अपनी व्यक्तिगत प्रवृत्ति और जिन मूल्यों को वे महत्व देते हैं, उनके आधार पर फ़ोकस चुनते हैं
frontend चुनने वाले लोग और backend डेवलपर्स की प्रवृत्ति आमतौर पर अलग होती है
भयानक code आखिर है क्या
क्या formatting एकसमान नहीं है या सुंदर नहीं दिखती, क्या variable names वर्णनात्मक नहीं हैं, क्या code को साफ़-सुथरे ढंग से बाँटा या संरचित नहीं किया गया है
मुझे लगता है कि frontend डेवलपर्स अक्सर code को सतही मूल्यों के आधार पर जज करने की ओर झुकते हैं
खासकर engineering-केंद्रित संगठनों में, मान्यता समस्या हल करके मिलती है
बहुत-सी टीमें मुख्य frontend प्रभारी के बिना भी अच्छी तरह चल जाती हैं, लेकिन मज़बूत infra या backend engineer एक भी न हो, या बेहतर कहें कई न हों, तो वे अक्सर डगमगा जाती हैं
यही हक़ीक़त है
frontend development को अक्सर स्त्रैण रूप में कोडित किया जाता है और कम महत्वपूर्ण माना जाता है
उदाहरण: https://thoughtbot.com/blog/tailwind-and-the-femininity-of-c...
टेक इंडस्ट्री में leadership को भी पुरुषत्व से कोडित गुणों के साथ जोड़ने की प्रवृत्ति है
इसलिए leadership और frontend पृष्ठभूमि का किसी तरह मेल न खाना माना जाए, इसमें ज़रा भी हैरानी नहीं है
वही gender dynamics code पर भी लागू होती है
मेरे लिए अच्छे code का एक हिस्सा यह भी है कि वह दूसरों के लिए अच्छा हो और collaboration के लिए अनुकूल हो
लेकिन अगर macho, alpha-nerd tech-bro की तरह बर्ताव करना हो, तो आप अकेले cowboy coding करते हुए अपनी प्रतिभा का प्रदर्शन कर सकते हैं
तब लक्ष्य टीम के साथ क़रीबी सहयोग में कुछ बनाना नहीं, बल्कि management की नज़र में चौंका देने वाले individual contributor बनना होता है
engineering VP ऐसा role नहीं है जिसे कंपनियों के बीच standardize करके तुलना की जा सके
मेरी मौजूदा कंपनी में director अक्सर अधिकतम 500 लोगों के संगठन संभालते हैं, और VP आमतौर पर 1000 से ज़्यादा, कभी-कभी 3000~5000 लोगों तक
50 लोगों वाले startup के VP और 1000+ लोगों वाले FAANG VP को एक जैसा मानना बेतुका है
यह नहीं कि कोई एक बेहतर है, बल्कि दोनों के लिए ज़रूरी skills साफ़ तौर पर अलग हैं
मैंने सचमुच छोटे संगठनों में VP title पाने वाले लोगों को यह फ़र्क न समझते हुए देखा है; वे FAANG में apply करते हैं, फिर manager या senior manager role का प्रस्ताव पाकर सदमे में आ जाते हैं
यह पूरी तरह बेतुका था
मेरे अनुभव में वह VP बड़े संगठन के पैमाने पर इंटर्न-स्तर के अनुभव वाला था, बस जल्दी शामिल हो गया था
director उससे भी बदतर था, और जिन दो लोगों को वे manage कर रहे थे, वे सक्षम थे
काश Honeycomb के कर्मचारी blog post लिखने के बजाय product को दिखने लायक बेहतर बनाने में थोड़ा समय लगाते
मुझे कंपनी में Honeycomb इस्तेमाल करने का दुर्भाग्य झेलना पड़ा, और कुछ services से ज़्यादा के साथ interact करने वाले systems में यह बस काम का नहीं था
समझ नहीं आता कि इस कंपनी से इतनी अत्यधिक उम्मीदें क्यों जोड़ी जाती हैं
मैं इस पोस्ट को यह ध्यान में रखकर पढ़ रहा हूँ कि Honeycomb का VP, बड़ी tech कंपनियों के senior manager के करीब है
बड़े कॉर्पोरेट मानकों से देखें तो यह director के बराबर है
मेरे अनुभव में individual contributors product बनाते हैं, managers लोगों को बनाते हैं, directors process बनाते हैं, और VP policy बनाते हैं
इनके ऊपर के सभी लोग budget request approval stage होते हैं
अगर आप policy और strategy को एक नहीं मानते, तो
या फिर अगर यह एक सूक्ष्म मज़ाक है कि strategy कोई नहीं बनाता, तो यह अच्छा मज़ाक है