इंजीनियर की सैलरी आखिर कहाँ से आती है?

• कई software engineers यह ठीक से नहीं समझते कि उनका काम क्यों महत्वपूर्ण है
• वे अक्सर ऐसे कामों पर ध्यान केंद्रित करते हैं जिनका profitability से सीधा संबंध नहीं होता (जैसे technical debt कम करना, accessibility सुधारना), और फिर layoff का सामना करते हैं या उन्हें कम rating मिलती है
• यह सोच कुछ वैसी ही है जैसे किसी ऐसे राजनेता का समर्थन करना जो आपकी नौकरी जाने का कारण बने

टेक कंपनी की प्रकृति

• टेक कंपनी एक ऐसा संगठन है जिसे कुछ लोग पैसा कमाने के लिए चलाते हैं
• सफल टेक कंपनियाँ बहुत revenue कमाती हैं, और उसे बनाए रखने या बढ़ाने के लिए software engineers को hire करती हैं
• कंपनी उन कामों को अधिक महत्व देती है जो revenue से सीधे जुड़े हों
• अगर एक engineer का काम कंपनी के revenue से जुड़ा नहीं है, तो वह भूमिका अस्थिर है

स्थिर position के लिए क्या समझना ज़रूरी है

• यह जानने के लिए कि आपका काम revenue से जुड़ा है या नहीं, दो चीज़ें समझनी होंगी:
  • कंपनी का business model (वह पैसा कैसे कमाती है)
  • आपका काम उस मॉडल को कैसे support करता है
• बड़ी कंपनियाँ अपना business model और financial जानकारी सार्वजनिक करती हैं, इसलिए उसका analysis किया जा सकता है
• कंपनी के भीतर आप मुख्य ग्राहकों की जानकारी, sales data, या संबंधित टीमों के साथ communication के ज़रिए भी यह समझ सकते हैं

profitability से जुड़ाव के उदाहरण

• अगर आप सीधे product बनाते हैं: यह analyze किया जा सकता है कि वह product कंपनी के revenue का कितना प्रतिशत लाता है
• अगर आप किसी indirect team में हैं (जैसे accessibility, localization):
  • नए customer segment हासिल करना
  • regulatory requirements पूरी करना
  • brand image बेहतर करना जैसे तरीकों से अप्रत्यक्ष revenue में योगदान देना
• ऐसा योगदान तभी मायने रख सकता है जब कंपनी के पास पर्याप्त गुंजाइश हो
  • उदाहरण: 2019 जैसे समय में, जब funding प्रचुर थी, value-based investment भी किए जाते थे
• बड़ी कंपनियों में growth का बहुत छोटा प्रतिशत भी बड़े revenue में बदल सकता है, इसलिए indirect काम भी मूल्यवान हो सकता है
  • उदाहरण: Google के मामले में, अगर customer base सिर्फ 2% भी बढ़े, तो अरबों डॉलर का revenue बन सकता है

सार्थक काम करते हुए स्थिरता कैसे पाएँ

• अगर आप जो काम करना चाहते हैं उसका profitability से सीधा संबंध नहीं है, तो बहुत अधिक profitable बड़ी कंपनी में काम करना महत्वपूर्ण है
• छोटी और कम profitable कंपनियों में value-driven काम अक्सर restructuring का आसान निशाना बन जाता है

दशमलव स्तर की value खोजने वाली बड़ी कंपनियों की रणनीति

• बड़ी कंपनियाँ कुल user base को थोड़ा सा भी बढ़ा सकने वाले 'अच्छे features' (जैसे accessibility, performance improvements) के ज़रिए profit कमाती हैं
• यही व्यावहारिक रणनीति है। इसके उलट अव्यावहारिक सोच कुछ ऐसी होती है:
  1. अच्छे features सभी के लिए अच्छे होते हैं
  2. अच्छी कंपनियाँ अच्छे features चाहती हैं
  3. मुझे बस एक अच्छी कंपनी ढूँढनी है
• ऐसी सोच कई engineers को burnout की ओर ले जाती है और बार-बार layoff के चक्र में फँसा देती है

सारांश

• सिर्फ इसलिए salary नहीं मिलती कि आप महत्वपूर्ण काम कर रहे हैं
• salary पाने के लिए revenue पैदा करना ज़रूरी है
• आपको समझना होगा कि आपका काम कंपनी के profit से कैसे जुड़ता है, और उस जुड़ाव को मजबूत करना होगा
• कुछ काम अप्रत्यक्ष रूप से revenue पैदा करते हैं। खासकर बड़ी कंपनियों में, छोटा योगदान भी बड़े revenue में बदल सकता है
• अगर आप profitability से असंबंधित काम पर ध्यान देना चाहते हैं, तो सफल टेक कंपनी में काम करना बेहतर हो सकता है

[roxie]

मोटे तौर पर सार यही है कि "जो काम तुम करना चाहते हो, वह मत करो; जो पैसे कमाए, वही काम करना चाहिए", है न?

लेकिन कुछ engineers किसी न किसी तरह यह समझा लेते हैं कि जो वे करना चाहते हैं, वही आखिरकार (लंबी अवधि में, परोक्ष रूप से, नतीजे में) पैसे कमाने वाला काम है, और अंत में वही करते हैं जो वे चाहते हैं.

यह वांछनीय strategy है या नहीं, यह अब भी मुझे साफ़ तौर पर समझ नहीं आता..

[cosine20]

यह Toss की दिशा के बिल्कुल उलट लगता है... Toss UX पर बहुत ज़्यादा ध्यान देते हुए भी अच्छा कर रहा है।

[tequila]

बाकी सभी तत्वों को पूरी तरह हटा दें और सिर्फ पैसों को देखें,
Toss की शुरुआत 2013 में हुई थी और पिछले साल उसने "पहली बार" "वार्षिक लाभ" हासिल करने में सफलता पाई।

[ztaka]

यह Toss से भी बड़ी कंपनी की कहानी है~

[ddots]

Toss के लिए UX सीधे तौर पर survival से जुड़ा है
लेकिन इस लेख से अलग नज़रिए से देखें, तो मुझे नहीं पता कि वह कंपनी revenue को अच्छी तरह pursue करती है या नहीं

[ephesian]

Toss के लिए UX में भिन्नता ही सीधे revenue और survival का मतलब है।
अगर वह commercial banks या दूसरे fintech apps के समान स्तर की संतुष्टि पर ही रुक जाए, तो उसे सफल नहीं कहा जा सकेगा.

[kaykim]

क्या यह इसलिए नहीं है कि Toss की conversion rate सीधे performance में बदलती है? साथ ही, कंपनी अभी listed भी नहीं है, इसलिए फिलहाल अगर आप growth में योगदान दे रहे हैं, तो आपका काम सीधे revenue से जुड़ा न हो तब भी चलता है.

शायद इसी वजह से लेख के बीच में यह कहा गया था कि कंपनी पैसा कैसे कमाती है, इसे देखना चाहिए.

[studydev]

जब मुझे यह समझ नहीं थी, तब 1 करोड़ की सैलरी का आधा भी पाना मुश्किल था, लेकिन यह समझने के बाद मेरी सैलरी कई करोड़ तक पहुंच गई। इसे समझना या न समझना पूरी तरह आपकी अपनी क्षमता पर निर्भर है। वैसे, यह तभी पता चल सकता है जब आप खुद जानने की कोशिश करें; कोई आकर आपको इसकी जगह समझाकर नहीं जाएगा.

आपको यह समझते हुए काम करना चाहिए कि आप जो काम कर रहे हैं, वह कितनी value और revenue पैदा करता है।

[jjw951215]

उससे ज़्यादा, मैंने शायद ऐसे मामले ज़्यादा देखे हैं जहाँ ऊपर से जैसा कहा गया वैसा सब करते-करते डेवलपर का तन-मन दोनों थक गया,
और प्रोडक्ट मेंटेनेंस करना नामुमकिन Frankenstein product बन गया..

हक़ीक़त शायद इन दोनों के बीच कहीं होगी।

[aer0700]

लगता है, अच्छी कंपनी किसे कहें, यही सवाल है।

[madsyntst]

इंजीनियर सीधे तौर पर revenue पैदा करने वाली भूमिका में नहीं होते, इसलिए कंपनी में उनकी position आम तौर पर कंपनी से जाने वाली लागत को कम करने पर केंद्रित हो जाती है। इस लागत में समय की लागत भी शामिल होती है.

....लेकिन management करने वाले लोग उस विशेषता को समझ नहीं पाते, ऐसा कहें तो.

[ethanhur]

कोरिया में Baegi Hong प्रतिनिधि ने भी "डेवलपर भी कंपनी के संगठन के सदस्य हैं" शीर्षक वाले लेख में इसी तरह की बात कही थी, और मैं उससे सहमत हूँ।

https://thestartupbible.com/2024/03/…

[GN⁺]

Hacker News की राय

• "सफल tech कंपनियों में engineering काम की value इस आधार पर तय होती है कि वह कंपनी के लिए कितना पैसा कमाता है" — इस राय के बारे में, मेरे अनुभव में ऐसा नहीं है

  • ज़्यादातर executives non-technical होते हैं, और engineering को asset नहीं बल्कि threat की तरह महसूस करते हैं
  • engineering को interchangeable commodity की तरह treat किया जाता है, और engineers के contribution को मान्यता नहीं मिलती
  • जब non-technical executives जगह बना लेते हैं, तो engineers के लिए executive पदों तक promote होना मुश्किल हो जाता है

• जब कंपनी एक तय scale तक पहुँच जाती है, तो पैसा कमाना एक social construct बन जाता है

  • "how to get promoted" वाला लेख बड़े संगठनों की reality को बेहतर समझाता है
  • A/B test से revenue साबित किया गया था, लेकिन management बदलते ही test बेकार हो गया
  • अभी बहुत-सी कंपनियाँ GenAI अपना रही हैं, लेकिन उससे वास्तव में पैसा नहीं कमा रहीं

• "अगर आपका काम कंपनी के profit से साफ़ तौर पर जुड़ा नहीं है, तो आपकी position अस्थिर है"

  • मेरे अनुभव में, सिर्फ salespeople ही profit से स्पष्ट रूप से जुड़े होते हैं
  • बाकी कर्मचारी cost के रूप में देखे जाते हैं
  • कंपनी के profit पर ध्यान देने के बजाय, अपने direct manager की success पर ध्यान देना चाहिए

• Mackenzie का analysis सच का एक पहलू दिखाता है, लेकिन यह सरल बना देता है

  • अगर आप ऐसी कंपनी में काम करते हैं जो सिर्फ dividends को ही value मानती है, तो आपको वहाँ से निकल जाना चाहिए
  • aviation industry regulation के बिना profit नहीं कमा पाती
  • software की भी ऐसी ही ज़िम्मेदारियाँ हैं, और उसे safety और security में invest करना चाहिए

• मैं 25 साल में बने product पर काम करता हूँ, और product की longevity सुनिश्चित करने के लिए काम करता हूँ

  • top management को उसकी value "बेचना" भी मेरे काम का हिस्सा है
  • technical debt को ठीक करना चाहिए, लेकिन उससे होने वाले financial improvement को साफ़ तौर पर समझाना भी ज़रूरी है

• "सफल tech कंपनियों में engineering काम की value इस आधार पर तय होती है कि वह कंपनी के लिए कितना पैसा कमाता है" — इस राय के बारे में, ज़्यादातर बड़ी tech कंपनियों में ऐसा नहीं होता

  • high-profit product पर होना ज़रूरी नहीं कि promotion में मदद करे

• बड़ी organizations में समस्या यह है कि व्यक्ति यह नहीं देख पाता कि उसका काम organization की success में कैसे contribute करता है

  • organization को social relationships से बनी संरचना के रूप में देखा जाता है

• बड़ी tech कंपनियों के corruption और selfishness से बचने के लिए मैंने university और छोटे startup में काम करने का फ़ैसला किया, लेकिन department को funding नहीं मिली

• इस article ने मुझे बहुत झटका दिया

  • मैं उन products/projects पर काम करता रहा जो ज़्यादा revenue नहीं लाते थे, इसलिए career growth को लेकर असंतोष रहा
  • मुझे revenue पैदा करने वाले काम पर ध्यान देना चाहिए था

• मैंने resource-constrained environment में काम किया है, इसलिए लगातार पैसा लाते रहने पर ध्यान देना स्वाभाविक लगता है

[kaykim]

नीचे वाली बात को छोड़कर:
“अर्थपूर्ण काम करते हुए स्थिरता भी पाने का तरीका
अगर आप जो काम करना चाहते हैं उसका profitability से सीधा संबंध नहीं है, तो किसी बहुत अधिक profitable बड़ी कंपनी में काम करना महत्वपूर्ण है
छोटी और कम मुनाफ़े वाली कंपनियों में value-based काम restructuring का निशाना बनना आसान होता है”

मुझे यह बात ज़्यादा persuasive लगती है

“जब कोई कंपनी एक निश्चित आकार तक पहुँच जाती है, तो पैसा कमाना एक social construct बन जाता है. how to get promoted नाम का लेख बड़े संगठनों की वास्तविकता को ज़्यादा अच्छी तरह समझाता है”

[roxie]

आपके विचारों के लिए धन्यवाद!

[duddnd649]

पूरा लेख इस धारणा पर आधारित है कि “केवल वही काम मूल्यवान है जो सीधे revenue से जुड़ा हो”, लेकिन वास्तव में कई कंपनियों में revenue का निर्धारण short-term revenue + मध्यम-से-दीर्घकालिक cost reduction + risk management के योग से होता है।
technical debt को कम करना, accessibility सुधारना, performance सुधारना जैसी चीज़ें short-term KPI में ‘सीधी sales’ जैसी नहीं दिखतीं,
लेकिन मध्यम अवधि में ये वास्तविक cost reduction, incident risk में कमी, development productivity में वृद्धि, और customer retention में सुधार जैसे रूपों में revenue पर बहुत बड़ा असर डालती हैं।

खासकर technical debt की प्रकृति ऐसी होती है कि जैसे-जैसे वह जमा होती है, incident cost, development lead time, और manpower risk तेज़ी से बढ़ते हैं; इसलिए उसे छोड़ देने पर profitability गिरती है।
management accounting के नज़रिए से, “debt removal = future cost reduction = वास्तविक revenue increase” है।

और यह हर कंपनी में पूरी तरह अलग होता है।
किसी कंपनी में technical debt को हल करना ही मुख्य business leverage होता है,
किसी कंपनी में नए features का development अधिक महत्वपूर्ण होता है,
और किसी कंपनी में regulatory compliance ही revenue की अनिवार्य शर्त होती है।

“engineer को केवल वही काम करना चाहिए जो सीधे revenue से जुड़ा हो” — यह बहुत ज़्यादा सरलीकृत नज़रिया है,
जबकि वास्तविक corporate operations सीधे revenue + cost reduction + risk prevention + long-term growth potential के संतुलन पर चलते हैं।

असल समस्या तो तब होती है जब engineer इन ‘कड़ियों’ को ठीक से समझा नहीं पाते,
या कंपनी इन्हें evaluation metrics के अनुरूप दोबारा परिभाषित नहीं करती।

संक्षेप में,
‘जो काम सीधे revenue से नहीं जुड़ा → बेकार’ नहीं,
बल्कि,
‘वह काम revenue, cost, और risk को किस माध्यम से प्रभावित करता है, यह परिभाषित नहीं है → यही समस्या’
है।