- 4 साल तक Google में software developer के तौर पर काम करने के बाद 1 फरवरी को नौकरी छोड़ने की पृष्ठभूमि में promotion evaluation structure और बार-बार project बंद होने से career पर नियंत्रण का एहसास कमजोर पड़ने का अनुभव था
- Promotion का फैसला direct manager नहीं करता था; उम्मीदवार को न जानने वाली senior engineers और managers की committee promo packet की समीक्षा करके निर्णय लेती थी
- Legacy pipeline improvement, bug fixes, tests, documentation और team support असल में उपयोगी थे, लेकिन उन्हें measurable impact के रूप में छोड़ना कठिन था, इसलिए पहली promotion review में यह नुकसानदेह साबित हुआ
- इसके बाद promotion में मदद करने वाले काम ही चुनने पर सर्वोच्च performance rating Superb मिली, लेकिन project cancellation और team reassignment बार-बार होने से promotion फिर भी नहीं मिला
- Indie Hackers के जरिए छोटे profitable software business का विकल्प मिला, और KetoHub, Sia-based business और writing monetization को कुछ-कुछ महीनों तक आजमाने का फैसला किया
Google में पहले 2 साल और promotion की उम्मीद
- Joining के बाद पहले 2 साल इतने संतोषजनक थे कि लगा कंपनी में लंबे समय तक रहेंगे
- आसपास बेहतरीन engineers थे, और advanced development tools व free meals भी मिलते थे
- हालिया performance review Strongly Exceeds Expectations था, और manager ने कहा कि अगले level, Senior Software Engineer promotion, के करीब पहुंच गए हैं
- Manager मानते थे कि काम करने की क्षमता पहले से senior level की है, लेकिन promotion committee के सामने इसे साबित करने के लिए उपयुक्त project चाहिए था
Google promotion process कैसे काम करता था
- Google में direct manager अपने reportee को सीधे promote नहीं कर सकता और उसके पास vote भी नहीं होता
- Promotion का फैसला senior-level software engineers और managers की एक छोटी committee करती है, जो उम्मीदवार को उसी दिन पहली बार देखती है
- Applicant promo packet बनाकर submit करता है
- Team members की recommendation letters
- लिखे गए design documents
- अपने काम के promotion-worthy होने की वजह समझाने वाला छोटा write-up
- Committee कई candidates के packets को साथ में review करती है और एक दिन में promotion का फैसला करती है
- शुरुआत में लगा कि यह तरीका bias और internal politics को कम करेगा, और code quality व engineering judgment का निष्पक्ष मूल्यांकन करेगा
Legacy pipeline improvement evaluation में क्यों नहीं दिखा
- मुख्य जिम्मेदारी एक पुरानी legacy data pipeline थी
- कई सालों से maintenance mode में थी, लेकिन load बढ़ने से दबाव में आ रही थी
- अक्सर चुपचाप मर जाती थी या गलत output देती थी
- शुरुआती design document के बाद documentation नहीं थी, इसलिए outages diagnose करने में कई दिन लग जाते थे
- Pipeline को सही करने के लिए कई improvements किए
- दर्जनों bugs ठीक किए
- Bugs दोबारा न हों, इसके लिए automated tests लिखे
- Dead code और modern libraries से replace किए जा सकने वाले code की हजारों lines हटाईं
- सीखी गई बातों को document किया ताकि knowledge केवल किसी व्यक्ति के दिमाग में न रहे
- Promotion review में ये काम quantify न हो पाने वाली problem बनकर लौटे
- Bugs खोजने से कुल bugs की संख्या उल्टा बढ़ी हुई दिखी
- Anomalies को चुपचाप pass करने के बजाय जल्दी fail करने जैसा बदलने से outage numbers भी बढ़ गए
- Developers द्वारा outages ठीक करने का समय बहुत घटा, लेकिन इसे track करने वाला कोई metric नहीं था
- Team members के launch risk को कम करने के लिए अपने projects को कई हफ्तों या महीनों तक टालना भी पड़ा
- Team के लिए यह सही फैसला था, लेकिन promo packet में प्रभावशाली नहीं दिखता था
- Committee को team member का project ऐसा महत्वपूर्ण काम लगा जिसमें ज्यादा coordination चाहिए था, और अपना काम ऐसा लगा जिसे आसानी से रोका जा सकता था
- पहली promotion review का परिणाम यह था कि technical complexity संभाल पाने के evidence और Google पर पड़े impact की कमी मानी गई
Rejection के बाद काम करने का तरीका कैसे बदला
- पहली rejection के बाद लगा कि वही अच्छे काम करते रहना है, बस records बेहतर रखने हैं
- Team को कई false-alarm email notifications मिल रहे थे, फिर भी तुरंत ठीक करने के बजाय पहले notification frequency metrics बनाकर historical record छोड़ना चाहा
- क्योंकि promotion के समय notifications घटने का graph दिखाया जा सकता था
- इसके बाद मिला project promotion के लिए अनुकूल दिखता था
- Google के लिए महत्वपूर्ण field machine learning पर बहुत निर्भर था
- सैकड़ों workers द्वारा manually किए जा रहे काम को automate करता था
- Junior developer को lead करना था, जो आमतौर पर promotion review में points दिलाने वाला factor था
Year-end gift incident और “business relationship” की समझ
- Google ने लंबे समय से चली आ रही lavish year-end gifts की tradition बंद कर दी, और gift budget से low-income students के लिए Chromebooks खरीदकर headlines में आया
- इससे जुड़ी employee conversation में एक employee ने कहा कि Google और employees का रिश्ता business relationship है
- उस बातचीत से यह एहसास हुआ कि Google और वे एक community से ज्यादा, पैसे लेकर services देने वाला संबंध हैं
- अगर promotion committee bug fixes या team support work को reward नहीं करती, तो ऐसे कामों में समय लगाने की वजह पर भी फिर से सोचना पड़ा
Promotion optimization और quality standards में बदलाव
- पहली promotion rejection से मिला lesson बाद में गलत लगा
- उसी काम को बेहतर package करने के बजाय, promotion committee जो चाहती है वही काम exclusively चुनने की तरफ बदलाव हुआ
- नई strategy थी कि हर काम शुरू करने से पहले पूछा जाए कि क्या यह promotion में मदद करेगा, और अगर नहीं करेगा तो उसे न किया जाए
- Code quality standards भी नीचे आ गए
- “क्या यह अगले 5 साल maintenance-friendly रहेगा” से बदलकर “क्या यह promotion तक टिक सकता है” हो गया
- Project launch को खतरा न पहुंचाने वाले bugs को register या fix नहीं किया
- Maintenance responsibilities से बाहर निकल गए
- Campus recruiting events में volunteer करना बंद किया
- हफ्ते में 1–2 बार लिए जाने वाले interviews को 0 कर दिया
बार-बार project cancellations और career control का खत्म होना
- Priorities बदलने पर promotion के लिए अनुकूल दिख रहा project India की sister team को दे दिया गया
- इसके बदले मिला project undocumented था, unsupported infrastructure पर था, लेकिन production का महत्वपूर्ण component था
- नया काम उस system को sister team के code से अलग करना और नए framework में migrate करना था, साथ ही production operations और performance metrics बनाए रखने थे
- Promotion के लिहाज से यह कई महीनों की पीछे हटने जैसी बात थी
- Cancelled project launch नहीं हुआ, इसलिए दो महीने का काम बेकार हो गया
- नए system को समझने में कई हफ्ते चाहिए थे
- Operations maintenance जैसे repetitive work में extra time लग सकता था
- 6 महीनों में तीसरी बार बीच project reassignment हुआ, और हर बार वजह work quality नहीं बल्कि top management strategy या team headcount changes थे
- Google कहता था कि project पूरा होने से पहले काम को judge नहीं किया जा सकता, लेकिन साथ ही project को बीच में रोककर नया काम assign करता था, जिससे completion मुश्किल हो जाता था
- Career ऐसी structure पर निर्भर हो गया जिसमें एक anonymous committee लगभग एक घंटे तक review करती है, और management decisions, जिनमें अपनी कोई भूमिका नहीं होती, दिशा तय करते हैं
आखिरी promotion attempt और resignation का फैसला
- Google में 3 साल promotion में invest किए थे, इसलिए resign करने से पहले आखिरी बार promotion के लिए apply करने का फैसला किया
- Performance period खत्म होने से 6 हफ्ते पहले project फिर cancel हो गया, और इस बार पूरी team cancel हो गई
- Google में ऐसी चीजें इतनी common थीं कि इसके लिए defrag जैसा euphemism था
- Team का project India की sister team को transfer हुआ
- Team members को company के दूसरे areas में फिर से शुरुआत करनी पड़ी
- फिर भी promotion के लिए apply किया, और result सर्वोच्च performance rating Superb था
- यह rating हर cycle में लगभग 5% employees को दी जाती है
- Promotion committee ने माना कि पिछले 6 महीनों में senior-level work साफ तौर पर दिखा
- वे 6 महीने promotion-optimized तरीके से काम करने की अवधि थी
- लेकिन यह कहते हुए promotion नहीं मिला कि 6 महीने पर्याप्त लंबा track record नहीं है
- Manager ने कहा कि इसी level का काम 6 महीने और करने पर promotion की संभावना ज्यादा है, लेकिन 2 साल से “6 महीने बाद promotion की संभावना” सुनते आ रहे थे, इसलिए छोड़ने का फैसला किया
Indie Hackers और independent development plan
- लगभग इसी समय Indie Hackers मिला
- Indie Hackers छोटे software business founders की online community थी
- इसका केंद्र वे लोग थे जो विशाल startup का सपना देखने के बजाय living expenses निकाल सकने वाला छोटा, profitable business बनाना चाहते थे
- पहले लगता था कि software founder बनने के लिए Silicon Valley-style startup path अपनाना होगा
- इसे ऐसा समझते थे कि ज्यादातर समय fundraising में जाता है, और अगले 10 लाख users लाने की चिंता रहती है
- Indie Hackers का तरीका एक अलग विकल्प था
- कई members अपनी savings या main job के साथ side project के रूप में business शुरू करते हैं
- Investors को जवाब देने की जरूरत नहीं
- Anonymous committee के सामने खुद को prove करने की जरूरत भी नहीं
- Downsides भी साफ थे
- Income कम stable होती है
- Fatal risks ज्यादा होते हैं
- अगर Google में 10 million dollars का नुकसान कराने वाली गलती की होती, तो postmortem लिखकर उसे learning opportunity माना जा सकता था; लेकिन छोटे founder के लिए यह business बंद होने और बड़े debt में बदल सकता है
- फिर भी Indie Hackers founders में यह बात आकर्षक थी कि उनका business तेजी से बढ़े या सालों तक stagnant रहे, फैसले वे खुद लेते हैं
- Resignation के बाद योजना है कि कई projects को कुछ-कुछ महीनों तक आजमाकर response देखा जाए
- KetoHub को continue develop करके monetization potential जांचना
- Distributed storage technology Sia के ऊपर business बनाना
- Writing पर ज्यादा समय देना और monetization methods खोजना
- Google अच्छी workplace थी और valuable skills सीखने की जगह थी, लेकिन निष्कर्ष यह रहा कि Google जैसे employers आगे भी रहेंगे, जबकि अपनी company शुरू करने की स्वतंत्रता हमेशा नहीं मिलती
1 टिप्पणियां
Hacker News की टिप्पणियां
इसी लेखक ने कई software businesses खड़े करने की अपनी कोशिशों पर वार्षिक retrospective सीरीज़ भी दिलचस्प तरीके से शेयर की है, और अपनी financial situation पर भी काफी ईमानदारी से बात की है
अगर bootstrapped तरीके से software business बढ़ाने में रुचि है, तो यह पढ़ने लायक है:
https://mtlynch.io/tags/annual-review/
https://mtlynch.io/i-sold-tinypilot/
सफलता की कहानियां अक्सर सुनाई देती हैं और सफल होने पर जोर से बोलना आसान होता है, लेकिन यह याद रखना चाहिए कि हकीकत में ज्यादातर companies असफल होती हैं। इस लेखक ने तीसरे साल में पैसे कमाने वाली चीज़ ढूंढ ली, लेकिन ज्यादातर लोगों के पास बिना income के उतना टिके रहने की गुंजाइश नहीं होती
इतने relatable और ईमानदार लेख लिखने वाले लोग दुर्लभ हैं। मैं कई सालों से उन्हें follow कर रहा हूं, और वे inspiration का शानदार source हैं
किसी भी career में सबसे अहम सीख यह है कि “customer, customer नहीं होता।” असली customer वे लोग होते हैं जो salary hike, bonus, promotion तय करते हैं
customer वह entity है जो उन products या services के लिए पैसे देती है जिन्हें वह valuable मानती है, और आम तौर पर वह manager होता है या मूल लेख के case की तरह promotion committee। उस नज़रिए से, अपने career को एक business की तरह चलाते हुए, ऐसे entity को value जल्दी deliver करने की दिशा में बढ़ना सही है जो पैसे को value से exchange कर सके। customer का मन बदलना, market का criteria बदलना, और यह अहसास होना कि मैं गलत चीज़ पर focus कर रहा था—ये सब business में भी आम हैं। अगर आप customer को उसकी चाही चीज़ नहीं दे पाते, तो customer आसानी से किसी और के पास जा सकता है, इसलिए strategy लगातार बदलनी और customer के हिसाब से ढलनी पड़ती है
अंत में असली customer कोई इंसान भी नहीं, बल्कि process बन जाता है। लोगों की मदद करने वाले बेहतरीन ideas को जुनून से pursue करना career और society दोनों के लिए सबसे अच्छा point है। मूल लेख का यह हिस्सा इसे अच्छी तरह दिखाता है: “यह स्वाभाविक है कि मेरी किस्मत एक ऐसी रहस्यमयी committee के हाथ में है जिसने मुझे कभी देखा तक नहीं। वे favoritism या politics से प्रभावित नहीं होंगे, और मेरे high-quality code और sharp engineering decisions को पहचानेंगे”
ऐसे patterns product quality गिरने और team dynamics खराब होने की ओर ले जाते हैं। बेहतर है कि इस अपरिहार्य प्रवाह को explicitly रोकने वाली company खोजें, या ऐसी company जहां यह प्रवाह अभी बना ही न हो। अच्छी quality बनाना और उसका recognition मिलना—इससे सभी बेहतर महसूस करते हैं
जब किसी के कहने पर कुछ बनाया जाता है, तो buyer जो चाहता है और असल में जिसकी जरूरत है, वे अलग हो सकते हैं, और अंत तक पहुंचने पर भी dissatisfaction रह सकती है। अगर boss के लिए काम करते हैं, तो boss खुद भी obstacle बन सकता है। सिर्फ customer जैसा चाहता है वैसा करना काफी नहीं होता, और boss “मेरे तरीके से” करने को कह सकता है, जिससे customer को उसकी चाही चीज़ नहीं मिल पाती। जब customer किसी और के लिए चीज़ खरीदता है, तब भी indirectness की वजह से failure हो सकता है—enterprise custom software में यह अक्सर होता है
इस लेख से पूरी तरह सहमत होना मुश्किल है। प्रोजेक्ट का पूरा होने से पहले टूट जाना बहुत झुंझलाहट भरा है, लेकिन लेखक ऐसा भी लगता है कि वहाँ सिर्फ प्रमोशन के लिए था
प्रमोशन अच्छी बात है, लेकिन यह पर्याप्त रूप से नहीं बताया गया कि वही छोड़ने लायक इतना निर्णायक कारण क्यों था। अगर नौकरी में टिके रहने की इकलौती वजह सिर्फ बेहतर पदवी की उम्मीद हो, तो यह खराब संकेत हो सकता है। बाद में उन्होंने Google में 4 साल में ज़िंदगी भर के लिए काफी पैसा कमा लिया, और उस वित्तीय स्थिरता के दम पर ऐसा high-risk विकल्प चुना जिसे ज़्यादातर लोग वहन नहीं कर सकते। खैर, अच्छी बात है कि उन्हें अपने लिए सही काम मिल गया, और उम्मीद है कि उस स्थिरता के आधार पर वे कुछ उपयोगी और प्रभावशाली बना पाएँगे
ये सारे तत्व पहले बहुत खुले तौर पर मौजूद थे, और presentations, slides, documents वगैरह की भरमार थी। आप किस level पर हैं और जिससे बात कर रहे हैं वह किस level पर है, यह मायने रखता था। लक्ष्य अच्छा इंजीनियर बनना या अच्छा product बनाना नहीं था, बल्कि सिर्फ वही काम करना था जिससे कोई अनाम committee वह जादुई नंबर बढ़ा दे। भले ही आप Google में इस वजह से शामिल न हुए हों, आखिरकार आप सीख जाते हैं कि आपसे क्या अपेक्षा है। दुख की बात है कि software engineers की एक पूरी पीढ़ी ने यह सबक सीखा
impact बनाने या संदिग्ध metrics सुधारने का दबाव कभी खत्म नहीं होता, और उसी दौरान technical debt जमा होता जाता है। संगठनात्मक फेरबदल और layoffs को लेकर अनिश्चितता भी हमेशा रहती है, और अगले review cycle को लेकर चिंता भी बड़ी होती है। कुछ साल बाद लगता है कि पैसा ही मुख्य motivation है। हालांकि मैं और stress नहीं चाहता, इसलिए promotion नहीं चाहता, और कहीं और इतना अधिक कमाना बहुत मुश्किल होगा, इसलिए इस कंपनी में जितना हो सके उतना लंबे समय तक रहना चाहता हूँ
मानव मनोविज्ञान ऐसे काम नहीं करता। आप अपने आसपास के लोगों से प्रतिस्पर्धा करने लगते हैं, और जब वे promotion पा रहे हों और आप ही पीछे रह जाएँ, तो खुश रहना मुश्किल है
Staff से नीचे के level पर लंबे समय तक टिके रहना नकारात्मक असर डाल सकता है, और promotion न होने पर घोषित expectations पूरी न करने के कारण आपको performance improvement plan में डाला जा सकता है। Google ने आखिरकार वह wording हटा दी, क्योंकि 100,000 लोगों वाली कंपनी में pyramid में पर्याप्त जगह नहीं होती, और वे लोग खो जाते हैं जो self-promotion नहीं करते लेकिन system चलाते रहते हैं। अगर मेरी याददाश्त सही है, तो 2018 में उन्हें अभी यह बात पता नहीं थी
लेखक हूँ। यह लेख फिर से ऊपर आया देखकर अच्छा लगा
इस लेख के बारे में कुछ पूछना हो तो जवाब दे सकता हूँ
सुनने में ऐसा लगता है कि आपने प्रवाह को देखा और उनमें से सबसे अच्छा दिखने वाला बहाव चुन लिया, लेकिन कई बार दूसरे विकल्प भी होते हैं। बाँध बनाना, यानी भू-दृश्य बदलना। business को उस तरीके से बदलने की कोशिश करना जैसा कोई करना नहीं चाहता था या कर नहीं सकता था। पीछे मुड़कर देखने पर, मैं तब सबसे खुश और सफल था जब मैं अपने boss को बता सकता था कि मैं क्या करूँगा, बजाय इसके कि boss मुझे कोई रोचक और impactful काम देने का इंतज़ार करूँ। अगर ऐसा विकल्प दिखाई न दे तो शायद छोड़ने का समय हो सकता है, लेकिन पहले कोशिश करना अक्सर क़ीमती रहा। कभी-कभी मुझे अपने भाग्य को खुद बनाने का अधिकार पाने के लिए गंदा काम आगे बढ़ाना पड़ा, लेकिन management system और भरोसा बनने के बाद उस capital का इस्तेमाल कर बड़ा, नया और दिलचस्प कुछ propose कर सकता था। हर बार जब देखता हूँ कि boldness को reward मिलता है, तो हैरानी होती है। पिछले हफ्ते ही एक colleague ने एक महत्वाकांक्षी और विवादास्पद proposal से funding के पत्थर से खून निकाल लिया, और इस हफ्ते वह नई team का technical leader बन गया। जब भी अटका हुआ महसूस करता हूँ, खाली document खोलता हूँ और नया design टाइप करना शुरू कर देता हूँ। उस वक्त promotion के बारे में नहीं सोचता, लेकिन आखिरकार वह कहीं न कहीं promotion या बड़े अवसर में बदल गया
जिज्ञासा है कि क्या आप कोई नया project कर रहे हैं। PDF parser fuzzing से जुड़ा लेख देखा, लेकिन वह नए project से संबंधित है या नहीं, इसका context नहीं देखा या शायद छूट गया
https://mtlynch.io/i-sold-tinypilot/
सार्वजनिक रूप से लिखने और अपनी यात्रा document करने के लिए धन्यवाद; मदद पाने वाला मैं अकेला नहीं होऊँगा। साथ ही, आपका username देखते ही हमेशा Mount Lynch जैसा पढ़ता हूँ
इस लेख से मेरा निष्कर्ष यह है कि promotion committee पर निर्भर structure कितना बेरहम है
समझ आता है कि Google ने engineering-focused culture बनाने के लिए ऐसी व्यवस्था रखी होगी। शायद उद्देश्य यह था कि manager मान्यता न दे तब भी शानदार engineering work को recognition मिले। लेकिन culture improvements जैसे काम, जिन्हें quantify करना मुश्किल है, उनके मामले में ऐसी committee शानदार engineering को सही तरह पहचानती है, ऐसा नहीं लगता। ज़िंदगी तब बेहतर होती है जब मुझे ऐसा counterpart, customer या leader मिलता है जो मेरे लाए value को पहचानता है, और उस recognition को promotion decision के रूप में दिखा सकता है। packets पर निर्भर faceless committee संरचनात्मक रूप से वह रिश्ता बना ही नहीं सकती जिसमें असली recognition पैदा हो। अगर leadership मुझे recognize नहीं करती, तो ऐसी कंपनी में जबरन क्यों रहना? ऐसी जगह खोजिए जो recognize करे। अगर Google यह नहीं सीख पाता कि खराब management या processes की वजह से अच्छे talent खोने से बचा नहीं जा सकता, तो यह उनका नुकसान है। ठीक-ठाक performance reviews का फायदा उठाइए और धीरे-धीरे exit plan बनाइए। ऐसे संगठन में काम करने के लिए ज़िंदगी बहुत छोटी है जो genuine और supportive professional relationships बनाने को सक्रिय रूप से रोकता हो
बहुत लोगों के लिए promotion वैसा है जैसे pie-eating contest जीतने पर इनाम और ज़्यादा pie मिलना। यह स्वीकार करना ठीक है कि आपके हित और employer के हित सिर्फ ढीले-ढाले ढंग से जुड़े हैं, और कंपनी जिस तरह का game चाहती है उसे खेलने से मना करना भी ठीक है
प्रमोशन की बात छोड़िए, वे ऐसा काम करना चाहते हैं जो आंतरिक प्रेरणा दे—यानी अर्थपूर्ण, प्रेरक और जिसमें डूबकर काम किया जा सके—और इतना ही कमाना चाहते हैं कि गुज़ारा चल सके और ठीक-ठाक बचत हो सके।
समस्या तीन तरह की है। कई कंपनियां इतना खराब compensation देती हैं कि थोड़ी बचत करने के लिए प्रमोशन जरूरी हो जाता है; अर्थपूर्ण काम अपने-आप में unicorn जैसा दुर्लभ है; और सबसे चिढ़ाने वाली बात यह है कि अपनी भूमिका में स्थिर और लगातार अच्छा प्रदर्शन करने वाले workers पर भी अमेरिकी कंपनियों में अनिवार्य रूप से “grow” करने और “career develop” करने का दबाव डाला जाता है, या उन्हें “पीछे रह गया” कहा जाता है। किसी खास level पर लगातार उत्कृष्ट प्रदर्शन करना ठहराव नहीं, बल्कि जानबूझकर चुनी गई स्थिरता हो सकती है। व्यक्ति के संदर्भ में अनंत growth, या कम-से-कम अनंत हलचल, अमेरिकी कंपनियों की समझ से परे पागलपन है।
लेखक की यह पंक्ति असरदार लगी: “career को आगे बढ़ाते रहने के लिए मुझे बड़े scope वाले projects और ज्यादा partner teams के साथ collaboration की जरूरत थी। लेकिन इसका मतलब था कि project मेरे control से बाहर के और ज्यादा factors की वजह से fail हो सकता था, और मेरी जिंदगी के महीनों या सालों का समय बरबाद हो सकता था।”
पीछे मुड़कर देखने और सोचने पर शायद यह मानना पड़ेगा कि startup की सफलता भी control से बाहर के 100 से ज्यादा factors पर निर्भर करती है। यह जिंदगी का समय बरबाद करना नहीं है। यह सीखना है कि दुनिया कैसे चलती है।
high-growth venture-funded startup में सफलता के लिए शायद कई चीजों का सही समय पर सही जगह बैठना जरूरी हो। लेकिन bootstrap business में मूल रूप से सफलता के लिए सिर्फ एक चीज चाहिए: product-market fit। अगर आप ऐसा product बनाते हैं जो लोग चाहते हैं, तो कई दूसरी गलतियों के बावजूद आम तौर पर सफल होने की संभावना काफी होती है। TinyPilot शुरू करते समय मुझे hardware या physical products बेचने के बारे में कुछ भी नहीं पता था, इसलिए मैंने अनगिनत गलतियां कीं। लेकिन मैंने ऐसा product ढूंढ लिया जिसके लिए लोग पैसे देने को तैयार थे, और उसे customers के सामने रखने का अच्छा तरीका ढूंढ लिया, इसलिए company चल पड़ी। कुछ चीजें मैंने सही भी कीं, लेकिन पहले साल में ज्यादातर ऐसा लगा कि revenue अपने-आप बढ़ रहा है और मैं बस उसे catch up करने की कोशिश कर रहा हूं। product-market fit पाने के लिए अब भी किस्मत चाहिए, क्योंकि कई credible लगने वाले ideas fail हो जाते हैं। फिर भी, कई चीजों के एक साथ किस्मत से सही होने का इंतजार नहीं करना पड़ता; बस एक बार किस्मत साथ देनी होती है।
यह भी 2018 वाला एक और कुख्यात “मैंने Google क्यों छोड़ा” लेख है।
और ऐसे लेख हमेशा यह कहते हुए शुरू होते हैं कि Google engineers दुनिया के सबसे smart लोग हैं। सच में brainwashed लोग हैं।
मैं भी इसी वजह से Google छोड़ने के बारे में सोच रहा हूं। meetings में बैठना, जरूरी काम दूसरों पर धकेलने की कोशिश करना, और games खेलने में मेरी लगभग कोई दिलचस्पी नहीं है, जबकि मेरे project में सैकड़ों छोटे tasks हैं जिन्हें मुझे पूरा करना है।
job बदलूं तो सालाना 50,000–100,000 डॉलर ज्यादा कमा सकता हूं। अगली company मेरे experience को सच में valuable मानेगी, जबकि वही experience technically Google के लिए कहीं ज्यादा उपयोगी है।
अब मैं 100,000 लोगों वाली सबकुछ करने वाली company के बजाय focused project वाली छोटी company में ज्यादा तेजी और असरदार तरीके से काम कर रहा हूं, और ज्यादा पैसा भी कमा रहा हूं।
structure ऐसा था: “क्या manager आपको promote नहीं करता?” “नहीं। Google manager अपने direct reports को promote नहीं कर सकते। उनके पास vote तक नहीं होता। इसके बजाय promotion decision senior-level software engineers और managers की एक छोटी committee लेती है, जो उस दिन पहली बार आपको जानती है।”
जहां तक मुझे पता है, 2022 के बाद यह बदलकर ऐसा हो गया लगता है कि manager के पास अकेला vote होता है।
promotion अब भी promotion committee के पास जाता है। बस अब कोशिश होती है कि committee organization के इतनी नजदीक हो कि उसने candidate के बारे में सुना हो, और meeting में manager नहीं बल्कि high-context reviewers हों। पिछले system से जो बात जारी है, और जिसे ऐसे लेख अक्सर miss कर देते हैं, वह यह है कि हर level पर साफ expectations होती हैं कि उस level का व्यक्ति किन activities को independently करने लायक माना जाता है। promotion decision मौजूदा काम अच्छे से करने का reward नहीं है, बल्कि यह फैसला है कि क्या आपने अगले level का काम करने की पर्याप्त क्षमता दिखा दी है। अगर कोई व्यक्ति किसी level पर लंबे समय तक रहता है, तो आम तौर पर वजह यह होती है कि वह अगले level के signals नहीं दिखा पाया। बेशक, team में अगले level signals दिखाने के मौके कम हो सकते हैं, या कुछ projects का impact evaluate करने में सालों लगते हैं और operational impact evaluate होने तक काम की recognition नहीं मिलती—ऐसी चीजें unfair लग सकती हैं। फिर भी, यह अक्सर उतना मनमाना नहीं होता जितना सुनाई देता है।
हर साल चीजें बदलती हैं, इसलिए मैं अपने निजी experience से 2024 के Google का judgment नहीं करूंगा, लेकिन जिस साल मैं वहां था, एक समय manager को यह भी मुश्किल से पता था कि मेरी सीट कहां है। मेरे L5 और L6 promotion packets को peer committee ने evaluate किया था, और मुझे नहीं पता कि उन्होंने manager evaluation देखा भी था या नहीं। जब मैं L5 promotion committee में बैठा था, तब भी manager evaluation को ज्यादा weight नहीं दिया था। उस समय यह समझ में आता था, क्योंकि managers L5 promotion का आधार बनने वाले areas से काफी hands-off थे।
लेकिन इसमें कोई mystery नहीं है; आखिरकार candidate को क्यों promote किया जाना चाहिए, यह साफ दिखाने वाला strong packet बनाने की जिम्मेदारी manager की होती है। promotion attempt अपने-आप में manager का vote है, और उसके बाद बात इस पर निर्भर करती है कि वह candidate के promotion को कितनी मजबूती से push करता है। मुझे लगता है कि promotions के बीच consistency सुनिश्चित करने का यही एकमात्र तरीका है।