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.

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

What category is Amazon? (the marketplace). It looks like a third category (company sells something else, but it has a software component supporting it).

I am asking because I am working in a company with similar business model and I am trying to figure out what category does my work belong to.

thank you.

EDIT: fix msg

I think there is nuance here, even within a product company, not all software is equal. There's software to support core business (think ads in Google) and there's probably software to support internal dashboards (also in Google), I'm sure engineers working in ads in Google have much more leverage than those working in making dashboards for ops or some internal ticketing system. Conversely, I'm sure the companies we traditionally think software is just needed to support the core business also have software lines which generate income or is critical to their core business.

thank you, maybe it is easier to understand

when you ask whether business will halt and die if the system you are responsible for is down or suddenly absent

it is going to be a mild inconvenience.

I think, defined like this makes it less ambiguous

edit: fix msg

when you ask whether business will halt and die if the system you are responsible for is down or suddenly absent

This is a great way to put it.

I also ask myself the question: "who are the rockstars" at a company. The folks that are celebrated.

If it isn't a developer/engineer, you aren't at a category 2 company.

thank you, I've got something to think about.

Amazon is unique. If you look at their revenue, the vast majority comes from E-Commerce. But if you look at their profits, the majority comes from AWS.

AWS is indisputably a software org, so it's clear that their senior leaders value software engineering. But I think that even Amazon's marketplace sees itself as a software org. From the early days, they always saw software as being a competitive advantage.

Amazon is a partial monopoly so it depends on where you're working. Your team could be any of the 3 areas mentioned under the same umbrella.

Honestly a good manager will do more for your job than anything else.

I agree that AWS is a software org, I am interested in E-Commerce in this particular case. Thank you for response

You can definitely tell the difference in priorities for end users between Amazon.com and AWS too.

These categories are nowhere as cut and dry as HN seems to often think. Netflix is an even better example than Amazon. Infrastructure and delivery is certainly somewhat of a competitive advantage, but their product is not software at all. They're a media company, a production studio, a distributor. People like Shonda Rhimes are the true superstars and they get $500 million contracts that reflect that. It doesn't mean you can't have an extremely rewarding, well-compensated career as an engineer there, but you're still not Chris Hemsworth. You're not what their users really care about. Without content, there is nothing to sell, no matter how strong the software is.

Then you have something like a Raytheon. They're a far purer "technology" company than any FAANG other than Apple. Hardware and software is literally all they sell. No ads, no media, no communities. But very few of the products made there are owned by the company. They're made on behalf of third-party buyers, usually the US military, which puts you in category 3 according to this kind of breakdown, but that is extremely misleading. You're not a cost center. The pay tends to be lower compared to silicon valley standards because of government acquisition laws and the huge number of hiring constraints that have nothing to do with technical excellence, but you're still the primary value creator and the military program you're working for will treat you that way. This one is arguably even weirder because the actual "product" of the military is war and the superstars are the soldiers, pilots, line officers. Technology developers are always in a support role, but that isn't any different from working for Apple or Microsoft. Whoever is actually using those products isn't deriving value simply from using a computer. They're doing real world work with it and that work is what they really care about. Technology is always an enabler. Nonetheless, technology developers for the military make a lot more money and have far easier jobs than even a four-star general, so which role do you really want?

100% second this, thank you

it is hard to say almost 99% product is not engineering but what it enables company to do. In a sense this division is psychological: either company cares about engineering and makes it a priority or it doesn't.

I think good proxy would be tooling which company uses, niche languages like Clojure/Erlang, open source activity, well known people in decision making positions rather than specific business type.

Over the years, Amazon has gone more and more in the direction of the software being the product.

As an immense e-commerce site, the software enabling all the sales was the key differentiator to the competition.

Then they brought in external sellers, making the e-commerce platform more directly a product.

Then of course they started selling the infrastructure directly as a product, as AWS. Which of course relies on software to automate the provisioning, operation, and monitoring of those computing resources.

thank you, so it more dependent not on a type of company but on how the company runs itself.

It can have its main product not in software, but it can bet on R&D in order to outrun their competition.

And the other way around is true too, that is how you get bad software products which somehow always stays afloat because of exclusive focus on sales.

I agree that AWS is indeed a software product, this one is obvious.

Is your company selling something else that has a software component or that software enables (pretty much every other company)?

I'm not sure this is true? If my company sells food or clothing or shoes, they don't have a software component. I'm not sure what the breakdown is, but my gut feeling is "pretty much every other company" is wrong.

I work for a company that makes clothing and shoes. We have an enormous tech organization, but we aren't a consulting company, don't sell software, and don't put software into our products.

This is an article about software engineering - for software engineers. In this context it should not be hard to reason that companies that do not employ any software people are out of scope. Of course they exist.

But, my company does employ thousands of software people. We just don't sell consulting, sell software to other people, or sell products that use software.

You misunderstand. The third group is not only companies that sell software-based products, the third group includes companies that use software to sell their products or manage other aspects of the business. Having an in-house online store is an example.

That presumably puts your company in that group, just like mine (or else I have no clue what thousands of software people would be doing on the payroll).

I bet our two companies have very different reliances on technology, but we're both in the same group, because all of our software supports our sales of our actual goods and services.

I'm guessing GAP.

If my company sells food or clothing or shoes, they don't have a software component.

E-commerce? I can't think of any chains without a website, or any large enough that 'company' seems apt that don't sell via it.

I work for a company that makes clothing and shoes. We have an enormous tech organization, but we aren't a consulting company, don't sell software, and don't put software into our products.

Ok that's the 'or that software enables' isn't it?

I guess we are interpreting the third bullet point differently. I interpreted "Is your company selling something else that has a software component" as something like a car that has software built into it. And, I interpreted "or that software enables" as something like a board game that requires the use of a mobile app (like The Search for Planet X). In other words, the products are not useable without the software. Whereas, a t-shirt doesn't have a software component and isn't enabled by software (though, I could imagine a t-shirt with a QR code that is enabled by software, but that isn't the norm).

Ah, sorry, when I wrote "that software enables" I meant you use some kind of software tool to help ship your product or service. That could be excel macros, SAP, custom POS systems or anything else. If it is customized or built in-house, you'll need developers.

Sorry I wasn't clearer.

Your shoes and clothes don't have a software component (well, most don't), but in most producers, software enables their production.

Inventory management, production automation, order management is software at pretty much every company now, because doing it with paper or in people's head is error prone. I imagine your tech organization is in an enabling role.

Retailers of all kinds employ enormous amount of data analytics, data engineers and software engineers.

Logistics and e-commerce is a component of commerce (aka selling)

That said, you will absolutely be a cost center.

Pepsi's hiring Elixir developers for their backend and logistics systems. Pretty much every company of significant scale realizes they can either save money or gain some advantage from using custom software.

To simplify, you always always always want to be working in bullet point 2, if at all possible.

In the other two, you are a cost to be minimized or eliminated. Only if you are working on one of the companies core products are you an asset bringing revenue into the company.

I disagree - It depends on your career aspirations, your skillset, the company, and the type of software you like making.

If you are a great communicator and have a great ability to just 'get stuff done', you might be a superstar in 1 & 3, and you might find working in bullet point two highly frustrating.

With number 2 you are more likely to be working on a tiny part of a larger application.

My brother went from bashing out big scrappy functional software with lots of client interaction (option 1 or 3) and moved to a bigger product organisation where he is suddenly working on a team building a microservice for a larger application, but doesn't feel like he is making the same direct impact (i.e. it can be more satisfying to make 10 people's jobs 10% easier compared to than making 1 million's peoples jobs 0.1% easier). He would rather build some scrappy tools that gets the job done than build highly refined software, just because the scrappy programming to meet an end is more satisfying to him (and is generally the bit where you can build fast value!).

I would also add career longevity and security. I work at a number 3, I wrote and maintain all the logistics stuff. Every product they sell goes through my code to package parts, put it together and get it out the door. Average time working here is measured in decades not years. It would take a new person roughly a year to figure out what's going on. It's incredibly complicated cash cow that complies with a slew of national and international regulations related to health care. I know more than I ever want to about HIPAA, international equivalents and transportation of hazardous and infections goods.

I wouldn't mind switching to #1 and doubling my paycheck but for now I could float here until I die, and many do.

(i.e. it can be more satisfying to make 10 people's jobs 10% easier compared to than making 1 million's peoples jobs 0.1% easier)

i think in this case, it's got nothing to do with the impact, but to do with the intimacy with the users. This has more to do with the organization rather than the category outlined in the OP.

As a software developer, I rather work at a company that sells billions of dollars in merchandise, with a huge amount of software to maintain doing that and endless middle management ideas to build on (most of which won't amount to anything). Job security. Lots of opportunities to move around and nobody needs to know how the reference was about all the s-shows, when you go somewhere else.

With #1- you are the product

All jobs are transactional, the transaction is just more clear-cut with #1.

Actually #1 is my favorite, as I'm better at technical sales and rapid prototyping than I am at slow, FAANG style politicking, planning, risk mitigation and eventual development. I've done both at various points in my career and consistently make about ~twice as much money running my own consultancy, not to mention I'm so much happier in that environment.

Eh, I don't think it's that clear cut. I've worked in all three types, and there were positives and negatives to each, and none are necessarily better than the other. I will say that #2 tends to be the most reliable and tolerant of your faults.

It depends on the person and the company as others have said. Personally, I found no 3 to be pretty nice in competent companies. On the other hand, I wouldn't want to work with companies like no 1 again. And no 2 can be quite a mixed bag.

Or a combination. I'm in a pretty small company (about 80 people total, 15 devs) and worked on all three of those last year.

I'm a bit confused. You worked as a consultant selling hours, one a software product sold for a price and also on an internal enablement tool for the same company?

Not the OP but I can believe it - where I work the main business is consultancy style work but to support that work there's custom generic software developed to sell/license to clients as part of a value add and there's dozens of internal tooling to support delivery teams. We have developers that will move between all 3 of those areas depending on their current allocation to client work.

Sounds awesome! Thanks for illuminating me. How are these different work streams prioritized?

At first glance seems like the last category would suffer unless someone was "on the bench".

Scarblac's mentions a company that only has 15 developers. That means time spent on internal tooling like, say, improving the CI system has direct benefits for the other 14 developers, all of whom probably report to the same boss.

We have a process whereby people can request a change after a certain period (and team permitting) to allow people to rotate amongst different clients and different work streams. I think it's usually after 6 months on one particular thing you are eligible to request reassignment. Won't always be approved ofc.

In a smaller company it's not hard for "invisible" (like CI) contributions to be actually seen and noticed by both leadership and by the people you work with every day. And on the other hand, if you're a dev working on product and getting work done is a lot harder than it should be, you've got a strong incentive to pause product work and focus on "maintenance" work.

When almost a quarter of the company (15 devs) can both see and feel your contribution to make their lives easier and more productive, you've got a pretty strong political position even if you aren't directly producing product. This is true even if you produce, say, an internal dashboard: you're known as the one dev who took time out to help the 20 sales people sell better (or whatever); you know their names, and they know yours.

Some consulting companies also have software they sell as well as internal things that need to be done. They can have a 'boxed software' that gets 90% of their customers. Then consulting on top for the customers that do not want to do anything themselves or something the boxed software doesn't do. Plus you have internal r&d projects or other things.

I’ve done this myself, too. We were building a WhatsApp-based support ticket system, that was the product; for large customers, we’d build chat bots (glorified decision trees) on hourly billing; and internally, we’d have an integrated CRM system and messaging API that other systems would rely on. Over the course of two years, I worked on all three.

this.

first company is good for starters to get to know others.

third should be avoided if you want to stay in software and not transition to management. You will always be seen as a necessary evil, your problems not understood while others working on core products will be perceived as an asset.

second one is the one to make a career in software dev.

I actually had a pretty good time at a third-category place. When you're writing software for a non-tech company, it means your customers are very close - often in the same building, working at the same time. You can watch them use the software, hear complaints in real time, and push solutions very fast.

In my case, I might've been lucky, though. One of the co-founders had a CS degree and deeply valued the productivity boost we got from custom software.

ofc individual experiences might differ! it certainly depends on the company and leadership. From my experience in a bigger one understanding ended when leadership was needed in software areas, but leadership was recruited only from the other domain...

Along those lines, one of the most toxic places I've ever encountered for developers was at a company that sold b2b software. You would think that developers would be valued for creating the product, but they were fully treated as a cost centre. The profit centre was the sales team who went out and got companies to send money. The developers merely existed because legal said that, for compliance reasons, the firm was required to provide the costumers with software after the client paid for said software (legal accounted for 24% of the company's budget while software development was 15%). If the sales team promised something that the software couldn't do (e.g. track the position of any cell phone in the country with just a phone number in the early 90's before smart phones), then any refund owed to the client would come out of the product team's budget. The salesman (they were all men) would not be required to return his commission, since he did his job and got someone to sign a cheque.

Surprisingly enough, the company was not Oracle.

second one is the one to make a career in software dev.

Your comment and a dozen others make this out to be so black and white. If this is true then why am I finding it so difficult to make a career out of these situations. I find it impossible to identify companies in this category that are good to work for. Does anyone have any heuristics, or should I keep bouncing from one to the next until I get lucky?

My experiences: 1) programmer in IT department of major newspaper: disregarded as IT geek. very small salary. the worst office spaces. 2) senior engineer in software startup: rockstar treatment, stock options, all the things you would expect as office culture 3) senior consultant at IT consulting company: must basically be a sales guy who writes good PowerPoints. Maximize billable hours. What ever you do dont complete a project quickly or with minimum amount of code.

you can probably guess where I am now.

The consulting company gig paid alright. and all the guys who stayed got really rich due to IPO. I left the second my options vested. Literally when the transaction went through... no regrets because it SUCKED

How often do consulting companies ipo nowadays tho… heck ipos in general have dwindled to a tiny number

Maximize billable hours. What ever you do dont complete a project quickly or with minimum amount of code.

OOF

Agree with these. I was a dev at a retailer that did catalog/phone sales and was starting to use web. Small salary, small PTO, no benefits. Pay increased when the business had an existential crisis and came to rely much more heavily on tech. Next was software consulting company churning out sites designed by marketing agencies, billed to the 15 min. Small salary, small PTO, some benefits. Then I went into SaaS (startup, then a public company). Nice salary + stock, great PTO, great benefits.

Aside from the comp/PTO/benefits, I learned that consulting isn't for me. The client interactions felt... adversarial, where they were trying to get more work for less money, while we were doing the opposite. I did not like that constant tension in conversations.

* Is your company selling a software product (product company)

In the B2B world it is common to have a complex enough product that needs training services and tech support as well. Some vendors also add exams/certifications on top of it.

That's fair, I was painting with a broad brush.

Once you get to a certain size of consulting company, you may also have an r&d department or someone responsible for building common libraries or knowledge repositories, for example.

I chose to make a career out of #3, specifically logistics. I know how stuff gets from vendor to customer.

This isn’t something you can buy out of a box. It’s usually heavily customized and made out of multiple systems were never design to work together. Every company does this differently.

I enjoy this. I’m good at thinking through whole systems across a company’s many departments. This requires knowledge of internal politics to navigate through problems. This is were I’m valuable. As a programmer, I’m good, but can’t match the expertise of someone who makes a career out of programming.

Brother

Missing the hackernews part of product to research and development,: Is your company planning to use the exponential growth nature of software to enter into a overlooked niche or rapidly take over a existing industry? In that case, product development does not really catch the situation. Cause using the situation, closing time window till competition appears or funds run out, is way more important than the product or its quality

Seems like a variation of #1 where the rewards are probabilistic and lumpy. I agree that the motivations and resulting behaviors end up pretty different.

As a third bullet point person, never ever attempt to solve interesting technical problems.

I’ve made that mistake, I’ve been asked into meetings and asked “how’s it going” then promptly told “don’t tell me the details.”

Working in bullet point three means working on boring, forgettable solutions. You may find yourself making valid technical solutions that are political suicide.

you'll never be the star of the show.

This is far too kind. If you work eg for a hardware manufacturer, not only won’t you be the star, but good luck getting any respect. You are a cost. One they wish they didn’t have to pay. Delivering on time and under budget doesn’t put you on their radar, it takes you off.

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.

Trading companies are one of the very innovative in IT and offer software engineers salaries that are higher that FAANG.

Is your company selling software development hours (consulting)?

From working with contractors, this bucket also motivates you to strongly optimize for number of sprint points delivered, not quality/reusability/maintainability.

#2 is the best because if you can do your job quickly and efficiently you can minimize the amount of actual time you spend working as long as you are delivering the software.

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

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.

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, better to watch Game of Thrones (which I did only for entertainment not for work-related reasons). Ignore politics (like I did) at your own peril.

What would you have done differently? Built a better relationship with the middle managers? Kept your ear to the ground and left before the CTO did? Interviewed every quarter so you'd be able to leave and land elsewhere? Something else?

I think better relationship with middle managers and maybe leave with the CTO if it made sense (it didn't, in my case). I was too focused on doing things and assumed the CTO was taking care of "winning the hearts" of middle managers. He wasn't. It was a very top-bottom initiative and that rarely works when culture is involved.

So yeah, I think I should have "managed up" so this initiative wasn't tied to the specific CTO but was a common agreement. If the CTO wasn't doing that, I guess I should have called his attention to it or done it myself.

To be honest, middle managers not thinking it was important is just baffling but that's another long story.

As for keeping ear to the ground, I wouldn't even attempt that because I really suck at that (and it's distracting, I'd rather leave). But many people have success with that approach.

>"He wasn't. It was a very top-bottom initiative and that rarely works when culture is involved."

I work at a very large organization where the top is too scared to give any direction whatsoever, so it's middle managers and their lower staff henchman, that battle it out over major decisions with politics and schemes to get their preferred stuff implemented. It's more terrible than you can imagine, I never seen a more chaotic place.

So, I just want to say top-down management isn't the worst thing. I'd prefer that to no top down management at all.

I'm on the same page. The problem in this case was a very hands-free approach to management that suddenly changed to top-down when the chaos produced almost daily outages. So the very relaxed environment now had to somehow have rigorous engineering practices... mandated from the top.

Reminds me of holacracy and how companies picked up the pieces after that fad went away.

There's a troubling/fascinating implication here: generally we just want to 'do the thing', but it's rarely that simple.

Often to be able to just 'do the thing' you have to game out a bunch of this political/strategic stuff, and start maneuvering across those dimensions, in order to create or maintain the conditions under which you can just keep doing the thing.

Yet the more you do that, and the more you think in that way, the less of the thing you're doing...

I already worked for companies where there were management changes at a crazy pace, I'm not sure that all of them got promoted and I have the impression that some of them might have been fired as well.

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.

Most people don't want to do technical jobs? That's not my experience at all. We've had vacant management positions for months because nobody wants to do that role. We'd get no volunteers internally and only a handful of suitable candidates would apply from outside.

If you ask people who come here, probably most of them would choose a technical over a managerial position, but I talk about the general population, of course. Being someone who coordinates the work of other people is much more amenable to human nature than banging your head against a many times unintelligible mass of code.

But you can always check on linkedin the many hundreds of people who apply to any managerial position.

trick is to hire women into technical positions and fast track them into management. My company uses this strategy and almost 90% of low/mid management and admin are women.

The higher up the org chat you report to is, the safer your position becomes

Last layoff at my company was predominantly of middle managagers and very few line workers. Even meta layoff was "the flattening".

surprised by your comment. Is there any data supporting this?

No data, just an intuition about being closer to the power centers.

I guess that makes sense. Level 1 and 2 managers are not really closer to power centers despite being higher in the org chain.

Because no manager would layoff him selfs even if his position and project is obviously unnecessary. In other words only above people can layoff below people :)

In my experience there are two things that bring layoffs: poor sales and bad product management.

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.

Salesforce layoffs had no internal cause - just "investors want us to cut costs". They selected people at random, and we lost tons of people who were essential and difficult to replace. Then they said "we can't guarantee there won't be more, and we can't tell you any way to avoid being hit". And then they said stuff about productivity going down but I didn't care, surprise!

Same situation at a different company, except they kept telling us "we made sure this won't keep happening". Of course few people believed and we lost many good engineers that simply left because they couldn't have a major source of income coming from such unstable place.

I like to believe executives know their workforce will shrink more than the layoff numbers. They must know this. They also must know it will be harder to hire new people. They know this, right? Please someone tell me so.

They must know this. They also must know it will be harder to hire new people. They know this, right? Please someone tell me so.

What time horizon are you thinking? People will forget '22/'23 layoffs very quickly. This is especially true if you made it through these last years, the market picks up and you want to move.

I have no doubt people will forget in time (<5 years).

But anyone looking for a job ought to do due dilligence when things pick up again and at least set the correct expectations about how long their relationship with the company could last if the market turns bad again.

Why? If anyone frequented this or many other forums they'd know employers can terminate employee any time without any reason whatsoever. Leave the job with as little notice as possible because employers absolutely do not care for you. And when last year it did happen people here are feeling hurt as if forever job promise is broken.

Salesforce layoffs had no internal cause

This is the shared theme of most of the recent layoffs.

I don't know where the GP is coming from. Layoffs with clear and local causes seem to be a tiny minority.

I think this example is way more common than the situation your parent commenter described. Most corporations don’t seem to be identifiably strategic about layoffs. They don’t make a coherent plan until the shit hits the fan and the board dictates that a certain percentage must go.

I’ve been laid off three times and not once was my layoff a result of a coherent strategy or reflective of my utility/value to the team.

The first time, I was an accounting mistake. The company quite literally hired me and numerous other contractors by accident. The bean counters in corporate simply weren’t talking to each other and hiring managers somehow got their reqs through.

The second time, I along with my new hire cohort was laid off a month after my start date. I’m not even sure how a company is so disorganized that they can go from approving new hires to laying off those same new hires within a time period that couldn’t have been longer than 3 months.

The third time was similar except that it took place in a slightly longer timespan, still less than a year. Company management handled growth immaturely and irresponsibly, choosing to bulk hire then lay off the cohort rather than growing more conservatively. Paying 5 employees for almost a year could have paid for one employee for over 3 years, no layoff necessary.

Nobody wants to believe that they are easy to replace... as they are laid off and replaced. So, comment redacted.

Peter Drucker called random firing amputation without diagnosis.

I don'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.

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.

Both maintenance and testing are not valued by business. Because you cannot sell maintenance to the customer, you only can sell features.

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.

Because you cannot sell maintenance to the customer, you only can sell features.

That does not seem to be true in many B2B areas. Software suppliers are selling maintenance and support contracts to their customers. Think ERP.

Maintenance of your software. Can you sell bug fixing of your software? You can sell new features. Of course you will add a line to the contract about bug fixing, and put few poor souls occasionally to fix issues reported by vip customers, but it is not a selling point.

See my reply to the sibling - in many B2B settings it is really different.

Even when a company sells maintenance/support/compliance, the incentive is still to put as few actual development hours into these columns as possible, and to pay as little as possible for those hours.

What is actually being sold is a promise, and that really comes from the sales department, not the engineering department. Once the customer signs the contract, the incentive is to do the minimum possible to keep the promise--or better said, break it infrequently and non-egregiously enough that the customer doesn't churn (or sue). So you'll unfortunately still be viewed as a cost-center at many companies if you're working on this stuff.

You are not considering the power dynamics in B2B. The customers get SLAs in their maintenance and support contracts, including monetary penalties. It is also a repetitive business. Bad experiences actually count.

In my experience, if anything development support/maintenance is delivering too much in many cases, i. e. not limiting themselves to fixing bugs, but enhancing functions on customer request.

> Both maintenance and testing are not valued by business.

It depends on the incentives I suppose - if commission and bonuses for sales people comes only from new sales, then sure, maintenance is irrelevant and will be ignored.

> Because you cannot sell maintenance to the customer, you only can sell features.

No, that's not true at all. If sales people are properly incentivised to sell support contracts (their base salary being a percent of maintenance fee for example) then it will be sold like crazy. I have seen this happen at my company - at one point we did not need new sales to be profitable - just raking support contracts fees was enough to keep up costs and then some.

Support contract does not linked directly to the maintenance of the software you are selling.

More support contract does not mean company will assign more resources into maintenance of software itself.

It depends on your business and your clients. Maintenance in the form of compliance always sells, albeit begrudgingly. If maintaining various compliance requirements is required (like DoD), then maintenance budgets are usually flush with cash.

This is very true. I work in MSP not software dev, but banking/finance clients almost always have budget for regular hardware refresh and premium support agreements. And they fork over tons of cash for security auditing and all the licensing.

You can sell security, support, and compliance and those tend to be tightly related to maintenance. A product hard to maintain becomes a nightmare for any recurring task, security, support and compliance all being examples.

You can also price in the effort of maintenance that needs to be done before adding of a new feature. That may explain it better from the leadership perspective.

It all depends on the structure of the organisation, and how well managed it is.

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

… and somebody gets the bright idea to replace the sysadmins with “managed cloud” and S3 file storage, leaving the sticker price as a “digital transformation” cost until they can work out the cross-org billing using an app someone built in their spare time to read itemized bills and re-bill internal budget numbers for their fair share of resources?

To complete the story here, the app doesn't work because dependencies have changed in the meantime, so everything is tracked on multiple giant spreadsheets.

Well there's "should" and actual reality. The article lays out the latter, pointing out that it's career suicide to go into bucket #3. If you are not an 'up or out' type of person, then maybe it's worth considering spending time in bucket #3.

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.

In 20 years and several different companies I have always heard this but never agreed with it.

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

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

Do you seriously suggest that banks outsource the maintenance of the mainframes that process their money transfers? If so I'd like to see a source, because the only articles I have read about on this topic (e.g. [0]) tell me the exact opposite: it's all in-house the risks are too high. For larger banks it's practically a national security risk. Maybe the software they use is from abroad (usually ancient IBM shit), but that's not the same.

[0] https://ezali.substack.com/p/interviewing-my-mother-a-mainfr...

They don't "out source", they in-source by opening technology hubs in cheaper locations.

Again, I would like to see a source. I'm not saying you're wrong. Maybe you're talking about small banks in the US or something, of which I know basically nothing. I am thinking of examples like Nordea, the bank in the article I linked, which has a market share of around 20% in Sweden[0] and handles the government's bank accounts. Especially that last part makes me extremely skeptical that the Swedish government would be OK with handing over the keys to their economic kingdom to cheap digital labor abroad so a company might save some money.

[0] https://en.wikipedia.org/wiki/Nordea#History

Well my brother worked in BNY Mellon India center. They have thousands of people and work core banking processing. BofA have their own India development center with thousands of employees. And this is outside of 10s of thousands outsourced to Tata, Infy etc.

You think core banking process like transfers/ trading is some kinda crown jewel. It may be in terms of messaging but most of core IT part is just a cost center.

Customer data and all need to be in their own secure data centers for legal reasons but all the processes can be designed, developed and executed from anywhere at lower cost.

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 as well.

I've seen a post on local job board in Poland, IBM was looking for junior cobol engineer. Any student with some java knowledge will fit, they said. I'm sure they will not pay anything more than 25k eur anually.

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.

legacy cobol system, many managers are incentivised to gather a new team to write a replacement with some modern technology stack.

Absolutely not in outsourcing centers like this. You're not supposed to show any initiative or god forbid - design anything. You grunt the COBOL until budget for the project is zero.

her earnings were something around 25k EUR annually.

That's a fairly good salary for a recent graduate in Eastern Europe.

Although I admit it does illustrate your point that some legacy tech stacks are quite easy to pick up.

There's nothing particularly difficult about Cobol, it can be learned, and with enough effort, all the undocumented existing code can be understood and reverse-engineered enough to be able to make changes. It's not pleasant work, but it's doable.

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.

There was a comment on HN a while back to the effect that the well-known stories of COBOL devs being dragged out of retirement to earn massive consulting payments was a myth. They were actually being paid good, but not extremely good, rates for their knowledge of the business logic embedded in old code-bases. The implementation language was largely irrelevant.

You're valuable in a way where everyone really wants to get rid of you and is planning hard on how to do that.

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

I think it’s a nonsensical model. Every department is ideally responsible for both revenues and costs. If you can’t measure it, it is a problem of your KPIs. So the KPIs may be cost-oriented (and thus badly aligned), it doesn’t make the department itself a cost center.

Which department are you talking about? If your department doesn't drive revenue, then the business leaders will see it as a cost center. It doesn't matter if you disagree with that perspective unless you can change their minds. How have you done that in the past, or hypothetically how do you think that might work?

It doesn't become any less nonsencial just because some business leaders who are still stuck in 1980s believe in it.

Both profit centers and cost centers are supposed to increase profit, otherwise you wouldn't hire those people. If a department doesn't drive profit, then just axe it and stop wasting money on it. If you can't [1], then it actually drives profit, you just have no idea how. The fact that you can't set proper KPIs to measure impact doesn't imply absence of impact, and of course it doesn't imply that you should treat it as if it has no impact.

Departments are engaged either in primary or support activities. And those activities are either efficient and optimal or not. Your competitive advantage doesn't even have to be your primary activity. If you are successful at making fidgets because you hire, plan and budget better than others in your industry; what insight can talking about profit centers and cost centers provide to you?

[1] How is someone supposed to run a company without HR or accounting?

It doesn't become any less nonsencial just because some business leaders who are still stuck in 1980s believe in it.

Of course it does.

Whatever your business leaders believe is reality in that company. It makes no difference what you or the outside world believe.

You're either OK with it, or you need to get out ASAP.

You redefined cost / profit center as 'primary' or 'support'. This is a circular argument.

The cost center vs. profit center concept has some utility for accounting, but overall it makes more sense to model the business as a modular system seeking a global optimum, a la Goldratt, rather than a set of separate sub-organizations each to be optimized separately.

In other words the business as a whole should be viewed as a singular profit center, and each department or project should be evaluated in terms of how much it contributes to optimizing the overall performance.

This has been my experience as well.

It doesn't matter how many presentations and case studies and financial models you build, whether you're a cost center or not is basically entirely determined by what a few people in the c-suite believe. This became blatantly clear over the past year or so of layoffs, when the same people who nodded and thanked teams for showing them how they generate revenue for the business immediately turned around and put them on the chopping block.

It is a completely nonsensical model, and leads to completely stupid decisions if applied.

But management uses it for every decision anyway.

Why not combine them? Both give different insights that could complement each other, no?

But I think it has a lot to do with how profit is made: if you sell machinery for example that has a software part you are a cost factor, even if software is required to run it. Think of it as an in-house supplier that could even be outsourced. Not that I think it is feasible, but upper management does. And as long as they do, you won't rise far building software in such a company...

This has been how I've usually define it too.

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.

Maybe 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?

This is close, there is more nuance to it, and a lot of it is going to be specific to your org.

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.

The projects that cost money upfront (OPEX) and can provably reduce recurring costs (CAPEX)

So you mean OPEX are upfront costs, and CAPEX are recurring costs?

Yeah, whatever mistakes the GP did, those names are the other way around.

Yes I did transpose them!!! I have since had coffee and am feeling much more on the ball, thanks for catching my error folks!!!!

Capital Expenditure (CAPEX) is the money invested up front, and Operational Expenditure (OPEX) is the money invested to operate the investment as you go.

3 parts of organisation mentioned in the article have their own respective Operating Expenses (OpEx) and Capital Expenses (CapEx). OpEx is what you spend on day to day activities, and CapEx is what you invest into something that you will use long term. You can pay via CapEx or OpEx for the same exact result: e.g. if you purchase a car, that's CapEx, but if you rent it each month, that's OpEx. I'm simplifying, but that's the gist of it.

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.

The CapEx -> OpEx push is also heavily tax based. I can write off (generally) 100% of an OpEx expense today (or, as I spend the money). CapEx expenses become Assets, which are tracked and taxed, and the business doesn't get to write off that spend immediately - it turns into a 'depreciation' write off, spread over the useful life of the item (sometimes 5, 10, or more years). Real estate, vehicles, large equipment, etc. is generally all done this way - a CapEx gets you an asset or property, which is then taxed and depreciated. Software licenses, insurance and other things can also be done this way (CapEx), depending on the terms and your accounting standards.

CapEx expenses become Assets, which are tracked and taxed,

Real estate, vehicles, large equipment, etc. is generally all done this way - a CapEx gets you an asset or property, which is then taxed and depreciated.

What tax(es) are you referring to? Property taxes?

In some cases (e.g. a building or expensive equipment purchase, probably yes, property taxes in most jurisdictions, at least in the US). The depreciation is deducted from income for income taxes over time, rather than all at time of purchase as an opex expense is. This implies a higher income tax bill 'now', with a smaller deduction smeared over time.

Maintenance is always on the chopping block

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.

Maintenance is instantly a good business case if you can sell maintenance and support contracts to your customers. Of course you will rarely find that in B2C areas, but in B2B it is not uncommon.

Though that just kicks the can. We sell support contracts so everyone does a bunch of bug fixing as a matter of course, and that doesn't even get called maintenance internally. "Maintenance" is the refactoring or other tech debt quashing that the devs always want to do but which mostly isn't a priority.

Where I am working bug fixing was always classified as maintenance work. That is even relevant for taxes, as ticket processing is a different category, with different tax rules.

I think it's because the biz types would sell the copper wiring from the office if you let them.

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

I think the budget is used figuratively here to mean where your contribution / value-add to the company is.

These budgets aren't often labelled as explicitly as the article states, but I've found they're generally accurate.

You either make money now (sales), you build long term value (product), or are circling the drain (maintenance) on an existing product.

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/marketing), but it also isn't maintenance.

The whole blog post is very tech company product oriented and seems almost completely oblivious to the vast number of software engineers building line of business applications for internal use, under the COO's budget.

Maintenance is a bad word for it, but the author clearly intends it to be in that category:

Building internal tools can fall into this category.

Sales/marketing don't even exist when a product is first being built, but you're getting paid... but your salary isn't R&D. The pace isn't calm. The stakes are high. The target can pivot violently.

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 think a better way to think is as product development. Sales and marketing exist from the beginning even though nothing is being sold yet.

I'm having trouble with this framing. The buckets only make sense metaphorically, but is written literally. The "laws" only make sense literally, too.

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

Right, I read that situation as they've gotten rid of "maintenance" budget altogether, because it was so de-valued -- you won't find any software engineering jobs actually attached to maintenance budget anymore in such an organization -- and now what maintenance is done is done in the margins of jobs whose primary purpose is R&D, attached to R&D budgets.

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

I'm in FAANG making close to that, and I have been testing the market for a few months. I found less than a handful of companies that could beat my current comp.

The vast majority of companies I've talked to seem to top around 250k even for Staff+ roles.

The author says that EU ain't no Silicon Valley, but 2024 sure ain't no 2022.

There are actually four buckets:

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.

There's also a fifth bucket for really large companies and really high end engineers:

5. CEO/COO/CTO's special budget for special consultants

Re: (US) Internal Revenue Code (IRC) Section 174

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

Software development costs now must be amortized.

https://news.ycombinator.com/item?id=38698457

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.

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

That’s my #1 rule; go (and stay) where there is either profit or a realistic path to profit.

Rule #2 is to play a role within that profit center which can be credibly linked to continued profitability. It doesn’t have to be directly making money, but it should be clear why the money will be directly impacted if I stop doing my job.

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

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

Very closely related, this comes up on HN from time to time: "Don't Call Yourself A Programmer, And Other Career Advice" https://news.ycombinator.com/item?id=3170766

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”

Building internal tools can fall into this category. That unloved admin dashboard that runs the company but never quite gets priority.

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”

I remember early advice in my career to always work for a revenue center not a cost center.

This was really helpful as having something that makes a firm money seems more easy to measure impact than a cost center.

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.

> You're only as good as the multiplier a company gets on pouring money into your bucket.

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.

The article cleverly groups the budget in three categories:

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

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.

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

Sounds like the Gartner RGT model

https://www.gartner.com/smarterwithgartner/align-it-function...

Background is completely white and text unreadable, toggling 'modes' fixes this but I presume its related to OSX and dark/light mode.

Chrome Version 120.0.6099.109 (Official Build) (arm64)

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

"Sales & Marketing" and "Research & Development" are categorizations you may read about in companies' annual reports, but "Maintenance"?

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.

All 3 actually. Depending on what task I work on.

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.

The analysis of maintenance budgets is depressingly accurate. Especially as tech companies get older (and they age surprisingly fast), it's quite startling to see how most of them become organizationally indifferent to various small to medium glitches in established products.

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.

I'm in sales/marketing; bored out of my mind, so I'm studying to be in R&D.