I think profit center vs cost center is a better model.
Software engineering salaries come from one of three budgets
31–40 of 265 posts
Re: Software engineering salaries come from one of three budgets
#32I think profit center vs cost center is a better model.
I like the addition of the R+D section because I think a good Maintenance oriented team should be doing R+D related to bringing their maintenance costs down the same way a good sales team would be doing R+D to bring their sales profits up.
Re: Software engineering salaries come from one of three budgets
#33What if you are one of the only few who know how to maintain a Cobol system for a bank? Aren't you very valuable?
No. Because COBOL maintenance is outsourced to the third world.
[0] https://ezali.substack.com/p/interviewing-my-mother-a-mainfr...
Re: Software engineering salaries come from one of three budgets
#34Re: Software engineering salaries come from one of three budgets
#35Earlier quoted context omitted.
It's different security. Like in game of thrones in that scenario you're as safe as your boss is, which will depend on the evolving politics. Even founders get housted sometimes, but I'd agree that I'd choose your scenario over others.
I can totally attest to that. I once worked for a company where the CTO that was 3-4 levels above hired me directly and I reported to him. It felt very empowering and motivating because I was working on what he considered a critical area for the day-to-day of the company. Once he was gone, I suddenly was a huge problem to all the middle managers that disagreed with the CTO. If you happen to be in that situation, bett…
Re: Software engineering salaries come from one of three budgets
#36It doesn't matter where you work at, when layoffs come, the executives will care about location, timezones, desire on finishing the current project you are working on, (maybe) performance etc. There are too many criteria and no clear pointer on what is safe and what isn't. Being part of a layoff and also watching other colleagues coming from other Big Tech companies share their experiences, you'd see people laid off…
The higher up the org chat you report to is, the safer your position becomes. At one job, I reported directly to the still-reigning cofounder of a long lived company. Never have I felt a stronger sense of job security than that.
I don't want to start a flame war but it's much easier to replace a manager than a technical person, a technical job is boring and most people don't want to do it while management relies more on soft skills, something that most people can do at a minimum level. Being a manager who's always employed is more about social connections, if you don't befriend the right people your job security might also be at risk.
Re: Software engineering salaries come from one of three budgets
#37All the companies that pay very well such as on https://levels.fyi/2023/ are profit centers encouraging investment in talent, competing for the best across companies because they know its worth it. Each hire even at extremely competitive wages will make back their salary manyfold if they're successful.
Re: Software engineering salaries come from one of three budgets
#38In 20 years and several different companies I have always heard this but never agreed with it.
Sure, the company wants new features to market, but the company also wants things to freaking work.
During layoffs and hiring freezes I have seen SRE type orgs fair better than their R&D siblings.
In only one place I worked was there this culture shift of always having to keep building new things and not reward maintaining old things. It actually shifted to that culture while I was there. Constant migration to new internal tools, constant depreciation, and half baked migration stories. After the people who built the product get their promotion they go off to the build their next portfolio piece. The new shiny quickly becomes unmaintained and a new team comes and builds yet another replacement. In 6 years one internally built tool was replaced 4 times with new internal tools, with users spread across all four.
You can say that this was just poor execution, but in reality saying maintenance is not valued by the business is incredibly toxic and leads to self destruction.
Re: Software engineering salaries come from one of three budgets
#39What if you are one of the only few who know how to maintain a Cobol system for a bank? Aren't you very valuable?
People get overly excited by some "last man standing" success stories of a COBOL developer based in US of A. My only encounter with COBOL developer was a freshly graduated girl based in post Communist country, her earnings were something around 25k EUR annually. I pointed out that her career might be something of a dead end but she was more like "a job is a job". Oh, and they were using some dinosaur version control…
Also if there is some legacy cobol system, many managers are incentivised to gather a new team to write a replacement with some modern technology stack. Cobol is definitely a dead end for the career.
Re: Software engineering salaries come from one of three budgets
#40Maybe someone who knows more about this stuff can enlighten me. From what I've heard there are actually only 2, opex and capex. If I recall correctly capex is better for the business because of how it gets treated in the accounting stuff. This naturally gives rise to the feature factory style work of a lot of dev jobs. Some reason like they can record capex spend as an asset with depreciation. Is this true?
Organisations tend to move away from CapEx where possible, because of two reasons:
1. management decisions require accounting know-how and accounting 'magic' when CapEx gets involved
2. large upfront investments are much less flexible and more risky than day to day expenses
Let me illustrate.
Your marketing department is investing into new on-premises IT system to run promotions and campaigns. They are spending $1M dollars upfront for the installation, equipment purchase, system licenses and so on - all these expenses will be booked under CapEx. That marketing department also pays day to day salaries, and some other regular expenses, which all go to their OpEx.
Let's say right after system is launched and everyone in Marketing starts using it there is a 30% growth in # of leads they bring, and resulting 10% growth in sales. But what does that mean, financially? Was the project a success? 10% growth in sales might not cover full cost of our $1M investment, so for how long would we need to keep up the growth in order to see returns? What growth numbers do we need to keep seeing? What if we decide to adjust and purchase more hardware and licenses as we go? What if system unexpectedly required us to hire extra people in marketing, bumping up department's OpEx?
All that requires calculation, recalculation, excel spreadsheets crunching, more spreadsheets, and a few fat decks of powerpoints just to align all the decision makers around the numbers and understand what worked, financially.
Compare that to marketing department buying access to the same system in cloud via monthly subscription (let's say they start paying $10K total monthly - these will go to your OpEx). Any growth is now super straightforward to assess - you've invested $10K, you got 10% more sales that month, and you can now deduct all the combined OpEx from that number and see if you are still profitable after bringing the new system in. That's a reason #1.
Accounting and decision making complexity is not the only reason to prefer OpEx. Note that accountants came up with smart ways to make CapEx behave more 'OpEx-y' - for example, this $1M in the books will be spread across many months or years by using depreciation across system lifetime, so that upfront investments can be comparable to daily expenses. But the same way you are not buying a local car each time you arrive on a vacation somewhere, businesses don't want to have hands tied in large investments - oftentimes renting something is preferred, and business people will still call their decision to rent instead of buying "switching from CapEx to OpEx". That's a reason #2.