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. And it doesn’t exactly add to the value the company brings to their customers.
"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.
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.
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.
> 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.
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 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.
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.
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 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.
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.
> 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.
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.
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.
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 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.
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.
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.
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.
> 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.
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.
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.
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.
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. And it doesn’t exactly add to the value the company brings to their customers.
"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.
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.
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.
Is it better when it's held hostage by a couple of non-technical employees?
> 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.
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.
But the relationships are what affords that change though, isn't it?
Or they’re not trying to understand how it works
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.
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.
> 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 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.
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.
> 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.
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.
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.
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
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.
Even many of those small startups are in the pocket of some unfavourable characters.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
Yeah. Company culture like the one mentioned in this document is toxic and will inevitably cause the company to fail.