I can mainly think of companies and projects from my professional experience, and it wouldn't be my place to publicly speak about these things. But I believe that many engineers like me have worked on death march projects where their critical problems have been brought up with management and thoroughly ignored.
Still, to try and give you some examples, Google Glass was known to be a failed product early on due to technical and practical problems voiced by engineers. But there was a culture of optimism or wilful ignorance at Google about Glass, so the project continued until it died due to these problems. And there are some articles on Hacker News about it. Right now there are murmurs online that Meta engineers are very aware that the metaverse is not engaging and VR efforts should pivot elsewhere. Yet the management seems to ignore this, even at tremendous cost to the company value. The whole VR effort at Meta could die because of this.
The interesting aspect of this culture is that it's not a "hindsight is 20-20" situation. In complete contrast, it's that engineers bring up problems that will significantly harm a project or a company in the future, but are ignored.
As of a few years ago I believe Google Glass was actually put to good use, by medical scribes. Not sure if that had changed or not. It seemed like the focus on consumers was the part that failed, not the technology.
That's a great counter-point. Still, I believe that the "moonshot" Google Glass project could have succeeded as well if they listened to internal feedback earlier.
I mean, Google Glass was crap and they did some dumb things there, but because they had a limited release, most people don't know how unusable it was, and it probably increases their cool high-tech image. Although, maybe it increases their out-of-touch image too (especially in the glasshole phase); but it doesn't contribute to killed by google, really.
Also, Google Watch is basically Google Glass on a wrist, so building it out wasn't a complete waste.
Metaverse being “not-engaging” is not an engineering type of observation, rather some kind of psychology/marketing type of insight. I wouldn’t trust engineers telling me something is, or is not going to be engaging to the general public.
In my experience, this is one of the ways that valid problems are dismissed. Engineers (and people in other disciplines) dogfooding and building the product should be listened to when they bring up these issues. They have T-shaped skills and an understanding of how the software works, as well as whether it can meet consumer expectations. There should not be gatekeeping about who can have insights into the product and who can't.
I think that you hit the nail on the head with the word "trust" - in many companies there should be more trust from management that engineers understand the context within which they work, and could have very unique and valid insights into how their software and hardware will be received by the consumer.
It would take a college class on the subject to do the topic justice, but the one that comes to mind readily for me is the Space shuttle O-ring disaster.
About the space shuttle o-ring disaster: what I feel being left out of the story is how often did previous warnings come up which turned out to be false?
The story as it is often told is that an engineer raised issue X, management dismissed it, issue X caused multiple deaths.
And when told like that it is obvious that management should not have ignored X. But what were the managements’ experience with warnings like that before?
Obviously they should have evaluated every warning on their merrits, but if the organisation was “crying wolf” all the time, one can imagine that can influence the decision making.
Columbia insulation damage as well. I'm not as familiar with the results of investigations with Columbia though to know if there was advice being ignored there too.
I don’t think there were the comparable warnings like Challenger. They actually struggled to recreate the impact in the lab afterwards. Talking to someone working on it, when they did finally recreate the effect, it was using parameters outside the test scope. From that perspective, it sounds very much like it was an unknown. * You can find the investigation report online [1]
* yes, they knew of the foam shedding, and knew it was out of spec. But they didn’t realize it could puncture the tiles in that manner.
Basically, they assumed that because all the damage they saw wasn't a threat to the orbiter that it couldn't be a threat to the orbiter. The orbiters could survive holes in the heat shield in most places so long as they weren't too numerous, but there were some key spots that would result in a loss.
They saw hundreds of spots of damage and decided it was just a nuisance, they never considered that there could be spots that wouldn't just be a nuisance. Beancounters unwilling to acknowledge a problem until it was decisively proven--and the only proof was a loss of the orbiter.
Kinda, but that’s not the full story. They didn’t realize the foam was physically capable of producing that damage. For one, the deltaV was higher than previous incidents because of when it occurred in the flight profile. And secondly, the foam demonstrated unknown characteristics at those speeds. They didn’t find that out until they tested the case afterwards and, since they couldn’t reproduce the effect, they basically said “let’s turn it up to 11 for shits and giggles and see what happens.” And voilà, the foam suddenly acted in an unexpected way that produced more damage.
It wasn’t really a “beancounter” issue. It came from the fact that we have imperfect models of physical systems and sometimes we encounter issues outside the boundaries of those model assumptions.
