If you are compensated better than 90% of your workforce, then you should receive better than 90% of the blame every single time something goes wrong. You're that important, no?
If you are compensated better than 90% of your workforce, then you should receive better than 90% of the blame every single time something goes wrong. You're that important, no?
Then you disagree with practically every military on the planet.
So, you're going to to have to provide at least a little bit of counterexample to support your position.
> Even when it’s specifically an engineering problem it’s the managers’ fault for not preventing the engineers from making a mistake.
There are VERY few times when engineering results in the failure of the project--Citicorp center, Tacoma Narrows, Therac-25, maybe I'll even give you Three Mile Island (the teletypewriter was producing bad data because it didn't have the capacity and got further behind as time went) ... I'm having to work hard after that but I'm sure I could come up with a few more. This is normally true because engineers almost always add a safety margin just in case something they can't account for goes wrong.
By contrast, most of our worst disasters have all been management failures. Chernobyl was a management-driven disaster. Fukushima was a management-driven disaster (spraying water on a core to prevent it melting down was a ferociously stupid management decision). The Navy Pacific fleet collisions are management-driven disasters. The first Johnstown Flood was a management-driven disaster. I can go on and on.
I think one reason the original claim is weird is that leadership should own the blame irrespective of their compensation. (E.g., if a manager has $1 salary they aren’t magically off the hook). It’s one of the core tenets of good leadership.
I think engineers sometimes are quick to jump on management because of 1) a hindsight bias and 2) because engineers often have a myopic view of risk. For example, a software engineer tends to only focus on software risks, while management must balance software risks, hardware risks, customer risks, labor risks, etc.
You will note that I specifically chose the spraying of water at Fukushima as a management failure (we can argue about the lack of failsafe for the cooling ponds)--because some idiot counting dollars decided to try to "save the core" they caused a hydrogen explosion which made things orders of magnitude worse.
In both Fukushima and Three Mile Island, for example, if everybody had simply SAT ON THEIR HANDS AND DONE NOTHING, the situation would have turned out far better than it eventually did. Yes, the Fukushima core would have still melted down, but it wouldn't have sprayed radioactive material all over the place.
In my experience, the result of bad decisions is usually due to incomplete information and risk assessments, whether by an engineer or management. Management usually has more risks to balance than the engineer. Engineers are typically only concerned with technical risk while management has both technical and programmatic risks to balance. When the balance tips towards programmatic risks, it may be due to a poor understanding of the technical risks as well as a bad incentive structure. When the technical risks aren't well understood, it's generally not because management is too dumb to grasp it. It's more likely the culture and organizational structure don't foster good communication or accurate assessments of those risks. For example, if you look at the Challenger disaster, neither the engineering staff or management has great estimates about the risk. (However, the engineers were much closer to the true risk probabilities). It came down to a concrete schedule risk vs. a somewhat nebulous technical risk and the absolute risk won out in the management decision process. In your Fukushima example, I'd bet the "idiot" probably didn't have an assessment (in terms of a failure-modes-effects-analysis or hazards analysis) to properly gauge the risk of their action. (Or there were likely communication failures of that risk, or both.)
I think the important point is that to really fix these issues, they have to be addressed as part of a process failure rather than pointing fingers distilling it down to a simplified notion that it's somehow the fault of an "MBA mindset"
Compensation tends to be tied to perceived impact. The perceived impact of a manager with 10 reports who are all focused and delivering individually is much higher than the impact of a manager with the same number of reports where half the team meets few of their goals.
The first manager is ultimately going to be seen as more effective and will get larger bonuses and will be more frequently promoted and ultimately grow the scope of what they own. That they happen to get paid more than individuals reporting to them is entirely appropriate based on their overall impact.
That managers sometimes blame the people on their team for the failure of the team is bad management (and worse if the people above them blindly accept that) but I don’t think you can assign all blame to a manager just because they happen to be the manager and certainly not because of their relative pay.
Maybe because when those goals involve cutting corners on safety and hundreds of people die as a result, that's one heck of a lot of "impact"?
So if you have someone telling you they're more talented than you are, and they take bigger risks, and that's why they're paid a lot more than you, why would you not expect them to take more responsibility than everyone else when things go wrong?
Separate out management for a moment. So an engineer who gets paid 50% more than another deserves 50% more blame for a failure?
I thought HN was a place where people attempted to form good arguments based on fact, not one where people let emotion rule the day.
To entertain the naive pedantry for a second: first, I think a heck of a lot of people would tolerate that 50% scenario more than the status quo, and second, it's not exactly outrageous to suggest the impact you have on a design goes hand-in-hand with how much blame you deserve for it when it breaks (or how much praise you deserve for it when it works). Now, you yourself say compensation should also be tied to impact. Apply the transitive property. You might be surprised what you get.
But surely you realize you're making a strawman out of the points people are trying to make? It's not literally the "same thing", it's an approximation meant to get a point across, and it's based on the assumption that you apply some common sense instead of treating it like a mathematical proposition. Like the understanding that you literally can't fire 98.3% of one guy and 1.7% of another, so clearly everyone understands "blame" will get out of sync with compensation; that in itself is obviously not the literal point. And the understanding what people are clearly upset about is the fact that those who are given more responsibility and power over a product (which just so happens to go hand-in-hand with their pay) frequently appear to bear far less blame than those whom they manage and give directions to. Nitpicking on why it should be proportional to the guy's salary is literally missing the gigantic problem the other person is trying to point out.