- Engineers की रोज़मर्रा की ज़िंदगी और career trajectory काफी हद तक इस बात पर निर्भर करती है कि उनकी salary sales/marketing, research & development, या maintenance में से किस budget से आती है
- Sales/marketing budget की engineering पैसे के करीब होती है और performance मापना आसान होता है, लेकिन इससे stack ranking और internal competition culture पैदा हो सकता है
- Research & development budget product organization के तहत सबसे ज़्यादा engineers को hire करता है, और short-term experiments की बजाय quarter से ज़्यादा की long-term value और asset creation को महत्व देता है
- Maintenance budget को cost optimization target माना जाता है, और sysadmin, पुराने systems चलाना, कुछ platform engineering, और internal tools का काम इसमें आ सकता है
- अगर आप जानते हैं कि आपका काम किस budget में आता है, तो आप growth work में बार-बार बदलाव, research & development में long-term investment, और maintenance की low priority को career decisions में शामिल कर सकते हैं
तीन budgets engineering work को बांटते हैं
- Software engineering salaries मोटे तौर पर तीन budgets में से किसी एक से आती हैं
- Sales/marketing
- Research & development
- Maintenance
- Budget की प्रकृति engineer के day-to-day working style और career direction को प्रभावित करती है
- Career vision या positioning के बारे में सोचते समय यह distinction उपयोगी हो सकता है
Sales/marketing budget: मापे जा सकने वाले immediate results
- Growth organization में आने वाली engineering के results को quantify करना आसान होता है
- कुछ काम करने पर metrics ऊपर जाते हैं—यह structure relatively clear होता है
- इस category में growth engineer, sales engineer, devrel जैसी roles आती हैं
- Existing product को बेहतर sell कराने में मदद करना
- लोगों को features के बारे में बताना
- Buyers को tools अपने workflow में adopt करने में मदद करना
- Company की expectation immediate impact की होती है
- इसका advantage यह है कि return on investment समझना आसान होता है, और काम सीधे revenue से जुड़ा होता है
- Measurement आसान होने की वजह से लोगों की आपस में comparison भी आसान हो जाती है
- Employees के बीच stack ranking बन सकती है
- साथ मिलकर problem solve करने की culture की बजाय internal competition culture मजबूत हो सकता है
- Work rhythm आम तौर पर short-term focused होता है
- अगला experiment
- अगला customer
- अगला marketing trend पीछा करने जैसा सिलसिला चलता रहता है
- Company इस budget में लगाए गए पैसे से बनने वाले multiples के आधार पर value देखती है, और optimization के process में revolving door effect पैदा हो सकता है
Research & development budget: समय के साथ जमा होने वाली assets
- Research & development, यानी R&D, सबसे ज़्यादा engineers को employ करने वाला area है
- आम तौर पर product organization के तहत होता है
- बड़ी companies में वास्तविक research organization या science organization हो सकती है
- इस category में product engineer, researcher, architect जैसी roles शामिल हैं
- Company जो बेचती है उसे बनाना
- या अगर सही से काम करे तो company जो बेच सकती है, उस संभावना को explore करना
- Company की expectation समय के साथ होने वाली growth की होती है
- Environment relatively ज्यादा शांत होता है
- Existing users को retain करने और नए users को attract करने वाले features के बीच balance देखा जाता है
- Signup के बाद actual usage तक ले जाने वाली activation बढ़ाने वाले features बनाते हुए growth की तरफ झुकाव हो सकता है
- कभी-कभी नई product lines explore करते हुए research की तरफ भी झुकाव होता है
- जिन companies में proper research department होता है, वहां कुछ लोग ऐसे ideas पर भी काम करते हैं जो कई सालों तक productized नहीं होंगे
- Research & development असल में दो अलग-अलग budgets को एक category में बांधने जैसा है
- Development और research अलग हैं
- लेकिन common point यह है कि दोनों long-term outcomes पर focus करते हैं
- जिस सबसे छोटी अवधि पर ध्यान दिया जाता है, वह quarter level की होती है
- Engineer का work एक asset बनने के लिए design किया जाता है, ताकि वह आने वाले कई सालों तक value दे सके
- छोटे experiments उस process के stepping stones होते हैं
- Performance measurement मुश्किल है, लेकिन company इस काम को investment के रूप में देखती है
- Assumption यह है कि product बेहतर होगा तो sales और retention भी बेहतर होंगे
Maintenance budget: वह cost जिसे कम करना चाहते हैं
- Maintenance आम तौर पर development work के अंदर absorb होती रही है
- इस budget की चाहत cost optimization है
- sysadmin, पुराने systems को चालू रखने वाले लोग, और कभी-कभी platform engineer इस category में आते हैं
- Company इस काम को pure cost मानकर minimize करना चाहती है
- कई companies में maintenance roles product development के अंदर फैली हुई होती हैं
- यह ऐसा काम है जिसे ज्यादा importance नहीं मिलती
- लेकिन जब किसी को काफी असुविधा होने लगती है, तो आखिरकार इसे handle किया जाता है
- Company engineers को NFR, यानी non-functional requirements, पर काम करने का समय देने को भी किसी खास benefit की तरह package कर सकती है
- जैसे हर sprint में annoying काम निपटाने के लिए 2 दिन देना—ऐसी situation इसी में आती है
- Internal tools बनाना भी इस category में आ सकता है
- Company चलाने में मदद करने वाला admin dashboard तो होता है
- लेकिन उसे हमेशा पर्याप्त priority नहीं मिलती
Budget position career decisions के लिए क्या संकेत देती है
- काम किस budget में आता है, यही engineer का day-to-day experience तय करता है
- Growth work measurable होता है और उसमें बदलाव अक्सर होते हैं
- Research work ज्यादा शांत होता है, लेकिन outcomes धुंधले होते हैं
- Development work को valuable माना जाता है और वह समय के साथ जमा होता है
- Maintenance work को ऐसा target माना जाता है जिसे कभी भी काटा जा सकता है
1 टिप्पणियां
Hacker News की टिप्पणियाँ
आपकी सैलरी किस budget item से आती है, सिर्फ यह नहीं; संगठन software development को कैसे value करता है, यह जानना भी आपके career पर बड़ा असर डालता है
अगर कंपनी development time बेचने वाली consulting company है, तो customer relationship skills और जल्दी से ठीक-ठाक software बनाने की क्षमता की कद्र होती है; अगर वह software product बेचने वाली product company है, तो software बनाने और चलाने की क्षमता की कद्र होती है
अगर business कोई और है जिसमें software आंशिक रूप से शामिल है या software से enabled है, तो budget के अंदर delivery करने की क्षमता की कद्र होती है, लेकिन मंच का मुख्य किरदार बनना मुश्किल होता है
दिलचस्प बात यह है कि यह विभाजन लेखक की बताई तीन categories से अच्छी तरह मेल खाता है: consulting sales/marketing से, product research & development से, और बाकी maintenance से correspond करता है
software startup में senior engineer होने पर star treatment, stock options और वैसी office culture मिली जिसकी उम्मीद की जाती है; और IT consulting company में senior consultant होने पर अच्छे PowerPoint बनाने वाले salesperson जैसा होना पड़ता था
billable hours को maximize करना पड़ता था, और project को जल्दी खत्म करना या minimum code से खत्म करना सही नहीं माना जाता था
अभी मैं कहाँ हूँ, इसका अंदाजा आप लगा सकते हैं
यह कोई ऐसा boxed product नहीं है जिसे खरीदा जा सके; आम तौर पर कई systems को बहुत ज्यादा customize करके जबरदस्ती जोड़ा गया होता है, और वे अक्सर शुरू से साथ काम करने के लिए design नहीं किए गए होते
हर company का तरीका भी अलग होता है
मुझे यह काम पसंद है, और मैं कई departments के पार पूरे system के बारे में सोचने में मजबूत हूँ
समस्याओं से रास्ता निकालने के लिए internal politics की knowledge भी चाहिए, और ठीक उसी जगह मेरी value बनती है
programmer के रूप में भी मैं ठीक हूँ, लेकिन programming को career बनाने वाले लोगों की expertise तक नहीं पहुँचता
बाकी दो मामलों में आप ऐसा cost बन जाते हैं जिसे minimize या eliminate किया जाना है
company का core product बनाने पर ही आप revenue लाने वाला asset बनते हैं
मैंने भी यह गलती की थी, और मुझे meeting में बुलाकर “कैसा चल रहा है” पूछा गया, फिर तुरंत कहा गया “details मत बताइए”
नंबर 3 में काम करने का मतलब है boring और भुला दिए जाने वाले solutions बनाना; और आप ऐसे solutions बना सकते हैं जो technically सही हों, लेकिन politically suicide हों
उदाहरण के लिए, अगर आप hardware manufacturer में काम करते हैं, तो मुख्य किरदार होना तो दूर, सम्मान पाना भी मुश्किल है
software staff को cost माना जाता है, ऐसी cost जिसे संभव हो तो चुकाना ही न पड़े
समय पर और budget से कम में delivery कर दें, तब भी आप notice नहीं होते; उलटा attention से बाहर हो जाते हैं
आधुनिक tech culture में यह समझना मुश्किल है कि maintenance को हमेशा list में सबसे नीचे रखा जाता है, budget काट दिया जाता है, और उसे सही budget नहीं मिलता
20 साल में कई companies में काम करते हुए मैंने ऐसी बातें लगातार सुनी हैं, लेकिन शायद ही कभी सहमत हुआ हूँ
company बाज़ार में उतारने के लिए नए features चाहती है, लेकिन साथ ही यह भी चाहती है कि service ठीक से चले
layoffs या hiring freeze के समय भी मैंने देखा है कि SRE प्रकृति वाली organizations R&D organizations की तुलना में बेहतर टिकती हैं
हालांकि एक company में culture ऐसा हो गया था कि लगातार नई चीज़ें बनाना reward होता था और existing चीज़ों को maintain करना नहीं; इससे internal tools के लगातार migration, ongoing deprecation, और आधे-अधूरे migrations चलते रहे
product बनाने वाले लोग promotion पाकर अगले portfolio work पर चले जाते, तो जो नया और चमकदार था वह भी जल्द ही उपेक्षित हो जाता और नई team फिर replacement बना देती
6 साल में एक internal tool को चार बार नए internal tool से replace किया गया, और users चारों tools में बिखर गए
इसे सिर्फ execution failure भी कहा जा सकता है, लेकिन यह कहने वाली culture कि business maintenance को value नहीं देता, बहुत harmful है और self-destruction की ओर ले जाती है
मान लीजिए हर बार जब developer नया feature जोड़ता है, तो वह 1,000 डॉलर का disk space इस्तेमाल करता है और 10,000 डॉलर का नया revenue बनाता है
system administrator बड़ा file server खरीदता है, और मान लीजिए एक नया server 500,000 डॉलर का है
bureaucratic organization में system administrator developers को disk space cost internally charge करता है, और जब नए file server की ज़रूरत होती है तो पैसा पहले से तैयार होता है
अच्छी तरह चलने वाली और कम bureaucratic organization में management समझती है कि 500,000 डॉलर का bill 5 million डॉलर लौटाने वाले project को संभव बनाता है, और उसे खुशी से देती है
खराब तरीके से चलने वाली organization में management 500,000 डॉलर को महंगा और किसी specific project से न जुड़ा मानकर चिढ़ जाती है, और system administrator अगले उस व्यक्ति से 500,000 डॉलर मांगता है जिसे 1,000 डॉलर का disk space चाहिए; वह मना कर देता है
आखिर में system administrator request reject करता है और developers को log retention 7 दिन से घटाकर 3 दिन करने के लिए मनाता है, और कुछ ही समय में management को system administrator के बारे में bad feedback सुनने को मिलता है
आपने जिस environment का वर्णन किया है, वह तो बल्कि इस reality जैसा दिखता है कि business maintenance को value नहीं दे रहा था
“maintenance सबसे नीचे है” वाली बात कोई prescription नहीं, बल्कि वास्तव में क्या हो रहा है उसका description ज्यादा लगती है
लेखक ने यह analyze नहीं किया कि ऐसा क्यों है, या कोई दूसरा approach business के लिए बेहतर होगा या नहीं, लेकिन अगर कोई चीज़ों के सही चलने और high quality को value देता है तो naturally अलग outcome चाहेगा
लेकिन अगर बहुत कम companies ही ऐसा behave करती हैं, तो likely है कि इसके पीछे incentive alignment से जुड़ा कोई reason हो
क्योंकि customer को maintenance नहीं बेचा जा सकता; बेची जा सकने वाली चीज़ features ही हैं
developer के नजरिए से भी maintenance वह काम है जिससे बचना चाहेंगे
résumé में maintenance को चमकदार item की तरह डालना मुश्किल है, और हर कोई achievements, shipped projects, और modern technologies देखना चाहता है
customers की अपेक्षित level पर service को चालू रखना सभी के लिए high priority है
कोई company SRE को इतना cut नहीं करना चाहती कि outages की वजह से customers छोड़कर चले जाएँ
लेकिन SRE traditional company के operations, यानी service देने के लिए unavoidable function, के ज्यादा करीब है; यह उस maintenance से अलग है जिसे जितना हो सके टाल दिया जाता है
इस नज़रिए से maintenance में technical debt reduction, internal tools improvement, experiment iteration time घटाना जैसी चीज़ें आती हैं, और मुझे लगता है कि product impact की तुलना में ऐसे कामों को अक्सर undervalue किया जाता है
लेख दूसरी चीज़ पर है, और कहता है कि category 3 में जाना career suicide है
अगर आप ‘promote or out’ type के व्यक्ति नहीं हैं, तो category 3 में समय बिताने पर भी विचार किया जा सकता है
बेशक software इस्तेमाल होते ही पुराना होने लगता है, इसलिए जो लोग सोचते हैं कि वे category 2 में हैं, वे भी असल में अपना ज़्यादातर time category 3 में और बहुत छोटा हिस्सा category 2 में खर्च कर रहे हो सकते हैं
फिर भी budget साल में एक बार, ज्यादा से ज्यादा कुछ बार ही allocate होता है, इसलिए अगर उस समय आप category 2 में classified जगह पर हैं तो आप अभी भी बेहतर position में हैं
“Sales/Marketing” और “R&D” वे categories हैं जो company की annual report में दिख सकती हैं, लेकिन maintenance उस तरह से नहीं दिखता
company के financial statements पढ़ना अच्छा रहेगा
“cost of revenue” या COGS, “G&A”, acquisitions जैसे one-time cost items दिखेंगे, और हर item की dynamics अलग होती है तथा companies के हिसाब से अलग तरह से काम करती है
जिस industry में आप हैं उसकी business structure समझना भी जरूरी है
इस thread में भी कई बार यह judge किया जाता है कि कोई company software engineering को “value नहीं देती”, लेकिन 70% gross margin वाली social media company की तुलना 15–20% के स्तर वाली auto/aviation company से करना naive है
स्वाभाविक है कि एक industry ज्यादा engineers hire कर सकती है, ज्यादा pay कर सकती है, और ज्यादा swag व benefits दे सकती है
एक ही company के अंदर भी कुछ product lines और functions को long-term investment मिलता है, और कुछ product lines की margins दूसरों से ज्यादा होती हैं
budget के आधार पर software product पर खर्च की जा सकने वाली रकम बहुत बदलती है
engineers को अपने काम के बारे में सोचते समय company की finances भी साथ में देखनी चाहिए
company कोई charity या church नहीं, बल्कि एक business है जिसे cash flow, revenue, long-term strategy और product development cost के बीच balance बनाना होता है
यह लेख भी अच्छा है, लेकिन patio11 का लेख भी cost centers और profit centers में अच्छे से बाँटकर समझाता है
वह convincingly बताता है कि profit center से जुड़े रहना क्यों जरूरी है, और अगर आपने नहीं पढ़ा है तो उसमें और भी अच्छा content है
https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
rule number 2 है कि उस profit center के अंदर ऐसा role लें जो sustained profitability से reliably जुड़ा हो
यह जरूरी नहीं कि मैं सीधे पैसा कमाऊँ, लेकिन यह साफ होना चाहिए कि अगर मैं काम रोक दूँ तो पैसे पर direct impact पड़ेगा
थोड़ा अलग विषय है, लेकिन मैंने कुछ साल पहले Swizec की लिखी Serverless Handbook बहुत उपयोगी पाई थी, और लंबे समय से उसका thoughtful और insightful email newsletter पढ़ना enjoy किया है
वह “करते हुए सीखना / public में सीखना” camp में firmly है, और सीखने की process share करने का काम बहुत अच्छे से करता है
follow या subscribe करने की strongly recommendation करता हूँ
ऐतिहासिक रूप से software engineering IT function का हिस्सा थी, और IT की शुरुआत accounting से हुई थी
मशीनों के आने से पहले “computer” सचमुच किसी व्यक्ति की job role हुआ करती थी
आज भी कई businesses में accounting अब भी software का मुख्य driver और budget का स्रोत है
असल में budget की चार categories होती हैं
नंबर 1 research and development है, जिस पर आम तौर पर खास tax treatment और tax credits लागू होते हैं
नंबर 2 sales/marketing है, जिसमें pre-sales engineers और कभी-कभी implementation work शामिल होता है
नंबर 3 maintenance है, यानी वे developers जो bugs fix करते हैं और non-R&D code work करते हैं, जो आम तौर पर खास tax treatment या credits के eligible नहीं होता
नंबर 4 hosting services, PaaS, SaaS में operations है, जिसमें आम तौर पर software engineers की salary कुछ हद तक शामिल होती है
पैसा किस budget से आ रहा है और आप कौन-सा काम कर रहे हैं, इसके tax impact को समझना बहुत जरूरी है, और scale बढ़ने पर यह कहीं ज्यादा जटिल हो जाता है
मुझे लगता है profit center बनाम cost center model बेहतर है
आदर्श रूप से हर department revenue और costs दोनों के लिए responsible होता है
अगर उसे measure नहीं किया जा सकता, तो वह KPI की समस्या है
KPI cost-centric होकर गलत तरह से align हो सकते हैं, लेकिन इससे वह department खुद cost center नहीं बन जाता
हालांकि R&D distinction जुड़ना मुझे अच्छा लगा
maintenance-focused teams को भी maintenance cost घटाने के लिए R&D करना चाहिए, ठीक वैसे ही जैसे अच्छी sales team sales profit बढ़ाने के लिए R&D करती है
वे अलग-अलग insights देते हैं और एक-दूसरे को complement कर सकते हैं
जिन companies में मैं रहा, उनमें growth engineering salary marketing budget से नहीं आती थी
“maintenance budget” नाम की कोई अलग चीज भी नहीं थी; सब बस research and development/engineering था
team या role के हिसाब से expectations बहुत अलग हो सकती हैं, लेकिन यह budget का मुद्दा नहीं, बल्कि इस बात पर निर्भर है कि company goals को कैसे track करती है
या तो आप अभी पैसा कमा रहे हैं, या long-term value बना रहे हैं, या existing product में धीरे-धीरे डूब रहे हैं—इन तीनों में से एक