Stripe में काम करने का अनुभव

 (jondlm.github.io)
2 पॉइंट द्वारा GN⁺ 2024-11-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Jon de la Motte ने Stripe में लगभग 4 साल तक engineer के रूप में काम करने के बाद, अगली नौकरी तय किए बिना 30 अगस्त 2024 को अपना आखिरी कार्यदिवस बनाकर कंपनी छोड़ी
  • पहला interview घबराहट और TypeScript errors की वजह से बिगड़ गया, लेकिन 6 महीने बाद फिर कोशिश करके वे नई बनी JS Infra team के पहले hire के रूप में शामिल हुए
  • Dashboard development को नए JS bundler पर ले जाकर development speed लगभग 10 गुना बढ़ाई, लेकिन communication और project management के तरीके के कारण performance review में PME मिला
  • बाद में team के भीतर ज़्यादा vulnerable बातें साझा कीं और JS modularity project को सफल बनाया, जिससे exceeds expectations rating मिली, लेकिन recognition से मिलने वाली motivation लंबे समय तक नहीं टिकती
  • उदासी, नींद की समस्या और काम की motivation में कमी बार-बार लौटने लगी, तो उन्होंने team के साथ अपना depression साझा किया और break लिया; यह समझकर कि अस्थायी recovery पर्याप्त नहीं है, वे अगला कदम जाने बिना ही कंपनी छोड़ गए

अगली नौकरी के बिना Stripe छोड़ना

  • Jon de la Motte ने Stripe में लगभग 4 साल तक engineer के रूप में काम किया, और उनका आखिरी कार्यदिवस शुक्रवार, 30 अगस्त था
  • अगली नौकरी तय किए बिना इस्तीफा देना डरावना था, लेकिन अप्रत्याशित रूप से ऊर्जा देने वाला फैसला भी था
  • इस्तीफे से पहले उन्होंने अपने विचारों को internal blog में लिखा, और पत्नी के साथ लेख को सँवारते हुए यह समझा कि उनके लिए महत्वपूर्ण बात कहानी को और अधिक सच्चाई से कहना है
  • उन्हें लगा कि शायद कुछ लोग ऐसी ही मुश्किलों से अकेले गुजर रहे हों, इसलिए उन्होंने अपना अनुभव सार्वजनिक करने का फैसला किया
  • सार्वजनिक करना भी डरावना था, लेकिन उन्होंने इसे अपने मुख्य मूल्यों में से एक humbling honesty को जीने का तरीका माना

Stripe में शामिल होने से पहले की घबराहट और पहली असफलता

  • Stripe से उनकी उम्मीदें बहुत बड़ी थीं
    • वे इसे परिष्कृत products, detail पर ध्यान और engineering excellence वाली company मानते थे
    • Hacker News पर Stripe के नए product launches देखते ही वे बहुत उत्साहित हो जाते थे, और Patrick को industry visionary के रूप में सम्मान देते थे
  • पहले phone screen interview से पहले उन्होंने TypeScript, testing framework, tmux और terminal setup तक तैयार कर लिया था, लेकिन वे बेहद घबराए हुए थे
  • Interview का सवाल simple data structure और constraint-based filtering से जुड़ा था, लेकिन types को पहले सख्ती से model करने की कोशिश में वे TypeScript errors में अटक गए
    • Dynamic keys वाले object की वजह से उन्हें लगा कि indexed type का उपयोग करना होगा
    • Error fix तुरंत समझ में नहीं आया, तो उन्होंने //@ts-ignore से compiler error को bypass किया
    • इसके बाद errors बढ़ते गए और उनका focus टूट गया
  • Interview के बाद उन्होंने समस्या को फिर से हल किया, उसे public gist में डाला और Twitter DM से interviewer को भेजा, लेकिन कुछ दिनों बाद उन्हें rejection email मिला
  • 6 महीने बाद उन्होंने फिर interview दिया और Stripe में select हो गए, और उन्हें इस बात पर बहुत गर्व हुआ

JS Infra की उपलब्धि और PME rating

  • Stripe में वे नई बनाई गई JS Infra team के पहले hire के रूप में शामिल हुए
  • शुरुआत में ऐसा project ढूँढने में समय लगा जो साफ business value दिखा सके, और खासकर writing मुश्किल थी
    • पहले की छोटी companies में उन्होंने गंभीर project proposals लिखने का लगभग कोई अनुभव नहीं लिया था
    • Stripe के polished shipped emails पढ़कर उन्हें लगा कि उनकी writing skills कमज़ोर हैं
    • अधूरे document में दूसरों के avatars दिखना भी उन्हें डराता था
  • करीब 1 साल बाद उन्होंने Dashboard development को नए JS bundler पर migrate करने वाले project में बड़ी उपलब्धि हासिल की
    • Development speed लगभग 10 गुना बढ़ाई
    • जब उन्हें पता चला कि उनका shipped email Patrick के Friday Fireside tabs में से एक था, तो वे बहुत खुश हुए
  • अगले 1:1 में manager ने communication और project management को लेकर चिंताएँ बताईं
    • Feedback था कि वे दूसरे engineers को project में पर्याप्त रूप से शामिल नहीं कर पाए
    • नतीजा गर्व करने लायक था, लेकिन तरीका आदर्श नहीं था, ऐसी evaluation मिली
  • Performance review में उन्हें partially meets expectations(PME) मिला
    • Manager ने कहा कि अगर वे project management feedback को अपनाएँ और अच्छे results देते रहें, तो अगले cycle में solid review मिल सकता है
    • Call के बाद Jon closet में गए और चुपचाप रोए; उन्हें शर्म और अपमान महसूस हुआ

Vulnerability साझा करने वाली team experience और recognition की सीमा

  • Team के एक पुराने दोस्त के साथ हुई ईमानदार बातचीत ने दोबारा खड़े होने में थोड़ी ताकत दी
    • वह पिछले workplace में भी साथ काम कर चुका colleague था, और Jon भरोसा कर सकते थे कि वह work performance से अलग भी उनकी परवाह करता है
    • साथ मिलकर उन्होंने JS bundler project के अगले चरण का proposal जल्दी बनाया
  • उस समय manager को लगा कि उस proposal से ज़्यादा urgent काम को priority देनी चाहिए, लेकिन उन्होंने यह बात सीधे नहीं कही, और Jon अंततः दूसरे JS modularity project पर चले गए
    • बाद में मुड़कर देखने पर उन्हें लगा कि वह बदलाव सही choice था
    • Manager ने ज़्यादा सीधे क्यों नहीं कहा, इस पर बात नहीं हो पाई
  • नए manager के आने के बाद, team onsite की शुरुआत में उन्होंने सुझाव दिया कि “अपने बारे में सामान्य workplace environment की तुलना में 10% ज़्यादा vulnerable होकर परिचय दें”
    • Jon ने साझा किया कि कुछ साल पहले उनकी शादी लगभग टूटने की कगार पर पहुँच गई थी और वह दर्द कैसा था
    • दूसरे colleagues ने भी ऐसी गहरी बातें साझा कीं जो उन्होंने workplace में पहले कभी नहीं सुनी थीं
  • Stripe में उनकी सबसे पसंदीदा memory किसी project की सफलता या Patrick द्वारा उनका लेख देखना नहीं थी, बल्कि वे पल थे जब वे साथ काम करने वाले लोगों को और करीब से जान पाए
  • नया project एक बार फिर बड़ी सफलता बना, और review में उन्हें exceeds expectations मिला
    • Positive shock तो था, लेकिन motivation जल्दी गायब हो गई
    • उन्हें और साफ महसूस होने लगा कि performance recognition में उनकी दिलचस्पी धीरे-धीरे कम हो रही है

Depression, break, और अनजाना अगला कदम

  • समय के साथ जीवन के हर हिस्से में motivation घटाने वाली उदासी आने लगी
    • आम तौर पर पसंद आने वाले video games खेलने की energy भी लगभग नहीं बची थी
    • कुछ शामों में वे सचमुच दीवार को देखते हुए बैठे रहते थे
    • नींद भी खराब हो गई
  • उन्हें यह बात खटकती रही कि कभी-कभी “run” week खत्म होने के बाद backlog शुरुआत से भी बड़ा हो जाता है, और team पर बोझ बनने की भावना गहराती गई
  • Distractions कम करने की कोशिश की, लेकिन असर सीमित रहा
    • Hacker News और Twitter को DNS से block किया
    • Google News पढ़ना बंद किया
    • कुछ समय तक मदद मिली, लेकिन उदासी बनी रही
  • वे team और काम से प्यार करते थे, लेकिन flow state धीरे-धीरे दुर्लभ होती गई
    • कभी-कभी code, documents और मुश्किल Slack replies अपने-आप बहते चले आते थे
    • लेकिन उन्हें लगा कि हर उपाय fail हो रहा है और अब ज़्यादा मजबूत कदम चाहिए
  • अंततः उन्होंने team से कहा कि वे depression से जूझ रहे हैं और उन्होंने समय लिया
    • Meeting से पहले उनका पेट मिचला रहा था और वे खुद से पूछ रहे थे कि क्या वे कमज़ोर हैं
    • Team ने बहुत support किया, और उस care और understanding के बीच वे काम की वजह से दूसरी बार रो पड़े
  • वे फिर काम पर लौटे, लेकिन कुछ महीनों बाद नींद और आराम फिर बिगड़ गए
  • उन्होंने माना कि recovery और energy लौटने के cycle होते हैं, लेकिन वे टिकते नहीं; इसलिए यह समय है कि वे यह जाने बिना भी कदम बढ़ाएँ कि आगे क्या आएगा
  • अंत में वे John O’Donohue की To Bless the Space Between Us में छपी कविता का उद्धरण देते हैं, और इस भावना के साथ समाप्त करते हैं कि भीतर की शक्ति बता रही है कि बदलाव का समय आ गया है और अज्ञात में जाने के लिए साहस चाहिए

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

1 टिप्पणियां

 
GN⁺ 2024-11-03
Hacker News टिप्पणियां

  • मैं नहीं चाहता कि मैनेजर group therapy के लिए दबाव डाले। रिश्ता बस इतना है कि मैं कंपनी को काम के घंटे देता हूं, और कंपनी मुझे पैसे देती है
    सहकर्मियों से व्यक्तिगत रिश्ता बनाना, दोस्त बनना या निजी बातें साझा करना मेरी पसंद होनी चाहिए। मेरी निजी जिंदगी कंपनी का मामला नहीं है
    बेशक मैं मैनेजर से यह सीधे नहीं कहूंगा, लेकिन उसे उन लोगों की सूची में डाल दूंगा जिनसे सावधान रहना है, और शायद ठीक-ठाक कोई नकली स्वीकारोक्ति कर दूंगा

    • ऑफिस में अपनी कमजोरियां/निजी बातें उजागर करना अपने ही पैर पर कुल्हाड़ी मारने जैसा पक्का तरीका है। अमेरिकी संस्कृति में ऐसी बातें खुलकर बोलने को लेकर positive self-help जैसी बहुत-सी बातें हैं, लेकिन असलियत में आप उन लोगों को drama और हमले का मसाला दे रहे होते हैं जो जरूरी नहीं कि आपके पक्ष में हों
      कुछ बातें, चाहे “openness” कितना भी trend में हो, करीबी दोस्तों, परिवार और therapist के बीच ही रहने देना बेहतर है
    • मूल बात तो यह थी कि “अगर comfortable हो तो 10% और vulnerable होने की कोशिश करें”; समझ नहीं आता कि वह “जबरदस्ती” और “group therapy” कैसे बन गया
    • पिछले कुछ वर्षों में मेरा सामना एक ऐसे मैनेजर से हुआ था जो pop psychology और self-help किताबें बहुत पढ़ता था। उसकी 1:1 meetings धीरे-धीरे therapy जैसी sessions बनती गईं, और वह बचपन, पारिवारिक जीवन, डर, anxiety जैसी बातें “खुलवाने” की कोशिश करता था
      हर बार मैं विनम्रता से बातचीत को काम और ऑफिस की बातों पर वापस ले आता था, और इसी वजह से हमारे संबंध अच्छे नहीं रहे
      शुरुआत में मुझे लगा यह कोई अजीब अपवाद है, लेकिन जब मैं invitation-only management Slack में गया, तो #1-on-1s channel के topics में से लगभग 1/4 टीम मेंबर्स का psychoanalysis करने या therapist जैसा बर्ताव करने की कोशिश करने वाले managers के बारे में थे
      अच्छी बात यह थी कि उस Slack में ऐसे लोगों को उनकी भूमिका और workplace की उचित boundaries के बारे में ठीक से समझा दिया जाता था। बुरी बात यह है कि नए managers कहीं से यह विचार सीखकर आते हैं कि उन्हें अपनी team का therapist और patriarch जैसा बनना चाहिए। यह B-grade business books और LinkedIn जैसी social media पर पनप रही New Age management philosophy का कोई अजीब variant लगता है
    • मुझे इस बात की उतनी चिंता नहीं कि वे बाद में उस कहानी का दुरुपयोग करेंगे; असली झुंझलाहट तो जबरन दिल खोलने और नकली दोस्त जैसा बर्ताव करने की मांग से है। यह एक कामकाजी रिश्ता है
      शायद इसलिए कि मुझे remote work पसंद है, लेकिन मैं 4000km दूर बैठे लोगों से दोस्ती नहीं करना चाहता। मेरी उम्र भी काफी हो चुकी है, और मुझे पता है कि workplace friendships कुछ सालों में गायब हो जाती हैं। उन कुछ सालों में भी हमने ज्यादातर काम और career की ही बात की
      बेहतर होगा कि सभी को अपनी personal history साझा करने के लिए मजबूर न किया जाए। मैं जिसे बताना चाहूंगा, जब बताना चाहूंगा, तब बताऊंगा
    • यहां कही गई vulnerability का मतलब शायद team को expectations, परेशानियां और इच्छाएं सामने रखने का मौका देना हो सकता है। workplace में vulnerable होना, जैसे यह स्वीकार करना कि review में डाली गई चीजों पर लोग सच में constructive feedback देने के बजाय छोटी-छोटी बहसों में उलझ जाते हैं और यह आपको पसंद नहीं, या यह कहना कि आपको लगता है git workflow contributions को fair तरीके से सामने नहीं लाता
      अगर दूसरे लोग भी ऐसा ही महसूस करते हैं तो सुधार किया जा सकता है। team level पर आगे जाएं तो यह कहना भी हो सकता है कि support inquiries का जवाब देना आपको सचमुच नापसंद है और आप चाहते हैं Pete यह ज्यादा करे, या Sue Figma में शानदार काम कर रही है और आप उससे सीखना चाहते हैं। इस तरह की “vulnerability” team के भीतर meaningful लगती है

  • अभी जो अनुभव हो रहा है, वह बड़ी कंपनियों में चाहे आप कितना भी अच्छा करें, अकेले दम पर meaningful तरीके से खेल बदलना मुश्किल होने वाली संरचना का लक्षण है
    इसके साथ यह भी जुड़ जाता है कि काम का अंतहीन सिलसिला हमेशा मौजूद रहता है। हर कंपनी में हमेशा काम होता है और कोई भी पूरी तरह “खत्म” नहीं कह सकता, लेकिन बहुत बड़ी कंपनियों में meaningful deadlines और deliverables भी impact के लिहाज से लगभग 0 पर round off होते महसूस होते हैं
    Microsoft में काम करते हुए मैं लगभग burnout के कगार तक पहुंच गया था। ज्यादातर metrics के हिसाब से मैं सफल था, लेकिन मुझे सबसे ज्यादा चलाने वाली चीज यह एहसास था कि काम meaningful है और impact रखता है, और पर्याप्त बड़ी कंपनी में यह पाना लगभग असंभव है
    startup CTO के रूप में जाने के बाद जिंदगी तुरंत फिर से मुस्कुराने लगी
    काम से अलग होकर आराम का समय जरूरी है, लेकिन बहुत लंबे समय तक दूर रहना जरूरी नहीं। “कई साल लगते हैं” वाली बात तब सही हो सकती है जब आप पूरी तरह घिस चुके हों, लेकिन यह मानकर कि असफल होना भी ठीक है, ऐसा काम आजमाना जिसमें आपको लगे कि वह meaningful है और समाज में योगदान देता है, recovery process का एक महत्वपूर्ण और कम आंका गया हिस्सा है

    • management में जाना और office politics सीखना होगा, तभी खेल बदला जा सकता है। बड़ी कंपनियों में politics बहुत होती है, और आपको खुद को जीतने वाली team की तरफ position करना होता है
      साथ ही लोगों को handle करने की क्षमता हमेशा technical ability से आगे रहती है। यह समझना मेरे career के लिए सबसे ज्यादा मददगार रहा
    • बड़ी कंपनी में काम करते समय लोग अक्सर priorities गलत सेट करते हैं। अगर impact बनाना है तो अपनी business बनाने की दिशा में बढ़ना चाहिए, और बड़ी कंपनी सिर्फ उसका एक साधन है
      bank balance बढ़ाने, अच्छी credit history बनाने, सादगी से रहने और खाली समय में ideas को विकसित कर उन्हें execution में लाने पर focus करना चाहिए
      कुछ jurisdictions में कंपनी work hours के बाहर विकसित किए गए ideas पर भी अधिकार जता सकती है, इसलिए employment contract देखना चाहिए। यह पक्का कर लेना चाहिए कि ऐसी clause न हो
    • कभी-कभी मुझे अपने early 20s में किए गए bakery, ice cream shop जैसे काम याद आते हैं। pay कम था और working conditions भी खास नहीं थीं, लेकिन सरल चीज बनाकर लोगों को देने और दिन खत्म होने पर सचमुच खत्म हो जाने में एक मनोवैज्ञानिक फायदा था
      कोई लगातार बची हुई to-do list, sprints, daily meetings, modern white-collar jobs की तमाम demands नहीं थीं
      सोचता हूं कि क्या knowledge work को भी इसी तरह design किया जा सकता है। मुश्किल हिस्सा यह है कि अधिकतम एक दिन के scope पर ही focus रखते हुए भी long-term progress कैसे बनाई जाए
    • अगर “काम meaningful होना चाहिए तभी motivation मिलती है”, तो जिज्ञासा है कि किस तरह का काम meaning देता है, इसका criteria क्या है
      मुझे लगा था कि users या customers के करीब जाने से मदद मिलेगी। आखिर software लोगों के लिए ही होता है। लेकिन bugs संभालना, feature expectations align करना जैसे social aspects थका देने वाले थे और meaningful नहीं लगे
      मैं सिर्फ तब खुश था जब budget के भीतर जितना हो सके custom-built software से customer या user को मेरे बिना भी अच्छा करते देखता था। लेकिन अफसोस, सिर्फ उससे business नहीं बनता
    • 6 लोगों वाले startup से लेकर merge हो रही बड़ी company तक का सफर देखने के बाद, नया startup बनाने या join करने की खिंचाव काफी है। कम से कम एक छोटे team का एक mission के लिए सचमुच डूबे हुए लोगों के साथ काम करने का आनंद तो है

  • लेखक को लगता है कि बड़ी कंपनी से अपेक्षाएँ अवास्तविक थीं
    उसे उम्मीद थी कि वह दुनिया बदलने वाला अर्थपूर्ण काम करेगा और उसकी मेहनत के लिए उसे हीरो की तरह सराहा जाएगा, लेकिन हकीकत ऐसी नहीं होती
    जान लगा कर काम करने पर भी पीठ थपथपाए जाने से ज़्यादा की उम्मीद नहीं करनी चाहिए। मैनेजरों को आपकी मेहनत, मानसिक स्थिति या बिना सोए गुज़ारी रातों से ज़्यादा इस बात में दिलचस्पी होती है कि वे ऊपर वालों को कैसे दिखें
    इसलिए बेहतर है कि बस उतना ही काम किया जाए जितना अच्छी रेटिंग पाने के लिए अपेक्षित है
    अगर कोई शानदार idea आए जो कंपनी के लिए बहुत मददगार हो सकता है, तो उसे तुरंत लागू न करें। बेहतर है कि ऊपर की परतों में अपने समर्थक खोजें, उन्हें उसका फायदा समझाएँ, फिर proof of concept या minimum viable product बनाएँ और किसी open meeting में top management को बताएँ। तब कंपनी के लिए अच्छा काम करने और सही लड़ाई लड़ने का credit और सराहना मिल सकती है

    • यह कहानी उस समय के काफी छोटे Stripe पर ज़्यादा फिट बैठती। जब हर किसी को जाना जा सकता था, Patrick हर programmer का interview लेते थे, और Mission की एक cafeteria में सभी लोग आ जाते थे, तब फर्क डालना मुश्किल नहीं था
      माहौल हमेशा competitive था, smart लोग लंबे घंटे काम करते थे, और details को लेकर जुनून ऐसी culture बनाता था जो कई लोगों में impostor syndrome छोड़ देता था। एक-दूसरे के प्रति विनम्र रहने की अपेक्षा भी काफी मजबूत थी। infra team द्वारा requests को ठंडेपन से ignore करना बस स्वीकार्य नहीं था
      इसलिए लगातार बढ़ती अपेक्षाओं पर खरा उतरने के लिए बहुत मेहनत करते-करते burnout होना आम था
      लेख में उस culture की एक और कमजोरी भी दिखी: बार-बार management changes और Amazon जैसी manager performance culture। अगर manager team बदल देता, तो जो व्यक्ति पहले expectations से ऊपर माना जाता था, उसे अगले manager से अचानक PIP मिल सकता था
      कल्पना कीजिए कि किसी के बारे में “जिन लोगों के साथ काम किया उनमें सबसे helpful व्यक्ति” कहने के 2 हफ्ते बाद वही व्यक्ति गायब हो जाए, तो morale पर क्या असर पड़ता होगा। कई मायनों में यह शानदार workplace था, लेकिन negative हिस्सों की कीमत भी बड़ी थी
      अंत में, यह कहानी दिखाती है कि कई साल बीत जाने के बाद भी Stripe के बहुत से पहलू अब भी पहचाने जा सकते हैं
    • अगर कोई कंपनी hiring criteria के रूप में passion को आगे रखती है, तो वह ऐसे लोगों को चुनेगी जो फर्क डालना चाहते हैं। अगर वास्तविक job उस expectation से मेल नहीं खाती, तो यह कंपनी के लिए भी अच्छा नहीं हो सकता
    • बड़ी कंपनी में strategy यह है कि internal chat या forums में ऐसे issues खोजे जाएँ जो interesting लगते हों। फिर उन्हें fix करें या थोड़ा कम भयानक बना दें
      हमेशा कुछ मजबूत और interesting बनाएँ, ताकि कोई उसे संयोग से पाए तो कह सके, “वाह, यह अच्छा है, इसे किसने बनाया?”
      फिर सही context में link को हल्के से share करें। 10% भी fit हो जाए तो संतुष्ट रहें
      assigned projects के बीच-बीच में, रोज़ 9 से 5 के दौरान ऐसा करते रहें, तो आप हैरान होंगे कि अपनी team के बाहर कितना बड़ा internal network बना सकते हैं। इससे lateral moves के options भी खुले रहते हैं
    • अगर आपके पास कोई शानदार idea है जो कंपनी की बहुत मदद कर सकता है, तब भी उसे सीधे न करना बेहतर है। आखिर में उससे आपको फायदा न मिलने की संभावना ज़्यादा है
      “समर्थक” ढूँढ भी लिए, तो वे आपको धोखा देकर idea का credit ले सकते हैं, promotion पा सकते हैं और आपको बाहर कर सकते हैं
      अगर कोई अच्छा idea है, तो उसे अपने पास रखें, कंपनी के बाहर उसका इस्तेमाल करने का तरीका सोचें, और अगर वह काफी मजबूत है तो उसी idea से business शुरू करें। वरना उसे भूल जाएँ
      जितना कहा गया है उससे ज़्यादा न करना ही बेहतर है

  • लेख बेहतरीन है, लेकिन पढ़ते हुए vicarious anxiety और थकान गहराई से महसूस हुई। यह व्यक्ति कम self-esteem या किसी और वजह से अस्वस्थ स्तर तक people-pleasing करने वाला साफ दिखता है, और हो सकता है उसने depression में योगदान दिया हो
    गंभीरता से देखें तो therapy सही विकल्प हो सकती है। फिर भी positive बात यह है कि वह अच्छा कुछ बनाना चाहने वाला अच्छा इंसान लगता है, और यह सराहनीय है

    • पूरी तरह सहमत। लेखक को therapy पर विचार करना चाहिए, या कम से कम ऐसी अगली job ढूँढनी चाहिए जिसकी उसे इतनी परवाह न करनी पड़े
      जो काम आप ship करते हैं उसकी quality की परवाह करें क्योंकि वह मज़ेदार है, लेकिन इंसान की तरह रहें और private life को private ही रखें
      people-pleasing और validation की चाह खुद को दूसरों की flashlight की battery बना देने जैसा है। आप खुद को हमेशा दूसरों द्वारा खर्च होते देखेंगे। दूसरों को अपनी खुशी control करने न दें

  • यह लक्षण आम तौर पर burnout का संकेत है। लेख में जो बात खास दिखती है, वह यह है कि काम किसी खास तरीके से अर्थपूर्ण और महत्वपूर्ण होना चाहिए—इस विचार से बहुत ज़्यादा बंधे रहना
    अगर हर चीज़ महत्वपूर्ण होनी ही चाहिए, तो हर चीज़ में भावनात्मक रूप से invest करना पड़ेगा, और यह अपने-आप में burnout तक ले जा सकता है। लेकिन कोई चीज़ मेरे लिए व्यक्तिगत रूप से इतनी महत्वपूर्ण न हो, तब भी मैं उसकी परवाह कर सकता हूँ; हर चीज़ में पूरी तरह डूबे बिना भी अच्छा काम कर सकता हूँ; और काम से प्यार करने के लिए हर detail का अर्थपूर्ण होना ज़रूरी नहीं
    तेज़ी से चलने वाला जटिल काम, हर तरफ technical debt, innovation की न रुकने वाली रफ्तार, और growth—इन सबके बीच हर चीज़ में खुद को invest करने के लिए बहुत कुछ है। चीज़ों का इतना ज़्यादा महत्वपूर्ण होना ज़रूरी नहीं
    कुछ बातें महत्वपूर्ण हो सकती हैं जिनकी सच में परवाह हो—जैसे तकनीक और quality, रिश्ते, आसपास के लोगों को mentor करना और आगे बढ़ाना, थोड़ा-थोड़ा सुधार होते देखना। लेकिन हर चीज़ महत्वपूर्ण नहीं हो सकती। और उन कुछ बातों के बारे में भी, बहुत गहरे स्तर पर यह समझना होगा कि वे असल में इतनी महत्वपूर्ण नहीं हैं
    Stripe इस दुनिया में सचमुच मौजूद कोई चीज़ नहीं, बल्कि दिन भर जिन कुछ लोगों से वास्तव में interaction होता है, उनके साथ संबंधों को frame करने के लिए एक साझा कल्पित कथा है। दिन भर सच में जो होता है, वह बस computer पर type करना और कुछ लोगों से बात करना है
    आपने क्या type किया, humble honesty या feverish curiosity या PME जैसे ऊँचे उद्देश्य, वे कहानियाँ जो हम खुद को सुनाते हैं ताकि कल्पना से वास्तविकता बना सकें—ये सब किसी अर्थपूर्ण मायने में वास्तव में महत्वपूर्ण नहीं हैं। सच में महत्वपूर्ण सिर्फ यह है कि मैं जिन लोगों से मिलता हूँ उनकी जिंदगी कैसे बदलता हूँ, और अपनी जिंदगी कैसे बदलता हूँ
    Burnout कठिन होता है। रोज़ meditation की आदत डालनी चाहिए, और अर्थ से चिपके रहने को छोड़ते हुए मन को recover होने देना चाहिए। अभी साथ मौजूद व्यक्ति—खासकर खुद के साथ मौजूद क्षण—का आनंद लेने का अभ्यास चाहिए
    कंपनी या career जैसी कल्पनाओं और उन छोटे-बड़े झूठों को, जिन्हें हम रोज़ अपने भीतर मजबूत करते हैं, अनिवार्य रूप से महत्वपूर्ण और गहरे अर्थ वाला होना चाहिए—इस obsession को जितनी जल्दी छोड़ेंगे, खुशी उतनी जल्दी लौटेगी
    मुझे लगता है burnout और depression एक जैसे नहीं हैं। मैंने दोनों झेले हैं, लेकिन burnout अलग है। इसमें भागीदारी की क्षमता खोना depression से overlap करता है, लेकिन आम तौर पर निराशा या जीवन खत्म हो जाए जैसी सोच साथ नहीं आती। यह उस मरे हुए-से एहसास के करीब है जिसमें आप वह काम शुरू नहीं कर पाते जिसे करना चाहिए लगता है, और इसका असर व्यापक रूप से हर चीज़ पर पड़ता है
    यह बेहतर होता है

    • Burnout से उबरने का मेरा तरीका था computer से जुड़ी नहीं होने वाली, job के बाहर की जिंदगी रखना। 20s की शुरुआत में मेरी जिंदगी में ध्यान देने लायक चीज़ें सिर्फ काम और computer ही थीं
      सुबह उठकर office जाता, programming करता, घर आकर side project code करता या computer games खेलता, सो जाता और अगले दिन वही दोहराता। कोई hobby नहीं थी, workplace पर मिले लोगों के अलावा दोस्त या परिचित नहीं थे, और office के कृत्रिम लक्ष्यों के अलावा मुझे चलाने वाली कोई चीज़ नहीं थी। यह burnout की recipe थी, और असल में लगातार वैसा ही होता रहा
      बाद में शादी हुई, परिवार बना, local community में करने के लिए काम ढूँढे, और computer बंद करके की जाने वाली exercise और hobbies बहुत करने लगा। 20s के बाद वाली नौकरियाँ उल्टे और भी ज़्यादा आत्मा निचोड़ने वाली थीं, लेकिन burnout के कोई संकेत नहीं थे
      काम खत्म हुआ तो computer बंद, और बात खत्म। furniture बनाना, car ठीक करना, बच्चे के साथ समय बिताना—ऐसे काम करता हूँ जिनका office politics, 2-week sprint, status report से कोई लेना-देना नहीं। काम के बाहर की जिंदगी ने mental health में बहुत मदद की। meditation या spirituality की ज़रूरत नहीं पड़ी
    • “काम की इतनी ज़्यादा परवाह मत करो” सुनने में हल्की बात लगती है, लेकिन असल में यह बेहतरीन सलाह है
      मानकर चलें कि हमारे पास परवाह करने का सीमित budget होता है, और यह budget कहाँ खर्च करना है, इसे लेकर सावधान रहना चाहिए। हर व्यक्ति का, और उसी व्यक्ति का भी जीवन के अलग-अलग दौर में, budget अलग हो सकता है; इसलिए उसका आकार समझना भी एक हुनर है
      Burnout तब आता है जब बहुत सारी चीज़ें बहुत ज़्यादा महत्वपूर्ण हो जाती हैं, और हर एक को अपना एक हिस्सा देने की भावनात्मक क्षमता को आप बहुत लंबे समय तक पार कर जाते हैं
      यहाँ महत्वपूर्ण बात यह है कि वे “बहुत महत्वपूर्ण” चीज़ें अच्छी चल रही हैं या बुरी, इससे अलग मामला है। चीज़ें खराब चलेंगी तो stress बढ़ेगा, लेकिन जो चीज़ें अच्छी चल रही हैं, उनमें से बहुत सारी को बहुत ज़्यादा महत्वपूर्ण मानने से भी burnout हो सकता है
    • “लोगों के बीच interactions को frame करने के लिए दुनिया की साझा कल्पित कथा” वाला expression किसी natural philosopher जैसा लगता है
      मुझे लगता है सार्वभौमिक रूप से महत्वपूर्ण बात यह है कि हम जो कर रहे हैं उसमें active participation बनाए रखें। कुछ लोगों को यह कल्पित कथा कहनी पड़ती है कि वे जो कर रहे हैं वह अर्थपूर्ण है, और कुछ लोग बस जानते हैं कि उनकी जिंदगी को अर्थ क्या देता है

  • मैंने यह pattern इतनी बार देखा है कि शायद इसे generalize किया जा सकता है। जब mental health टूट जाती है, तो बाकी किसी चीज़ की कोई कीमत नहीं रह जाती
    सपनों की job, शुरू में चाही गई प्रतिष्ठा, income—सब मिल जाए, तब भी mentally healthy होना pyramid की नींव है
    इसलिए मैंने सीखा कि mental health को सचमुच priority बनाना चाहिए
    अगर आपको लगता हो कि career ही सब कुछ है, तब भी अपनी income का कुछ हिस्सा खर्च करके professional help लेना सस्ता investment है। अगर टूटकर job छोड़नी पड़े, तो सैकड़ों हजार dollar का नुकसान हो सकता है और recovery भी दर्दनाक होती है। मैंने ऐसे लोगों के बारे में भी सुना है जो burnout के बाद tech industry पूरी तरह छोड़ना चाहते थे
    mental health के संदर्भ में जोड़ूँ तो sleep health के मामले में number 1 priority होनी चाहिए। अगर कई महीनों तक लगातार अच्छी quality की नींद नहीं मिलती, तो coffee या exercise के सहारे टिके रहने पर भी आखिरकार शरीर टूट जाता है
    लेख शानदार है, और इसे share करने की हिम्मत दिखाने के लिए सच में आभार महसूस होता है। उम्मीद है आप फिर से खुशी पाएँगे

  • यह राय शायद लोकप्रिय न हो, लेकिन थोड़ा सामान्यीकरण करूँ तो इसमें Gen Z वाला एहसास काफ़ी है। ऐसा कहते हुए मुझे भी लगता है कि मैं बूढ़ा हो गया हूँ, लेकिन शायद मैं लेखक से निश्चित रूप से ज़्यादा उम्र का हूँ
    गंभीरता से देखें तो कहानी की शुरुआत से ही perfectionism के संकेत दिखते हैं। जैसे font को धुंधला करना, meeting में जाने से पहले 30 सेकंड इंतज़ार करना वगैरह। व्यक्तिगत रवैये में भी बहुत बड़ी vulnerability है
    लगता है कि यह व्यक्ति अपेक्षाकृत युवा, idealistic और career के शुरुआती दौर में है। ऐसे लोग अगर अंदर से बदल नहीं पाते और manager या company की बकवास को नज़रअंदाज़ नहीं कर पाते, तो लंबे समय तक टिकना मुश्किल होता है
    गरिमा बनाए रखने के लिए कुछ हद तक “मुझे क्या” वाला रवैया ज़रूरी है। Performance review मुझे एक इंसान के रूप में define नहीं करता, और कर भी नहीं सकता। वरना निराश होना या emotionally burn out होना आसान है, और यहाँ वही दिख रहा है

    • उस व्यक्ति की जगह खुद को रखकर देखें तो बात समझ आती है
      आपने एक ऐसी company को idolize किया है जो top-tier engineering talent और बेरहमी से मुश्किल interviews के लिए जानी जाती है, और संयोग से आपको उसी company में interview का मौका मिल गया है
      interviewer किस वजह से “hire नहीं” कह देगा, यह पता नहीं होता, इसलिए स्वाभाविक है कि आप मान लेते हैं कि वे perfection चाहते हैं। कई सालों से जिस dream job का सपना देखा है, उसे न पाना कोई विकल्प नहीं लगता, इसलिए गलती से बेहद डरना और पहली छोटी-सी गलती के बाद तुरंत नीचे की ओर spiral हो जाना भी समझ में आता है
      dream job मिलने के बाद और भी ज़्यादा मेहनत करनी पड़ती है। दबाव रहता है कि यहाँ के engineering talent को देखा है न। manager से “fail” performance rating मिलने पर यह anxiety तेज़ हो जाती है, और व्यक्ति अपनी value साबित करने के लिए और मेहनत करने लगता है
      कुछ लोग ऐसी परिस्थितियों में किसी तरह टिके रहते हैं। कुछ लोग सफलता, चाहे वह जो भी हो, उसके लिए अपनी ज़िंदगी की हर चीज़ और हर व्यक्ति को जलाने के लिए तैयार हो जाते हैं
    • जीवन की हर चीज़ में स्वस्थ मात्रा में मुझे क्या वाला रवैया ज़रूरी है
      जिस पल मैंने यह सीखा और ऐसे जीना शुरू किया, happiness बढ़ी और anxiety घटी
      यह रवैया चाहिए कि बिगड़ भी गया तो क्या। दूसरों की नज़र में मैं कैसा दिखूँगा, इस बारे में अपनी कल्पना के हिसाब से जीना बंद करना होगा
    • लेखक ने कहा कि उनका industry experience लगभग 10 साल है, इसलिए अगर मान लें कि college के तुरंत बाद उन्होंने पहली programming job शुरू की, तो उम्र करीब 30–32 होगी और काफ़ी निश्चित रूप से वे millennial के ज़्यादा करीब हैं। बेशक, ऐसी बातें मायने नहीं रखतीं। “generation” जैसे बनाए हुए पैमानों पर generalize करना मुझे हमेशा संदेहास्पद लगता है
      लोगों को खुश करने की प्रवृत्ति साफ़ महसूस हुई, और screen को साफ़ दिखाने या meeting join करने का समय design करने वाली बातें ज़्यादा लगीं—इससे सहमत हूँ। अगर interviewer ऐसे “metrics” पर ध्यान देता है या उनसे प्रभावित होता है, तो वह काफ़ी superficial माना जाएगा
      पहला performance review देखकर लगता है कि यह bad manager का मामला था। Communication बहुत महत्वपूर्ण है, इससे सहमत हूँ, लेकिन किसी ऐसे व्यक्ति को low rating देना जिसने बाकी पहलुओं में बहुत सफल project पूरा किया हो, क्रूर और morale तोड़ने वाला है
      Communication issues को employee की motivation तोड़े बिना या career growth को नुकसान पहुँचाए बिना भी handle किया जा सकता है
      अगर खराब performance review employee के लिए surprise हो, तो यह अपने-आप में management failure है। समस्या को review तक इंतज़ार कराने के बजाय तुरंत सामने लाकर solve करने की कोशिश करनी चाहिए। Review के समय तक समस्या खत्म हो सकती है, और अगर नहीं भी हुई तो employee कम rating की वजह सुनकर हैरान नहीं होगा
    • Generalize करने या assumptions लगाने की ज़रूरत नहीं है। लेखक ने कहा कि उन्होंने “लगभग 10 साल तक software engineer के रूप में सफल career बनाया” और resume देखें तो लगता है कि वे 10 साल से ज़्यादा समय से professional engineer रहे हैं
      Perfectionism और idealism वाली बातों से सहमत हूँ, लेकिन ये सिर्फ़ Gen Z तक सीमित नहीं हैं
    • लेखक resume के आधार पर साफ़ तौर पर millennial दिखते हैं। मैं भी एक उम्रदराज़ millennial के रूप में चाहता हूँ कि HN और हमारी industry युवा और उम्रदराज़ दोनों तरह के लोगों के खिलाफ age discrimination से मुक्त रहे। ऐसे comments मददगार नहीं होते

  • इस लेख के “10% और vulnerable होना” वाले हिस्से पर बहुत-सी प्रतिक्रियाएँ “मैं कंपनी को काम के घंटे देता/देती हूँ और कंपनी मुझे पैसे देती है” जैसी थीं, और “कैसे हो?” “ठीक हूँ” से थोड़ा आगे जाने वाले मानवीय जुड़ाव को लेकर कड़ा विरोध दिखा। एक comment ने manager के सवाल को abuse तक कहा और यह भी कहा कि उसे निकाल देना चाहिए
    लेकिन अगर ज़्यादातर दिनों में ज़्यादातर समय हम इन्हीं लोगों के साथ बिताते हैं, तो सिर्फ इसलिए कि वे उसी कंपनी में काम करते हैं, उन्हें मानवीय जुड़ाव के दायरे से अपने-आप बाहर रखकर हमें क्या हासिल होता है, यह समझ नहीं आता
    और इस कहानी में यह कहना मुश्किल है कि manager ने किसी पर कुछ थोपा था

    • जब कोई manager कुछ suggest करता है, तो वहाँ power imbalance होता है। भले ही वह पूरी ईमानदारी से, 100% सच में, share न करने पर बिल्कुल परवाह न करता हो, power balance फिर भी काम कर रहा होता है, इसलिए यह जोखिम भरा है
      मुझे अपना manager पसंद है, वह comfortable इंसान है, और काम के बाद हमारी कुछ गहरी बातचीत भी हुई है। लेकिन अगर working hours में ऐसा कुछ किया जाए, तो मैं 100% कहूँगा/कहूँगी कि यह inappropriate है
      मुझे पता है कि इसमें बुरी नीयत नहीं है, लेकिन जो व्यक्ति नया join करके असुरक्षित महसूस कर रहा है, वह कैसे react करे? उससे कैसे उम्मीद की जा सकती है कि वह मना करे और यह HR वाली cliché भाषा—“team player नहीं है”—जैसा न दिखे
      कुछ लोग workplace के लोगों को acquaintance से ज़्यादा नहीं बनाना चाहते। उनकी अपनी social life अलग है, और workplace life की तुलना में उसमें कहीं ज़्यादा energy लगाना पूरी तरह ठीक है
      निजी तौर पर, मुझे शायद ही याद हो कि किसी ex-colleague ने कंपनी छोड़ने के बाद, या मेरे छोड़ने के बाद, हमने संपर्क किया हो; और मैं उन्हें दोस्त भी नहीं कहता/कहती। कठिन sprint के बाद शुक्रवार शाम को bar में साथ hang out भी किया, अच्छे working relationships भी थे, लेकिन वे दोस्त नहीं थे। वह समय मैं अपने असली दोस्तों के साथ बिताना चाहता/चाहती हूँ
    • मैंने ऐसे मामलों के बारे में सुना है जहाँ ऐसे माहौल में vulnerability share न करने पर share करने वाले लोग नाराज़ हो जाते हैं और बाद में व्यक्ति को exclude किया जाता है। manager को निकाल देना चाहिए कहना बहुत ज़्यादा है, लेकिन power imbalance और वह किस तरह सब पर conform करने का दबाव बनाता है, इसे ध्यान में रखना चाहिए
    • मैंने खुद ऐसे manager का अनुभव किया है जो इसी तरह invasive तरीके से पेश आया और professional boundaries और private boundaries को धुंधला करने की कोशिश करता था। बाद में उसने मेरे professional evaluation में मेरी मानी हुई emotional state और motives की आलोचना की
      अगर “force” का मतलब शारीरिक रूप से पकड़कर group में बोलवाना है, तो शायद यह सटीक न हो; और अगर “abuse” का मतलब सक्रिय रूप से power misuse करना है, तो वह भी शायद सटीक न हो। लेकिन हिस्सा न लेने के negative consequences होते हैं
      मैं colleagues से connect होने के खिलाफ नहीं हूँ। पिछली नौकरी से मुझे दो ऐसे दोस्त भी मिले जिन्हें मैं 10 साल से ज़्यादा समय से बहुत संजोकर रखता/रखती हूँ। बस वह connection organically, colleagues के बीच, और उस group से अलग होना चाहिए जिसे वह व्यक्ति lead कर रहा हो जो मेरी salary पर sign करता है और annual review लिखता है
    • vulnerable होना personal relationships बनाने में शानदार और मददगार हो सकता है। लेकिन manager का direct reports से professional setting में, group के सामने, personally vulnerable होने को कहना inappropriate है
      मैं सहमत हूँ कि यह force नहीं था, और मैं खुद अपने comfort level तक share करने में दिक्कत नहीं महसूस करूँगा/करूँगी। लेकिन उस team में कम-से-कम एक व्यक्ति ऐसा रहा होगा जिसे discomfort हुआ हो, फिर भी उसे लगा हो कि share न करने पर किसी न किसी तरह—चाहे सिर्फ socially ही सही—नुकसान हो सकता है। यह ठीक नहीं है
      अगर team meeting में boss के vulnerable moments share करने को कहे बिना team members के साथ bond नहीं बनाया जा सकता, तो वहाँ कोई गहरी समस्या है जिसे ऐसी activity solve नहीं करेगी
      हाल की नौकरी से मेरी कई strong friendships हैं जो कई साल पहले हम सबके वह कंपनी छोड़ देने के बाद भी कायम हैं। लेकिन दूसरी नौकरियों में तथाकथित colleague-friend relationships में से ज़्यादातर, दोनों में से किसी एक के कंपनी छोड़ने के बाद जल्दी फीकी पड़ गईं। यह काफी normal है और इसमें कुछ गलत नहीं
      colleagues के बाहर active social life होना, और colleagues में acquaintance से ज़्यादा interest न होना भी कोई समस्या नहीं है
    • इस स्थिति में conversation पर control नहीं होता, इसलिए कुछ participants uncomfortable हो सकते हैं। मेरा 10% और किसी और का 10% बहुत अलग हो सकता है
      लेखक ने भी माना कि “मैंने 10% से आगे जाने का फैसला किया। कुछ साल पहले मेरी शादी लगभग टूट गई थी और वह कितना painful था, इसका थोड़ा share किया”
      कल्पना कीजिए कि manager ने लगभग 10% share करने को कहा और किसी ने “कभी-कभी काम, deadlines, performance की वजह से anxiety होती है” जैसा कुछ कहा, लेकिन अगला व्यक्ति लगभग टूट चुकी शादी जैसी बेहद personal और गंभीर बात कर दे। वह व्यक्ति पूरी conversation का tone set कर सकता है और सबको उसी दिशा में follow करने पर मजबूर कर सकता है, या क्योंकि उसने ज़्यादा गंभीर बात share की है, वह conversation को hijack कर सकता है
      पहले से यह जानने का कोई तरीका नहीं कि कौन क्या share करेगा, इसलिए यह भी पहले से जानने का कोई तरीका नहीं कि सभी comfortable होंगे या नहीं
      मानवीय जुड़ाव colleagues से hobbies पर बात करके भी हो सकता है। यह ज़रूरी नहीं कि सभी अपने कठिन अनुभवों पर roundtable करें

  • ऐसी स्थितियों से निपटने में मेरे लिए तीन तरीके सबसे helpful रहे। पहले, meaningful की definition को refine करना। जो काम मेरी या colleague की मदद करे, कुछ नया सिखाए, या कुछ सुंदर बनाने दे, वह भी meaningful हो सकता है
    किसी भूखे व्यक्ति को एक meal देना भी बहुत अर्थ रखता है, भले ही वह किसी बड़े social problem को solve न करे या बहुत लोगों से applause न मिले
    दूसरा, लेखक के पहले manager जैसे लोगों को बहुत personally न लेना। समय के साथ पता चलता है कि वे आम तौर पर बुरे या भयानक इंसान नहीं होते, बस उनका mission अलग होता है। वे भी आमतौर पर हमारी तरह खोए हुए होते हैं और meaning व recognition खोज रहे होते हैं
    अगर सच में personality match नहीं करती, तो उन्हें दी जा रही importance कम करके काम पर focus किया जा सकता है। फिर भी अगर toxic हो जाए, तो move किया जा सकता है
    सबसे important है काम के साथ अपने relationship को फिर से गढ़ना। मैं कौन हूँ और मैं क्या करता/करती हूँ, ये ज़रूरी नहीं कि एक ही हों। “बस आराम से time pass करो और salary लो” वाली सलाह मुझे पसंद नहीं। मैंने ऐसा करके देखा है, और समय के साथ वह भी खराब महसूस होने लगता है। फिर भी उस direction में थोड़ा जाना balance खोजने में मदद करता है

  • लेख अच्छा लिखा गया है
    जिस point पर तुरंत गुस्सा आया, वह यह था कि शानदार काम कर लेने के बावजूद management ने results के बजाय हर दूसरी चीज़ पर attack करने के लिए कारण X पेश किया। वह कारण अपने-आप में सच में important नहीं था। असली कारण यह था कि किसी न किसी तरह उनसे threat महसूस हुआ था, और उन्हें अपनी jobs justify करनी थीं
    सच कहूँ तो, उस point पर मैं बस resign कर देता/देती। अगर और ज़्यादा रुका/रुकी, तो वह लगभग saint होने जैसा है
    काम करने के लिए सच में भयानक company लगती है

    • saint नहीं, बल्कि “तुम कभी enough good नहीं होगे, इसलिए और कोशिश करो” वाले pattern को repeat कर रहे हैं
      वह manager typical रूप से भयानक लगता है, और मुझे नापसंद है कि दुनिया ऐसे लोगों को दूसरों पर power देती है
    • शायद वह बस एक bad manager था। नए manager के साथ उसे बेहतर reviews मिले