Knowing where your engineer salary comes from
seangoedecke.com
seangoedecke.com
You would think that, but decades of experience have disproved that.
Most of management, past first-gen if the company was founded by engineers, is non-technical.
Most are (more or less) aware that somewhere technical engineering in software is needed, but they feel that as a threath rather than an asset. If engineering is not a commodity, they fear being called out for not being in touch with the grounded reality of the business, and fear the unpredictability this entails for their own operation.
So they will tend to treat engineering like a commodity, generic and interchangable at will, and even deliberatly not recognize differential contribution by engineers to the company's success.
This is also why once non-technical management has consolidated, rising from engineering into management will become very difficult, often requiring you deny your technical competences.
Also every employee should be able to quit at any time and not affect business.
So I disagree describing all like it is some evil scheme - that’s how businesses work.
Unless they are sales reps that have good relations with customers.
I do agree that it's simpler for management to pretend that they are, and that's why great management is insanely rare. But great management, like great engineers, can make a huge difference in the success of a company / project.
Sure, but that is a load bearing "great" for sure. Not every company is staffed with great, selfless engineers.
I'm an engineer and I've worked at companies with engineers who actively resisted making themselves not a single point of failure because it gave them control and job security. I think it's not uncommon to have these types at companies and it really sucks when they have their management Stockholm syndromed because they make it hard for all the other "great" engineers to do their jobs.
Obviously it can't succeed (in the desired time frame) without those specific people, and pretending like it can is lunacy.
The vast majority of companies are putting web forms over a database. Letting one or two people hold all the technical knowledge for something like that is borderline fiduciary negligence.
It's about specialized knowledge. To the owners of the business, making sure the business doesn't fail to deliver is existentially important.
Web developers are fungible. The guy who designed the carefully tuned graph database that runs on a custom Linux kernel with a custom tuned filesystem is not. If this sort of thing is critical to your business succeeding, that engineer might as well be Niels Bohr.
How many companies have an in-house tuned graph database? How many companies have custom Linux kernels? How many companies have custom filesystems?
That's the fundamental problem. Some MBA or book somewhere convinced people that respect and dignity were optional. Once they realized they could apply this to more than engineers they started painting the entire world with this bullshit.
It would be nice if they could meet us half-way on the technical stuff. They regularly merge architects and sysadmins into developer roles making us learn more stuff.
Whatever the origin, this is actually a very serious problem that afflicts our society at large, well beyond MBA culture.
If all of sales says "I am losing these deals because our competitors have X, and I cannot make my quota without X, and you do not make your numbers without X." - how do you balance that against a department head who says, "I cannot give you any features this quarter because we've been focusing on features over codebase health for too long?"
Someone who says no for too long doesn't last.
I actually think the engineering manager is probably in the wrong there, because if killer feature X is that critical to sales, then it needs to be prioritized in among the tech debt. It doesn't matter that the codebase health is not great if sales plummet. Being a good employee means sometimes prioritizing the health of the business and not the ergonomics of the work environment. And being a good manager means understanding when the health of the business is really at stake or whether the sales team is just throwing shade because they don't want to sell what the company has.
And all of those might be plausible answers. As you'd agree, nuance is key here. However, that is all from the department or product head. Now consider the CEO's perspective that has 8 equally loud voices all clamoring for resources.
My point is that it might not be disrespect but rather a management team that is trying to navigate competing priorities and economic realities.
Even among engineering software is somewhat unique in that we intentionally make sub-optimal decisions and then expect other departments not to raise an eyebrow when we demand time away from the next set of features to address (some of) those decisions, usually introducing more sub-optimal decisions in the meantime.
Nobody has figured out a better way to do it but it's easy to see why non-technical people would be inclined to think tech debt is just a way to do less "real work."
From an outside point of view, focusing on code quality and playing videogames instead of working look identical over the short term (or more realistically, working on little niche bits of the code or doing tidying-up busywork that doesn’t really improve the overall quality of the project—it could legitimately be hard to tell the difference). Of course, it should eventually become apparent that the latter group didn’t actually accomplish anything in that time.
“How do you balance the,” I guess it is a social thing/judgement call ultimately.
I've worked on many, many features that never recouped their engineering cost despite the absolute assurance by sales that it was necessary. It would have been more effective long term to work on improving code maintainability so that we could better capitalize on features that substantially affect revenue in a positive direction. All too often I see that code maintainability only matters to the business when features can no longer be reliably and quickly delivered, but by then it's usually too late to really change course. This sort of balance also tends to drive all of the new fancy frameworks that cause so much churn as the signal from the business to engineering is that engineering needs to be able to pump out features very quickly but will not be given time to focus on maintainability so naturally this gets outsourced to someone else.
To be fair, I have also been involved in an emergency project that if it wasn't completed in a very tight time frame the company would have lost 30% of their revenue and there would have been substantial workforce reductions. We did not focus on maintainability in this situation rather we focused on saving the company.
Everything is a trade-off in business. My experience tells me companies generally focus on short term profit over long term concerns and there's very little in the way of feedback mechanisms that allow an inspection of these decisions in aggregate to see if the right balance is being struck.
Frankly everyone downplays someone else based on their social circle. The only people who don’t have wide social circles but most people don’t.
relation to company profitability is optional and often times counterproductive
It's the guy/gal who you know needs to be informed that the feature they've been painstakingly working on for the last 2 months is scrapped due to a strategic realignment and now they're tasked on working on some non-revenue bullshit to win a turf war and their response is a shrug and brainstorming of how do we play this rather than getting all up in their feelings and require emotional babysitting for the next 2 months.
I feel like managers - even good managers - understand that better than most. That isn't to say there isn't variation in humans - choosing the humans right for your team and organization will help advance a lot, but it really helps us to think of organizations as ant colonies. One person can slow it down, but very few can speed it up, and they can only do so much.
It's the network of communication that matters more than the person.
There are exceptions - I can think of a couple CTOs I know that are worth their weight in gold - but they are just that - exceptions.
I will say, the smaller the organization, the more having the right executives is important though, but it seems that only lasts while headcount is sub ~200 people or so and executives maintain an active role with all pillars of the organization relevant to their function (e.g., it isn't weird for an IC to talk to the CTO from time to time about how their job is going)
But a lot of companies aren't - or at least, they don't think they are.
Are they?
There is a subtlety. Your manager might be able to do your job, with time, but if they haven't spent time understanding the same data you have or the greater context of what you are doing, then they won't be able to come to the same conclusions you do.
Therefore your manager must trust your judgement because they do not have sufficient data to make the judgements you make yourself. This necessary deference is what prevents commoditization. Judgement is also unequal, being informed by experience and quality, further denying commoditization because all engineering decisions are not equal.
The corollary is also clear. If a manager thinks they know better than you and treats you like a commodity, then you are forced into performing a job in a dogmatic rather than analytical or informed way. You may be asked to do things that don't make sense or are even directly counter to the organizations goals because they don't know things you know.
Comments like these make me remember that the tech world is very big and companies come in many different shapes.
I haven’t had non-technical management below the CEO level in many years.
Even stranger was the experience of my company being acquired by a large name-brand tech company. My manager (Director) and their manager (VP) were the worst kind...non-technical and second guessing everything in silly ways. Meanwhile, the co-founder and CTO popped into our tiny office one day because they were in town, rolled up to my desk and said "hey, you're fatnoah, right? I have some questions" and then pulled me into a conference room where we went deep on our entire tech stack. He got everything the first time and understood the how and why of what we built and why.
That might have been the case with CIO/CTOs coming from pre-2010s era where they indeed were maintaining landscapes built from commodities or vendor solutions (i.e. on-prem server racks, CRM and ERP systems, networks, end user devices, subscriptions to cloud applications etc - some still do). Modern CTOs managing complex tech landscapes that were partially built in-house are rarely like that.
In my experience any CTO ties engineering, be it commodity or not, to value which is highlighted in the article, or get replaced. That's a key part of their role, if not 80% of it. If you think your CTO is underselling engineering contributions, he's either not doing a good job of making that value visible, or you overestimate these contributions.
There is not a competent Executive Vice President or Division President in the world that needs to be managed by their boss.
Sure, to first order, and in the short term, engineering work is often valued more or less at random. The valuation is driven by factors that we can't predict (or that we would really rather not predict).
But to second order, and in the long term, engineering work is often valued according to whether it makes money. Often enough that it's worth paying attention to the article.
Like most advice you find on the internet, the author of this piece is writing "the way the world ought to work" rather than the way there's any evidence that the world does work.
Complex jobs cannot be accomplished effectively with transients. Therefore, a manager must make the work challenging and rewarding so that his people will remain with the organization for many years. This allows it to benefit fully from their knowledge, experience, and corporate memory.
The Defense Department does not recognize the need for continuity in important jobs. It rotates officer every few years both at headquarters and in the field. The same applies to their civilian superiors.
This system virtually ensures inexperience and nonaccountability. By the time an officer has begun to learn a job, it is time for him to rotate. Under this system, incumbents can blame their problems on predecessors. They are assigned to another job before the results of their work become evident. Subordinates cannot be expected to remain committed to a job and perform effectively when they are continuously adapting to a new job or to a new boss.
When doing a job—any job—one must feel that he owns it, and act as though he will remain in the job forever. He must look after his work just as conscientiously, as though it were his own business and his own money. If he feels he is only a temporary custodian, or that the job is just a stepping stone to a higher position, his actions will not take into account the long-term interests of the organization. His lack of commitment to the present job will be perceived by those who work for him, and they, likewise, will tend not to care. Too many spend their entire working lives looking for their next job. When one feels he owns his present job and acts that way, he need have no concern about his next job.
Rickover would be a savage critic of society and American culture as it is now, he even was then. He was a man who successfully challenged people in power, which is why I imagine most people never hear of him. He won many political battles, but the same people he challenged remained in power. When they wrote the history books, they diminish his legacy, because they don't want stories of people successfully challenging power structures and especially not stories of people who challeneged corporate power, or prove that the government can do something better, cheaper, and more dangerous/complicated than corporations.
It's like, what if you were working at a Frontier AI Lab in 2024 but also living in the aftermath of a bioweapon that selectively killed INTJs that like rockclimbing and anime, and you need to build really good AI by 2030 because if you don't you and all your friends will die of Huntington's Disease?
And then you told people that building great teams and getting things done is easy, even when they're "Moving the Munitions Depot 30mi Down the Road Because We Didn't Renew The Lease" or "Integrating OpenTelemetry With The Ingestion Service For The Staging Environment"; just frame those as "Actually the Most Ambitious Logistics Project in the South-Central District Since the Similar One 3 Years Ago" or "Revolutionizing PreProduction Observability in the Portion of the EMEA SRE org under Joe"! It should be just as easy to motivate the 23 year old trying to secure the bag and become a passport bro to update staging as it is to motivate the best engineers in the world to use cutting edge technology to protect their loved ones from an imminent danger!
Once a company reaches a certain size, basically once it has a financial planning department w/ different VPs owning their PnL, who is making money increasingly becomes a social construct. "how to get promoted" by spakhm is much more closer to how a large, successful org works IMO: https://spakhm.substack.com/p/how-to-get-promoted
I've seen this in my career multiple times. For example, when I was involved in search for some companies, we would demonstrate through A/B testing that we would make X more money per month. Executive team changed, they decided that "A/B test does not work and slows us down", the definition of making money changed, we overnight went from a money-aking org to a cost center.
Nowadays, most companies are pushing GenAI everywhere. Most of those things don't make money, and yet a lot of promotions will be obtained across the board until the tune ends.
The essential issue is attribution, which fundamentally requires some choices about how money is actually made. Even when everybody is in good faith, there are reasonable ways to agree. And people are rarely in good faith around those things.
You mentioned that attribution is to be decided when house is burnt, but that certainly not my observation. Which department is responsible for what revenue is what senior leadership fights over all the time, whether times are good or not.
This can also be seen with cost saving. There are numerous examples on HN when people wonder why reducing the cost of something by X millions was not recognized (e.g. https://x.com/danluu/status/802971209176477696). Based on my own experience, most likely explanation is that's because there was no item related to this in the financial planning to be recognized.
Damn that’s a good read and sadly rings true
Lots of the work I do now is to ensure it lasts another 25 years. Thats good, but its only the start of "my work".
It's up to me to "sell" that benefit to upper management. There's no point in assuming they'll figure it out by accident. Part of my job is enumerating the value I add.
By all means work on technical debt. But be sure to make a compelling case as to how the eradication of that debt will impact the project over the next decade. Try and throw in immediate results as well (faster, more reliable, reduced support) but more importantly translate that into terms that measure the improvement in cold hard cash.
I know it will, but I wouldn't feel comfortable without quantifying.
I have some rough idea for approaches to this, but would appreciate some external input as well
If management comes with new [crazy] ideas and/or feature [cruft] every other week it should be easy to prefer a warehouse with ready to use components over a scrap yard. If you need a set of usable tires a few times per year the scrap yard will provide. If you need a set of tires 20 times per day you want at least 200 sets of each kind stored in a convenient place. You probably live some place in between.
edit: Also, timing is everything. Write down everything you want, add the pony. Wait for the right moment when their head is not raging with 50 deadlines.
Most important imho is to not want anything but explain what options they have. If they want faster results they might be able to get them by attacking the technical debt.
Make them up. If you're uncomfortable with this, ask ChatGPT to make them up for you. Most places don't have any real way to measure productivity or rate of feature delivery, so as long as you promise a reasonable number (5-10%) they have no way of contradicting you.
Incremental refactoring is also the other classic way to do this. Slip bits into other tickets until you've slowly dragged the ship around. But it's not always possible.
Depending on the stakeholder(s) you're dealing with, approaching it like this (as risk assessment/management) might help to convey the short-term impact of a long-term problem.
It's worth keeping open the option that "now is not yet the right time".
One key way to understand the situation well is to explore both thd upsides and downsides of the issue. Its almost never an obvious decision and being acquainted with all points of view really helps both to figure out what is right, whether it's worth doing, if now is the right time, and so on.
If it was obviously necessary it would likely already have been done, so it may be necessary, but it might not yet be time.
Sometimes it comes down to groundwork. Finding out who us affected, and how. (And if you can't find those people, that's a clue too.)
Why pay off tech debt A and not tech debt B? Is this really more urgent than implementing feature C?
I have some financial debts, but I prioritise paying off some over others, and even allow myself to buy myself nice things instead of paying off the mortgage early. The same principle applies with tech debt, except I have to justify my choices to my bosses instead of to my girlfriend.
Every company I've ever worked at has more work that they would like to do than they have engineers to do it. The problem often isn't that they don't understand why fixing technical debt is important, it's to decide if fixing that particular technical debt right now is the best use of these resources right now. Also they might also know things that I might not know, like long term plans for and the relative profitability of different projects, which will affect how they make decisions. No point in spending effort fixing technical debt if that project/department is already slated for closure.
Also maybe it's a US vs EU thing, but at every engineering and IT company I've ever worked in Europe, the person two steps above me was basically always an engineer or at least has a science or technical background.
I've worked at a couple of BigTechs, where there were between 5-20x more engineers than actual work. The trade-offs are... strange in that world.
> Also maybe it's a US vs EU thing, but at every engineering and IT company I've ever worked in Europe, the person two steps above me was basically always an engineer or at least has a science or technical background.
I haven't found that to be common in the US. I've had a number of front-line managers who were (somewhat) recent engineer conversions, rarely had anyone above that level who was.
Never seen that in my life, and I've worked at small, medium, and huge companies. Sounds wild. So they actually have zero bugs in their bug tracker, and no feature on deck waiting to be built? What do they do all day?
Typical case I've seen at many companies is: Team has N engineers, with a rough capacity to fix N x 2 bugs per week. Bugs come in at a rate of N x 3, and the bug backlog is N x 80 and constantly growing until the team does periodic "bankruptcy" ritual where they mass-close N x 50 bugs that they admit they'll never get to fixing. Repeat forever.
A big chunk of the company would be off doing Greenfield projects that would mostly get cancelled before they ship, another big chunk is off working on multi-year rewrites of existing services (that never finish), every successful team sprouts spin-off teams with amorphous charters like "apply machine learning to service X"...
It's a side effect of an incentive structure that drives all the managers to grow headcount as fast as they can (since you need more reports to justify promo), and money basically growing on trees in those places
Hence you work on "huge priorities" and then they turn out to attract 2-3 tiny customers....Meanwhile you have horrendous problems with things that do sell that make them inconvenient for your customers such that they will be delighted to go elsewhere the moment they find out that your competition does it better.
Mainly to prove you can sell, not that they can buy. Selling involves understanding the customer's needs, their tradeoff preferences, your value prop and being able to reflect that back to them. The minimum bar for successful selling requires you to demonstrate a certain degree of competence and due diligence that provides assurance that you're able to operate autonomously with trust.
Nowhere is that said.
The benefit of them selling is not for the management to understand, it's for the worker to understand and be able to articulate as it will flow downstream to strategy.
Maybe the management doesn't understand but my point is it's irrelevant. I've been in management situations where I've understood perfectly well and ones where I have zero clue, my requirements for you selling to me remain exactly the same which is I'm using it as a gauge of how much you understand.
You do realise that almost all of the unicorns and almost-unicorns of the last two decades were conceived, started and built by engineers, do you? Perhaps beacuse having ones brain primed to very hard problems, does not make it so hard to learn the "hard" business skills on the side after all, all the while coding up the product? But how would former humanities students get their "tech salaries" if we did not somehow convince engineers that they suck at what are honestly said, third-tier competencies.
Because engineers are typically (although not always) terrible at business. Or marketing. Or Sales. Or whatever.
In other words, a successful business needs many skills. One of those skills is management. It's inevitable that top management (who's core skill is hopefully, well, business) needs to people to do the other skills. Marketing, Sales, Engineering, and so on.
Hence those skilled people need to communicate with management in ways in which management can understand. They can then make sure everyone has aligned goals. It's no good if engineers are doing one thing, marketing is doing something else, sales is targeting the wrong demographic, and so on.
It seems to be a unique conceit of software engineers that "management just gets in the way". When, more realistically, management is trying to communicate the business requirements, and we feel we know better.
Most engineers (again, not all) are terrible at the actual business part. The list of failed companies, multi-year solo projects that never sell a single copy, and so on are evidence of this. Joel made his name writing (literally) "The business of software".
So back to your question;
>> why do people not understanding engineering work, end up managing engineering work?
because how else will engineers know what to do?
The reason I explain the value of what I am doing (to both technical and non-technical managers) is because it helps them understand the bigger picture.
Or perhaps it helps them understand that I see the big picture, so that they know (and I know) our goals are aligned.
I am aware that not everyone is as fortunate as I am. I'd equally suggest that not many managers are fortunate enough to have engineers that can articulate what they are doing in terms they can understand.
There are plenty of managers out there who are not team players. And probably more engineers who are equally unable to see the bigger picture. Which is unfortunate because when you learn to work together towards a common goal, it really improves everything.
Try to be as objective as possible when evaluating that tech debt. It's possible (in many cases, probable) that the tech debt actually isn't as bad for the business as an engineer perceives, and it's quite possible there are other engineering efforts that are more worthy of development time and resources.
Being willing and vocal about acknowledging and accepting that reality is also quite helpful.
In my experience, only salespeople are clearly connected to profit. Everyone else is percieved as a cost.
> In other words, you’re probably depending on a kind-hearted manager (or CEO) who personally values your work.
Yes, this is the position for everybody except salepeople. Which means, in turn, that focusing your efforts to make the company profitable, as the articles advocates, is a grave mistake. You should focus on making your immediate manager profitable and successful. (For those who are fresh out of school, this is often a wildly different goal.)
The only situation in which the article’s advice makes any sense is if your immediate manager is also the company owner, who benefits personally and immediately if the company’s profits go up.
If you work at a company whose notion of value is purely dividends, get out.
The aviation industry didn’t get profitable without regulation. Safety is a big part of the value generated. Spending on safety is not spending money putting more butts in seats and selling more tickets faster. But few people will choose to fly if the risk to their safety is too great.
Software does have similar responsibilities. People hate losing their money, having their private data leaked, having their entire production run screwed up because of a software error. It can cost a business a lot of money. Cutting corners to bring new features to the table doesn’t exactly add to the value the company brings to their customers. You also need to respect their privacy, do what's required to avoid security errors, programming errors, etc.
Update: This article, and Mackenzie's advice, is decent if you're trying to survive at such a company and you can't get out yet.. for reasons. But I would aim your career towards getting out at some point because such a company will never value your work.
Then my whole department got defunded. More fool me.
Having a great boss+team in a large company is probably the most ideal — at least while it lasts.
Also matches my experience and I think I can explain why.
Small companies usually have tight social cliques (for better and for worse) which also translates to group think, more gossip, and less diversity of though as most people working there likely know each other form before or went to the same schools, worked at the same company before, etc.
Therefore if you don't click from the start with the core "gossip" group on all wavelengths, then your career prospects in the company are fucked.
Good luck anyways, I hope better times are on the horizon.
By that I mean, in order to advance in ones career (assuming an intensive research track) one needs to bring in research money (i.e. regularly apply for funding) then publish research that came from that funding.
That funding needs to be managed (so basically a small business with allocating costs to equipment, labor, etc).
Then "sell" that published research at conferences.
Then manage/mentor a variety of students (because that's a key part of your labor supply).
And maybe even teach on top of that.
In private sector you just need to focus on your work making your boss/company money and if you want to manage people, learn how to communicate (listen and speak).
If you look at what it actually takes to get promoted at most tech companies I’d say this isn’t generally true at many big tech companies.
Being on a very lucrative part of the product may not get you as much “impact” on your promotion packet as if you are working on a platform/infra touching the whole org. Even if that platform isn’t generating the company much money even indirectly.
Almost everyone is resource constrained in that the ambition of non-dev management is always 10x what they have the money to pay for. I take that back a bit - I haven't worked for FAANG so perhaps they do have more people than real work.
Ive been unhappy with my career growth in past several years, and basically it’s because I worked on products / projects that did not make a ton of money.
I knew this intellectually of course, work on revenue generating things, but emotionally I gravitate toward such reasons that it’s good for customer, or this is high risk / high reward, it’s more interesting, etc.
If I had kept this heuristic as my North Star, I would be further ahead and making more money.
I’m not sure if emotionally I could have done it - I was offered a management position if I moved OFF a high revenue product, so that would’ve been hard to say no to. But in the long run, with hindsight, it would’ve been the right choice.
Even if no customer today cares about something, a form of employee compensation that is a bit unusual, say, or 'reversed' VAT declaration in invoicing, or whatever, if large actors in your segment do, and that's most likely the case, then you should at least build things based off the formalities in the local jurisdiction so that when your sales people get a big prospect on the hook you'll have an easy time adding what they need.
It can also shield from legal or financial liabilities if someone gets angry at you, and your lawyer will be happier and possibly cheaper if they know you understand your legal environment. If you're doing an exit buyers will also appreciate good compliance, just like they appreciate other forms of risk management.
Is it? Maybe I'm out of touch, or used to a different work culture (non-US, consultant), but that's kinda obvious, you're paid because you make money.
Also, no one that knows a single teacher or nurse would ever fall into the trap of thinking that salary is proportional to job importance.
In the same companies people do care about the UI ...even when it has about 2-3 unique users per day. I won't explain how this translates to being able to function as a company at all - just to say it does because most selling is actually through salespeople.
So what I get from the OP's dose of "realism" is that everything is about perception and hopes for the future etc. The things that are making money now are assumed to be able to carry on doing so forever without attention. Just as some people buy a car and never look after it. When the day of disaster comes they're surprised.
Some companies implement new features to make a sale. So there's a continual struggle to complicate an already complicated system......but you're not allowed to refactor or spend time upgrading from gcc 4.3 or whatever because that's not work that leads to a sale. So each new feature takes more and more effort of course....and when you lose developers their replacements don't understand the convoluted codebase so bugs can't be fixed and customers don't renew their contracts.
So you do need to work for profitable companies rather than the kind of slow motion car-crash companies that are trying to do something which cannot really support itself.
But no individual manager loses anything compared to their colleagues. There is nothing for them to lose by not caring.
> “it’s so unfair that I haven’t been promoted - look at all this amazing accessibility/standards/open-source work I’ve been doing!”
Stories like these might exist, but I genuinely haven't seen a story like either case.
I really wish it were like that, but IMHO it's more of an exception to the rule than the rule. At least this is my experience of being an engineer and a manager.
Not mentioned in the article but this implies the importance of hiring. Having the right people to build the culture together, sitting in the room to discuss the priority of these things can turn a filibuster popping clown fiesta into productively working out actual competitive advantages for the company.
As many, many others have pointed out however, modern companies, especially modern tech companies, aren't operating from that mindset. Presently they're all championing products for the sake of the product itself, rather than sticking to their profit centers. It's why everyone for the past decade or so has engaged in a "checkbox race" of adding the latest fad to their product suite, regardless of its value to said product or its customers in the first place. Likewise, internal politics has shifted to prioritize those working on the "right" product, as opposed to recognizing those who create the most value. It's a large reason why enshittification continues to grow: leadership doesn't care about value, product, or engineering, so much as they want the latest shiny thing to add to their sale sheet and make the Board and/or Shareholders "happy".
My own data points supporting this theory:
* Cutting a cost-center's AWS costs by 60% and saving the equivalent of my TC every 2.5 months (~$1.3m/year) got me sent to the Private Cloud team
* Building multi-cloud showback wasn't recognized because I wasn't on the Public Cloud team (a new team rebuilt it two years after I'd finished it)
* Building a Cloud-as-a-Service model with AI Agent hooks got me RIFed
So to add a caveat to the OPs own article for others based on my own experiences: if your organization isn't prioritizing value regardless of origin, your position is unstable. In those cases, you need to either find a way onto the "right" team if the company is important to you, or you need to brush up your resume and find an exit post-haste. Creating value in a company that doesn't acknowledge or respect it is a huge red flag that I naively thought tech companies ("we're a meritocracy!") wouldn't display, but I was gravely mistaken.
We couldn't function at all if all companies failed to do work properly because of some odd decision about what's a cost and what isn't. If you have a toll bridge then fixing the bridge isn't a cost....unless you actually WANT it to fall down.
Having said that, "value" doesn't have to be measured in euros. I personally work in a semi-governmental institution, and the main focus of my team is reducing the amount of cybercrime in my country. I still need to provide that value to earn good money, but I enjoy that more than working to make investors rich (there's nothing wrong with that though, and it usually pays better).
[1] anecdotal, among my social groups, I don't really have hard data about this.
Also the part where employees have to constantly justify their own existences. I just want to work on interesting things and be left alone.
(To be fair I am exaggerating a bit, and I think the author is, too. I don't think the reality is as bad as presented.)
Truth hurts lol.
This I think is where Capitalism is at odds with a lot of people's intrinsic values. Accessibility unarguable improves people's lives and many people are in software to make the world better but yeah if you want to make as much money (or maybe just more money) doesn't mean working on even a useful item; just a much demanded one.
Corollary : This is also the reason why people (i.e. Wall Street) who are close to / handle the money earn more money. Drinking straight from the firehose.
It wasn't the best paid job, but the satisfaction when you can talk with someone who uses your product daily for obvious life improvement beats any cozy bank job.
This is a huge underdeveloped market BTW, and as the populations worldwide age it's only going to be more and more important.
The author never answers this question. He suggests that small groups of people run them but he does not elucidate what are tech compaines.
If a so-called "tech" company is not profitable, and this may comprise the vast majority of them, then the "engineer salary" comes from VC money. Essentially, a loan. The author omits this simple truth as well.
More commentary below:
https://open.substack.com/pub/therosen/p/knowing-where-your-...
"When we work on making our devices accessible by the blind, I don't consider the bloody ROI." -Tim Cook
Except that not-very-profitable Apple of the 1990s still cared about accessibility, UI, industrial design (PowerBook, Duo/dock, Newton, eMate...), and sustainability, even before the return of Steve Jobs and their subsequent meteoric rise. In the short run it probably looked like bad business, but Jony Ive started out on the Newton, after all...
They don't produce anything, at best they're taste arbiters and at worst parasitic middle men that happen to control the budget; funny how that always means they get more of it.
The best long term performing companies are run by technical people that happen to be competent managers. As soon as the professional managerial class takes over they quickly figure out their most profitable move is to cheapen out on engineering and trade in the future for bonuses right now; they'll be long gone when the company craters.
I bet the MBA who made this happen got a promotion and wouldn't understand how they crippled everyone.
I admit this is an old story but IMO it does show you how management by people who don't know and don't care screws a company quietly. That's a famous company that did in fact have a major problem.
Let’s just put the simplistic “be a profit center” thing at face value. The funny thing is that you can generate 10% surplus or 5X surplus. The difference in benefit to the company is large. But your benefit might not be much. Maybe a wage increase, maybe not. Maybe better job security.
Now others have already questioned the “profit center” line here. With so much alienation in the work force it becomes laughable to claim that you can point to a group of individuals as “the profit center” or “the cost center”. This reeks of political jockying. Is Sales the profit center? Without Sales nothing would be sold... but without Engineering there would be no product.
What ends up happening is that the people who insist the loudest are the ones who get promoted to Profit Center. Maybe.
If low-level workers are a 'cost centre', why don't companies just get rid of them? Wouldn't they be more profitable if they removed everyone outside the 'profit centre' of senior management? Obviously not.
'cost centre' does not mean a place that a capitalist is unable to perform exploitation. A cost center in Marxist terms can be understood as a department that participates in the money-commodity-money' (MCM') flow but doesn't directly complete the circuit to M'.
For example, delivering and receiving mail does not realize profit for most companies, but is an essential part of the business. If they spend $1,000,000 on the mail department in Q1, spending $2,000,000 in Q2 is likely to waste the extra $1,000,000. But spending zero in Q2 would cripple the company. That's a cost centre.
> If your work isn’t clearly connected to company profit, your position is unstable
You know what really makes your position unstable as an engineer? Delaying a product over "safety" concerns, thereby doing work that's clearly connected to preventing company profit. Only young, bright-eyed engineers would be naive enough to bring up safety concerns right?
Ugh, this.
After doing SRE for nearly a decade and being utterly pigeonholed, I've come to believe it's more accurately placed in the "controlled opposition" bucket than anything about either reliability or engineering.