Knowing where your engineer salary comes from
183 comments
·April 6, 2025PeterStuer
hayst4ck
Admiral Rickover was likely the single most competent engineering manager in the last century and wrote this: Doing a Job https://govleaders.org/rickover.htm
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.
briankelly
Reminds me of Steve Jobs on consulting: https://www.youtube.com/watch?v=-c4CNB80SRc
weitendorf
The thing is, Rickover was working on nuclear submarines for the US between 1950 and 1958. He could attract the best engineers because nuclear energy was THE cutting edge technology of the time, the budget was enormous, the project was extremely interesting, and people were literally building something that they thought would protect them and their families from a nuclear attack from the USSR (or another Holocaust; Rickover was Jewish).
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!
Aeolun
By the end of this message I felt like I was having a stroke. Wut?
eVeechu7
Chief executives are so often transients.
Aurornis
> Most of management, past first-gen if the company was founded by engineers, is non-technical.
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.
fatnoah
It's multilayered. I've had technical and non-technical bosses at large and small companies, and the universal thing that made them "good" or "bad" was whether they gave me sufficient context and trusted me to get the work done. The best ones challenged me in good faith and provided honest feedback.
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.
eek2121
I would love to work for a company like that. It seems like my experience with companies that have “people” vs folks with engineering experience is worse overall. My favorite jobs had all engineering talent, and management was smart enough to stay out of the way.
throwaway98797
make those with power like you and rewards will flow
relation to company profitability is optional and often times counterproductive
shalmanese
OK, but the people who keep on harping on this never seem to mention that the boss "liking you" is not about you cracking jokes and bringing in muffins on Thursday. It's about you being low drama and helping them achieve their KPIs in a way that helps them get promoted so they can bring you along with them.
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.
thevillagechief
Thank you. I tend to be clueless on office politics, and this is actually a really helpful reminder.
stogot
Gee, you said what I’ve been thinking for years.
dclowd9901
Yep, this. Being aligned with an influential and well-liked manager is probably the biggest indicator of your overall career trajectory at a company.
supportengineer
In my career experience, this type of successful and well-liked manager is likely to jump ship for a better offer.
A4ET8a8uTh0_v2
Basically, yes. You still should be able to make easy for those in power to argue that you 'deserve' it, but the dynamic is impossible to deny.
null
pc86
I can't think of a scenario where it's directly counterproductive, at least not to the point where its counterproductivity overshadows the degree to which the people who make decisions like you.
commandlinefan
> decades of experience have disproved that
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.
tqi
What if they're right, and at a certain point engineering is a commodity?
ebiester
It is, but at some point, so is management. So is any human capital past your key positions.
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.
keybored
Most labor is a commodity in this system “past your key positions” (overpaid execs).
acedTrex
It is, until it isn't. Basically modern tech management is about flying as close to commodified engineering sun as possible without burning up.
sudoshred
I like this. Engineering is not a commodity in general but management “adds value” by ensuring engineers are interchangeable.
hayst4ck
A job is a commodity if your manager knows how to do your job right now.
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.
arijo
Perhaps that was true 50 years ago, but in an increasingly complex technological world, problems simply cannot be solved without increasingly advanced engineering skills.
HeyLaughingBoy
The overwhelming majority of software engineers are building garden-variety CRUD apps.
bentcorner
[dead]
mkoubaa
The other departments are arguably more so. Law, sales, finance, marketing.
pc86
Have you never worked in an organization that survived off of outside sales and employed really, really good sales teams? Of all the departments listed, engineering included, sales would probably be the last one I would consider a commodity.
hosteur
HR, management…
fmbb
What if?
Are they?
nyeah
This is an important point. But it doesn't conflict severely with the article.
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.
dirtybirdnj
I think your comment can be boiled down to "management doesn't respect engineers"
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.
ebiester
Let me take the opposite point - it isn't that management does or doesn't respect engineers, but that it does not respect them more or less than sales, or product, or marketing, or legal, or any other part of the system.
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.
throwway120385
> 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.
bee_rider
I generally believe engineering is right in this sort of hypothetical. But, at some point if they really are focusing on code quality… I mean, ultimately the point of code quality is to deliver features/reduce maintenance over the long run, right? So if they really are doing a good job of improving code quality, over the long run they should have a good relationship with management and the political capital to make this request.
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.
jack_h
Code maintainability could be analogized to 5S in the manufacturing world. As a hypothetical let's say someone started assembling some product on the bare concrete warehouse floor because they had a pressing order to fill. A few months later it's just a mess of parts strewn about the floor that workers have to sift through to find the correct pieces for the assembly. The goal of a business is to make money, not have a clean workspace as a sibling comment mentioned. Ultimately this would leave a company vulnerable to a competitor who doesn't have such an expensive and inefficient production process though.
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.
InDubioProRubio
Someone who says yes for too long, doesn't blast- out of the airframes plug.
danaris
> Some MBA or book somewhere convinced people that respect and dignity were optional.
Whatever the origin, this is actually a very serious problem that afflicts our society at large, well beyond MBA culture.
harrall
Software engineers tend to downplay artists, designers, marketing and product.
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.
sunrunner
"Everyone thinks their job in the Silo is the most important. Mine actually is." -- Juliette Nichols (also some Software Engineers)
hnthrow90348765
Personally I think it's just their social circles that reinforce this, not the boogeyman MBA stuff. Because at some level, yes, they can be intimidated by technical people and this is a defense to avoid the "why am I even employed" spiral.
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.
Clubber
I think they take them for granted not realizing that things can get much worse. I think they do this because they don't understand it. Ever been on a call with a company and they have to tell you, "You'll have to call back, our systems are down." This can cost millions an hour.
Fruitmaniac
I'm an engineer with an MBA and they definitely don't teach in business school that respect is optional. It's just something bad managers do all on their own.
smugglerFlynn
CTO is "management" by definition. Do you mean to say most companies have non-technical CTOs who treat engineering as commodity?
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.
pc86
C-suite executives are "management" only insofar as they are someone's direct supervisor and that person wants to make them happy. And if you've got brand new managers with single-digit years of experience reporting to them, sure they probably do a fair bit of people management. But that's not the norm. If you're at a sufficiently large company you'll have Presidents reporting to the C-suite, 3-5+ levels of VPs below that, 1-3 levels of directors, and a level or two of individual contributors. So you're approaching double-digit numbers of people between C suite and the people who should theoretically actually need day-to-day performance management.
There is not a competent Executive Vice President or Division President in the world that needs to be managed by their boss.
cdavid
This article makes the naive assumption that "what is making money" is an objective thing.
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.
t43562
Thank you. "Spearheading" is always valued and the way to do it is to leave for some new initiative somewhat before everyone realises the current one is a turd. The blame then attaches to the people left holding the turd.
Hjack
But still there are objective metrics by which you can track which products are making money and which are not. You can do ALL the financial manipulation to an extent, but everyone above bragging VPs/Directors know which product lines are making money yoy
cdavid
Say you are meta. You know that a big stream of revenue is ads. You are an engineer working for one of the myriad ML model around feeds, ads click prediction, whatever. Those ML models are in production, and cost a lot of money to maintain / operate. How much you are a cost center or a money maker will depend on a lot of non objective choices.
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.
Hjack
Ads are still bread and butter for Meta. The first to go will be the folks who are in vogue bcoz of cultural reasons, eg. diversity, green, etc. I would even go the extent of saying that a lot of open source maintainers will also be axed, the day Meta stops making ad money and fights for survival. The issue of `attribution` is to be decided at last, when anyway the house is partially burned and the company is fighting for survival. I am talking about the initial phase, where a lot of engineers work on teams that make no monetary/value sense for company and are there, bcoz manager/CEO don't care or are kind(mostly former).
Anon1096
You have chosen a very very poor example in calling out Meta Ads. I can assure you that the entire org has a massive magnifying glass over it with insane amounts of data analysis, every % change in revenue is absolutely attributable to exactly what group brought it about whether it be DC hardware, ML teams, or backend infra. It is the lifeblood of Meta with many billions flowing through it of course it isn't just being cowboy'd with random changes that have undefined impact on yoy revenue.
blackhaj7
Hadn’t read “how to get promoted” before!
Damn that’s a good read and sadly rings true
bruce511
I work on a product that has been built over 25 years. Lots of the work I did years ago is to ensure the product longevity.
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.
moduspol
100%, although also:
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.
Fire-Dragon-DoL
How do you put numbers in there usually? I'm facing an issue at work where an important factor should be done to correct a serious design mistake, but it doesn't get in the way of any feature. It's probably the cause of a lot of loss of development time over the lifetime of the project, but I don physically know how much of a boost will it give to development.
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
jeffparsons
One way to communicate this is in terms of _schedule risk_, rather than straight-up lost productivity. E.g. for a particularly troublesome design flaw, you might estimate that for any given 4-week project there's a 20% risk of the project blowing out by an extra week due to that flaw.
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.
bruce511
It can be tough, and in some cases measurable numbers are hard to find. That can make prioritization hard.
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.)
Fire-Dragon-DoL
Indeed, I was the one suggesting to not do the refactor because I couldn't find a reason. Today at standup though, a task that would take 1 hour once the refactor is done, will probably take about 2 days instead, so i'm back thinking about it (the refactor would take longer than 2 days)
6510
I only do small solo projects but the value from maintainable code depends on how often it needs to be updated.
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.
pjc50
> How do you put numbers in there usually?
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.
hansmayer
I get your point at the basic level, but as engineers and managers, we need to stop this nonsense. Think deeper about why do you need to "sell" your work inside (some) companies ? Could it be because those companies are full of people who somehow occupy important positions without understanding the basics of the engineering work. What's the value such busywork managers are adding, besides the anti-value of layers of explanatory communication and wasted time? The busywork folks should be working to understand where their salaries are coming from, not the engineers. Note that I am not saying all managers are useless (its also a part of my job), it's the people-and-ideas-managers who are useless in the technical setting. The point about technical debt should be a non-issue, why the hell would you have to explain that the technical debt is a bad thing? Did we not clear this issue many times over and establish zero technical debt as an engineering ideal a long time ago? Well it is because some person with 1/4 of your experience and competence somehow got lucky and talked themselves into one or two hierarchical positions above you. We need to start a pushback across the industry and stop allowing former accountants and humanist science graduates into "leadership" roles in IT.
dagw
Could it be because those companies are full of people who somehow occupy important positions without understanding the basics of the engineering work.
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.
t43562
Sometimes they're looking for the next big product that will make millions but IMO they never really stack the odds of that working against the chance of losing current business through not updating, improving their current offering to make it e.g. more sticky.
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.
swiftcoder
> Every company I've ever worked at has more work that they would like to do than they have engineers to do it
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.
dave4420
There’s a difference between management knowing that it’s worth paying off tech debt in general, and management knowing that now is the right time to pay off this piece of tech debt in particular.
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.
m_rpn
Man, you are making too much sense, somebody is going to have his feelings hurt by your words. Management is now trying to have even more control on the people that actually do things, and AI is being used as scapegoat to entrench their position. The reason is fear, because most managers couldn't do even 1/10 of the work people under them can do.
bruce511
Fortunately I don't work in such an organization, and I have extremely competent in my chain of command.
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.
hansmayer
Please don´t take it as trolling - but if your higher ups are as competent as you say: why do you need to help them with the big picture ? Shouldn´t they be the ones setting it or at least directing? I am saying this because topics like improvement of performance and reduction technical debt were established as drivers of revenue a long time ago. That is why Amazon optimised the sh*t out of their checkout process and Google (before they were took over by the business types) obsessed about page loading times. Oh coincidentally - that was also the time when major tech companies were run mainly by engineers. Is that why their products used to be so much better? Too many "busyworkers" are now wasting everyone's time by having engineers explain "the big picture" so that they can present it at some meeting and take credit for. And in the process, the products get more entshittified every damn day.
shalmanese
> Think deeper about why do you need to "sell" your work inside (some) companies
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.
hansmayer
No, actually. He said it was a part of his job because they did not understand his work? So we are back at square one here, why do people not understanding engineering work, end up managing engineering work?
bruce511
That's an excellent summary!
chrisweekly
"zero technical debt" is a pipe dream. Not all tech debt is equal; think "low-interest student loan or mortgage" vs "high-interest credit cards or payday loans".
hansmayer
Well, that is why I said it was an ideal, something to strive for. Since we are in lecture-mode here, ever heard of objectives and key results? Think that would be a more fitting alternative to your black-and-white metaphor of low-interest vs. payday loan ...
agentultra
Mackenzie’s analysis holds a grain of truth and remains too simplistic.
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.
BJones12
The profitability problem in the aviation industry was not a lack of regulation. The profitability problem was simply that there were a lot of countries pouring money into their flag-carrying airlines to enable them to operate at a loss. Since many competitors wanted to operate at a loss, the entire industry operated at a loss.
teddyh
> If your work isn’t clearly connected to company profit, your position is unstable
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.
mirawelner
This sort of thing is why I decided to do research so I could work at universities and small startups! I figured that way I could be away from the corruption and selfishness that exists in large tech companies.
Then my whole department got defunded. More fool me.
BobbyTables2
I’ve also found some small companies have even worse politics and infighting than large companies.
Having a great boss+team in a large company is probably the most ideal — at least while it lasts.
FirmwareBurner
>I’ve also found some small companies have even worse politics and infighting than large companies.
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.
em500
Sayre's law: "Academic politics is the most vicious and bitter form of politics, because the stakes are so low."
52-6F-62
Even many of those small startups are in the pocket of some unfavourable characters.
sightbroke
I would think there's almost more pressure in academia compared to private sector to sell your work as valuable.
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).
kbrkbr
Well, I left academia 20 years ago, because of the perceived corruption and selfishness. I guess you just need to be lucky, no matter where you go.
Good luck anyways, I hope better times are on the horizon.
cjs_ac
I think this is a problem that arises from people working in these gargantuan organisations where individuals can't see how their work contributes to the success of the organisation. They perceive the organisation as a construct built around social relationships rather than a construct that exists to drive some change in or generate profit from the surrounding economy, because they can't see how their work drives that change or generates that profit.
ttoinou
Or they’re not trying to understand how it works
ikiris
I can see how my work applies just fine, that doesn’t mean my VP+ agrees.
moolcool
But the relationships are what affords that change though, isn't it?
tybit
> At successful tech companies, engineering work is valued in proportion to how much money it makes the company
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.
xivzgrev
Oof this article hits like a kick to the nuts.
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.
sanitycheck
It's very surprising to me that this needs to be said - but maybe that's because I've mostly worked in, let's say, 'resource constrained' environments. You focus on the stuff that keeps the money coming, or people start losing their jobs.
t43562
Is that on the things that make money now or the speculative things you might make money on later?
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.
thundergolfer
The author works at Github, so yes not so much a "resource constrained" environment. It matches my experience at a high growth company, Canva, where in places it was easy to see the connection to profit and in other places quite hard. There were people that didn't care about their connection to profit, and there were expensive employees doing "good work" done merely because it was good to do. Canva could do that because its margins are 80+% and it made almost $1B in revenue at the time.
cess11
My pet peeve in this area that pretty much always gets overlooked by technical people even if they're somewhat experienced in management and business, is compliance. It's always good and profitable to adapt to and preferably implement representations of laws and regulations, including 'soft' rules, like standard contracts, established business practices, non-compulsory laws, things like that.
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.
tonnydourado
> It’s easy to fall into the trap of thinking that you get paid for work because it’s important
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.
hiddencost
[flagged]
"At successful tech companies, engineering work is valued in proportion to how much money it makes the company"
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.