Software engineering salaries come from one of three budgets
swizec.com
swizec.com
* 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 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.
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.
At first glance seems like the last category would suffer unless someone was "on the bench".
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.
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.
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.
Surprisingly enough, the company was not Oracle.
over the long term I would think that two things will happen: good devs will leave the company while the remaining fight an uphill battle maintaining code until the customers leave.
but ofc sales and incentives in general are a whole different area of problems.
This policy was also useful for retention. Other firms in the area knew that he fired all of the good devs, so they never tried to poach his employees. In fact, if you got tired of the toxic environment and quit, the firm's name on your resume meant that you probably weren't going to get another dev job without leaving town. When a dev sees their former colleagues making sandwiches at Subway, another weekend of unpaid overtime doesn't sound as bleak.
This. A mentor told me, “[As a software developer], never work for a company with a CEO who has never pushed code to production.”
I think you miss some good places to work by following that advice, but you avoid a ton that are worth avoiding.
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?
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
when you ask whether business will halt and die if the system you are responsible for is down or suddenly absent
or
it is going to be a mild inconvenience.
I think, defined like this makes it less ambiguous
edit: fix msg
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.
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.
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.
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.
Honestly a good manager will do more for your job than anything else.
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?
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.
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.
If everyone else does the opposite, you can make a career out of making correct technical decisions.
Seems to work for me anyway.
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.
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 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.
I wouldn't mind switching to #1 and doubling my paycheck but for now I could float here until I die, and many do.
And I have a network of other independents I can bring in to help out with things. They're a good source of leads for me as well.
From working with contractors, this bucket also motivates you to strongly optimize for number of sprint points delivered, not quality/reusability/maintainability.
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.
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.
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.
That said, you will absolutely be a cost center.
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.
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?
Sorry I wasn't clearer.
What ever is being manufactured, the real product is data for process improvements, improve product quality.
you can probably guess where I am now.
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.
as soon as you encounter an unexpected problem, your margin suffers. since unexpected problems can radically alter dev time, your margin can be obliterated.
If unexpected costs are shrinking your margin, you’re failing either:
1. …to negotiate the terms of your agreement correctly (what constitutes additional scope and therefore additional charges?). I will never take another client project without first agreeing on an SRS for this reason.
2. …to negotiate a fee with a margin proportional to the likelihood of unexpected situations arising. This is a function of the accuracy of requirements by simple/complicated/complex problem domains. I think this is what parent is suggesting.
If clients don’t like (2) they will work with you more on (1) by providing more accurate requirements, which lets you bucket some problems into more readily estimable domains.
What you’re saying is a much clearer answer. And what you’re saying is frankly pretty tough. But being a consultant is more than just asking someone to shut up and and pay you to code.
if you can maximize margin on all fixed price work while not pricing yourself out of the market you will dominate software dev and also make millions selling books. hint: it's not that easy.
handling fixed price software dev is like handling dynamite.
(Lost on the current site, as far as I can tell.)
So suppose you've fixed cost, have you fixed the other five project variables too? If yes, you've just reinvented waterfall - which is fine if you have a very well defined task you repeat often, and there is little chance of much scope variation being desirable. It still might be adversarial in that you, as a consultant, might do the same process for every client, but it might be your first time working with a client, who expected more than the scope, or disagrees with your interpretation of the scoping document supplied.
Now suppose it is a much more bespoke task, where both sides need to discover some things about what works. You are likely to learn that part of the plan you originally had won't work to capture the benefits. Now the actual scope required is bigger; perhaps that is a risk you take. But perhaps one client realises some big scope requirement early, and deliberately takes advantage of the fact your scope is variable to conceal this from you when you set your fixed price; maybe you put some language in to try to reduce this risk. And perhaps your boss encourages you to use some of that language on an honest client who did genuinely try to communicate the scope, to make the client pay. Everything is once again back to being adversarial.
I think time and materials contracts are actually the best for aligning incentives - the consultant gives their best attempt at an accurate estimate of the work, and the client can freely change things as they go along - but carry the risk of cost changes. If the consultant is poor at estimation, doesn't give frank advice, or does low quality or slow work, the client ends the contract with the consultant and gets a better consultant, and since it is time and materials, it is clear what is payable and who owns what - so ultimately everything is well aligned.
OOF
There's a real continuum of engagement budget here - at the other end of the scale you have the opposite problem where the fees are barely adequate, and your success is based on systemitizing shortcuts to crash out cookie cutter minimum viable products, and being able to get clients to actually cough up.
Trading companies are one of the very innovative in IT and offer software engineers salaries that are higher that FAANG.
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.
But I'm still getting paid damn well for a job that isn't at a software company. Woo!
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.
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.
That does not seem to be true in many B2B areas. Software suppliers are selling maintenance and support contracts to their customers. Think ERP.
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.
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.
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.
More support contract does not mean company will assign more resources into maintenance of software itself.
This is why I do not work for faceless corporation. I deliberately sticked with small lifestyle business that values maintenance as much as new sales (as a matter of fact just this week I was refactoring my own, original piece of code, that its first version is dated by versions control as written 15 years ago and during this whole time there were clients that were paying support fees for it)
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...
Not that I've bitterly seen multiple versions of that in my career or anything, this is still just purely hypothetical complaints department, eh?
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...
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.
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.
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...
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.
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.
5. CEO/COO/CTO's special budget for special consultants
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.
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.
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?
Well, those are rather funny categories in the first place. Cost and profit aren't complementary categories; cost and revenue are. Profit consists of them both (i.e. the difference between their sums across all departments).
Just as there are no pure revenue centers -- every department has costs! -- it could be argued that there are no pure cost centers: Every department contributes to revenue in its own way. Without maintenance, you'd soon have no services to sell; without R&D you'd soon have no new products to sell... Heck, even HR -- without it, you'd soon have no personnel to staff the other departments.
Seems a bit skewed that some departments get to hog the "profit" label all to themselves while others are -- pejoratively, in MBA-speak -- condemned to the "cost" category.
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.
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.
I do believe there are still organizations (or at least teams within) that have not been taken over by the parasites you describe. It takes hard work and a lot of looking, but they can be found.
Everything the company does should generate value.
But management uses it for every decision anyway.
You either make money now (sales), you build long term value (product), or are circling the drain (maintenance) on an existing product.
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."
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.
[0] https://ezali.substack.com/p/interviewing-my-mother-a-mainfr...
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.
If you're 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, then you need to re-evaluate your mental model, because that is definitely happening in reality. They may impose some legal limitations - the exact same limitations as towards any other bank - but they generally act as a normal minority shareholder, demanding the company to be cost-efficient and maximizing profit even if it means outsourcing and offshoring.
Well, to begin with, the Swedish government seems to have known for a rather long while that Nordea has been doing quite a lot of other shady shit abroad, and still stuck with them... From your own WP cite, a bit further down: https://en.wikipedia.org/wiki/Nordea#Scandals .
Not that the Swedish government is much of a guarantor against sending sensitive data abroad in the first place: They were quite OK with the Swedish Transport Agency letting a contractor (Oh look, IBM again!) hand over data, including higly secret (protected identities, military vehicle registry, security van routes and timetables) to sub-contractors abroad with no Swedish security clearances: https://simple.wikipedia.org/wiki/Swedish_Transport_Agency%2... (very cursory article; much more in the Swedish-language version). So them trusting Nordea... Isn't much of a recommendation for Nordea either.
It's definitely not the case where it's all in-house. Some organizations do, some don't, and there are so many banks (and so many different types&sizes of banks) in the world that every option is represented.
But even after narrowing it down to that your stories make me think I had too much faith in the banking system.
404, Ezali seems to have left substack.
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.
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.
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.
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.
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 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.
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.
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 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.
Reminds me of holacracy and how companies picked up the pieces after that fad went away.
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.
But you can always check on linkedin the many hundreds of people who apply to any managerial position.
It is really the minority who can do tech for the long haul.
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?
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.
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.
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.
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.
I've got an employer that I've held a grudge against for nearly two decades now and another that friends of mine have held grudges against since at least two corporate rebrandings ago, all just off the top of my head. We'll all happily talk dirt in a LinkedIn DM or over beers and who is to say how many of us all posted some anonymous strongly worded letter to something like Glassdoor.
Labor is still a market, for now, and while it isn't as liquid or as free of a market (in terms of open price [wage/salary] information, in terms of too many near monopsonies and/or trust-like behavior) as it should be in America, and companies should stop treating it like a one-way street. Bad labor relations hurts brands and eventually the market uses that information. It's not always efficient at using that information especially because it isn't liquid/free enough, but it uses that information.
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.
- Layoff to hopefully bump stock price prior to M&A negotiations
- Layoff to "streamline" before new CTO start date whether or not the CTO was expected to change directions and before incoming CTO even evaluated the existing teams. Further simplified: layoff to hopefully bump stock price due to speculation about CTO transfer being theoretically messy on paper.
There's definitely a common thread in my layoffs of some dull ideas to please some form of stock investor's short-term, single Quarter thinking, maybe influenced by actual stock investors. That's also something that there seems to be some data on in 2022/2023 layoff cycles in general how much of them have been "activist" shareholder lead, as much or more than board strategy (though the Venn Diagrams between boards and "activist" shareholders is sometimes quite close to a circle, go figure).
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.
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?
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.
So you mean OPEX are upfront costs, and CAPEX are recurring costs?
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.
> 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?
I would not characterize a lower deduction for a business expense as taxing something. I would have assumed it meant a buyer has to pay an additional tax as a result of purchasing something.
For a simplified example, let's assume that this year you bring in $100 of cash and spend $50 of it on opex and $50 of it on capex.
In this case, your revenue this year is $100, but your expenses this year are all $50 of opex plus some percentage (depends on over how many years you capitalize the investment, as set by your policies but limited by tax law) of capex, if it's a 5-year depreciation then it would be $10 of those opex $50, so for your $100 of outgoing cash $60 are expenses this year and $40 is treated as accumulated assets for future. So the accounting says that you have $40 of profit this year - and, crucially, it could have been as low as $0 or as high as $80 (this year! The total profit doesn't change, but it can get moved around in time to a different year) if your accountants can make the case that those activities were 100% opex or 100% capex.
And while there are various reasons why the company might prefer these numbers to look higher or lower, the main practical impacts are twofold - one is taxes, where saying that some expense is opex means you pay less taxes today, deferring them for a few years and improving your cash flow, but the other is stock market, where saying that some expense is capex means that your quarterly profit is higher and thus it helps your stock price and any employee benefits linked to stock price.
And because of that your management often will have KPIs with a very strong motivation to push things towards opex or capex depending on the company.
https://www.eisneramper.com/insights/tax/impact-174-software...
"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.
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.
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.
https://www.gartner.com/smarterwithgartner/align-it-function...
> Building internal tools can fall into this category.
Chrome Version 120.0.6099.109 (Official Build) (arm64)
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.
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”
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.