Nobody Pushed Back: Why Engineers Stay Silent Until It's Too Late
Posted by Itchy-Warthog8260@reddit | programming | View on Reddit | 55 comments
Most architectural disasters aren't a knowledge problem. The engineers knew. Speaking up just wasn't worth it.
Nullberri@reddit
Often times its also “nobody told me what they were making or asked for my opinion” cause i would have told them why their plans needed more consideration and they just wanted to build what they wanted to build without regard for what they needed.
ZorbaTHut@reddit
I got hired at a game studio making Game A, which I thought was a pretty good idea. When I joined, I was told they were also working on Game B, which was much bigger than Game A. I thought Game B was not a good idea - in the best of cases, it was extremely risky, and they weren't setting things up to be the best of cases. By pure coincidence I also had six years at a game studio specializing in games like Game B, and I said that I would be absolutely happy to braindump to the management working on Game B and give them a whole bunch of stuff that I super-ultra-strongly-this-will-kill-the-company-if-you-don't-do-it recommended, and was told pretty clearly "no, they've got it under control, don't worry about it", with hints that I was pushing my luck as a new hire. And they weren't wrong about that, admittedly.
So I worked on Game A. We released Game A. It was reasonably successful; we had a few problems, but so it goes. Then they moved everyone to Game B. I quit in under a year.
They released Game B, it was a catastrophe, and within a year the company had downsized by over 90%. The entire company is now a third the size the Game A team used to be.
I warned you.
Welp.
vividboarder@reddit
I wouldn't expect those asking me to build something to know how best to architect a technical system.
That's why I always ask what they are trying to do and offer up my opinions framed to explain how it will get them what they want in the best way possible. This is what I'm paid to do...
amartincolby@reddit
That has worked more often than not for me, but I have lost contracts for doing it and was nearly fired from a full-time role as well.
nanotree@reddit
Yep. This is why I make it my business. I feel like this is where seniors start to step up to principle engineer level. Don't let people, especially product teams, make these decisions without you.
And for the people who say "yeah, that's not my job and I'm not doing something I'm not getting paid for," this isn't about giving the company free labor but about training your skills that you can then take on to your next job when they inevitably fail to promote you. It's also about trying to keep your job sane and manageable.
CallousBastard@reddit
After I raised some concerns over a new feature implementation that my manager had suggested, he blew up at me. Said I was too negative and argumentative. I kept my mouth shut since then and let the disaster unfold as predicted.
mwobey@reddit
I believe every senior dev has at least one story like that in their belt, and it informs the way the entire industry approaches its work.
I've long suspected that the root cause is that non-technical staff really do see programming as a kind of arcane spellcraft -- programmers are viewed as company wizards, hired to write the bindings that bend the silicon beasts to our will. If the machine does not do as we were tasked, clearly it is because we failed to invoke the more potent magics that would command it to do as it was told.
Very few product managers I've worked with truly appreciate the 'engineering' side of software engineering, or understand that if we are wizards then it is in a world where we are simply writers of rules the machine must follow, desperately searching for a set of instructions that satisfy all the requirements without leaving a contradiction by which the beast could escape. When we push back on requirements it is not out of a desire for insubordination, but because we've identified two conflicting requests that can't both exist without a contradiction manifesting.
Ahhmyface@reddit
I like the way you put that. I suspect you are right.
They don't understand that the spell they're trying to cast doesn't make sense. It's not a matter of merely doing as we're told.
The magical rules require a sensible request to function.
AccurateRendering@reddit
The elephant in the room re: the Nokia story was that Microsoft saw were Nokia were going with the Linux based "smart phone" Maemo in 2005 and did whatever it took to crush it. That was 4 years before the iPhone and Android. The story about what the engineers knew is a side-show to the power plays in the board room.
happyscrappy@reddit
Story nails it.
The reason engineers don't speak up is they are punished for saying that something is a bad idea. If you say it's a bad idea you're a bad person and will be punished or fire. But if the project just falls on its face the it's no one's fault (success has many fathers, failure is an orphan) and so you come out relatively okay. Especially the high ups of course.
It's a fucked up system. Execs don't want to hear reality, they want to hear platitudes.
Choralone@reddit
Even in organizations where there is demonstrably no punishment, and, in fact, open and transparent encouragement to speak up, without a bunch of protective middle management, this is a challenge.
Speaking up contrary to the company's momentum means putting yourself out there in front of everyone. Many people just aren't comfortable with it.
Ahhmyface@reddit
Nobody cares.
I mean about any of it. The exec that made some vague wish doesn't care if the project fails later. He still gets 6-18 months of hype and presentations before it fails. That's all he needs to say he drove change (besides his bullshit reorg) to get his bonus and switch companies
The directors only care about showing loyalty. Hitting bullshit metrics, kissing ass, over promising, always pretending like everything is sunshine and running smoothly. These sorts deliberately sugar coat what ever is coming from engineering. They don't care if half the projects do nothing as long as their PowerPoint has a check mark on it
Engineers can talk until they're blue in the face. The metrics are wrong. The product doesn't work. The timeline is unrealistic. This just gets absorbed into the machine as "documented and accepted risk". Nobody cares if engineers object. The project always moves forward because directors want to please their bosses and the execs are just throwing shit at the wall because--let's face it, all they had was a vague idea in the first place
I'm an outlier. I complain. Loudly. I constantly ask why we weren't consulted for an estimate before the deadline was decided. I ask why the platform was decided without an engineering evaluation. I straight up refuse to provide estimates for work without clear requirements. My manager constantly asks me to avoid discussing the problems with the project whenever I need to speak about it in front of his bosses, and I go around him if I have to.
But nobody cares about my opinion. I'm not their boss. I don't decide their bonus. They aren't going to take up the torch and raise my concerns. It's a dysfunctional system where the only people that seem to care about the users are those least empowered to help.
As a side note, this is why I laugh whenever anybody praises capitalisms ruthless efficiency.
SoilMassive6850@reddit
The article says engineers stay silent but every example says "but management didn't listen". These things don't exist at the same time.
My personal experience is that when the average engineer hears about something it's already been decided and "locked in" by a smaller circle (often more management than engineering heavy) and it's "too late" to change the decision that has been made so the only option left is grumbling between engineers who have to implement bullshit which will affect nothing, which happens to be the same as what effect complaining up the chain does.
ReallySuperName@reddit
This matches my experience. This is why I've seen it happen multiple times, two of the most absurd were:
Every team had to use another teams microservice for user login and auth, doesn't seem too bad at first. That team decided on using... ElasticSearch to store the auth data. They used it for nothing else, not for searching, or anything. They even managed to fuck that up so much that it regularly timed out and fell over and it took them months to replace it with a normal database.
Another team (it might be the same team actually) decided to DIY our feature flag system instead of paying for a third party one. OK, fair enough, but wait! They decided to do that in the worst way possible too. Although they used a real database for this, they insisted the only way to create a new flag was raise a PR to their repo... to then add a new line to a plain text file that was pipe character delimited for some reason.
anarchist1312161@reddit
Reminds me when I had to take over a project from a Junior developer started it, and was fired due to incompetency.
They didn't let me rewrite this plugin, it was horrible (race conditions, sometimes duplicate rows get stored, etc, as it was a middleman transferring data from one service to another).
It took me 2 years (instead of a month, starting from zero) to finally fix everything before they laid me off as I wasn't making them profit... the irony.
falconfetus8@reddit
That's why you don't ask for permission to rewrite it---you just do it.
mankeyless@reddit
But why do it if 1. you're not get any recognition for it. 2. you're not gonna be paid more for it. 3. might actually get you in trouble to be working on something outside of the planned work?
hdkaoskd@reddit
You get paid for it and it makes your life less miserable. In theory.
anarchist1312161@reddit
Yeah lesson learnt. 😅
azsqueeze@reddit
The second bullet didn't sound bad at first until it did lol
vividboarder@reddit
The last sentence is "Speaking up just wasn't a rational choice", which seems to put the blame on the companies not incentivizing or encouraging the behavior.
GargantuanCake@reddit
Corporate America has been absolutely overrun by toxic positivity. You aren't allowed to mention problems, complain, or have any questions in any way. You need to have a can do attitude, you see, and if you can think it you can create it!
Except that it's literally an engineer's job to spot problems. Physical reality is, in fact, a thing that exists and there's no way to positively think your way around it so you get non-technical idiots in charge that tell the engineers to "just make it work" because wow my idea is so good!
If you bring up problems you get fired for being a bad culture fit or having a negative attitude or some bullshit. I'll admit that I'm a relentlessly negative person but that's actually served me well when doing some engineering. I can and will spot most problems ahead of time and will prevent them from being an issue if you'll fucking let me.
vividboarder@reddit
I guess I should consider myself either lucky to work somewhere that responds well or I'm just very convincing.
I do think there is a bit of an art to it that takes time to master. You don't just say "No, that won't work" or "That's a bad idea". You can be a team player by redirecting to an alternative so you're not stymieing progress but keeping things moving in a more sane way. Eg. "I think we could achieve the same goal, but cheaper/more stable by doing X".
It's still framed positively, but it's also constructive and drives towards a new direction.
GargantuanCake@reddit
My experience so far has been that the bigger and more corporate a place is the more likely it is you'll run into toxic positivity bullshit. Small companies and small teams I saw none of it but boy howdy was it a problem in bigger companies.
With the smaller places I could just say "that's a bad idea because..." and could give a surface level, not terribly technical explanation. It was nice. Granted in those places everybody was at least a little bit technical if they weren't software engineers so they understood where I was coming from.
The worst was bigger companies with non-technical leadership that neither understands math nor desires to. There's simply no explaining "no the computer can't actually do that" or why computational complexity matters. Granted those are the places I also saw the worst horrors in code bases; all they cared about was getting more software features out faster.
mwobey@reddit
Not just a lack of incentive, at many companies there's an outright disincentive to speaking up.
In my first industry programming job, our project manager had the brilliant idea to build a new generation of our product that would replace our entire database with a single tall table to hold everything: every user, every role, every location, every piece of inventory, every log interaction... we're talking tens of trillions of records on some customer deployments.
After about six months of working on the system and doing my own profiling when time permitted, I started to raise the alarm that our homegrown ORM to convert this data back into objects at the application layer was going to drive performance into the dirt. However, my data was never hard enough, and my suggestions would always 'break the sprint'... But I kept bringing it up for about two and a half years.
...Then the big upgrade weekend came, and it was time to port over our largest customer. When we started to do testing on their schema, It took 30 seconds just to log in, and several minutes to navigate between any view that showed any amount of data. In the first meeting after the preliminary benchmarking was in I opened with an admittedly sardonic, "This is what I've been trying to warn you about!", and I was told I was not being a team player by bringing it up and I was put on a PIP because I "didn't seem happy here."
D-cyde@reddit
Seconding this. Some managers also want proof that your idea is going to be of benefit. They want a baseline, by how much will this increase performance, how much time it will take? etc. Congratulations, now you have been rewarded with more work that will be rejected anyways.
gimpwiz@reddit
Sounds a little bit like the halting problem. How much better is it going to be? I dunno, let me do all the work to do it, then I will tell you. ;)
arihoenig@reddit
I love the "how long will it take to find and fix that bug?" Question. I mean, I haven't even looked at it yet. It could end up being a CPU errata for all I know at this point, how am I supposed to provide an estimate?
Librarian-Rare@reddit
They both can exist at the same time, in different degrees. Devs offer hedged “I’m curious why…” questions, and then get shut down. Then they stop speaking up.
Apterygiformes@reddit
Yeah exactly this. The beginning of the project is already too late to influence any changes to it
BordicChernomyrdin@reddit
The bureaucratic weight of the scrum industrial complex has reduced developers to bricklayers and cobblers.
hyrumwhite@reddit
I always express my concerns, then implement what I’m asked to
LetsGoHawks@reddit
Or... you get tired of being ignored. If lives were at stake, that would be one thing, but they're not. So fuck it, lose a few million, I don't care anymore.
lizardhistorian@reddit
Well that's what you get when you hire all type B's and capitulate to their design by consensus.
You get no consensus because they just sit there, useless. Fire them.
leogodin217@reddit
"because at Nokia, being the person who brought bad news upward was a career risk, not a career move."
I've seen this in the past. We'd do some analysis and things look bad. Review with manager and they look a little better. Review with director and things look even better. By the time decision makers read it everything is great.
Even had a CIO write an external article that was completely based on false data. I know, because I generated the real data.
TigercatF7F@reddit
An engineering joke that's been going around for decades:
In the beginning was the plan, and then the specification; And the plan was without form, and the specification was void.
And darkness was on the faces of the implementors thereof; And they spake unto their leader, saying: "It is a crock of shit, and smells as of a sewer."
And the leader took pity on them, and spoke to the project leader: "It is a crock of excrement, and none may abide the odor thereof."
And the project leader spake unto his section head, saying: "It is a container of excrement, and it is very strong, such that none may abide it."
The section head then hurried to his department manager, and informed him thus: "It is a vessel of fertilizer, and none may abide its strength."
The department manager carried these words to his general manager, and spoke unto him saying: "It containeth that which aideth the growth of plants, and it is very strong."
And so it was that the general manager rejoiced and delivered the good news unto the Vice President. "It promoteth growth, and it is very powerful."
The Vice President rushed to the President's side, and joyously exclaimed: "This powerful new software product will promote the growth of the company!"
And the President looked upon the product, and saw that it was very good.
After the subsequent disaster, the suits protect themselves by saying "I was misinformed!", and the implementors are demoted or fired.
hamateur@reddit
"Sure, a you in a car might have the right of way, but how far are you willing to go to prove that against a truck?"
Also, let's say, for the sake of argument that you are right. If they never listen to you anyway they're eventually not going to see the point in paying you to be ignored. (They won't admit to that though).
a-cloud-castle@reddit
Better yet, they take your idea and claim credit for it. You get a $50 Amazon gift card as thanks.
Qweesdy@reddit
The main problem is that "software engineers" are not engineers.
For actual engineering there's an underlying set of laws (physics, etc) and you can provably without question say something like "that bridge will fall down", and anyone who has a different opinion can be told "opinions are worthless, here's the formulas, do the maths".
For software developers (who are never software engineers even if they fell for the "let's apply marketing crapology to their job title" bullshit) it's always just "my unprovable opinion is better than your unprovable opinion", and the person who pays the wages (or their closest delegate in the management hierarchy) always wins those arguments.
DominusFL@reddit
This article suggests a much larger degree of inclusion than I have experienced while working at Fortune 500 companies.
Often, decisions affecting teams are made by individuals in other areas, usually at higher levels, without consulting or informing those involved. By the time you become aware of a decision, it is already finalized, and you are forced to adapt or simply live with it.
I kept reading this article thinking, "Gee, it would be nice to be in these kind of meetings where you even had the option of raising your hand."
urthen@reddit
The amount of times I have to drop everything to build a feature an exec promised but wasn't on our roadmap is WAY too high.
At least my manager isn't the type to throw me under the bus about it, but it's still annoying as hell to constantly be the bad guy saying we're delayed because we had to rush unplanned work.
teknikly-correct@reddit
Luckily AI is known for pushing back on bad ideas!
Michichael@reddit
Dealing with this right now.
Pushing back is exhausting and I don't feel like fighting that battle any longer.
Smile, nod, get paid, stop caring. Not paid enough to care and not respected enough to be the loud American.
Let me know how that works out.
nhavar@reddit
If you are the one in meetings to call out bad decisions or poor engineering choices then you are also often a target for the type of management that "manages up". They don't want your negativity or your "facts". They want to check the box on what their manager wants from them, however stupid or wasteful they might know it to be.
knightly234@reddit
Well also we do speak up, then are told to get onboard, then asked why we didn’t say anything, then told we’re not being constructive when we remind them we did.
cashto@reddit
AI slop article glorifying hindsight bias.
"Some people thought it was a bad idea" != "the whole engineering team knew it was a bad idea".
stipo42@reddit
We had a tech meeting today and it feels like we're inching towards a developers union
VeritasOmnia@reddit
Had a project that my team spent over a year on and burned through software architects trying to take over a frankensteined program that they purchased and we kept pushing back that it wouldn't work. We kept being told that we didn't have a choice in the matter, the decision was already made.
When managment finally saw the light and ended the project, there was a debrief and we were asked why we didn't speak up earlier. 😮💨
Everything is pretend and for show.
browner12@reddit
I don't think I've ever had an article speak to me like this one.
dragenn@reddit
They fired all the enginners that actively pushed back...
esiy0676@reddit
Nothing new, nothing that will get resolved. There's much worse cases of this, such as when air crash investigations reveal that no crew member wanted to challenge the senior captain decision making despite obviously knowing that a crash was imminent.
GenazaNL@reddit
If you would speak up to management, you get fired
Caraes_Naur@reddit
Maybe bring the engineers into the project before budgets, timelines, and UI designs are all signed off by the client, all rushed by the non-technical account manager.
Every project I've seen fail shares a common trait: prioritizing pixels over data, to deliver the client's "first look". That's the moment they start nitpicking (which sets the budget & timeline on fire), causing unplanned change requests, introducing creep, etc.
Speaking for web development, anyway.
leogodin217@reddit
This hits hard from a few past jobs.
8yatharth@reddit
The odds of speaking out and getting rewarded are very less. Most of the time they think you're a shirker or you a rebel. Or may they underestimate your thinking of the system. Or they give more priority to what has already been decided and you dont need to be given enough attention. Either of the cases, engineers prefer to take quiet and let it be.