"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 Jobhttps://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!
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.
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.
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.
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.
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.
I often struggle to understand what executives do all day. I work (and have worked in many different orgs) with executives quite a bit, see insight into their process, and often come away underwhelmed instead of more confident in leadership.
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)
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.
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.
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?"
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.
So, I absolutely agree here that an engineering manager has to have the insight to tell truth from catastrophising on both sides. At the same time, I've seen sales orgs drive a department into the ground where everything comes to a screeching halt. I've seen times where that "feature X" is vaporware. Times when feature X is possible there because of different architecture choices. Newer entrants who learned from the older entrants. Features that look great for smaller customers that can't scale.
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.
In most organizations the engineering manager would share that prioritization responsibility with a product manager who acts as the voice of the customer. One simple approach is to just divide team capacity into two buckets: 80% for new features and customer bug fixes, 20% for tech debt. The specific percentages can vary based on circumstances.
"Some portion of your time is reserved to work on whatever you want to work on with no input from outside your small team" does not work long term and it does not work at scale.
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."
Nah. I've seen that kind of capacity allocation work just fine on large teams and programs. It's not "whatever you want", the tech debt payments still have to be justified with escalating levels of approval required depending on effort and risk.
This comment shows great understanding and experience. Too often engineers treat work like their pet/FOSS project and forget it's a business, and businesses are in business to make money, not pretty code bases.
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.
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.
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.
The company not being able to run without you doesn't mean you have job security, it just makes the company hurt more when they fire you based on someone's spreadsheet.
Good managers will recognize that and know what those kinds of engineers are doing. Every company should have at least some good managers - seek them out, it's worth it. If you can't find one in current company, try to switch company - again, it's worth it IMO.
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.
That isn't the point; It's not about the importance
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.
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.
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.
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
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.
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).
Sure, but things like DEI, OSS, are tiny minority in most companies. At least they were in the companies I've worked at.
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.
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.
I am not saying mature companies are "YOLO-ing" this randomly, but that many assumptions are made about how the input metrics trickle back to revenue/profits, and those can change. The attribution exists, but how it is done is far from an objective thing. E.g. how do you translate CTR into revenue ? How do you value an additional user ?
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.
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.
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.
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
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.
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.)
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)
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.
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.
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.
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.
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.
> 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.
> 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.
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.
No, the company obviously makes up work to occupy their spare engineering capacity - but the point in that era of BigTechs was to hoover up all the engineering talent, whether or not you needed it.
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
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.
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.
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.
> 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.
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?
>> So we are back at square one here, why do people not understanding engineering work, end up managing engineering work?
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?
> 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.
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.
> Because engineers are typically (although not always) terrible at business. Or marketing. Or Sales. Or whatever.
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.
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.
"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".
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 ...
It's not an ideal. There is an optimal level of technical debt to maximize shareholder value. Eliminating all technical debt makes no more sense than eliminating all financial debt. Used effectively, debt is a powerful lever. The trick lies in finding the optimal level based on incomplete information, and many corporate managers aren't very good at this.
By stating it should be zero, it is literally, by definition an ideal. That is not something you can decide on. Maximising shareholder value? Now, that is an ideal which is a root cause of many evils today.
> 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.
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.
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.
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.
>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.
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).
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.
> 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.
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.
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.
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.
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.
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.
My software engineer job is to destroy my own position by solving all the problems and automating the job away. I have done it multiple times over my career.
I usually tell new hires this often; understand how this company makes money. Is engineering seen as a necessary cost or income multiplier on the balance sheet.
In most companies, it falls in the land of IT, a cost center.
I have often ended up working on the billing system - nobody cares if it functions and I don't know why. It pulls in the money every month and if it makes mistakes the company loses money.........!!!!.....
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.
> nobody cares if it functions and I don't know why. It pulls in the money every month and if it makes mistakes the company loses money.........!!!!.....
But no individual manager loses anything compared to their colleagues. There is nothing for them to lose by not caring.
> I regularly see stories like “I convinced my idiot bosses to finally let me do only tech debt work, and would you believe they fired me after a few months?”
> “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.
> At successful tech companies, engineering work is valued in proportion to how much money it makes the company (directly or indirectly).
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.
Well said. Young engineers must understand that there is no problem more sales can't fix. Your brilliant solution to problem X must pass the sales test for it to be considered a true success story for your company.
This article offers advice for ICs. Well-meaning managers should remember to set up the analytics to connect work to revenue. That which is not measured is not valued, so be sure to measure what matters.
Metrics for things like FCP, better screenreader and refactor are less straightforward so having the capability to correctly evaluate the cost and benefits, making the right judgement calls and communicating it to everyone is vital.
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.
The whole trend of cracking FAANG/MAANG interviews has made this notion of not having self-awareness/understanding of where money comes far more entrenched. Folks who crack these interviews feel like they are passing sermons from top of 'tech' hill to other noobs, not knowing in effect that their minuscule value is as long is company is making profit. The day that stops, everyone's job is on the line and especially folks who are away from centers which make money.
The article makes good career advice in general: understand what pays your salary, and contribute enough such that your costs are offset by your labor. For engineers, that means understanding how the company makes money, or how you can save the company money, and then focusing on those things.
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.
It is not the responsibility of the rest of society to pay you a handsome salary for a programming hobby. If your code isn't generating enough value that someone wants to pay for it, it's about as useful as model trains.
I never said it is. I responded to the question about "what's sad about it", and having idealistic ideas about the IT is common among newer/fresh programmers. And (almost?) nobody wants to feel like a replaceable money making pawn, most[1] people in IT value self-realisation at least a bit. And some successfully gaslight themselves into believing that their backend work on their ad-sponsored e-commerce CRUD is somehow making the world a better place.
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.
I wouldn't take it quite as seriously as it takes itself. These articles like to lay down a view of the universe as if it was the first and last word but I don't think it is at all.
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.
The part where employee whose work improves the life of people around them (by refactoring, work on tech-debt), or the life of people around the world in general (open source, accessibility, etc.) isn't rewarded financially. And somehow capitalists want me to believe people working to advance their own self interests will collectively benefit the society at large.
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.)
Interesting article. I’m currently trying to justify “tech debt” to upper management. The way I try to communicate it: we can move faster and better on business requirements if we delete unused code/upgrade legacy dependencies/etc. Both need to happen at the same time, though, and that’s where it gets hard: “this feature request would be so much easier if I upgraded to Angular vlatest” runs the risk of always paying tech debt and never providing value.
Anecdotally, working in profit centres (and being a productive member of said centres) somewhat protected me from large layoffs, but that’s pretty much it. There isn’t much otherwise that ever shielded me (or any of my team members, as a team lead somewhat involved in these decisions) from being expensive line items, in the eyes of people some levels above my pay grade taking business decisions looking at a balance sheet.
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.
> They throw themselves into various pieces of work that don’t make money ... better screenreader support
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.
I worked at a company that makes machines reading books/press/whatever to people with impaired vision (or altogether blind).
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.
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.
This line triggered me a bit, but later on they do give examples of how accessibility can be profitable. I think "not getting huge fines" due to (very important) laws, is a great example.
Replace "profitable" with "popular with management" and you're right on the money. Just don't get caught holding the hot potato when the wind shifts. And good luck figuring out when that is.
I think the biggest career mistake engineers make -- myself included -- is assuming your contributions will be automatically recognized when in fact the amount of credit you receive is equal to how much you contributed multiplied by the amount of attention you draw to it.
I mean, I've never worked with a project manager who generated one iota of business value... Just stirring up drama, inserting themselves into decisions that they can't understand, and calling unnecessary meetings with management that they should be handling on their own. I think there's a lot to be said for simple visibility to management. Also, ignorant overconfidence seems to be something that management loves.
> If you want your work to be valued (i.e. you don’t want to be reshuffled or fired), and you want to work on personally-satisfying features like accessibility, or UI polishing, or anything else not directly connected to profit - you need to go and work for a very profitable company.
"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...
OK, now explain where management's salary comes from.
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.
Absolutely. Some genius outsources IT to Malaysia....I ask for an IP address to be statically assigned to a test machine and the ticket is opened and closed.....next day the IP has changed. Repeat x20 till we give up - telephone calls and complaints notwithstanding. Someone closes 20 tickets and looks productive because that's the way they're being managed.
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.
From the perspective of the business, you need to generate more money than your wage plus whatever else expenses that are associated with your employment. This surplus is what adds up to the profit.
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.
These Silicon Valley folks really ought to read some Marx.
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.
I'm not sure you understand Marx. The author probably has read Marx during their philosophy training.
'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.
Marx was a techno-utopian sci-fi author who insisted his fiction was non-fiction and was proven wrong 100 years ago. Where is the dictatorship of the proliteriat?
Running companies like this is how you end up with the current state of Boeing. Only valuing engineers who are directly earning you profit and firing the ones who only have an indirect role in your profit centers.
> 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?
> Or even worse, engineers who are preventing you from making profit over "safety" concerns.
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.
"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).
I often struggle to understand what executives do all day. I work (and have worked in many different orgs) with executives quite a bit, see insight into their process, and often come away underwhelmed instead of more confident in leadership.
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)
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.
Engineering might be a commodity if you're "building garden-variety CRUD apps"
But a lot of companies aren't - or at least, they don't think they are.
Which is like saying most software is reading, modifying and writing memory. Technically true, but not at the level it tells the story.
If that was really true, the world would need only ONE generic CRUD app. It just needs to operate at scale.
[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.
If it's b2b SaaS sales is probably more important than engineering. If you're designing flight control software it isn't.
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.
So, I absolutely agree here that an engineering manager has to have the insight to tell truth from catastrophising on both sides. At the same time, I've seen sales orgs drive a department into the ground where everything comes to a screeching halt. I've seen times where that "feature X" is vaporware. Times when feature X is possible there because of different architecture choices. Newer entrants who learned from the older entrants. Features that look great for smaller customers that can't scale.
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.
In most organizations the engineering manager would share that prioritization responsibility with a product manager who acts as the voice of the customer. One simple approach is to just divide team capacity into two buckets: 80% for new features and customer bug fixes, 20% for tech debt. The specific percentages can vary based on circumstances.
"Some portion of your time is reserved to work on whatever you want to work on with no input from outside your small team" does not work long term and it does not work at scale.
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."
Nah. I've seen that kind of capacity allocation work just fine on large teams and programs. It's not "whatever you want", the tech debt payments still have to be justified with escalating levels of approval required depending on effort and risk.
This is an important point. Many people lose sight of the idea that tomorrow doesn't matter if you don't survive today.
This comment shows great understanding and experience. Too often engineers treat work like their pet/FOSS project and forget it's a business, and businesses are in business to make money, not pretty code bases.
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.
The company not being able to run without you doesn't mean you have job security, it just makes the company hurt more when they fire you based on someone's spreadsheet.
Tell that to the gatekeeping engineers who think otherwise.
Good managers will recognize that and know what those kinds of engineers are doing. Every company should have at least some good managers - seek them out, it's worth it. If you can't find one in current company, try to switch company - again, it's worth it IMO.
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.
That isn't the point; It's not about the importance
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.
My point is 90% of companies have no specialized knowledge whatsoever and are staffed almost entirely by web developers.
How many companies have an in-house tuned graph database? How many companies have custom Linux kernels? How many companies have custom filesystems?
90% of companies don't need to think too deeply about compensation, then.
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.
In that case, all employees bar sales reps are replaceable (and the reps are too, you just see the pain more).
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.
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.
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
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.
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).
Sure, but things like DEI, OSS, are tiny minority in most companies. At least they were in the companies I've worked at.
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.
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.
I am not saying mature companies are "YOLO-ing" this randomly, but that many assumptions are made about how the input metrics trickle back to revenue/profits, and those can change. The attribution exists, but how it is done is far from an objective thing. E.g. how do you translate CTR into revenue ? How do you value an additional user ?
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.
Hadn’t read “how to get promoted” before!
Damn that’s a good read and sadly rings true
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.
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.
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
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.
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.)
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)
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.
> 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.
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.
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.
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.
> 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.
> 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.
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.
No, the company obviously makes up work to occupy their spare engineering capacity - but the point in that era of BigTechs was to hoover up all the engineering talent, whether or not you needed it.
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
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.
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.
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.
> 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.
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?
>> So we are back at square one here, why do people not understanding engineering work, end up managing engineering work?
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?
> 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.
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.
> Because engineers are typically (although not always) terrible at business. Or marketing. Or Sales. Or whatever.
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.
You replied to the wrong person in the thread.
That's an excellent summary!
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.
"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".
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 ...
It's not an ideal. There is an optimal level of technical debt to maximize shareholder value. Eliminating all technical debt makes no more sense than eliminating all financial debt. Used effectively, debt is a powerful lever. The trick lies in finding the optimal level based on incomplete information, and many corporate managers aren't very good at this.
By stating it should be zero, it is literally, by definition an ideal. That is not something you can decide on. Maximising shareholder value? Now, that is an ideal which is a root cause of many evils today.
Your claim of zero being the ideal level is not supported by any reliable data. You aren't qualified to make any statements about ideals.
I am not sure you see the irony in your own statements.
> 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.
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.
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.
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.
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.
>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.
Sayre's law: "Academic politics is the most vicious and bitter form of politics, because the stakes are so low."
https://en.wikipedia.org/wiki/Sayre%27s_law
Even many of those small startups are in the pocket of some unfavourable characters.
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).
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.
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.
I can see how my work applies just fine, that doesn’t mean my VP+ agrees.
Or they’re not trying to understand how it works
But the relationships are what affords that change though, isn't it?
> 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.
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.
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.
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.
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.
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.
> 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.
[flagged]
My software engineer job is to destroy my own position by solving all the problems and automating the job away. I have done it multiple times over my career.
I usually tell new hires this often; understand how this company makes money. Is engineering seen as a necessary cost or income multiplier on the balance sheet. In most companies, it falls in the land of IT, a cost center.
I have often ended up working on the billing system - nobody cares if it functions and I don't know why. It pulls in the money every month and if it makes mistakes the company loses money.........!!!!.....
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.
> nobody cares if it functions and I don't know why. It pulls in the money every month and if it makes mistakes the company loses money.........!!!!.....
But no individual manager loses anything compared to their colleagues. There is nothing for them to lose by not caring.
> I regularly see stories like “I convinced my idiot bosses to finally let me do only tech debt work, and would you believe they fired me after a few months?”
> “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.
> At successful tech companies, engineering work is valued in proportion to how much money it makes the company (directly or indirectly).
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.
Well said. Young engineers must understand that there is no problem more sales can't fix. Your brilliant solution to problem X must pass the sales test for it to be considered a true success story for your company.
This article offers advice for ICs. Well-meaning managers should remember to set up the analytics to connect work to revenue. That which is not measured is not valued, so be sure to measure what matters.
Metrics for things like FCP, better screenreader and refactor are less straightforward so having the capability to correctly evaluate the cost and benefits, making the right judgement calls and communicating it to everyone is vital.
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.
The whole trend of cracking FAANG/MAANG interviews has made this notion of not having self-awareness/understanding of where money comes far more entrenched. Folks who crack these interviews feel like they are passing sermons from top of 'tech' hill to other noobs, not knowing in effect that their minuscule value is as long is company is making profit. The day that stops, everyone's job is on the line and especially folks who are away from centers which make money.
The article makes good career advice in general: understand what pays your salary, and contribute enough such that your costs are offset by your labor. For engineers, that means understanding how the company makes money, or how you can save the company money, and then focusing on those things.
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.
I have no words. this is just… so sad.
Which part?
If you don't want to feel like a cog in a heartless money making machine, all of it.
It is not the responsibility of the rest of society to pay you a handsome salary for a programming hobby. If your code isn't generating enough value that someone wants to pay for it, it's about as useful as model trains.
I never said it is. I responded to the question about "what's sad about it", and having idealistic ideas about the IT is common among newer/fresh programmers. And (almost?) nobody wants to feel like a replaceable money making pawn, most[1] people in IT value self-realisation at least a bit. And some successfully gaslight themselves into believing that their backend work on their ad-sponsored e-commerce CRUD is somehow making the world a better place.
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.
I wouldn't take it quite as seriously as it takes itself. These articles like to lay down a view of the universe as if it was the first and last word but I don't think it is at all.
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.
The part where employee whose work improves the life of people around them (by refactoring, work on tech-debt), or the life of people around the world in general (open source, accessibility, etc.) isn't rewarded financially. And somehow capitalists want me to believe people working to advance their own self interests will collectively benefit the society at large.
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.)
Interesting article. I’m currently trying to justify “tech debt” to upper management. The way I try to communicate it: we can move faster and better on business requirements if we delete unused code/upgrade legacy dependencies/etc. Both need to happen at the same time, though, and that’s where it gets hard: “this feature request would be so much easier if I upgraded to Angular vlatest” runs the risk of always paying tech debt and never providing value.
Anecdotally, working in profit centres (and being a productive member of said centres) somewhat protected me from large layoffs, but that’s pretty much it. There isn’t much otherwise that ever shielded me (or any of my team members, as a team lead somewhat involved in these decisions) from being expensive line items, in the eyes of people some levels above my pay grade taking business decisions looking at a balance sheet.
"What are tech companies?"
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.
> They throw themselves into various pieces of work that don’t make money ... better screenreader support
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.
I worked at a company that makes machines reading books/press/whatever to people with impaired vision (or altogether blind).
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.
That is why laws like the ADA exist: to give companies a financial incentive to make their products accessible.
https://x.com/ben_el_baz/status/1908063819966067048
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.
This line triggered me a bit, but later on they do give examples of how accessibility can be profitable. I think "not getting huge fines" due to (very important) laws, is a great example.
Are any jobs really secure? You still need to show output if you’re in a profit center, and sometimes things happen outside your control.
More commentary below:
https://open.substack.com/pub/therosen/p/knowing-where-your-...
Replace "profitable" with "popular with management" and you're right on the money. Just don't get caught holding the hot potato when the wind shifts. And good luck figuring out when that is.
And make sure your bosses boss knows who you are and how good you are, so that they'll want to keep you when your boss ends with said potato.
Positioning is key in sports and in corporations.
Haha, that's the most practical way to put it compared to the theoretical blog post.
I vaguely remember the engineering code of ethics, I'm pretty sure it goes against most things expressed in this post.
I think the biggest career mistake engineers make -- myself included -- is assuming your contributions will be automatically recognized when in fact the amount of credit you receive is equal to how much you contributed multiplied by the amount of attention you draw to it.
I mean, I've never worked with a project manager who generated one iota of business value... Just stirring up drama, inserting themselves into decisions that they can't understand, and calling unnecessary meetings with management that they should be handling on their own. I think there's a lot to be said for simple visibility to management. Also, ignorant overconfidence seems to be something that management loves.
> If you want your work to be valued (i.e. you don’t want to be reshuffled or fired), and you want to work on personally-satisfying features like accessibility, or UI polishing, or anything else not directly connected to profit - you need to go and work for a very profitable company.
"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...
The anomaly here are AI researchers
OK, now explain where management's salary comes from.
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.
Absolutely. Some genius outsources IT to Malaysia....I ask for an IP address to be statically assigned to a test machine and the ticket is opened and closed.....next day the IP has changed. Repeat x20 till we give up - telephone calls and complaints notwithstanding. Someone closes 20 tickets and looks productive because that's the way they're being managed.
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.
From the perspective of the business, you need to generate more money than your wage plus whatever else expenses that are associated with your employment. This surplus is what adds up to the profit.
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.
Reading this from somewhere that "engineer" is a protected title (Canada), this is a weird read.
These Silicon Valley folks really ought to read some Marx.
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.
I'm not sure you understand Marx. The author probably has read Marx during their philosophy training.
'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.
Marx was a techno-utopian sci-fi author who insisted his fiction was non-fiction and was proven wrong 100 years ago. Where is the dictatorship of the proliteriat?
Running companies like this is how you end up with the current state of Boeing. Only valuing engineers who are directly earning you profit and firing the ones who only have an indirect role in your profit centers.
> 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?
> Or even worse, engineers who are preventing you from making profit over "safety" concerns.
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.
Quality Assurance reporting in. Everybody talks a good game, then when you bring up compliance it's straight to the executive override.
Yeah. Company culture like the one mentioned in this document is toxic and will inevitably cause the company to fail.
[dead]
[dead]