Software engineering salaries come from one of three budgets

In addition to knowing which bucket your salary comes from, I think it is also useful to know how your organization values building software. Because this affects your career just as much.<p>* Is your company selling software development hours (consulting)? I&#x27;m this car you&#x27;ll be valued for client relations skills and the ability to bang out acceptable software.<p>* Is your company selling a software product (product company)? In this case you&#x27;ll be valued for your ability to build and run software.<p>* Is your company selling something else that has a software component or that software enables (pretty much every other company)? In this case, you&#x27;ll be valued for your ability to deliver on or below budget and you&#x27;ll never be the star of the show.<p>Funnily enough, these seem to map well to the three categories the author mentioned. Consulting to sales&#x2F;marketing, product to research and development, everyone else to maintenance.

I don&#x27;t understand our modern tech culture of saying maintenance is the last on the list; always getting chopped and cut; never getting a decent budget.<p>In 20 years and several different companies I have always heard this but never agreed with it.<p>Sure, the company wants new features to market, but the company also wants things to freaking work.<p>During layoffs and hiring freezes I have seen SRE type orgs fair better than their R&amp;D siblings.<p>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.<p>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.

&quot;Sales &amp; Marketing&quot; and &quot;Research &amp; Development&quot; are categorizations you may read about in companies&#x27; annual reports, but &quot;Maintenance&quot;?<p>I&#x27;d suggest you read your company&#x27;s financial statements. You&#x27;ll find headings like &quot;cost of revenue&quot; or COGS, &quot;General &amp; Administrative&quot; and others like one-off costs for mergers. All of these will have different dynamics, and in each company the dynamics may be different.

It&#x27;s also important to understand the business of the industry that you are in.<p>Many are judgmental (even within this thread) of some companies not &quot;valuing&quot; software engineering. It&#x27;s naive to compare social media companies that are making 70% topline margins to auto or airlines companies that are making ~ 15-20% . Of course one industry can hire more engineers, pay them better, give them more swag &amp; benefits.<p>Even within companies, some product lines and functions will be receiving long term investment. Some product lines may be higher margin than others. There will be a big difference in the money available for software products depending on the budget.<p>I encourage engineers to consider their business&#x27; finances when thinking about their job. The company is not a charity or a church -- it&#x27;s a business with cash flow, revenue &amp; a long term strategy that all has to be balanced with the cost of building the product.

I really like this, but patio11’s blog does a nice job as well. He breaks it down into cost centers and profit centers, and argues why you really want to be attached to a profit center.<p>Lots of other good stuff in here if you haven’t read it.<p><a href="https:&#x2F;&#x2F;www.kalzumeus.com&#x2F;2011&#x2F;10&#x2F;28&#x2F;dont-call-yourself-a-programmer&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.kalzumeus.com&#x2F;2011&#x2F;10&#x2F;28&#x2F;dont-call-yourself-a-pr...</a>

Tangent: Swizec authored a book I found very useful a few years ago (&quot;Serverless Handbook&quot;), and writes a thoughtful and insightful email newsletter I&#x27;ve enjoyed for many years. He&#x27;s firmly in the &quot;learn by doing &#x2F; learn in public&quot; camp, and does an excellent job sharing what he learns along the way. Highly recommended follow &#x2F; subscribe.

Historically software engineering was part of the IT function, which historically was born out of accounting, a computer literally was someone’s job, before a machine could do it.<p>Today, for many businesses accounts is still the main driver behind software, and also the budget.

There are actually four buckets:<p>1. Research and Development. Special tax treatment and tax credits usually apply to R&amp;D.<p>2. Sales&#x2F;Marketing - Pre-sale sales engineers, sometimes implementations<p>3. Maintenance. Developers that fix bugs and perform non-R&amp;D work on code that usually isn’t eligible for special tax treatment or credits.<p>4. In hosted services&#x2F;PaaS&#x2F;SaaS, operations usually carry some level of swe salaries.<p>Understanding the tax implications of which budget and what work is being done is really important, and gets much more complex as you grow.

I think profit center vs cost center is a better model.

No company I have ever worked for has had growth engineering salaries come out of the marketing budget. And there&#x27;s no such thing as a &quot;maintenance&quot; budget either. It is all simply R&amp;D&#x2F;engineering. Sure the expectations are very different depending on your team&#x2F;role, but that&#x27;s not a budget thing, and depends on how the company tracks its goals.

I&#x27;m having trouble with this framing. The buckets only make sense metaphorically, but is written literally. The &quot;laws&quot; only make sense literally, too.<p>For maintenance, if &quot;you&#x27;ll see this role smeared into product development&quot; and &quot;We give you a generous 2 days every sprint to take care of shit that&#x27;s annoying,&quot; the budget here is R&amp;D, not &quot;Maintenance.&quot;<p>Similarly, Growth and Developer Relation engineers are often (usually?) in the Product org.<p>If these roles are actually in the R&amp;D&#x2F;Product Development budget, the &quot;laws&quot; about budget management don&#x27;t apply cleanly enough that they can be a &quot;law.&quot;

What if you are one of the only few who know how to maintain a Cobol system for a bank? Aren&#x27;t you very valuable?

It doesn&#x27;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&#x27;t.<p>Being part of a layoff and also watching other colleagues coming from other Big Tech companies share their experiences, you&#x27;d see people laid off from literally everywhere: key projects, R&amp;D (I was part of), sales, high-performing etc.<p>It&#x27;s a financial decision, the cut NEEDS to happen once the higher ups have decided and you can be cut, for you as an employee, anything can happen.<p>Lots of R&amp;D people end up being on the chopping block as well because you could be suddenly in a very promising project, but that the company no longer cares about, because some executive above even the boss of your boss told it isn&#x27;t a priority.

Maybe someone who knows more about this stuff can enlighten me. From what I&#x27;ve heard there are actually only 2, opex and capex.<p>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?

Re: (US) Internal Revenue Code (IRC) Section 174<p>&quot;The Tax Cuts and Jobs Act was enacted more than five years ago, but certain changes under the legislation are only now coming into focus as taxpayers prepare their 2022 tax returns. In particular, there are significant changes as to the deductibility of certain research and experimentation expenses, as well as the ability to utilize net operating loss (NOL) carryforwards. These changes may result in greater tax liabilities for companies and may also affect certain qualified small business stock eligibility requirements&quot;.<p>ref&#x2F; <a href="https:&#x2F;&#x2F;www.cooley.com&#x2F;news&#x2F;insight&#x2F;2023&#x2F;2023-04-28-startups-rd-heavy-companies-higher-tax-2022" rel="nofollow">https:&#x2F;&#x2F;www.cooley.com&#x2F;news&#x2F;insight&#x2F;2023&#x2F;2023-04-28-startups...</a>

All 3 actually. Depending on what task I work on.<p>Sometimes the customers want a specific feature, sometimes we have an idea that we want to develop in the hopes of selling it later, and sometimes you need to work on maintenance. Which also gets paid by customers in our case.

Sales&#x2F;marketing don&#x27;t even exist when a product is first being built, but you&#x27;re getting paid... but your salary isn&#x27;t R&amp;D. The pace isn&#x27;t calm. The stakes are high. The target can pivot violently.<p>Your salary is coming from the Business Plan&#x27;s Capital Expenditure, as part of an initial round of investment needed to achieve the Business Goals. This is a marked difference from Operational Expenditure, which &quot;Maintenance&quot; is most often lumped under.<p>Whether your salary is CapEx or OpEx has a much larger impact on your ability to work freely and productively than what of these 3 (really 4) categories are.

&gt; Maintenance is always on the chopping block<p>I wonder if someone or someplace figured a way to make software maintenance and support to be better valued. It&#x27;s like, it&#x27;s reasonably easy to market and sell internally the start of a project and consume from some internal investment (CapEx like) budget to make it, but once you have done all of that was in scope, you delivered, it&#x27;s a lot harder to keep it going at the same steam and get budget for the continuous maintenance (OpEx like). Also, why it&#x27;s so hard to get promotions or market work in good maintenance.

As an aside, it seems that the $500K&#x2F;year jobs have dried up - at least I don&#x27;t see much of that on the &quot;Who&#x27;s hiring&quot;. Salary ranges seem to be more in the $100K - $200K range.

The analysis of maintenance budgets is depressingly accurate. Especially as tech companies get older (and they age surprisingly fast), it&#x27;s quite startling to see how most of them become organizationally indifferent to various small to medium glitches in established products.<p>I can see why a lot of people working in tech will focus weekend&#x2F;break energy on side projects (woodworking; solo sports; playing in a band) where exquisite craft is everything.

&gt;&gt; You&#x27;re only as good as the multiplier a company gets on pouring money into your bucket.<p>Well that&#x27;s why some places have sales people on commission. You set a fixed multiplier and let the sales person do their thing. You can still offer bonuses, but if one guy makes half the sales as another so what? He automatically gets paid half as much. Software supporting multiple sales people isn&#x27;t so individualized though.

It&#x27;s important I think to note the head fake that Google&#x27;s engineering pulled off when they developed site reliability as its own discipline.<p>It&#x27;s maintenance, but the argument they successfully sold to management was that if management planned to scale indefinitely, maintenance cost would also scale indefinitely <i>unless maintenance also had a budget for R&amp;D</i> to push up the ratio of services maintained to maintainers (and the authority to tell software engineering &quot;Yes, you built a new shiny thing, but it&#x27;s not shaped correctly yet to be maintainable so here is the pager, enjoy your 2:00 a.m. wake up calls to keep the money flowing&quot;).<p>This has, overall, worked pretty well for them given what they want to do. While maintenance is still a cost, it&#x27;s understood that they minimize that cost via R&amp;D, not cutting.

The article cleverly groups the budget in three categories:<p>- A first one that develops a product that creates a value for the company in the present(sales&#x2F;marketing).<p>- A second one that develops a product that will possibly create value for the company in the future(research&#x2F;development).<p>- And the last one that develops a product that created value for the company in the past and now has only to be maintained(maintenance).<p>Honestly I think that this division is a bit tautological. Everybody in the industry knows that maintenance project are bad and only are worth it if you&#x27;re making a good money working in them. Now in practice the hypothetical division between sales&#x2F;marketing and research&#x2F;development that the author proposes is pretty blurry and in my opinion doesn&#x27;t do a great service in categorizing the activity of a developer.

I disagree with the absolute framing of 2 and 3. They&#x27;re not wrong takes, but they&#x27;re highly dependent on the company stage.<p>For 2, it&#x27;s a feature factory below a certain size or market penetration. You will be valuable but you will be anything but calm and relaxed. Research doesn&#x27;t qualify, talking about Product here.<p>3, which is Platform and&#x2F;or maintenance is definitely unsexy until you are a scale up and your software sucks ass since you never maintained it and no amount of infrastructure can save it. Then to grow you become extremely important.<p>I think you want to consider the company size, the state of the product, and its market fit before making these assertions.<p>All three are the best and worst jobs to have, it just depends when and where you are.

One word of warning about the cozy R&amp;D department of a product org: you may suffer from the boiling frog syndrome. Little attrition and long-time continuity means everybody stays in their seat and there a few true career opportunities beyond seniority promotions (dev - senior dev etc). After 5-10 years you find yourself quickly at the end of your promotion trajectory and realize that much younger&#x2F;cheaper folks have the same role as you. This puts you at a disadvantage in salary negotiations and increases the risk of being let go. Project-driven orgs can be brutal environments, but there is always a possibility to climb up the ladder due to high churn.

Very closely related, this comes up on HN from time to time: &quot;Don&#x27;t Call Yourself A Programmer, And Other Career Advice&quot; <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=3170766">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=3170766</a>

Sounds like the Gartner RGT model<p><a href="https:&#x2F;&#x2F;www.gartner.com&#x2F;smarterwithgartner&#x2F;align-it-functions-with-business-strategy-using-the-run-grow-transform-model" rel="nofollow">https:&#x2F;&#x2F;www.gartner.com&#x2F;smarterwithgartner&#x2F;align-it-function...</a>

What about HR? HR Tech is not working on software to create new products (research and development) or on software to sell said products to other people (sales&#x2F;marketing), but it also isn&#x27;t maintenance.

Background is completely white and text unreadable, toggling &#x27;modes&#x27; fixes this but I presume its related to OSX and dark&#x2F;light mode.<p>Chrome Version 120.0.6099.109 (Official Build) (arm64)

I remember early advice in my career to always work for a revenue center not a cost center.<p>This was really helpful as having something that makes a firm money seems more easy to measure impact than a cost center.<p>The natural incentives seem to jive better. Revenue centers are supposed to increase and are a function of margin. So more salaries and expenses should lead to more revenue. Cost centers are supposed to decrease or stay the same. So always a pressure to cut expenses.

The only orgs I’ve not had mad stress have been research oriented, with the expectation that some things will pan out and others won’t.

&gt; Building internal tools can fall into this category. That unloved admin dashboard that runs the company but never quite gets priority.<p>Amazon: “we can build S3 - a service that millions use with no down time. But we can’t keep a simple website up to serve our internal employees come review time in April”

Another framing of this is whether companies treat their engineering organizations as a cost center or a profit center. Cost centers suppress salaries as much as possible optimizing the budget. There&#x27;s little growth within these companies which is why the zero-sum philosophy is passed down to their compensation strategy. Whereas profit centers encourage more and more investment as compounding profits come in from previous dividends. Growth is what powers everything, higher pay has a positive-sum gravitational pull on talent sustaining a flywheel for more profits to come in (hopefully).<p>All the companies that pay very well such as on <a href="https:&#x2F;&#x2F;levels.fyi&#x2F;2023&#x2F;" rel="nofollow">https:&#x2F;&#x2F;levels.fyi&#x2F;2023&#x2F;</a> 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&#x27;re successful.

Amazon: “we can build S3 - a service that millions use with no down time. But we can’t build a simple website to serve our internal employees come review time in April”

Lol! “ We give you a generous 2 days every sprint to take care of shit that&#x27;s annoying! Why aren&#x27;t you happy!??&quot;

I&#x27;m in sales&#x2F;marketing; bored out of my mind, so I&#x27;m studying to be in R&amp;D.

My salary comes from <i>Arachis hypogaea</i>.