After reading this article, I reflected on my own experience with burnout, which doesn't quite align with the typical causes mentioned.
In my case, the burnout stems more from organizational dysfunction. Our company is highly political—senior leadership mostly comes from non-technical backgrounds, and they manage by fostering competition between teams rather than creating clear functional boundaries. Success is measured by who delivers first, who secures more resources, and who can strengthen their position, leading to constant turf wars.
My manager, despite holding a PhD in computer science, is not technically hands-on. He has a strong ego and is deeply invested in winning these internal power struggles. He also places a lot of importance on maintaining a polished image, both for himself and for the team.
As a result, much of our time is spent building flashy demos instead of focusing on meaningful technical work. We're often tasked with superficial or peripheral projects meant to impress, rather than solve real problems. Internally, the "product" is essentially a collection of immature, duct-taped solutions that don't hold up, and many of our demos eventually get discarded. There’s little emphasis on building something robust or valuable—just on making things look good. I’ve learned very little in this role; the work feels more like labor than growth.
bluGill · 8h ago
8 is wrong. The idea is right - promoting engineers who do fire fighting is a bad thing. However their reasoning is wrong. The real problem is the engineers who do fire fighting to get the thing shipped at the last minute are the engineers who couldn't design a robust system that doesn't need last minute fire fighting and you are rewarding them for their lack of skill.
perrygeo · 7h ago
> rewarding them for their lack of skill
I'm not sure it has to do with skill. That would imply the average worker has agency to apply their skills. The dynamic is more: leadership doesn't understand any of technical details and is happy to defer blame on engineers. But engineers are often expressly forbidden from proactively solving problems. So any employee with half a brain can read the writing on the wall - projects will fail due to incompetence (literally no way to stop it) so we might as well prepare to clean up the inevitable mess.
The result: a brittle system that requires heroics just to keep it operating. Once the heroics are rewarded, and proactive problem solving is eliminated, the cycle is locked in place. Cleaning up messes that you yourself begrudgingly create is the new job description.
billy99k · 8h ago
I suppose it depends on the engineer doing the fire fighting. Most of the time, I've been the one cleaning up the mess from a previous engineer. I have the skills to fix the issues and get it shipped (and also build it right the first time).
tuyguntn · 6h ago
> engineers who do fire fighting to get the thing shipped at the last minute are the engineers who couldn't design a robust system
What is the average tenure in your company? In most tech companies I know, its 2-4 years (add changing teams into that)
A lot of times you are maintaining existing system. Even then you can't blame other engineers, because information/context/constraints they had at that time could be totally different than what you have now.
If business is burning in 2 months, I am willing to create 100K lines of spaghetti code to save it. Afterwards, we can discuss how to rewrite/refactor
bluGill · 6h ago
> What is the average tenure in your company? In most tech companies I know, its 2-4 years (add changing teams into that)
Where I work 20 years or so. Many people who switch in never leave, and a lot of kids who started as an intern are now retiring. Some people do of course find new jobs, but it isn't common (and having worked for a lot of other companies previously I'm not looking - we are not perfect but better than many other options). Maybe part of tech's problem is most can't figure out how to keep good people. They throw money, ping pong tables, and the like around. A good stable paycheck where you are expected to work 40 hours a week and go home is worth a lot to many people even if they could make more elsewhere.
drewcoo · 6h ago
The article explains systemic problems. You are rewording this systemic problem into a personal problem, blaming individual workers:
> Rewarding only crisis response discourages preventive work and sends the wrong signal about what the organization truly values.
CBLT · 8h ago
I just read the article and feel I learned nothing. It's all the obvious lessons, without any real implementation advice. Am I the wrong audience?
bluGill · 8h ago
Unfortunately despite how obvious all this is, they are common real world problems that management all over gets wrong time and time again.
tuyguntn · 8h ago
Valuable tips, but does it work though?
For example: "Building Fragile Engineering Systems"
I wish, I would work in companies who encourage long term maintainability of the platform we are building, but competitors don't wait and building good/stable products are not fast (even if you hire the best, even if you work smart, it just takes time to build, whether you add tests or not, remove features, it just takes time)
Also, consider the fact that building stable products sometimes opposite of making impact, your company treats impact as something which helps the baseline sooner, until you get outcompeted.
bluGill · 8h ago
Slowly things are changing though. More and more products are past the point where a competitor can quickly come in and snipe you. Now a lot of products are at the point where there are so many features that it takes years of effort for them to match. What this means is the only way for a competitor to take over is to have a well designed product which allows adding new features faster than you even after they match you on nearly all features.
20 years ago I read that the nobody uses more than 5% of the features of Word - but every user has a different set of features making up that 5% and so a competitor couldn't release with 5% of the features and get more than a handful of customers. Sure you could maybe get one customer by finding a feature Word doesn't have and making your 5% features what that one customer needs, but you cannot charge a reasonable price if you only have one customer.
Of course you are correct that company reward impact. Which isn't all bad, if you decided to compete with Word your company would need to be willing to invest in 20 years of losses before you have a product that has a chance. This is probably not a good investment unless you already have a lot of sunk costs because you have been a competitor for decades.
tuyguntn · 8h ago
Another point, most web based software is getting rewritten every 2-3 years, so why should you build as if you are building for Voyager or a medical device?
I would rather value fast iteration and allowing engineers create mess, learn from it and apply learnings to rewrite (again with quick iteration), instead of focusing on reliable/stable product from get go and making it work for 99% of users
bluGill · 8h ago
Why is web software rewritten every 2-3 years? If you invest in a good framework you shouldn't have to rewrite that often. Sure the content will change, and the theme will as well. You will need to add new features all the time, but a good design means that in 6 years you are saving all the cost of rewriting things and that means you can let some of those expensive engineers rewriting everything go.
Investments take time to pay off, but if you make a good investment you get a reliable/stable product. Fast iteration and creating a mess is fine when your company is new, but once your real products are proved to be useful you need to transition to something sustainable. Spending money rewriting your web site is money that you could use for some thing else. Computers and the web are tools - don't spend too much money on them - this often means investing in good tools.
tuyguntn · 6h ago
Its not about frameworks you choose, its about changing business landscape and I am specifically talking about web based software (figma, uber, google, you name it).
What you knew 2 years ago is completely different than what you know now. And the tools existed 2 years ago is different what you have now (e.g. Google might have built new internal service which will simplify 50% of your service, would you migrate?), hence when you just started building you haven't accommodated for a bunch of upcoming things. With the knowledge you have now, tools you have now and what you see is coming, you are going to rebuild the software again.
billy99k · 8h ago
This isn't my experience at all. When most companies pick a framework/technology, they usually stick with it for a long time (until some other circumstance forces them to change).
I could see startups blowing through VC money doing this.
tuyguntn · 6h ago
I think we should make a clear distinction between craft and business.
- Craft is when you try to achieve perfection by investing your time.
- Business is when you try to optimize return on investment.
Craft brings you joy, Business brings you money and money, in capitalistic world doesn't care about your mental state. You are in real world with sharks like yourself, fighting for the TAM (total addressable market) or trying to expand TAM (which is not an easy job).
When you have 2 opposing ideas (in some ways), its very difficult to come up with good principles.
bluGill · 4h ago
The world does not care about your mental state. No need to bring capitalism in. The world doesn't care. Some people care about you, some do not - you find this in all cultures. This is nothing to do with economics and trying to make it so is not helpful.
In my case, the burnout stems more from organizational dysfunction. Our company is highly political—senior leadership mostly comes from non-technical backgrounds, and they manage by fostering competition between teams rather than creating clear functional boundaries. Success is measured by who delivers first, who secures more resources, and who can strengthen their position, leading to constant turf wars.
My manager, despite holding a PhD in computer science, is not technically hands-on. He has a strong ego and is deeply invested in winning these internal power struggles. He also places a lot of importance on maintaining a polished image, both for himself and for the team.
As a result, much of our time is spent building flashy demos instead of focusing on meaningful technical work. We're often tasked with superficial or peripheral projects meant to impress, rather than solve real problems. Internally, the "product" is essentially a collection of immature, duct-taped solutions that don't hold up, and many of our demos eventually get discarded. There’s little emphasis on building something robust or valuable—just on making things look good. I’ve learned very little in this role; the work feels more like labor than growth.
I'm not sure it has to do with skill. That would imply the average worker has agency to apply their skills. The dynamic is more: leadership doesn't understand any of technical details and is happy to defer blame on engineers. But engineers are often expressly forbidden from proactively solving problems. So any employee with half a brain can read the writing on the wall - projects will fail due to incompetence (literally no way to stop it) so we might as well prepare to clean up the inevitable mess.
The result: a brittle system that requires heroics just to keep it operating. Once the heroics are rewarded, and proactive problem solving is eliminated, the cycle is locked in place. Cleaning up messes that you yourself begrudgingly create is the new job description.
What is the average tenure in your company? In most tech companies I know, its 2-4 years (add changing teams into that)
A lot of times you are maintaining existing system. Even then you can't blame other engineers, because information/context/constraints they had at that time could be totally different than what you have now.
If business is burning in 2 months, I am willing to create 100K lines of spaghetti code to save it. Afterwards, we can discuss how to rewrite/refactor
Where I work 20 years or so. Many people who switch in never leave, and a lot of kids who started as an intern are now retiring. Some people do of course find new jobs, but it isn't common (and having worked for a lot of other companies previously I'm not looking - we are not perfect but better than many other options). Maybe part of tech's problem is most can't figure out how to keep good people. They throw money, ping pong tables, and the like around. A good stable paycheck where you are expected to work 40 hours a week and go home is worth a lot to many people even if they could make more elsewhere.
> Rewarding only crisis response discourages preventive work and sends the wrong signal about what the organization truly values.
For example: "Building Fragile Engineering Systems"
I wish, I would work in companies who encourage long term maintainability of the platform we are building, but competitors don't wait and building good/stable products are not fast (even if you hire the best, even if you work smart, it just takes time to build, whether you add tests or not, remove features, it just takes time)
Also, consider the fact that building stable products sometimes opposite of making impact, your company treats impact as something which helps the baseline sooner, until you get outcompeted.
20 years ago I read that the nobody uses more than 5% of the features of Word - but every user has a different set of features making up that 5% and so a competitor couldn't release with 5% of the features and get more than a handful of customers. Sure you could maybe get one customer by finding a feature Word doesn't have and making your 5% features what that one customer needs, but you cannot charge a reasonable price if you only have one customer.
Of course you are correct that company reward impact. Which isn't all bad, if you decided to compete with Word your company would need to be willing to invest in 20 years of losses before you have a product that has a chance. This is probably not a good investment unless you already have a lot of sunk costs because you have been a competitor for decades.
I would rather value fast iteration and allowing engineers create mess, learn from it and apply learnings to rewrite (again with quick iteration), instead of focusing on reliable/stable product from get go and making it work for 99% of users
Investments take time to pay off, but if you make a good investment you get a reliable/stable product. Fast iteration and creating a mess is fine when your company is new, but once your real products are proved to be useful you need to transition to something sustainable. Spending money rewriting your web site is money that you could use for some thing else. Computers and the web are tools - don't spend too much money on them - this often means investing in good tools.
What you knew 2 years ago is completely different than what you know now. And the tools existed 2 years ago is different what you have now (e.g. Google might have built new internal service which will simplify 50% of your service, would you migrate?), hence when you just started building you haven't accommodated for a bunch of upcoming things. With the knowledge you have now, tools you have now and what you see is coming, you are going to rebuild the software again.
I could see startups blowing through VC money doing this.
When you have 2 opposing ideas (in some ways), its very difficult to come up with good principles.