* Is your company selling software development hours (consulting)? I'm this car you'll be valued for client relations skills and the ability to bang out acceptable software.

* Is your company selling a software product (product company)? In this case you'll be valued for your ability to build and run software.

* Is your company selling something else that has a software component or that software enables (pretty much every other company)? In this case, you'll be valued for your ability to deliver on or below budget and you'll never be the star of the show.

Funnily enough, these seem to map well to the three categories the author mentioned. Consulting to sales/marketing, product to research and development, everyone else to maintenance.

In 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.

I'd suggest you read your company's financial statements. You'll find headings like "cost of revenue" or COGS, "General & Administrative" and others like one-off costs for mergers. All of these will have different dynamics, and in each company the dynamics may be different.

Many are judgmental (even within this thread) of some companies not "valuing" software engineering. It'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 & benefits.

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.

I encourage engineers to consider their business' finances when thinking about their job. The company is not a charity or a church -- it's a business with cash flow, revenue & a long term strategy that all has to be balanced with the cost of building the product.

Lots of other good stuff in here if you haven’t read it.

https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

Today, for many businesses accounts is still the main driver behind software, and also the budget.

1. Research and Development. Special tax treatment and tax credits usually apply to R&D.

2. Sales/Marketing - Pre-sale sales engineers, sometimes implementations

3. Maintenance. Developers that fix bugs and perform non-R&D work on code that usually isn’t eligible for special tax treatment or credits.

4. In hosted services/PaaS/SaaS, operations usually carry some level of swe salaries.

Understanding the tax implications of which budget and what work is being done is really important, and gets much more complex as you grow.

For maintenance, if "you'll see this role smeared into product development" and "We give you a generous 2 days every sprint to take care of shit that's annoying," the budget here is R&D, not "Maintenance."

Similarly, Growth and Developer Relation engineers are often (usually?) in the Product org.

If these roles are actually in the R&D/Product Development budget, the "laws" about budget management don't apply cleanly enough that they can be a "law."

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 from literally everywhere: key projects, R&D (I was part of), sales, high-performing etc.

It'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.

Lots of R&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't a priority.

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?

"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".

ref/ https://www.cooley.com/news/insight/2023/2023-04-28-startups...

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.

Your salary is coming from the Business Plan'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 "Maintenance" is most often lumped under.

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.

I wonder if someone or someplace figured a way to make software maintenance and support to be better valued. It's like, it'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's a lot harder to keep it going at the same steam and get budget for the continuous maintenance (OpEx like). Also, why it's so hard to get promotions or market work in good maintenance.

I can see why a lot of people working in tech will focus weekend/break energy on side projects (woodworking; solo sports; playing in a band) where exquisite craft is everything.

Well that'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't so individualized though.

It's maintenance, but the argument they successfully sold to management was that if management planned to scale indefinitely, maintenance cost would also scale indefinitely unless maintenance also had a budget for R&D to push up the ratio of services maintained to maintainers (and the authority to tell software engineering "Yes, you built a new shiny thing, but it'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").

This has, overall, worked pretty well for them given what they want to do. While maintenance is still a cost, it's understood that they minimize that cost via R&D, not cutting.

- A first one that develops a product that creates a value for the company in the present(sales/marketing).

- A second one that develops a product that will possibly create value for the company in the future(research/development).

- 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).

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're making a good money working in them. Now in practice the hypothetical division between sales/marketing and research/development that the author proposes is pretty blurry and in my opinion doesn't do a great service in categorizing the activity of a developer.

For 2, it'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't qualify, talking about Product here.

3, which is Platform and/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.

I think you want to consider the company size, the state of the product, and its market fit before making these assertions.

All three are the best and worst jobs to have, it just depends when and where you are.

Imagine an organisation where developers are adding features to the service, where each new feature uses $1000 of disk space and enables $10,000 of new sales.

And imagine the sysadmins buy huge file servers, each new file server costs $500,000

In a highly bureaucratic organisation, the sysadmins will cross-charge the developers for disk space, and they'll already have the money ready when a new file server is needed.

In a well run and less bureaucratic organisation, the bosses will realise that $500,000 bill enables projects that will return $5M, so they'll gladly pay it.

In a poorly run organisation, the bosses will blanch at the $500,000 bill because it's expensive and not linked to a project; the sysadmins will ask the next person who needs $1000 of disk space to pay $500,000 for it (they'll refuse); then the sysadmins end up having to refuse requests and cajole developers into only keeping 3 days of logs instead of 7 to free up disk space. Before you know it, the bosses are hearing bad feedback about the sysadmins...

Do you mean your companies didn't act like maintenance was last on the list, you didn't agree with descriptions that said they would?

Or they indeed did, you just didn't agree this was appropriate, you thought they were acting inappropriately?

Because you seem to be describing environments where indeed maintenance was not valued by the business -- you just didn't like it. So to "say maintenance is not valued by the business" is just to describe reality, like you in fact just did.

I think the common saying that "maintenance is the last on the list" is not meant to be a prescription, advocating this -- it's a description of what seems to happen. Analyzing why and if there's a way for a different approach to be better for the business is not something OP engages in. One would hope so if one, like you, values things working and being high quality... but if very vew companies act this way, there's probably a reason regarding alignent of interests...

From the developer's point of view maintenance also a thing to avoid. You cannot put a maintenance as a shiny point to your CV. Everyone wants to see your achievements, projects you shipped, and with modern technology, of course.

Keeping the service running to a level that customers demand is a high priority for everyone. Nobody wants to cut SRE to the point outages cause customers to leave.

But I think SRE is closer to "operations" in a traditional company (i.e. unavoidable to provide the service), rather than maintenance (something often deferred as long as possible).

In this framing maintenance is things like tech debt reduction, improving internal tools, experiment iteration time, etc, which is often undervalued relative to product impact IMO.

Of course, software is obsolete the moment it's written, so it could be argued that a lot of people who think they are in #2 are probably in #3 much of the time, spending a small sliver in #2. However, budgets are allocated once a year or maybe a couple more times, so if you are in something that's categorized as #2 when that exercise occurs, you are still in a better place.

If there was value in it, salaries/consulting rates would reflect it and people would be queuing up to learn it and make good money. That isn't happening, so it seems like Cobol devs aren't actually that valuable to these companies.

The bank would see the situation (only one person knows the Cobol system) an extreme risk and do whatever it takes to mitigate that risk. The short term answer is to keep you hired but the long term answer is to either find a steady supply of Cobol programmers or move away from Cobol to something where expertise is more available.

When I was at Travelocity they had by far the best brand awareness and marketing. They also had the best pricing algorithms resulting in massive profit margins compared to the competition. Nonetheless they were destroyed in the marketplace. The biggest killer is that Expedia invested heavily in sales to the sacrifice of everything else eventually resulting in inventory relations teams 3-5x greater than what Travelocity could dream of affording. That was enough to achieve market dominance for Expedia.

Then to make that worse Travelocity only understood growth which was a colossal strategic failure executives would repeat over and over. When it became clear to the original executive team they simply left the company. There was a later executive that doubled down on this and in one year converted a $100 million business to a $60 million business. That guy is still a travel industry executive.

The final nail in the coffin is poor product. It would fail at checkout thereby dropping sales and those customers would never come back. It costs too much to maintain because of poor decisions about software execution. They would also make bad decisions about new initiatives until they doubled down on A/B testing. Then to compensate for all these product failures they would over invest in advertising which drove more customers off the site.

Poor software execution resulted in my layoff from my previous job. The thing that has saved me from layoffs in the past was having a skill that was both essential and difficult to replace just by hiring. The thing that resulted in my layoff from the last job was a fragile product and the unwillingness to fix that product. This is why I have abandoned any kind of web related work. More often than not terrible decisions are intentionally made on the basis of immediate people replacement or immediate feature delivery without regard for how shitty or expensive the new feature is. So much of the time it feels like children are running the daycare because people with inadequate experience want to visibility and nobody wants to clean up their messes.

If you work in office, and there are accountants there go make friends. They are just another flavor of nerd, so you're gonna get along with them, and they have insights into the company that you will never get outside of the C level.

IF you dont KNOW the answers to accounting questions, take some classes. Candidly this is a function of every business that engineers should be aware of! The projects that cost money upfront (OPEX) and can provably reduce recurring costs (CAPEX) can be HUGE wins for all involved.

There is a story about how Dr's in the US have no idea what a procured costs, and that many non us ones do. Though the example is about insurance, I think the lack of awareness of costs is pervasive in more places. Do you know your AWS spend? Do you know the per customer cost/spend (is that individual or organization).... These numbers start to matter in a value engineering situation.

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.