Google द्वारा अधिग्रहण की प्रक्रिया से सीखे गए सबक
(shreyans.org)- Socratic ने यह समझने के बाद कि केवल usage growth से निवेशकों को मनाना मुश्किल है और monetization की सीमा है, Snapchat partnership discussion से शुरू हुई प्रतिस्पर्धी प्रक्रिया के बाद मार्च 2018 में Google द्वारा अधिग्रहित किया गया
- 10 लोगों की टीम Google की एक internal team के साथ मिलकर product को फिर से बनाया, और उसके परिणामस्वरूप Socratic by Google, Search·Lens features, और math solving feature बने
- Google के अंदर विशाल monorepo, data center status, long-term strategy documents, और 2 लाख से अधिक लोगों के network तक पहुंच मिलती है, लेकिन ज़्यादातर काम Google के तरीके के अनुसार करना पड़ता है
- Search और AI पर काम केवल advanced algorithms का सवाल नहीं है, बल्कि example review, pattern discovery, manual labeling, और spreadsheet-based parallel comparison पर भी बहुत निर्भर करता है
- Google बड़े काम संभव बनाता है, लेकिन changing goals, reorg, approval process, process debt, और senior-heavy team structure product launch को कठिन बना देते हैं
Socratic का Google द्वारा अधिग्रहण
- Socratic ने 2017 में Series B की तैयारी करते समय यह समझा कि usage growth को प्राथमिकता देकर revenue को टालने की रणनीति fundraising में समस्या बन रही थी
- growth ने VC meetings के दरवाज़े खोले, लेकिन हर VC ने monetization plan मांगा
- credit card न रखने वाले high school students को target करने वाला education app बड़ा business बनना मुश्किल है, इस निष्कर्ष पर पहुंचे
- लगभग उसी समय Snapchat के CEO Evan Spiegel ने camera-based homework helper को Snapchat app में integrate करने के लिए partnership का प्रस्ताव दिया
- एक advisor का मानना था कि Snapchat के Head of Corporate Development से परिचय आगे चलकर acquisition offer में बदल सकता है
- Socratic ने प्रतिस्पर्धी प्रक्रिया बनाने के लिए Microsoft, Chegg, Byju’s, और Google से संपर्क किया
- co-founder Chris अपने Google में काम करने के पिछले अनुभव की वजह से Lens team से जुड़ पाए
- उस समय Google की तरफ़ से Khan Academy और Android के co-founders की भागीदारी वाले education-related efforts पहले से शुरू थे
- दोनों पक्षों ने पाया कि learning-focused AI tutor की उनकी vision काफ़ी हद तक मिलती है
- Google Play के 2017 Best App चुने जाने के बाद, मार्च 2018 में Socratic का Google द्वारा अधिग्रहण हुआ
Google के तरीके से product को फिर से बनाना
- Socratic team को Google की समान आकार की एक मौजूदा team के साथ मिला दिया गया, और यह कई long-tenured Googlers वाला संगठन बन गया
- Chris और लेखक ने क्रमशः product और engineering lead की भूमिका संभाली
- लक्ष्य AI-based tutor बनाना और उसकी capabilities को Google के बड़े products तक ले जाना था
- अगले 3 सालों में Socratic को फिर से बनाया गया और Socratic by Google के रूप में relaunch किया गया
- Search और Lens में Socratic features जोड़े गए
- math solving feature launch किया गया, और step-by-step math tutor prototype बनाया गया
- Google भर में इस्तेमाल होने वाली capabilities भी बनाई गईं
- Google में existing codebase को बनाए रखना मुश्किल था
- product insights को नई team के साथ फिर से खोजना पड़ा, और app को Google stack पर शुरू से दोबारा बनाना पड़ा
- homework problems के topics classify करने वाले ML system जैसे पहले से हल किए गए problems को भी Search techniques और Search standards के हिसाब से फिर से हल करना पड़ा
- app mascot Ceebo Google के सामान्य app icon style से अलग एक अपवाद था
- Google की तरफ़ से “हम anthropomorphize नहीं करते” कहकर विरोध हुआ, और Socratic की तरफ़ से Android का उदाहरण देकर जवाब दिया गया
- team छोटी थी, इसलिए यह बड़ा मुद्दा नहीं बना, और Ceebo app icon बना रहा
- बाद में Google के अंदर इसके कई variations बनाए गए और यह documents व sites में दिखाई दिया
Google के अंदर क्या संभव है और क्या सीमित है
- Google में काम करना दूसरे passport होने जैसा है
- badge दुनिया के प्रमुख शहरों में offices, food, desks, और Google internal network तक पहुंच खोल देता है
- 2 लाख से अधिक लोगों वाले Google network से तेज़ी से जुड़ाव हो जाता है
- joining के तुरंत बाद ही विशाल internal assets तक पहुंच मिल सकती है
- अरबों lines of code वाला Google का विशाल monorepo
- दुनिया भर के data centers की real-time status
- 20 सालों के strategy documents
- Jeff Dean जैसे लोगों तक सीधी पहुंच
- Google का लगभग सारा software और infrastructure अंदर ही बनाया जाता है
- Google ने ज़्यादातर कंपनियों से पहले सबसे कठिन engineering problems का सामना किया है, इसलिए बाहरी दुनिया का अंदर आना दुर्लभ और सावधानी से होता है
- external tools या startup-style तरीके अक्सर Google के scale और standards पर फिट नहीं बैठते
- Socratic की computer vision capability ने भी यही सीमाएं झेलीं
- startup दिनों में image के अंदर के text और math को पढ़ने के लिए third-party tools इस्तेमाल होते थे
- Google के अंदर sensitive data exposure, scale expectations, और जटिल vendor review की वजह से उनका उपयोग कठिन था
- इस problem में रुचि रखने वाली AI research team ने PhD-level talent hire किया और 6 महीनों के भीतर world-class math recognition API बना दी
- Steve Yegge के Google·Amazon platform comparison लेख की तरह, यह service बाहरी दुनिया के लिए जारी नहीं की गई
Search और AI काम की असली तस्वीर
- Socratic के query classification system को Search veterans के साथ फिर से बनाते हुए, Search कैसे बनता है इसकी झलक मिली
- Google के पास information retrieval tools की गहराई बहुत है, और वह internet के हर page पर नए signals compute करके जोड़ सकता है
- उदाहरण हैं
contains_math,subject:chemistryजैसे signals
- Search improvements का बड़ा हिस्सा engineers द्वारा old vs new results की सीधी तुलना करके review किया जाता है
- यह comparison spreadsheets में होता है
- advanced algorithms implement करने वाली छवि के विपरीत, बहुत सा काम examples देखना, patterns ढूंढना, और data को manually label करना होता है
- बेहतरीन AI teams में भी manual data review महत्वपूर्ण होता है
- Jason Wei के अनुसार, अच्छा AI researcher वह है जो बहुत सारा data खुद देखने को तैयार हो, और उसे तेज़ी से करने के लिए infrastructure भी बनाता हो
- manual data review चमकदार नहीं लगता, लेकिन यह problem के बारे में intuition देता है
बड़े संगठन में काम आगे बढ़ाने की कठिनाई
- Google 1 करोड़ से 5 करोड़ users के scale की problems पर भी समय नहीं लगाता अगर वे उसकी strategy से मेल न खाएं
- वहीं दूसरी ओर, अगर कोई problem Google के स्वभाव, strategy, या किसी के promotion goals से मेल खाती हो, तो उस पर बहुत बड़ा प्रयास लगाया जा सकता है
- Google में असाधारण काम करने के लिए ज़रूरी है कि सही लोग लगातार रुचि बनाए रखें
- समझदार VP, संबंधित goals वाली research team, और org goals के साथ compatibility चाहिए
- privacy, trust and safety, और infrastructure capacity जैसे approvers की अनुमति भी चाहिए
- idea संभव है या नहीं यह जानने के लिए दर्जनों बातचीत चाहिए, और उसे हक़ीक़त बनाने के लिए सैकड़ों और बातचीत करनी पड़ती हैं
- org goals और structure लगातार बदलते रहते हैं
- हर quarter में team goals बदल सकते हैं
- reorg से पूरी team गायब हो सकती है
- अलग-अलग दो teams एक ही idea पर काम करें और अंत में केवल एक ही आगे बढ़े, ऐसा भी हो सकता है
- हारने वाले project के internal users ऐसी स्थिति झेल सकते हैं जहां जिस API पर वे निर्भर थे उसका support बंद हो गया हो, लेकिन replacement अभी तैयार न हो
- Googlers अच्छे काम launch करना चाहते थे, लेकिन कई barriers के नीचे दबे रहते थे
- बहुत सारे reviews, बार-बार होने वाले reorg, पिछली असफलताओं से बने organizational scars, और global scale पर साधारण काम करने की जटिलता समस्याएं थीं
- startup बहुत सी चिंताओं को नज़रअंदाज़ कर सकता है, लेकिन Googlers आम तौर पर ऐसा नहीं कर पाते
- ऐसे smart लोग जो हर चीज़ का विरोध कर सकते हैं लेकिन किसी चीज़ का समर्थन नहीं करते, ऐसे leaders जो असुविधाजनक सच्चाई नहीं बोलते, और ऐसे लोग जिन्हें बिना स्पष्ट project के hire किया गया लेकिन जिन्हें promotion-worthy काम खुद बनाना है, ये सब भी रुकावट बनते हैं
- senior-heavy teams के लिए direction बदलना कठिन होता है
- सफल co-founders और 10~20 साल के Google veterans से भरी team अद्भुत चीज़ें बना सकती है, लेकिन deadlock में फंसना भी आसान है
- कई exploration areas, स्पष्ट goals, और मजबूत autonomy हो तो यह काम कर सकता है
- लेकिन एक unified product बनाने के लिए स्पष्ट leader, स्पष्ट direction, और सोचने वालों से ज़्यादा execute करने वाले लोगों की ज़रूरत होती है
- शुरुआती stage project में सिर्फ़ और लोग जोड़ देने से काम तेज़ नहीं होता
- process debt technical debt जितनी ही वास्तविक समस्या है
- failed launches की वजह से reviews जुड़ते जाते हैं, lawsuits की संभावना रोकने के लिए legal review बढ़ते हैं, और document templates में sections जमा होते जाते हैं
- कई सालों तक परतें जुड़ने के बाद, feature तैयार होने पर भी वह reviews के बीच फंसा रह सकता है और महीनों तक launch नहीं हो पाता
- Google ने हाल ही में performance review process को साल में दो बार से एक बार, और लंबे survey से छोटे survey में बदला
- उम्मीद है कि managers के समय का 30% से अधिक लेने वाली प्रक्रिया 10% से कम पर आ जाएगी
- Google ने ChatGPT की बुनियादी technologies का आविष्कार किया था, लेकिन वही company उस product को launch करने वाली नहीं थी
- अब Google को AI lead वापस पाना चाहने वाले builders और हर संभव समस्या रोकना चाहने वाले reviewers के बीच के तनाव को सुलझाना होगा
- Google के “The Three Respects” में तीसरे, respect the opportunity, को इस सवाल की तरह समझा गया कि Google जैसे असाधारण अवसर का उपयोग कैसे किया जाए
- पहले आपको दिया गया काम करना होता है
- फिर Google के विशाल network में जाकर plans और inventions को समझना होता है, और future vision को documents और demos के रूप में ठोस बनाना होता है
- उसके बाद उस image और goal से मेल खाने वाले leaders खोजने होते हैं, और idea को लगातार बेचना पड़ता है
- step-by-step math tutor demo इसका उदाहरण था कि यह तरीका काम कर सकता है
- नई math solving feature के ऊपर तीन लोगों ने कई महीनों तक side project के रूप में इसे बनाया
- demo ने intelligent tutor vision को link से share किए जा सकने वाले रूप में बदल दिया और बातचीत को ठोस बनाया
- यह team के बाहर फैल गया, स्वतंत्र रूप से discuss हुआ, और फिर वापस Socratic team से जुड़ गया
- एक leader ने आने वाली दिशा को साफ़ देखा और अच्छा demo बनाया, लेकिन वह company के उस हिस्से में था जहां वह फिट नहीं बैठता था, और उसके manager के goals भी अलग थे
- बाद में वह अधिक उपयुक्त team में चला गया, और उस सपने को हक़ीक़त बनने की संभावना मिली
- Socratic acquisition का नतीजा मिश्रित रहा
- दो संस्कृतियां मिलीं, product जीवित रहा, और अब हर साल लगभग 5 अरब queries संभालता है
- Socratic team के सदस्यों के careers भी आगे बढ़े
- दूसरी ओर Chris और लेखक Google छोड़कर अपनी-अपनी startups शुरू करने चले गए
- Socratic team और Google व्यापक रूप से अब भी Google की क्षमता के अनुरूप AI-based tutor नहीं बना पाए हैं
1 टिप्पणियां
Hacker News की राय
red badge समस्या सच में बहुत वास्तविक थी
टीम में TVC होना एक अजीब अनुभव था, और साथ में कड़ी मेहनत करके लॉन्च करने पर भी केवल red badge कर्मचारियों को ही celebratory swag या टीम लंच से बाहर रखा जाता था
वजह पूछने पर मैनेजर ने कहा, “अगर Jim को सीधे कुछ दे दिया जाए तो वह compensation जैसा लगेगा और इससे ऐसा माना जा सकता है कि उसके साथ employee जैसा व्यवहार किया गया,” और all-hands मीटिंग में शामिल होने की पाबंदियां, ऐसे दरवाज़े जिन्हें खोला नहीं जा सकता था, और ऐसी internal sites भी थीं जिन्हें देखा नहीं जा सकता था
TVC के साथ काम करते समय ऐसा training दिया जाता था मानो house-elf ownership law सिखाया जा रहा हो: “कपड़े दे दिए तो वह आज़ाद हो जाएगा, इसलिए कभी मत देना, और अगर वह दावा करे कि वह Google में काम करता है तो रिपोर्ट करो” जैसी बातें थीं
कई किस्से हैं, लेकिन सबसे ज़्यादा याद रहने वाली बात यह है कि उसी फ़्लोर पर सबको earthquake safety kit मिला था, सिर्फ़ मुझे नहीं
सचमुच ऐसा लगा कि Google को इस बात से कोई फ़र्क नहीं पड़ता कि मैं जिऊँ या मरूँ
उम्मीद यह बनी रहती थी कि अगर काफ़ी चापलूसी करके “अपनी क़ीमत साबित” कर दूँ तो शायद किसी दिन असली employee बन जाऊँ, और यह किसी अजीब Velveteen Rabbit fetish game जैसा लगता था
Google को “अपने employees” के साथ कितनी अच्छी तरह पेश आने पर खुद की तारीफ़ करते देखना, और साथ ही उन लोगों को खुलेआम कुचलते देखना जो full-time काम करते थे लेकिन तकनीकी रूप से regular employee नहीं थे, घिनौना था
यह एक caste system है, और जो कंपनी इस तरह चलती है उसे शहर से बाहर निकाल देना चाहिए था, लेकिन उल्टा उसने San Francisco पर ही क़ब्ज़ा कर लिया
पहले contractors के साथ employees जैसा काफ़ी बेहतर व्यवहार किया जाता था, लेकिन Microsoft के contractors ने यह कहते हुए काफ़ी मूल्य के stock की मांग की कि “हमारे साथ employees जैसा व्यवहार किया गया, इसलिए हमें employee जैसी compensation मिलनी चाहिए,” और वे मुकदमा जीत गए
अब यह कानूनी मिसाल बन चुकी है कि अगर contractors के साथ employees जितना अच्छा व्यवहार किया जाए तो legal liability पैदा हो सकती है, इसलिए उल्टा उनके साथ बदतर व्यवहार करना पड़ता है
morale या productivity के लिए यह साफ़ तौर पर बुरा है, लेकिन अगर यह distinction न बनाया जाए तो बहुत बड़ा legal risk पैदा होता है, इसलिए यह एक business decision है
यह सच है कि मैं अपनी पत्नी को लंच पर नहीं ला सकता था और free massage भी नहीं मिलती थी, लेकिन बाकी सब शानदार था
एक प्रभावशाली व्यक्ति, जिसने मेरी लिखी दो किताबें मज़े से पढ़ी थीं, ने मुझे hire किया, हम कभी-कभी फ़ोन पर बात करते थे, और एक दिन उसने मुझे Google के अपने passion project में शामिल होने के लिए बुलाया
perks में कुछ चीज़ें हैरान कर देने वाली थीं, और एक 8 घंटे की ‘end to end’ class में मैंने सिर्फ़ एक दिन में उस project के लिए ज़रूरी internal systems और कई दिलचस्प चीज़ें सीख लीं, जिसके लिए मैं पैसे देकर भी जाता
2013 के हिसाब से मैंने खाना भी बहुत enjoy किया, invited talks भी सुनीं, और इस बात का ध्यान रखा कि इस समय को दिन के 8 घंटे के काम में न गिना जाए
Molly Katzen और Alexis Ohanian से मिलकर लंबी बातचीत करना भी बहुत अच्छा लगा
मैं हमेशा सुबह लगभग 6 बजे काम शुरू करता हूँ और जल्दी निकल जाता हूँ, और कम-से-कम मेरी जानकारी में यह कभी समस्या नहीं बना, और मुझे रोज़ कम-से-कम 2 घंटे बिना व्यवधान के समय की ज़रूरत होती थी
अगर Google में थोड़े समय के लिए contract पर काम करने का मौका मिले, तो मैं इसे करने की सलाह दूँगा
science fiction में यह लगभग cliché है कि utopia को बनाए रखने के लिए कुछ ऐसे लोग ज़रूरी होते हैं जिन्हें उस utopia का हिस्सा माना ही नहीं जाता
कहानियों में protagonists इस untouchable class की हालत दुनिया के सामने लाते हैं और बुरे शासकों को गिराकर ज़्यादा बराबरी वाला समाज बनाते हैं, लेकिन शायद इसी वजह से वह fiction होता है
दुख की बात है कि यह टीम, जिसने यह लेख लिखा, मेरे जाने के 8 साल बाद acquire हुई, फिर भी वही structural problems झेल रही थी जिनके बारे में मैंने exit interview में कहा था कि वे आख़िरकार Google को बर्बाद कर देंगी
संदर्भ: https://en.wikipedia.org/wiki/Permatemp
अदालतें इस तथ्य को कि employer ने temps के साथ full-time employees जैसा “एकसाथ” व्यवहार किया, जैसे उन्हें वही benefits दिए, इस बात के सबूत के रूप में देखती हैं कि वे वास्तव में temporary workers नहीं थे
इसलिए अगर कोई कंपनी temporary या contract workers को hire करना चाहती है, तो वह ऐसा नहीं कर सकती
यह “caste” का मामला नहीं है, न ही जानबूझकर किया गया भेदभाव, न सिर्फ़ wage suppression या cost cutting का मामला, और न ही यह केवल Google की बात है
मूल रूप से दोष अदालतों का है, और यह एक भयानक फ़ैसला था जिसने अपने इरादे के ठीक उल्टा असर पैदा किया
TVC के साथ काम करते समय “कपड़े दे दिए तो वह आज़ाद हो जाएगा” जैसी training इसलिए दी जाती है क्योंकि वास्तव में ऐसा हो जाता है
Microsoft में ऐसा हुआ था और इसकी क़ीमत बहुत भारी थी, इसलिए कोई भी वही चीज़ फिर से नहीं झेलना चाहता
यह कोई खुशहाल कहानी है या नहीं, पता नहीं
इसे पढ़कर मेरा प्रभाव यह है कि अधिग्रहण के तुरंत बाद Google के तरीके से ऐप को फिर से लिखने की मांग की गई, एक अलग रिसर्च टीम ने मुख्य फीचर के लिए नया API बनाया, और अब Play Store पर Socratic by Google को 21 अक्टूबर 2020 के बाद कोई अपडेट नहीं मिला है और Android 13 डिवाइसों पर यह इंस्टॉल भी नहीं होता, तो यह बस मरा हुआ ऐप लगता है
ऐसा दिखता है जैसे Google ने कंपनी खरीदी, टीम को Google के अंदर घोल-मिलाकर खत्म कर दिया, और ऐप को मरने दिया
startup के पास ऐसे काम के लिए संसाधन नहीं होते, और Google startup-शैली में बने प्रोडक्ट को वैसे का वैसा ship नहीं कर सकता
उदाहरण के लिए, Google में जो भी चीज़ user data तक पहुंचना चाहती है, उसे डिजाइन चरण से लेकर implementation तक access control, audit, approval और enforcement की कई परतों वाले बहुत ऊँचे मानकों से गुजरना पड़ता है
Google में यह अच्छी बात है, लेकिन 10 लोगों के startup में यह काफ़ी हास्यास्पद लगेगा
Google जिस चीज़ में अच्छा नहीं है, वह कई कारणों से नए product ideas पर जोखिम लेना है, और इसलिए वह अक्सर ऐसे काम करने वाली कंपनियों को खरीद लेता है
जैसे वास्तविक जीवन में अच्छा और बुरा मिला-जुला होता है, वैसे ही यह insight दिलचस्प है
वे ज़्यादा समय तक रुके भी नहीं, इसलिए शायद यह उनके लिए काफ़ी संतोषजनक रहा होगा
यह सही है कि कोड और इंफ्रास्ट्रक्चर को फिर से लिखना पड़ा, लेकिन “ऐप को मार दिया” का मतलब होगा उसे बंद कर देना, और ऐसा नहीं हुआ
अगर पूछा जाए कि क्या यह “खुशहाल कहानी” है, तो Socratic के संस्थापकों ने बहुत कुछ सीखा, और Shreyans उस सीख को साझा करना चाह रहे हैं; यह न तो बधाई देने वाली पोस्ट लगती है, न शोक मनाने वाली
सुना है कि अब यह बेहतर हुआ है, लेकिन शायद नहीं भी
Google की search और ads से अरबों डॉलर लगातार बरसते रहे, इसलिए अधिग्रहित प्रोडक्ट को मार देना कोई बड़ी समस्या नहीं था
Google द्वारा अधिग्रहित होने पर मैंने सीखा कि अगर कंपनी एक निश्चित आकार से छोटी हो, तो सबको hiring और level तय करने के लिए technical interview देना पड़ता है
management से कहा जाता है कि कर्मचारियों से बस यह कहें कि यह एक-दूसरे से मिलने, चल रहे प्रोजेक्ट्स और सामान्य background पर बात करने का मौका है, लेकिन असल में यह पूरा का पूरा surprise technical interview होता था
2010 के दशक की शुरुआत में ऐसा था, अब भी ऐसा है या नहीं, पता नहीं
ज़रा सोचिए, graduate school से निकले 20 साल से ज़्यादा हो गए हों और अब technical interview रूम में जाना पड़े
हालांकि, पिछली रात आराम से सोना और तनाव में न होना, कई हफ़्तों की interview preparation से ज़्यादा मददगार था या नहीं, यह मुझे नहीं पता
सबको पहले ही बता दिया गया था कि interview होंगे और सभी को hire नहीं किया जाएगा
अगर यह acqui-hire हो, तो पूरी interview process हो सकती है
मैं ऐसे ही एक meet and greet में गया था, और वह बस नाड़ी चल रही है या नहीं यह देखने वाले googlyness interview के ज़्यादा करीब था; कुछ और लोगों का तो वह भी नहीं हुआ, और पूरी टीम hire हो गई
हालांकि, इससे level और price पर असर पड़ा हो सकता है
यह बात बताने पर बहुत से लोग हैरान हो जाते थे
“अगर सही लोग परवाह करें, तो Google में चौंका देने वाली चीज़ें संभव हैं” वाली पंक्ति साफ़-साफ़ बताती है कि Google OpenAI से क्यों पीछे है
उसके पास सारी तकनीक थी, लेकिन बहुत ज़्यादा bureaucracy, प्रक्रियाएँ, और साहसी leadership की कमी के कारण वह उसे बाहर नहीं ला सका
GPT-4 paper के contributors देखें, तो टीम का आधा हिस्सा Google Brain से आया था, और ऐसा लगता है कि उन्हें महसूस हुआ कि अपने काम को product बनाने के लिए उन्हें छोड़ना पड़ेगा
incentives के लिहाज़ से यह संस्कृति जड़ों तक सड़ चुकी है
Google के “अंदर” कुछ तेज़ी से करना हो, तो लगभग यही एक रास्ता बचता है कि नौकरी छोड़ो, बाहर जाकर उसे बनाओ, और फिर दोबारा अधिग्रहित हो जाओ
पिछले साल मुझे Maven में software engineer के रूप में Shreyans के साथ काम करने का मौका मिला था, और यह पोस्ट देखकर मज़ा आया क्योंकि अब समझ आता है कि वह साथ काम करने का तरीका वैसा क्यों था
उन्हें meetings और process से गहरी चिढ़ थी, और वे इस बात पर बहुत ज़ोर देते थे कि कर्मचारी खुद निर्णय लें और भरोसा न हो तो राय माँगें
उस समय यह बस बहुत तर्कसंगत लगा, इसलिए मैंने इस पर सवाल नहीं उठाया, लेकिन हो सकता है कि Google से अभी-अभी निकलने के कारण उनका यह विरोध और भी मज़बूत रहा हो
आखिरकार मुझे वह काम करने का तरीका पसंद आया, और शायद बड़ी टीमों में यह काफ़ी कठिन होगा, लेकिन मैं इसे अपनी अगली नौकरी में भी ले जाना चाहूँगा
मैं इसलिए चला गया क्योंकि यूरोप घूमते हुए urban studies में master's करने के लिए support का अवसर मिला (https://www.4cities.eu/), लेकिन यह आसान फैसला नहीं था
मैं भविष्य में फिर साथ काम करना चाहूँगा, और जो लोग education startup में काम करना चाहते हैं, उन्हें maven.com ज़रूर देखना चाहिए
शुरुआत में मैं Google इसलिए जॉइन किया था क्योंकि सीखना था, चीज़ें बनानी थीं, और जी-तोड़ मेहनत करनी थी
कुछ ही महीनों में समझ आ गया कि जिस टीम में मैं शामिल हुआ था वह “गलत” वर्ज़न थी, और टीम का “सही” वर्ज़न किसी दूसरे ऐसे विभाग में था जहाँ जाना संभव नहीं था
मैनेजर हक़ीक़त से इनकार कर रहा था, टीम के लोग जल्दी-जल्दी नौकरी छोड़ रहे थे, और ऊपर का मैनेजर बेहद toxic था
लेकिन सबसे बुरी बात यह थी कि बहुत ही साधारण काम भी एक विशाल काम बन जाता था
startup में जो काम एक घंटे के भीतर पकड़कर PR बनाकर, review करवाकर, release करके, analytics तक देखकर किया जा सकता था, वही Google में 2 महीने लेता था
हाँ, बीच में parallel में और काम किए जा सकते थे, लेकिन iteration cycle भयानक रूप से धीमी थी और feedback पाने की क्षमता लगभग न के बराबर थी
जिस टीम में मैं शामिल हुआ था, वह 6 साल से product बना रही थी, और मेरे जुड़ने के कुछ महीनों बाद ही उसके पास सबसे शुरुआती feedback metrics आए
3 महीने के भीतर समझ गया था कि मुझे निकलना होगा, और जुड़ने के 15 महीने बाद बाहर आ गया
सोमवार से startup की दुनिया में लौटने को लेकर मैं सचमुच उत्साहित हूँ
Google का अतिरिक्त compensation और scale मेरे लिए मायने नहीं रखता
मैं फिर कभी किसी बड़े संगठन में काम नहीं करना चाहता, और अमीर होकर उदास जीने से बेहतर है कि गरीब रहकर कुछ हासिल करने वाले इंसान की तरह मरूँ
मैं Silicon Valley इसलिए आया था ताकि जितना हो सके उतना सीख सकूँ
अगर बड़े scale के systems संभालने हैं, तो उसकी योग्यता 0वें चरण से खुद बनाकर, launch करके, और operate करके कमानी चाहिए, और अगर बड़ा reward मिले तो वह बेहतरीन product development से मिलना चाहिए
पिछले 10 साल में Silicon Valley में जिन लोगों से मिला, उनमें 80% से ज़्यादा के पास ऐसा mindset नहीं था
इस philosophy को मज़बूती से पकड़े रखना चाहिए
बढ़ती साधारणता की दुनिया में यही गुप्त हथियार है
इस क्षेत्र में ऐसा mindset रखने वाला कोई नहीं मिलेगा, ऐसा सोचकर मैंने programming ही छोड़ दी
यह विचार इतना उदास करने वाला था कि मैंने दूसरी career चुन ली
लिखे गए शब्दों का tone और असल सामग्री में इतना फ़र्क था कि पढ़ना मुश्किल लगा
यह कुछ ऐसा लगा जैसे हाथ कुचलने वाली मशीन की कहानी हो, और उसके बाद अपने लिए नोट छोड़ दिया गया हो कि अगली बार दाँत पहले तेज़ कर लेना ताकि हाथ जल्दी कुचले जाएँ
“हाथ कुचलने वाली मशीन” वगैरह — लेखक ने साफ़ तौर पर बहुत कुछ सीखा, मज़ेदार पल भी रहे, Google की समस्याएँ पहचानीं, और फिर खुद नौकरी छोड़ी
यह तो बस किसी और नौकरी जैसा ही लगता है
बची हुई आँख से laser में मत देखना
यह comment आने से पहले का context क्या था, और क्या इसमें large language model शामिल था, यह जानने की सच में जिज्ञासा है
इसे दूसरा पासपोर्ट कहना काफ़ी हद तक सही है
विदेश में रहते हुए, हाल में Buenos Aires में भी, मैं office space, free food, gym, और guitar तथा piano की practice के लिए music room तक इस्तेमाल कर सका था
Amazon में बिना approval के बगल की इमारत का दरवाज़ा भी नहीं खुल सकता
कुछ साल पहले जब मैं Barcelona गया था, तो misc- alias पर mail करके पूछा था कि क्या कोई Montserrat साथ चलना चाहता है, और 5 लोग साथ चढ़े तथा बहुत अच्छा दिन गुज़रा
सबसे अच्छी बात यह है कि आम तौर पर “हाँ” कहने वाले लोग काफ़ी दिलचस्प होते हैं
पूरी तरह social skills से रहित nerds ऐसे mails का जवाब नहीं देते
अगर आप ऐसे शहर पहुँचें जहाँ Google का बड़ा office हो, और कहें कि आप काम के लिए आए हैं और Google में काम करते हैं, तो customs अधिकारी आपसे badge दिखाने को कह सकता है
मौजूदा inflation की स्थिति में यह कैसे चलता होगा, यह जानना दिलचस्प है, और क्या engineers को pesos में salary मिलती है, या हर कुछ हफ़्तों में pay फिर से adjust करनी पड़ती है
मैंने भी acquisition झेला है, किसी thought leader की तरह नहीं बल्कि एक individual contributor के रूप में, और दूसरों को भी ऐसा करते देखा है; Google acquisition के हिसाब से यह काफ़ी typical लगता है
Google acquired कर्मचारियों को काफ़ी लंबे golden handcuffs पहनाता है, और जैसा यहाँ दिख रहा है, वह अवधि खत्म होते ही ज़्यादातर लोग, खासकर founders और senior लोग, चले जाते हैं
मैं 3~4 साल के golden handcuffs खत्म होने के बाद भी 6 साल और रुका रहा, क्योंकि मेरे इलाके में इतना compensation देने वाली और कोई जगह नहीं थी
लेकिन उसी acquisition के मेरे ज़्यादातर NYC सहकर्मी, जैसे ही उन्हें कोई ठीक-ठाक मौका मिला, निकल गए
जो लोग तेज़ी से चलने वाले startup में छोटे codebase पर खुद फैसले लेते थे, उनके लिए Google जैसे विशाल जानवर में जाना मुश्किल होता है, और इस लेख की बहुत-सी बातें जानी-पहचानी लगीं
जब हम जुड़े थे तब Google engineers “सिर्फ़” लगभग 25,000 थे, और अब संख्या उससे कहीं ज़्यादा है
हमारे मामले में तो सचमुच ऐसा लगा जैसे हमें हटाने के लिए ही खरीदा गया हो, और अब DOJ भी शायद यही कह रहा है https://crsreports.congress.gov/product/pdf/LSB/LSB10956
उस समय यह बात नहीं कही गई थी, लेकिन पहले साल में उन्होंने हमें integrate तक नहीं किया, बस हवा में लटका छोड़ दिया, हमारी functionality को अपने stack में फिर से लिख लिया, और ज़्यादातर काम हमारे बिना ही आगे बढ़ाया
लगभग 2 साल बाद यह Silicon Valley के Rest and Vest scene जैसा महसूस होने लगा, लेकिन कुछ समय बाद मैं खुद उस जड़ता से बाहर निकल आया
मौके और सचमुच बहुत अच्छे पैसे को लेकर खुशी भी थी, और पूरी स्थिति को लेकर हल्की कड़वाहट भी — एक अजीब-सा मिश्रित एहसास
startup खरीदने वाली बड़ी companies बहुत हैं, लेकिन Google जैसी compensation structure बहुत कम जगहों पर है
फिर भी मुझे compensation से ज़्यादा overall execution incapacity चुभती थी, और इसी वजह से मैं मूल रूप से Google छोड़कर startup में गया था
“हरा है तो नया code deploy” वाले दिन बहुत याद आते हैं, जब किसी idea को 5 मिनट में production में डाला जा सकता था
corporate दुनिया में ऐसा नहीं होता
अगर लोग अजीब और रचनात्मक काम कर सकें, उसके लिए अलग जगह बनाई जाए तो मैं लौट सकता हूँ, वरना बाकी ज़िंदगी startup की अव्यवस्थित लेकिन मज़ेदार दुनिया में ही बिताऊँगा
कुछ लोग बेड़े के लिए नहीं, बल्कि pirate ship के लिए बने होते हैं
जिस startup में मैं काम करता था, उसे IBM ने acquire कर लिया था, और कुछ बातें खास तौर पर नज़र आईं
acquisition के तुरंत बाद ऐसा लगता है जैसे आप superstar बन गए हों
ऐसा इसलिए क्योंकि आपके पास मौजूद shares सचमुच पैसे में बदल जाते हैं, आप बड़ी organization के भीतर एक चमकदार नई चीज़ बन जाते हैं, और acquisition को आगे बढ़ाने वाले लोग काफ़ी ऊँचे पद पर होते हैं, इसलिए CEO तक पहुँचने की परतें कम होती हैं और आम तौर पर आप सीधे उन्हीं को report करते हैं
लेकिन समय बीतने पर आप hierarchy के भीतर नीचे समा जाते हैं और वह दूरी धीरे-धीरे बढ़ती जाती है
career के लिए सामान्य hiring की तुलना में acqui-hire कहीं बेहतर होता है, और आप निश्चित रूप से ज़्यादा ऊँचे band से शुरुआत करते हैं
IBM में Google की तरह सभी code के लिए किसी विशाल repository जैसी एकल संस्कृति नहीं थी
इसके बजाय अलग-अलग groups चाहते थे कि दूसरे लोग उनके products इस्तेमाल करें, और हम Perforce इस्तेमाल करते थे, लेकिन हमें ClearCase और Rational Team Concert इस्तेमाल करवाने की बहुत कोशिश की गई
बेशक, उन tools का इस्तेमाल करने के लिए हमारे group को Perforce license के लिए "green dollars" की जगह "blue dollars" चुकाने पड़ते थे
IBM के कुछ हिस्से trade shows से चलते थे
इन events में नए products दिखाने होते थे, इसलिए internal invention और development को बढ़ावा मिलता था, लेकिन मेरे अनुभव में उनमें से लगभग कुछ भी market में सफल नहीं हुआ
IBM एक पुरानी company थी, इसलिए वहाँ लोगों का distribution कहीं अधिक सामान्य था, और startup की तुलना में उम्र, नस्ल और gender diversity भी बहुत ज़्यादा थी
वहाँ सिर्फ़ दुनिया बदलने निकले लोग ही नहीं थे, बल्कि परिवार पाल रहे mid-career professionals भी कहीं अधिक थे
Google में भी शायद ऐसा ही होगा, लेकिन "thought leaders" बहुत तेज़ी से promote होते थे
सिर्फ़ असली coding करके promotion नहीं मिलता था, और bugs ठीक करना या planned features जोड़ना दुनिया बदलने वाला काम नहीं माना जाता था