Comment by PeterStuer
13 days ago
"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.
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.
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!
By the end of this message I felt like I was having a stroke. Wut?
Reminds me of Steve Jobs on consulting: https://www.youtube.com/watch?v=-c4CNB80SRc
Chief executives are so often transients.
> 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.
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.
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.
make those with power like you and rewards will flow
relation to company profitability is optional and often times counterproductive
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.
Thank you. I tend to be clueless on office politics, and this is actually a really helpful reminder.
Gee, you said what I’ve been thinking for years.
Yep, this. Being aligned with an influential and well-liked manager is probably the biggest indicator of your overall career trajectory at a company.
In my career experience, this type of successful and well-liked manager is likely to jump ship for a better offer.
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.
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.
> 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.
What if they're right, and at a certain point engineering is a commodity?
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.
Most labor is a commodity in this system “past your key positions” (overpaid execs).
1 reply →
It is, until it isn't. Basically modern tech management is about flying as close to commodified engineering sun as possible without burning up.
I like this. Engineering is not a commodity in general but management “adds value” by ensuring engineers are interchangeable.
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.
Perhaps that was true 50 years ago, but in an increasingly complex technological world, problems simply cannot be solved without increasingly advanced engineering skills.
The overwhelming majority of software engineers are building garden-variety CRUD apps.
3 replies →
[dead]
The other departments are arguably more so. Law, sales, finance, marketing.
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.
1 reply →
HR, management…
What if?
Are they?
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.
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.
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.
> 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.
6 replies →
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.
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.
Someone who says yes for too long, doesn't blast- out of the airframes plug.
> 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.
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.
"Everyone thinks their job in the Silo is the most important. Mine actually is." -- Juliette Nichols (also some Software Engineers)
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.
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.
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.
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.
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.
But also company actually is much better off when it is not held hostage by couple of technical employees.
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.
There's a subtle but very important difference between making sure nobody is a "single point of failure" or bottleneck (heck, most great engineers will actively work with management to make sure they're not single points of failure!), and recognizing that engineers are not fungible resources and should not be treated as such.
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.
> most great engineers will actively work with management to make sure they're not single points of failure!
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.
3 replies →
Would you say that the atom bomb project was held hostage by a couple of technical physicists?
Obviously it can't succeed (in the desired time frame) without those specific people, and pretending like it can is lunacy.
Functionally 0% of companies are working on things as important or impactful as the atom bomb, and I include FAANG et al in that. Maybe a small handful of AI companies will actually put out something that important? But even most of them won't.
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.
3 replies →
Is it better when it's held hostage by a couple of non-technical employees?
Non-technical employees are by definition replaceable.
Unless they are sales reps that have good relations with customers.
1 reply →