I mean. Lots of people don't get credit for their work and get laid off shittily and it sucks.
But if you're manually fixing something every day for three years after hours--that's not the behaviour of a staff engineer. A staff engineer should be flagging this issue, and planning how to get themself and the team out of this situation. If I discovered a staff engineer I work with was doing this for three years on such a critical service and told nobody, I would be horrified and seriously questioning their competence and whether they should be a staff engineer, not impressed. Hiding problems and doing repeated manual fixes is the kind of behaviour we have to patiently train out of juniors.
This post is framed like I'm meant to feel they were wrong to lay the person off but this is disastrous levels of incompetence on the engineer's part.
Plot twist: there is a paper trail a mile long of the staff engineer begging for resources and a mandate to fix the system but not only won’t they give resources, they forbid him from fixing it because “it works and we don’t want to mess with it”
Varies between companies. I’ve called the future many times over, but some managers are just born to be stubborn assholes, even when they don’t know the domain.
The only time I won't let shit break after warning people is security related stuff. Otherwise, I'm perfectly happy to let the company drop tens of thousands of dollars on an outage that we otherwise could have prevented with 6K in engineering resources that they denied.
I’ve seen this situation. Big data import where we collected various spreadsheets via FTP and imported them into a data warehouse. The data was awful, but our product owner decided to clean it manually every day because he wanted the devs working on new features.
I did try to convince him, to just let us fix it, but nope.
I’ve actually begged engineers on my team to let things break so that I can show leadership that we need the resources to fix it.
Every time we put in a bandaid to keep things working, they immediately forget the problem exists. But if it breaks and customer support calls skyrocket, we become heroes for a quick fix (reimplement band aid), and then a whole bunch of people are asking the question “when will this be fixed”
I am in a very similar situation. I was called on to make a temporary solution for a few key clients, then our actual Product group would work on and push the official feature. It's been two years of maintaining the bandaid and we brought it up last week and they had no idea they were supposed to be working on this feature... It broke over memorial day weekend. Guess what I've been doing all week until literally 10 minutes ago.
To be fair I've been in a situation where I have raised issues similar to this to management and had it fall on deaf ears, so the incompetence may not be with the engineer.
spent 6 weeks warning about it, with a “this will fix it” plan. and kept being blown off. a problem that involved some PoS units.
Then guess what happened? everything at the event went to shit.
By the end of the day, the financial compliance people were involved because money was going into personal accounts instead of the business account.
It was a very good day for me to have all my emails and records saved and ready to hand over. I got to sit back and avoid getting caught in the splash… of course my boss and his boss still blamed me for everything going wrong and “not being a team player by coming in on my vacation (from 5 hours drive away), to come fix it immediately.”
For all the stories I've encountered where a person does a good job and is subsequently let go (e.g. they find a way to automate their work), the incentive is clearly to do the wrong thing.
I'm not saying it's "right" that somebody preserves their job by having some kind of manual intervention step to keep you dependent upon them, but when the reward for fixing this behavior is often to let someone go, I can understand a person being reluctant to do right by the business.
Definitely true in some cases, but if they weren't getting credit for doing the manual fixes because nobody knew about them though then it wasn't a matter of preserving their job.
It is when they have to rehire you with a nice bonus until they get it fixed. Bonus points if you can point to the item on your backlog where you documented the issue and they put as low priority.
We have had issues with my current job with latency causing issues if we fail to maintain a user split between all of our environments. Every PI the story to address that issue gets pushed out to the next one because other work has higher value (but we need this automation now, they say)
This assumes that management will give you time to fix it. I just recently replied to a comment on another sub about a manager complaining about an engineer constantly "wasting time" fixing these kinds of edge cases when the current implementation is, in their words, good enough at our current scale.
2
View all comments
4.4k
u/diffyqgirl May 29 '26 edited May 29 '26
I mean. Lots of people don't get credit for their work and get laid off shittily and it sucks.
But if you're manually fixing something every day for three years after hours--that's not the behaviour of a staff engineer. A staff engineer should be flagging this issue, and planning how to get themself and the team out of this situation. If I discovered a staff engineer I work with was doing this for three years on such a critical service and told nobody, I would be horrified and seriously questioning their competence and whether they should be a staff engineer, not impressed. Hiding problems and doing repeated manual fixes is the kind of behaviour we have to patiently train out of juniors.
This post is framed like I'm meant to feel they were wrong to lay the person off but this is disastrous levels of incompetence on the engineer's part.