स्टार्टअप किस तरह अपनी ऊर्जा खो देता है

 (blog.johnqian.com)
2 पॉइंट द्वारा GN⁺ 2023-08-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • अच्छी तरह चल रहे seed-stage startup में engineers खुद user problems खोजते हैं और implementation से लेकर launch तक सीधे काम करते हैं, लेकिन कंपनी के बढ़ने पर यही loop धीमा और बिखरे हुए काम में बदल जाता है
  • 10 से कम लोगों वाली टीमों में user touchpoints, idea selection, peer feedback, छोटे codebase और हल्के deployment की वजह से implementation speed तेज होती है
  • 100 से अधिक लोगों वाले संगठन में users से सीधा संपर्क PM के हिस्से में चला जाता है, और security review, CI, PR review, और infrastructure process जुड़ते-जुड़ते work speed काफी धीमी हो जाती है
  • इस बदलाव के पीछे stake कम होना, कर्मचारियों की संख्या बढ़ने पर O(N^2) communication, और users व regulations बढ़ने के साथ risk tolerance का कम होना जैसे कारण होते हैं
  • मज़े के खत्म होने को पूरी तरह रोकना मुश्किल है, लेकिन बड़ी कंपनियों के process की जल्दबाज़ी में नकल न करके, छोटी independent teams और incentives डिज़ाइन करके, और hiring speed धीमी रखकर इसे टाला जा सकता है

छोटे स्टार्टअप में काम इतना नशे जैसा क्यों लगता है

  • अच्छी तरह चल रहे seed-stage startup में engineer का मुख्य काम user problems को समझना, ideas बनाना, teammates से चर्चा करना, implement करना, फिर launch और retrospective को दोहराना होता है
  • 10 से कम लोगों वाली टीम में इस loop का हर चरण आनंददायक हो सकता है
    • आप जिन users में रुचि रखते हैं, उनसे सीधे संपर्क कर सकते हैं और बीयर पर बात कर सकते हैं
    • अगर कोई idea कंपनी के लिए उपयोगी और व्यक्तिगत रूप से दिलचस्प लगे, तो आप चल रहा काम रोककर तुरंत उस पर काम शुरू कर सकते हैं
    • teammates का कंपनी की सफलता में सीधा stake होता है, इसलिए वे अच्छे ideas को बढ़ावा देते हैं और खराब ideas की समस्याएँ समझाने के लिए प्रेरित रहते हैं
    • कोई teammate उस idea का user भी हो सकता है, या आपके साथ उस पर काम करना चाहता हो, और उसे codebase के बड़े हिस्से की समझ होने के कारण वह उपयोगी insight दे सकता है

तेज implementation और ऊँची उम्मीद

  • छोटी टीमों में implementation speed तेज होती है
    • आप अपनी पसंद के tools चुन सकते हैं और कोई security review नहीं होता
    • codebase छोटा होने से उसका पूरा ढाँचा दिमाग में रखा जा सकता है, इसलिए बड़े refactor भी अपेक्षाकृत आसानी से आज़माए जा सकते हैं
    • तेज hot reload की वजह से trial-and-error debugging बहुत जल्दी दोहराई जा सकती है
  • changes merge करना भी हल्का-फुल्का होता है
    • CI में slow tests नहीं होते, और safe changes के लिए blocking PR review की ज़रूरत नहीं पड़ सकती
    • कुछ मामलों में आप सीधे master पर push कर सकते हैं, या risky change के लिए teammate के पास जाकर review माँग सकते हैं
    • अगर users कम हों, तो backend या database में तेज बदलाव के लिए downtime स्वीकार किया जा सकता है
  • छोटे स्टार्टअप में कुछ भी संभव है जैसी उम्मीद बहुत मजबूत होती है
    • नया feature equity value बढ़ा सकता है, और बाद में लोग उसी feature पर आगे बनाते जा सकते हैं
    • आप इस उम्मीद में काम कर सकते हैं कि कोई user कहे, “क्या यह idea आपने दिया था? इसने मेरी ज़िंदगी बचा ली”
    • क्योंकि टीम के सभी लोगों का stake साझा होता है, इसलिए एक-दूसरे की सफलता के लिए उत्साह का माहौल बनता है

कंपनी के बढ़ने पर यही loop कैसे बदलता है

  • 100 से अधिक लोगों वाले संगठन में users के साथ सीधा संपर्क कम हो जाता है
    • users से बात करना PM की भूमिका बन जाता है, और engineer अक्सर केवल user insight का summary और priority list पाता है
    • खराब स्थिति में आपको ऐसा उलझा हुआ task list मिल सकता है जो users की गलत समझ या manager के self-centered vision पर आधारित हो, और हर task क्यों ज़रूरी है यह समझाने वाला भी कोई न हो
  • व्यक्ति के लिए अपनी पसंद का काम तुरंत चुनना मुश्किल हो जाता है
    • अगर हर कोई अपनी पसंद का काम करे, तो O(N^2) communication chaos पैदा हो जाता है
    • manager संगठन के दूसरे कामों को भी ध्यान में रखकर व्यक्ति की योजना तय करता है
    • अपने ideas पर काम आपको तय काम खत्म करने के बाद करना पड़ सकता है, या फुर्सत के समय चुपचाप करना पड़ सकता है
  • teammates से ideas पर बात करना अभी भी संभव है, लेकिन रुचि और समय दोनों कम हो जाते हैं
    • teammate को किसी एक व्यक्ति की सफलता से मिलने वाला लाभ छोटा होता है, और वह promotion competitor भी हो सकता है
    • सबके पास लंबी task list होती है, इसलिए अपना काम छोड़कर साथ काम करने की आज़ादी नहीं रहती
    • संभव है कि उन्हें उस code का context या याद भी पर्याप्त न हो

बड़े संगठन में implementation धीमा क्यों पड़ता है

  • 100 से अधिक लोगों वाले संगठन में tool selection पहले से तय होता है
    • बेहतर नए tools होने पर भी consistency तोड़ने की लागत के कारण उन्हें अपनाना ठीक नहीं माना जा सकता
    • नया tool इस्तेमाल करने के लिए आपको manager से पूछना होगा और security review team को email भेजना होगा
  • बड़ा codebase अक्सर legacy कारणों से बड़ा होता है
    • उसमें ऐसा बहुत-सा code होता है जिसे छूने से डर लगता है, और ऐसा code भी होता है जिसे अब कोई ठीक से समझता नहीं
    • thorough tests ही इस बात का लगभग एकमात्र भरोसा बन जाते हैं कि पूरा system खराब नहीं होगा
    • trial-and-error debugging की ज़रूरत रहती है, लेकिन compile time लंबा होने से iteration cycle धीमी हो जाती है
  • एक छोटे PR को merge करने में भी 2 हफ्ते लग सकते हैं
    • CI pass होने के लिए 20 मिनट इंतज़ार करना पड़ता है, और अगर tests flaky हों तो उन्हें फिर चलाना पड़ता है
    • review का इंतज़ार करते समय merge conflicts बढ़ते जाते हैं
    • reviewer के पास पर्याप्त context या motivation न होने से वह महत्वपूर्ण सुझावों की बजाय मामूली टिप्पणियाँ ही कर सकता है
    • requested changes लागू करके फिर push करने और उसके बाद फिर 20 मिनट इंतज़ार करने की प्रक्रिया हर PR पर तीन बार दोहर सकती है
  • infrastructure change, 1 करोड़ users के downtime या data loss से बचने के लिए 14-step process बन सकता है
  • 3 महीने चुपचाप काम करने के बाद launch करने पर भी reward और recognition सीमित हो सकते हैं
    • शुक्रवार की meeting में CEO को demo दिखाने का मौका मिल सकता है, लेकिन वास्तव में ध्यान देने वाले teammates कुछ ही हो सकते हैं
    • manager कह सकता है कि इसका फायदा 5 महीने बाद performance review cycle में मिलेगा
    • अच्छी स्थिति में 20% salary increase और title change मिल सकता है, और बुरी स्थिति में 4 महीने बाद reorg हो जाए, नया manager आ जाए, और project की priority गिर जाए या वह बंद कर दिया जाए

मज़े की मौत को कैसे टाला जाए

  • यह बदलाव पूरी तरह रोकने से ज़्यादा उसे देर से आने देने का मामला है
    • मूल कारण हैं stake का कम होना, O(N^2) communication, और risk tolerance का घटना
    • stake का कम होना और communication की समस्या, कर्मचारियों की संख्या बढ़ने पर टालना कठिन हो जाता है
    • risk tolerance का कम होना users की संख्या बढ़ने का परिणाम है, और आंशिक रूप से government regulation से भी जुड़ा है
  • स्टार्टअप बड़ी कंपनी के process की नकल करके अनावश्यक रूप से जल्दी corporatized हो सकते हैं
    • अगर आप बड़ी कंपनी से manager hire करते हैं, तो उनके साथ उनका पुराना playbook भी आ सकता है
    • बहुत-से स्टार्टअप सिर्फ इसलिए Jira इस्तेमाल करते हैं क्योंकि बड़ी कंपनियाँ करती हैं, लेकिन यहाँ राय यह है कि इस तरह के तरीके से बचना चाहिए
    • Y Combinator को इस सोच को फैलाने का श्रेय दिया जा सकता है कि बड़ी कंपनियों को स्टार्टअप की तरह operate करने की कोशिश करनी चाहिए
  • बड़ी कंपनी का playbook बड़ी कंपनी के लिए होता है, और जब तक स्टार्टअप उस आकार तक पहुँचता है, scale problems से निपटने के बेहतर तरीके उपलब्ध हो सकते हैं
    • scale pain आने पर first principles से समाधान निकालना, या उसी आकार के लेकिन तेज़ी से चलने वाले स्टार्टअप से प्रेरणा लेना ज़्यादा बेहतर है
  • कंपनी को कई independent startups की तरह संगठित करना, जहाँ तक संभव हो, आज़माने लायक है
    • Rippling को कुछ हद तक ऐसा कर पाने वाले उदाहरण के रूप में बताया गया है
    • लेकिन product components अक्सर बहुत कसकर जुड़े होते हैं, और ज्यादातर components अपने दम पर revenue नहीं बना पाते, इसलिए आमतौर पर इसकी सीमाएँ होती हैं
  • incentives का डिज़ाइन, stake के कम होने की रफ्तार को अर्थपूर्ण तरीके से धीमा कर सकता है
    • लेकिन बड़े equity stake और उसकी value बदलने की ताकत जितने मजबूत incentives बहुत कम मिलते हैं
  • सबसे अच्छे तरीकों में से एक है कम hiring करना
    • बहुत-सी कंपनियाँ manager incentive mismatch, investors के इस दबाव कि वे दूसरे तेजी से बढ़ते स्टार्टअप जैसी दिखें, और एक अतिरिक्त कर्मचारी की वास्तविक लागत न समझने की वजह से बहुत जल्दी hire करती हैं
    • tools, खासकर AI, जितने बेहतर होंगे, उतने कम लोग अधिक users को support कर पाएँगे
    • भविष्य के founders को इस तरह के scale pain की कम चिंता करनी पड़ेगी, और काम सबके लिए अधिक मज़ेदार हो सकता है

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

1 टिप्पणियां

 
GN⁺ 2023-08-13
Hacker News की राय

  • 10 साल पहले, जब Netflix अभी छोटा था, उसका काम करने का तरीका सचमुच अच्छा था। वे परिपक्व लोगों को हायर कर पाते थे और प्रक्रियाएँ हटा सकते थे; असल में वे हर चीज़ को process-free बनाने की कोशिश करते थे
    नतीजा यह हुआ कि काम बस चलता गया, और उस समय Netflix में अक्सर यह उम्मीद की जाती थी कि “बिना किसी बड़े ड्रामे के चीज़ें स्वाभाविक रूप से हो जाएँगी।” active-active region भी कुछ महीनों में बन गया, इस्तेमाल में आसान deployment tool Asgard भी आया, और अपना CDN बनाने व ISP के साथ partnership करने की योजना भी करीब 12 लोगों ने 6 महीनों में पूरी कर दी
    एक इंजीनियर के तौर पर, बस एक weekly team meeting होती थी, और managers व directors team context align करने के लिए काफ़ी meetings कर लेते थे, इसलिए engineers खुलकर productive काम कर पाते थे। तब यह स्वाभाविक लगता था, लेकिन बाद में समझ आया कि यह बहुत ऊँचा standard था

    • अहम बात यह है कि इस तरीके के लिए परिपक्व engineers और managers चाहिए। अनुभवी engineers को हायर करके अपरिपक्व “leadership” का हर चीज़ में निर्देश देना जितना बुरा है, वैसा कुछ नहीं
      ऐसे developers भी चाहिए जो हाथ पकड़कर चलाए बिना काम पूरा कर सकें, लेकिन managers को भी हाथ पकड़कर control करने के बजाय coordination करना आना चाहिए
    • यह तरीका उन deep tech organizations में अच्छा फिट बैठता है जहाँ enterprise sales किए बिना technical problems में डूबकर काम किया जा सकता है। MongoDB या NVIDIA का hardware division जैसी जगहें याद आती हैं
      लेकिन अगर product ऐसा है जिसे दो या अधिक लोगों से subjective input लेकर iterate और improve करना हो, तो communication और distributed collaboration अहम और ज़रूरी होते हैं। इसका मतलब यह नहीं कि यह ज़रूर painful होना चाहिए, लेकिन ऊपर वाला Netflix model हर जगह लागू नहीं होता और उसे आँख मूँदकर copy नहीं करना चाहिए
    • ये छोटी-छोटी कहानियाँ अगर सच भी हों, तो इनका समय 10 साल पहले से काफ़ी पहले का होने की संभावना है। 2012 में Adrian Cockroft का presentation सुनते समय Netflix में पहले से ही हज़ारों engineers और सैकड़ों services थीं, और Asgard भी पहले से मौजूद था व open source किया जा रहा था
    • मुझे लगता है कि शायद Netflix का product अपेक्षाकृत narrowly defined था, इसलिए यह संभव हुआ। Content library को screen पर stream करने वाली service—लक्ष्य स्पष्ट था
      जिन जगहों पर मैंने काम किया, वहाँ products अच्छी तरह defined नहीं थे; लापरवाही की वजह से नहीं, बल्कि वे नए और आकार में अस्पष्ट थे, इसलिए किसी को नहीं पता था कि वे क्या होने चाहिए। इसके उलट Netflix में “video को screen तक जितना संभव हो उतनी efficiently पहुँचाना” लक्ष्य साफ़ था, इसलिए यह लगभग pure technical problem solving जैसा बन जाता है
      बेशक ads या back office जैसे product development चलते रहेंगे, लेकिन मुझे wonder होता है कि क्या product का core mission काफ़ी solid होने के कारण लोगों को एक ही दिशा में align करने में कम समय लगाना पड़ता था
    • मुझे उत्सुकता है कि क्या वे अब भी वैसे काम नहीं करते। अगर वे अभी भी अनुभवी engineers हायर करते हैं, तो क्या बदल गया? साथ ही, Netflix में अब भी कोई low-hanging fruit या दिलचस्प काम बचा है या नहीं, यह भी जानना चाहूँगा

  • ऐसे लेख देखते ही मेरी आँखें घूम जाती हैं। लगता है कि लिखने वाला या तो काफ़ी junior है, या ऐसा founder type है जिसकी यह समझ अजीब तरह से टूटी हुई है कि employees उसकी company के लिए काम क्यों करते हैं
    यह काफ़ी हद तक SF tech industry की अजीब culture से निकला है, लेकिन उसके बाहर लोग अपनी job के बारे में ऐसा नहीं सोचते। जिन best developers के साथ मैंने काम किया, वे काम के नशे में नहीं थे; वे professionals थे जिन्हें पता था कि वे क्या कर रहे हैं, उस knowledge के लिए उन्हें अच्छा compensation मिलता था, और काम के बाहर भी दोस्तों व personal interests के साथ उनकी भरी-पूरी ज़िंदगी थी
    यह narrative युवा और आसानी से प्रभावित होने वाले engineers से उनकी salary जितना justify करती है उससे अधिक जीवन काम में लगवाने वाला propaganda जैसा है। अगर आप young engineer हैं, तो ऐसा मत कीजिए। बहुत से bosses excitement और naïveté का फायदा उठाकर personal life पूरी तरह बिगाड़ देते हैं, लेकिन ऐसी जगहें भी बहुत हैं जो normal employer-employee relationship की उम्मीद करती हैं

    • मेरी पहली job दुनिया के लिए अच्छा project थी, लेकिन pay लगभग grocery store wages जितनी थी। सचमुच 2–3 लोगों की छोटी company थी, और CEO एक बुज़ुर्ग व्यक्ति था जिसके पास “retirement fund नहीं था” और “$2 million debt” था
      जब उसने product launch तक wages defer करने का प्रस्ताव रखा, तो वर्षों से बनाए गए trust tactics आखिरकार cash में बदल गए, और मुझे धीरे-धीरे समझ आया कि घटिया salary intentional थी। वे उस काम के लिए decent wage दे सकते थे, लेकिन जब मैंने proper compensation माँगा, तो बदले में resistance, breadcrumb-style promises और stonewalling ही मिला
      बाद में जब मैंने बकाया पैसे माँगे तो कहा कि “देने के लिए पैसे नहीं हैं,” लेकिन जब मैं गुस्से में छोड़कर चला गया, तो उसने मेरे दूसरे project को शुरुआत से दोबारा करवाने के लिए किसी और को hire कर लिया। मैं सबसे तेज developer नहीं था और नया hire भी शायद काफ़ी अच्छा था, लेकिन मेरी और दूसरे developer की नज़र में मैं अपना काम पर्याप्त रूप से कर रहा था
    • सिर्फ /r/sysadmin देख लें, messiah complex वाले लोगों की संख्या देखकर हैरानी होती है
      हालात कुछ ऐसे होते हैं: “तीन colleagues निकाल दिए गए, अब मैं चार लोगों का काम कर रहा हूँ, overwork कहने पर भी boss सुनता नहीं।” कोई professional व्यक्ति शायद layoffs से पहले ही छोड़ चुका होता, या ऐसी स्थिति बनते ही normal work week के भीतर क्या करेगा और क्या नहीं करेगा, इस पर boundaries set करके negotiate करता
      company बिना सोचे लोगों को निकाल सकती है, लेकिन इतने सारे लोग अपने जीवन से ज़्यादा company की चिंता करने के लिए brainwashed हैं कि यह बेतुका लगता है
    • हर व्यक्ति एक जैसा नहीं होता और motivations भी अलग होते हैं। पहले 10 साल मैंने stable और ठीक-ठाक pay वाली job में काम किया, लेकिन इतनी boredom थी कि हर दिन office से निकलने का समय गिनता था और महीनों पहले vacation book कर लेता था
      बाद में startup में गया और पछतावा नहीं है। ज़्यादा काम करता हूँ, लेकिन कहीं ज़्यादा मज़ा आता है; हमेशा तो नहीं कर पाऊँगा, लेकिन financial reward भी बेहतर हो गया है, इसलिए शायद पहले वाली stable और boring job की तरह 65 साल तक काम नहीं करना पड़ेगा
    • अपने काम के प्रति passionate लोग बहुत होते हैं। काम cancer cure न होकर computer programming है, इससे बात नहीं बदलती
      इसका मतलब यह भी नहीं कि उनकी life fulfilling नहीं है, या उनका exploitation हो रहा है। उल्टा, जो लोग कहते हैं कि ऐसा नहीं है, वे शायद काम से मिलने वाली चीज़ें कम हासिल कर रहे हैं। हफ्ते के 40 घंटे इस तरह बिताना थोड़ा waste लगता है
    • Online आसानी से मिल जाता है। University drop out करने के बाद startup में 4 साल “founding engineer” के तौर पर काम किया, और अब किसी दूसरे startup में पहला साल है—ऐसा ही कुछ
      मूल रूप से उसने Kool-Aid पी लिया है, और उसे यह भी नहीं पता कि उसे क्या नहीं पता

  • “चिंगारी” से एक कदम आगे जाकर पूरी तबाही लाने वाले कारण भी होते हैं
    अब तक मैंने जिन चीज़ों को engineering team और product को कमजोर करने या गिरा देने में बड़ा कारक माना है, उनकी अधूरी सूची यह है: बहुत ज़्यादा technical leaders, non-technical leaders, समस्या पैदा करने वाले engineers, और micromanagement
    जब startup बढ़ता है, तो superstar engineer VP Engineering, architect, CTO जैसी leadership roles में चले जाते हैं, लेकिन अगर वे leader type नहीं हैं तो team आसानी से बिना vision वाला चिड़ियाघर बन जाती है। इसके उलट, engineering experience लगभग न रखने वाला non-technical leader भी उतना ही जोखिम भरा होता है
    उथले interviews के कारण समस्या पैदा करने वाले engineers अंदर आ जाते हैं और firing भी ढीली हो, तो team में सिर्फ 5~10% लोग भी ऐसे हों, वे progress रोकते हैं, जिम्मेदारी से बचते हैं, बस reputation बनाते हैं और घटिया output को आगे धकेलकर morale को बहुत नुकसान पहुंचाते हैं। अच्छी engineering team और culture बनाए रखना पेंसिल को उसकी नोक पर खड़ा करने जितना मुश्किल लगता है

    • लोगों से जुड़ी समस्याओं के नतीजे के रूप में गलत hiring को जल्दी ठीक न करना भी जोड़ना चाहूंगा
      नए founders अक्सर negative feedback देने, उस अत्यधिक technical manager को demote करने जिसे IC ही रहना चाहिए था, या mismatch employee को बाहर करने में बहुत हिचकिचाते हैं
      एक local startup ने C-level executive के UI designer दोस्त को product VP बना दिया। वह काम बिल्कुल संभाल नहीं पाया, लेकिन “उसे बढ़ने का मौका दे रहे हैं” कहकर उसे 2 साल तक रखा गया। VP के नीचे हर किसी को पता था कि वह अक्षम है, और वे उसे bypass करने के तरीकों पर बात करते थे
      आखिरकार product initiatives शुरू तक नहीं हो पाए और company को पूरी तरह service-based काम की ओर pivot करना पड़ा। ऐसे startup में नहीं रहना बेहतर है जो एक ऐसे अयोग्य leader को बनाए रखता है जिसे company के लोग पहले ही छोड़ चुके हों
      उसी company के पास downsizing के समय product VP और उसके उस empire को खत्म करने का perfect मौका था, जिसका काम उससे लगभग जुड़ा ही नहीं था, लेकिन C-level से connection की वजह से उन्होंने इससे बचा और उसकी जगह engineers को निकाल दिया। उन्होंने high compensation वाले engineers से कटौती शुरू की, core engineers खो दिए, यह signal दिया कि अगर सही लोगों को जानते हो तो incompetence भी tolerate की जाती है, और अगले कुछ महीनों में और भी कई core लोग चले गए
      hiring mistakes हर कोई करता है, लेकिन उन mistakes पर आप कैसे respond करते हैं, वही company की किस्मत तय करता है
    • 25 साल तक IC और management, दोनों तरह की भूमिकाओं से गुजरने के बाद मुझे यकीन हो गया है कि expertise, maturity, judgment का कोई substitute नहीं है
      “IC को उतनी autonomy देनी चाहिए जितनी वे संभाल सकें” जैसे rules of thumb कहे जा सकते हैं, लेकिन हर rule के exceptions होते हैं। संक्षिप्त wisdom context खो देती है और गलत समझी जा सकती है, या कम experience वाला व्यक्ति उसे cargo cult की तरह follow करने लगता है
      मैंने देखा है कि individual personality और organization structure के subtle differences से पैदा हुई छोटी dynamics, जबकि सभी लोग अच्छे इरादे से अपनी पूरी कोशिश कर रहे थे, भारी dysfunction और productivity loss में बदल गईं। ऊपर से आदेश देकर और central planning से अच्छी engineering नहीं होती
      product और business को अंत तक समझने वाले पर्याप्त लोग होने चाहिए, field engineers तक, ताकि छोटे decisions बड़े picture के अनुरूप लिए जाएं और सही concerns leadership तक ऊपर जा सकें। product, design, legal, finance, support, security, operations की short-term और long-term costs को साथ में तौलना पड़ता है
      यह तभी संभव है जब high trust और safety हो, जहां experts अपनी राय दे सकें और उचित trade-offs खोज सकें। ego और personality clashes आसानी से बाधा बनते हैं, इसलिए leadership में maturity चाहिए। पेंसिल को उसकी नोक पर खड़ा करने वाली analogy काफी सटीक है
    • एक और बात जोड़ूं तो, बाहर से किसी बेहतरीन व्यक्ति को hire करके architect या principal role में बैठाने पर भी ऐसी ही समस्या पैदा होती है
      वह व्यक्ति app को देखते हुए context के बिना लिए गए सभी decisions को technical debt कहना शुरू कर देता है। मैंने ऐसा कुछ बार देखा है, और एक बार नए VP Engineering से कहा था कि original problems, decisions और schedule में आप थे ही नहीं, फिर उन्हें bad judgment कहना अज्ञानता जैसा दिखता है
      सौभाग्य से बाद में उन्होंने मुझे अलग से बुलाकर धन्यवाद कहा और और background पूछा। पूरी कहानी सुनने के बाद वे इस बात से सहमत हुए कि हमने सही choices की थीं। लेकिन मैंने उलटा भी होते देखा है, और तब यह सच में बहुत कठिन होता है
    • बहुत ज़्यादा technical leader वाली बात से मैं काफी सहमत हूं। मैंने कई बार देखा है कि एक शानदार engineer को 50 teams की जिम्मेदारी मिलते ही वह एक team में जो करता था, बस उसे “scale” करने की कोशिश करने लगता है
      वह सभी teams को spreadsheet में डालकर uniform metrics से management automate करने की कोशिश करता था, बजाय इसके कि अपने direct reports को manage और grow करने पर focus करे
      इसके उलट, मैंने देखा कि एक कम technical leader आया तो आसपास के engineers ने थोड़े male chauvinism के साथ आंखें घुमाईं, लेकिन असल में उसने bad hires को बाहर किया, star players को hire किया, और सभी की priorities align करके उन्हें productive बनाया। leadership, technical excellence से पूरी तरह अलग काम है, और जिस क्षमता को raise या bonus से reward करना चाहिए, उसे बहुत बार promotion से reward कर दिया जाता है
    • मैंने देखा है कि startup के लिए 35 साल से ऊपर के लोग fit नहीं होते, ऐसा assume न करने वाला तरीका काम करता है
      जिन लोगों के पास leadership experience हो, फिर भी hands-on capability हो, और पर्याप्त समय दिए जाने पर नए tech stack या financial moves की details तक समझ सकें, वे long-term leadership contribution के जरिए ground-level superstars का सम्मान पा सकते हैं

  • असहमत। मैंने एक छोटी कंपनी शुरू की है और FAANG व बड़े बैंकों सहित बड़ी कंपनियों में भी काम किया है, लेकिन ऐसा immersive माहौल कहीं भी बनाया जा सकता है
    मुख्य बात यह है कि कोई dynamic leader ऐसी टीम बनाए जिसे ठीक-ठीक पता हो कि लोग वहाँ क्यों हैं, हर व्यक्ति को वह काम दे जिसमें वह अच्छा है, और जिन चीज़ों में वह कमजोर है उनमें कोई बेहतर व्यक्ति मदद करे। फिर टीम के mission की कंपनी के mission और दुनिया में उसके purpose के लिए क्या value है, यह स्पष्ट करना चाहिए, और production व impact के रास्ते की बाधाओं को लगातार हटाना चाहिए
    N² communication जैसी दलील reductionist और inaccurate है। कोई भी टीम संगठन की हर टीम पर निर्भर नहीं होती, और आम तौर पर क्षेत्र छोटा होता है और adjacent teams भी सीमित होती हैं। core team अपवाद है, लेकिन अच्छी तरह काम करने वाली core team N² overhead नहीं, बल्कि focus point की तरह काम करती है, जहाँ teams आती हैं—यानी N structure बनता है
    N बड़ा हो सकता है, इसलिए effective triage, automation, self-service, खुद-ब-खुद documented consistent platform, और ऐसे team members अहम हैं जिन्हें सच में सिखाना पसंद हो। ऐसी टीम बनाना management के लिहाज़ से बेहद कठिन रहा और मैं थक गया, लेकिन management मूल रूप से बेहद कठिन काम ही होना चाहिए। अगला काम एक late-stage startup में distinguished engineer के रूप में वापस जाकर कुछ समय के लिए अपनी जड़ों में लौटना होगा

    • लेखक ने जो बताया है, वह मैंने ठीक-ठीक झेला है, इसलिए “दलील पूरी तरह गलत है” इस बात से सहमत नहीं हूँ
      हालांकि ऐसा immersive माहौल कहीं भी बनाया जा सकता है, और ऐसा dynamic leader अहम है जो ऐसी team बनाए जिसे पता हो कि लोग वहाँ क्यों हैं—यह सही है। फिर भी मेरा मानना है कि इसका scale और खराब incentives से संबंध है। मैंने सुना है कि FAANG में भी कुछ departments startup जैसे होते हैं और दूसरे departments आत्मा चूस लेने वाली बोरियत जैसे
    • मैं अभी 100 से ज़्यादा engineers वाले engineering organization में title और अनुभव के हिसाब से सबसे senior engineering IC हूँ, लेकिन जिन समस्याओं से निपटता हूँ वे सब non-technical और organizational problems हैं। जबकि कागज़ पर मुझे अपने समय का 30% coding करनी चाहिए
    • N² communication वाली दलील को “reductionist और ridiculous” कहना लेख के तर्क को बेवजह बहुत कठोर ढंग से छोटा कर देना लगता है। मैंने startup में ठीक वही failure mode देखा है
      आपने जो counterexample दिया है वह यह example नहीं है कि N² complexity मौजूद नहीं है, बल्कि यह example है कि उस complexity को ठीक से manage किया गया
    • लेख में कहा गया था, “आप जो चाहे वह नहीं कर सकते। coordination O(N²) communication mess बन जाता है”
      अगर आप कह रहे हैं कि हर team हर दूसरी team पर निर्भर नहीं होती, तो आप असल में लेख से सहमत ही हैं। फिर कौन-सा हिस्सा गलत है, यह मुझे समझ नहीं आता
    • इससे सहमत हूँ। लेख का पहला वाक्य सरल और inaccurate है। बड़ी कंपनियों का ज़्यादातर काम काफी boring हो सकता है, लेकिन सही conditions में उस चिंगारी को फिर से जलाया जा सकता है

  • बड़े organizations से मिलने वाली economies of scale असल में efficiency जैसी नहीं लगतीं। मेरा मतलब hiring, HR, quality assurance, user research जैसे specialized लोगों को रखने वाली efficiency से है
    शायद अधिक “efficient” organizational structure बनाने के बजाय, उस सबसे छोटी team को बार-बार replicate करके organization बढ़ाना बेहतर हो सकता है जो effective ढंग से चलती थी। हालांकि उन “mini companies” को आपस में efficiently communicate कराने का तरीका अलग समस्या है

    • मुझे नहीं लगता कि यह सिर्फ economies of scale की समस्या है। एक निश्चित scale पर पहुँचने के बाद खेल के नियम सिर्फ employees की संख्या में ही नहीं, revenue के हिसाब से भी बदल जाते हैं, और अचानक बहुत ज़्यादा regulatory scrutiny झेलनी पड़ती है
      जब company की value बढ़ती है और कम risk appetite वाले shareholders और managers आ जाते हैं, तो risk management और avoidance पर बहुत पैसा खर्च करना पड़ता है। मेरी पिछली company में एक competitor ने user needs हल करने के लिए खुलेआम कानून तोड़ा, लेकिन शायद छोटा और बिना revenue वाला होने के कारण बच निकला
      साथ ही, मेरे निजी अनुभव में ज़्यादातर employees founders जितनी energy नहीं लगाते, और यह पूरी तरह समझ में आता है। जैसे-जैसे founder-to-employee ratio छोटा होता जाता है, आप वह काम reliably और समय पर पूरा कराने के लिए तीन लोगों को hire करने लगते हैं जिसे आप अकेले कर सकते थे
      शुरुआती hires founders के करीब होते हैं और company की सफलता से उनका gain बड़ा होता है, इसलिए वे founders जैसे अधिक होते हैं, लेकिन 213वाँ employee हफ्ते के 40 घंटे बेच रहा होता है और effectively fixed salary ही उसका लगभग पूरा reward होता है। कई independent startups से बनी बड़ी company का romantic idea अच्छा है, लेकिन मैंने इसे सच में काम करते नहीं देखा और कल्पना भी मुश्किल है
    • team को replicate करना असंभव है। team व्यक्तियों का समूह होती है, इसलिए यह वैसा ही है जैसे कहना कि World Cup जीतना है तो सबसे अच्छी team को बस clone कर दो
      scale करने का सबसे अच्छा तरीका, मेरे हिसाब से, ऐसे processes बनाना है जो team में चाही गई विशेषताओं को reinforce करें, और ऐसे managers hire करना है जो समझते हों कि teams अलग-अलग व्यक्तियों के समूह होती हैं। managers को delivery optimize करने और attrition कम करने के तरीके से अपने लोगों को freely manage कर पाने की स्वतंत्रता होनी चाहिए
      teams के बीच communication और deliverables के quality standards बहुत ऊँचे होने चाहिए, और organizational culture हर hire किए गए व्यक्ति के प्रति सम्मान और उन्हें ऐसी team में रखने पर obsessive focus के आधार पर बननी चाहिए जहाँ वे effectively काम कर सकें
    • मैं इस approach से सहमत हूँ, और कई companies में इसे अच्छी तरह काम करते देखा है। हालांकि मुझे लगता है कि एक बड़ा मुद्दा, जिसे लेखक ने अजीब तरह से बिल्कुल नहीं छुआ, “चिंगारी” खोने में योगदान देता है
      श्रम के फल धीरे-धीरे और ऊँचाई पर टंग जाते हैं। startup के शुरुआती दिनों में problem space भरपूर होता है, किसी व्यक्ति का impact असामान्य रूप से बड़ा हो सकता है, और उस उपलब्धि को बाँटने वाले लोगों की संख्या सबसे कम होती है
      company बड़ी होने पर तीनों factors दबाव में आ जाते हैं। problem space दुर्लभ हो जाता है, बड़े impact का credit धीरे-धीरे hierarchy के ऊपर की ओर चला जाता है, और impact share करने वाले लोगों की संख्या बढ़ जाती है जबकि recognition छोटा और धुंधला हो जाता है
    • mobile game studio Supercell ने शुरुआत में ऐसा ही किया था। नाम की तरह ही company को 15–25 लोगों वाले कई indie studios में बाँट दिया था
      लेकिन आखिरकार वह एक single giant organization बन गई। Valve की flat organizational structure भी मिलती-जुलती है। पर्याप्त बड़ा होने पर कुछ भी अंततः एक ढेर बन जाता है
    • लोग और roles जोड़ना तब फायदेमंद है जब वह दूसरों को कठिन और distracting काम से मुक्त करे। इसके उलट, अगर वह सभी के लिए कठिन और distracting काम बढ़ाए तो समस्या है
      growth management की कला काफी हद तक लोगों को बेड़ियों में जकड़ने के बजाय मुक्त करने के तरीके खोजने में है

  • “अधिकांश startups बड़ी companies के processes की नकल करके अनावश्यक रूप से corporatization की गति बढ़ा देते हैं। आमतौर पर वे बड़ी companies से managers लाते हैं, और वे अपना playbook साथ लाते हैं” — यह वाक्य दर्दनाक रूप से सटीक है

    • कोई रुककर यह नहीं सोचता कि “वह company ऐसा इसलिए करती है क्योंकि यह effective है, या इसलिए कि यह एक inefficiency है जिसे वह बड़ी होने के कारण झेल सकती है”

  • यह cycle मैंने कई बार देखी है। मेरा सबसे पसंदीदा और आख़िरी सफल startup, अपने चौथे साल यानी 2007 में, एक विशाल global company ने acquire कर लिया था, और मैं दो साल और रुका रहा।
    Product launch के बाद customer support और sales support की ज़रूरतों की वजह से रफ़्तार साफ़ तौर पर धीमी पड़ गई। शानदार VP Engineering CTO बन गया, और एक बेवकूफ़ middle manager को VP बना दिया गया—यहीं से अच्छे दिन ख़त्म हो गए। नए VP ने अच्छे engineers के बजाय “team players” को hire किया, क्षमता से ज़्यादा loyalty को reward किया, और हास्यास्पद चीज़ें होने लगीं।
    मेरा मज़ेदार startup-जैसा समय साल में सिर्फ़ एक हफ़्ते, Christmas और New Year के बीच, तक सिमट गया। उस हफ़्ते कोई नहीं होता था, इसलिए मैं उन कामों पर कहीं ज़्यादा आज़ादी से काम कर पाता था जिन्हें मैं महत्वपूर्ण मानता था, और चमकदार नए feature का alpha version बनाकर संगठन को उसके पीछे आने पर मजबूर कर सकता था।

    • Senior leadership में promote होने के बाद मैंने जो सबसे कठिन सबक सीखा, वह यह था कि middle management hiring बेहद मुश्किल है।
      Candidate pool में हैरान कर देने वाली संख्या में शार्क जैसे लोग होते हैं। वे आते हैं, पहचान लेते हैं कि आप नए हैं, आपको वह सब बताते हैं जो आप सुनना चाहते हैं, और कहते हैं कि वे आपकी सारी समस्याएँ हल कर देंगे। वे दावा करते हैं कि पिछली हर company में उन्होंने ठीक वही काम किया है जिसकी आपको ज़रूरत है, चापलूसी करते हैं, और कहते हैं कि वे आपके जैसे व्यक्ति के साथ काम करने के मौके का इंतज़ार कर रहे थे।
      इसे ऐसे समझें: अब तक interview किए गए सबसे चिकने-चुपड़े IC candidate का पाँच गुना ज़्यादा ताक़तवर और पहचानने में मुश्किल version। इनमें अविश्वसनीय charisma होता है, लेकिन कठिन काम करने का इरादा बहुत कम होता है; company में घुसने के बाद वे चीज़ें निकालने लगते हैं।
      वे अपने compensation, दोस्तों को hire करने के headcount, उन दोस्तों के compensation, और outsourced दोस्तों के लिए लाभदायक contracts निकालते हैं—यहाँ तक कि kickbacks भी हो सकते हैं। वे बहुत activity पैदा करते हैं, इसलिए लोगों को यह समझने में सालों लग सकते हैं कि असल में उन्होंने कुछ ख़ास किया ही नहीं। इस दौरान सक्षम कर्मचारी bullshit से थककर, या incompetence पर सवाल उठाने के कारण किनारे कर दिए जाने पर, छोड़कर चले जाते हैं।

  • Safi Bahcall की Loonshots इस phenomenon को काफ़ी अच्छे से समझाती है। लगभग 150 लोगों के आसपास incentives का “phase transition” होता है, जो कई संगठनों के लिए घातक हो सकता है।
    असली तरकीब यह है कि startup इस headcount को कैसे पार करता है। सच कहें तो कई software companies को शायद 150 से ज़्यादा लोगों की ज़रूरत ही न हो।

    • Dunbar’s number भी देखने लायक है।
      Dunbar’s number उस cognitive limit के लिए प्रस्तावित concept है कि कोई व्यक्ति कितने लोगों के साथ स्थिर सामाजिक संबंध बनाए रख सकता है। यहाँ संबंध का मतलब है यह जानना कि हर व्यक्ति कौन है और वे एक-दूसरे से कैसे जुड़े हैं।
      https://en.wikipedia.org/wiki/Dunbar%27s_number
      दुनिया हज़ारों साल पहले ही इस सीमा से आगे scale कर चुकी है, और companies भी उससे आगे scale कर सकती हैं।
    • Miller की Barbarians to Bureaucrats भी पूरी corporate lifecycle समझाती है: barbarian → builder → explorer → administrator → bureaucrat → aristocrat।
    • यह तर्क उन organizations के पक्ष में जाता है जो core business के करीब रहती हैं, और non-core functions के लिए outsourcing cost स्वीकार करती हैं।
    • जब लोग “100 लोग” या “150 लोग” कहते हैं, तो मुझे उत्सुकता होती है कि वे आम तौर पर पूरी company size की बात कर रहे होते हैं, या engineering और product headcount की।

  • कम hire करें वाली सलाह का महत्व जितना भी कहा जाए कम है। दूसरे शब्दों में, hiring तभी करें जब समस्या हल करने का कोई और तरीका न हो—और तब भी सावधानी से।
    इस principle की वजह से schedule काफ़ी लंबा होने की बात स्वीकार करनी होगी। Overhiring की मध्यम-से-दीर्घकालिक cost launch delay की cost से कहीं बुरी होती है। दुर्भाग्य से startup funding environment और growth expectations अक्सर उल्टा व्यवहार encourage करते हैं।

    • Canada, ख़ासकर Quebec से आने वाले व्यक्ति के तौर पर, यह देखना दिलचस्प है कि ऐसी समझ Silicon Valley में उभर रही है। Quebec में historically छोटी companies की funding का एक मसला यह रहा है कि पैसा ऐसे sources से आता था जो hiring-plan commitments मांगते थे। उदाहरण के लिए, दो साल में 50 लोगों को hire करने का वादा करना पड़ता था तभी funding मिलती थी—इसने पूरी तरह पागलपन पैदा किया, और successful exits की कमी आश्चर्यजनक नहीं है।
      हालांकि मैंने यह काफ़ी underestimate किया था कि Silicon Valley startups में hiring की हालत इतनी ख़राब हो चुकी है। बहुत से लोग FAANG burnout से recover करते हुए या interviews की तैयारी करते हुए अपने resume में जोड़ने के लिए startups का इस्तेमाल कर रहे हैं।
      ऐसी संरचना में hiring managers बहुत optimistic हो जाने की ओर झुक सकते हैं, क्योंकि वे उन कुछ लोगों को खोने से डरते हैं जो सच में company बना सकते हैं। अंततः जो लोग fit नहीं बैठते, उन्हें aggressively बाहर करना ज़रूरी होता है।

  • इस लेख में कुछ बातें मुझे पसंद आईं और कुछ से मैं सहमत नहीं था।
    जिस बात से मैं सबसे ज़्यादा सहमत था, वह थी “बहुत जल्दी hire मत करो।” मुझे ऐसे startups या companies याद नहीं आते जो बहुत धीमी hiring के कारण fail हुए या बहुत suffering झेली हो, लेकिन बहुत जल्दी hire करने से पैदा हुई समस्याएँ—मेरे personal experience सहित—बहुत याद आती हैं।
    वहीं “Jira का इस्तेमाल मत करो” वाला हिस्सा देखकर आँखें घूम गईं। जैसे सूरज पूरब से उगता है, वैसे ही engineers का Jira को कोसना उनका पसंदीदा शौक है। Startup के type के हिसाब से Jira इस काम के लिए बहुत अच्छा tool हो सकता है।
    अगर company को कई workflows support करने हैं, तो tracking ठीक न होने और issue ownership clear न होने पर बहुत चीज़ें छूट जाती हैं और समय भारी मात्रा में बर्बाद हो सकता है। बेशक, बेकार के लाखों statuses बनाकर Jira को ज़रूरत से ज़्यादा complex कर देना भी समय बर्बाद करने का आसान तरीका है, लेकिन आजकल Jira छोटे teams के लिए जल्दी productive होकर इस्तेमाल करने में आसान हो गया है, ऐसा मुझे लगता है।
    मेरा मतलब यह नहीं कि शुरू करने के लिए Jira सबसे अच्छा tool है; पिछले startup ने Trello से शुरू किया था और ठीक चला। लेकिन जब आप operations में आ जाते हैं और नए feature development के साथ बहुत सारे operational issues को manage और prioritize करना पड़ता है, तो सभी को aligned रखने और information share करने के लिए Jira जैसे tool की ज़रूरत पड़ने की संभावना काफ़ी बढ़ जाती है।

    • “Jira का इस्तेमाल मत करो” वाला हिस्सा मुझे भी confusing लगा। तो फिर कोई dinosaur company को “startup की तरह operate” करने देने वाला alternative क्या है, यह जानने की उत्सुकता है।