The title reminds me of an interesting ancient Chinese anecdote. And it is also a bit ironic that Toyota has gotten itself into some scandals recently (https://www.bbc.com/news/articles/c1wwj1p2wdyo).

King Wen of Wei asked Bian Que:

“Of you three brothers, all physicians, who is the finest in the healing art?”

Bian Que replied:

“My eldest brother is the finest; my second brother comes next; I, Bian Que, am the least of the three.”

King Wen said:

“May I hear why?”

Bian Que answered:

“My eldest brother sees illness in the spirit, before it has taken shape, and removes it unseen; therefore his name is known only within our household.

My second brother treats illness when it is but a hair’s breadth from appearing; therefore his name does not travel beyond our village lane.

As for me, Bian Que: I pierce the blood vessels, administer strong medicines, and cut open the flesh. Thus, by such visible acts, my name has spread among the lords.”

I've been in those companies where "struggling departments" ended up getting all the praises and raise in budgets the following quarter because of the heroic saves they did, and raising awareness on how important they are... For stuff they totally caused on themselves.

Meanwhile, my perfectly purring department was struggling to keep the lights on.

It's a serious problem in this industry due to the disconnect between non-technical management (who understands how to double click) and engineering (who holds the company standing).

<insert IBM story about IT department cost cuts>

I'm not sure how we solve this, other than having management come from engineering.

I had this problem at a previous job. I spent almost all of my time taking care of the behind the scenes administrative work (scheduling meetings, making sure that people had the information they needed to come into the meetings prepared, etc.). However, when performance review came around I was told that the only thing that they cared about was that I hadn't completed many story points because I was too busy keeping things from falling apart.

So I stopped doing all the administrative work and focused on just completing story points. A week or two later my manager asks the team "how come all of our meetings are falling apart now? We get into a meeting and no one knows what's going on."

There are a lot of things like this.

My favorite is how elegant solutions often look simple in retrospect. So if you noodle on a problem for a while and then come up with a clever solution: once you explain it to someone they'll be like, "yeah, of course."

Meanwhile the guy next to you that overcomplicates the problem ends up getting kudos for building something so difficult :D

The headline is only half true. A more accurate rendition might be "Transactions don't happen because you fixed a problem that never occurred."

That illustrates the converse. People will absolutely try to avoid future problems if they are the ones that bear the consequences for them. Use birth control (or put your kid on it) so you don't have to raise another child for 20+ years. Don't hang out with that volatile "friend" who always seems to be having another crisis. Fix your roof so you don't lose the house. Don't go into debt because you're the one who will be paying interest on it.

But almost by definition, bearing the consequences of your own decisions implies that there's no transaction.

It's interesting and fitting that the article begins with a discussion of Toyota. People buy Toyotas because they want to avoid problems. The biggest selling point is reliability; a Toyota's value prop is that you can keep it for 20 years and you won't have unexpected things go wrong with it. Toyota has managed to turn this into a sales driver because they appeal to the self-interest of a buyer who will be living with the car for 10-20 years. There are thousands of individual decisions that Toyota makes to avoid problems with their cars, starting with a very conservative aversion to new technology or anything that is engineeringly risky. Each individual one is invisible to the customer, and often comes with significant costs in isolation. But because their sales driver is "be reliable at all costs" and they've ingrained that into the culture, they've built an organization that is willing to make these feature trade-offs for reliability.

Also, an interesting corollary is "Oftentimes, a good life is lived with few transactions."

I began migrating from network/hardware/IT work and into marketing after nearly 2 years of heavy lifting getting ready for Y2K. In the end, "nothing happened," so all that time and money was wasted, according to nearly every company I worked with. Even had one demand a full refund. I agreed as long as I could revert all the work that I had done. They agreed, and the next day after that their entire system collapsed.

I couldn't even get my own dad to pay for network support for his company since he would never pay my rate for anyone no matter what. After 2 other people failed to solve his problem I fixed it in 15 minutes and then he "really" didn't want to pay because it only took 15 minutes.

I was very good at what I did but got no appreciation for keeping things from breaking, only for fixing things after they broke. Marketing paid better, and I could point at real world numbers daily and justify my pay. I don't like it anywhere near as much, but at least it gets more respect than any other IT work I did.

Ian Rush said it best: "It's best being a striker. Miss five, score the winner, you're a hero. The goalkeeper plays a blinder, lets one in, and he's a villain."

Every place I've worked rewards the firefighter over the person who made sure nothing ever caught fire. And the worst part is the math is obvious to everyone except the people who set the incentives.

This is true but if you remove the need for credit then you can just get back to work and not have to create a category about it.

This is how people get promoted at work. They break something, it escalates and gets visibility, emails sent to executives. Now, they 'fix' it, many thank yous from everyone for a job well done. Another version of this is delay the work you are supposed to do a long time back and let it gain visibility. Executives are blind, they can't see work being done by people who take ownership and get shit done before it becomes a problem. However, executive will remember the name of the person who breaks shit and 'saves' the day.

My time in IT has really oscillated between these two extremes:

- "Everything around is working just fine. What are we paying IT for?"

- "Everything is broken. What are we even paying IT for?"

Personally, I strive for the former rather than the latter; I like to say "If I do my job right, you never know I'm here." But that's what got me let go.

(and for karma's sake, I keep in touch with folks at the old company; it's an absolute crapshow. So I got that going for me; which is nice)

This brings to mind Neil Rickert's "The Parable of the Two Programmers", which was published in the ACM SIG Software Engineering newsletter, January 1985.

https://dl.acm.org/action/showFmPdf?doi=10.1145%2F1012443 for the original, or https://realmensch.org/2017/08/25/the-parable-of-the-two-pro... for a reprint.

We all learned this back in first grade. The kids that behaved in class and did their homework did not command most of the teacher's time and effort. It was the problem children who refused to follow the rules and needed constant praise for every bit of actual effort that they put into their studies; that got the teacher's attention.

You'll see capability traps everywhere once you learn about them.

Sterman, Repenning and other collaborators wrote several papers after this one. All fascinating and almost entirely depressing.

Especially since MIT's Sloan school, where system dynamics first became a discipline, is just around the bend from Harvard Business school, where system dynamics first became ignored.

As Futurama said, when you do things right, people won't be sure you've done anything at all.

I never gave credit to my electricity company for delivering electricity to me. I only get mad when there is an outage.

I'm looking for some data -- if anyone has it -- on the fraction of companies that are led (CEO) by a technical person, over the years/decades. I have the (anecdotal) impression that this fraction has been falling (stories like Boeing), but it would be cool to support or refute this with hard data. Anyone know where to find/assemble something like this? Also, if this trend is true, then why?

This is why Apple never gets any credits.

Two significant prior discussions:

https://news.ycombinator.com/item?id=8940820 - 24 Jan 2015, 50 comments

https://news.ycombinator.com/item?id=39472693 - 22 Feb 2024, 434 comments

Aka:

* https://en.wikipedia.org/wiki/Preparedness_paradox

There is something I saw on a reddit post of all places, about how every manager who doesn't predict a baseline of "3 annoying problems every month, 1 awful problem every 3 months" is essentially a bad manager. The reasoning being that, if your number of problems is under that threshold, then someone is doing a 'good job'.

This is exactly the problem with the nature prevention. When it's well done, it seems like nothing was done.

I recognise almost every aspect of this document - it's exactly what's so intractable about the software business. This is why I think you do need to do some programming every now and again no matter what your level is because otherwise you cannot see what's happening and you'll be tempted into the "lazy developer" attribution.

Article published in the Summer 2001 edition of California Management Review, yet it never mentioned Y2K, the first thing I thought of when I read the line "fixing problems that never happened". Perhaps it was actually written in 1999 and took a while to get published, because otherwise that seems a very strange omission. The Y2K problem was very much over-hyped by the American news media at the time (no, at no point would airplanes have been falling out of the sky — I literally heard someone say that would happen once — even if no effort had been put into fixing the bug).

But in recent years I have seen people (elsewhere, not on HN) claim that Y2K was a big nothingburger, and all the money spent on fixing the bug was wasted. No, that's not true either. All the money spent on fixing the bug was why it turned into a big nothingburger. Sure, some of that money was wasted, by executives who wanted an "official" Y2K-certified certificate, issued by a consulting firm that had nothing "official" about it except their own say-so. And so they spent $2 million learning what their own employees could have told them for $2,000. THAT money was wasted. But a lot of banks were running old COBOL code that used 2-digit years, and needed to be fixed. The fact that in January 2000, everyone's bank interest was still calculated correctly, and not calculated as if it was January 1900? THAT was entirely due to the vast amounts of money spent paying old COBOL coders to come out of retirement and fix the 2-digit years.

The lesson I learned from that is that it's possible for a problem to be overhyped, even massively overhyped, and yet still be a serious problem. The other lesson I should have learned is that people rarely get credit (I won't go so far as the article authors and say "nobody ever gets credit") for fixing problems that never happened.

Its really hard to measure effectiveness, problem becomes even harder when a non-engineering person has the job to measure effectiveness of a engineering person.

On other hand. for software engineering some of the signals that can be used to measure such a management itself can be

1. On call requirement, outages and team burnout - A well written software should not require on-calls from the dev team

2. Ask them about the "concrete" roadmap for next 6 months to a year - Absence of concrete items is a bad sign

Apt comic: https://www.workchronicles.com/p/comic-prevention-vs-cure

I feel obliged to point out Stanslav Petrov, who absolutely got credit for fixing a problem that never happened. Granted it's a very extreme case.

I remember finding a comment in the first codebase I ever worked on professionally in my first ever job.

It read "This fixes a bug that hasn't happened yet".

It seemed really smart at first, but later I learned that the developer that added that code also had a pattern of appending spaces to the start and end of user input and comparing the length to 2 to determine whether the value was empty or not...

So I'm fairly sure "that hasn't happened yet" was probably more a case of "that I personally haven't introduced unnecessarily yet" :)

Pendatically speaking, people do get credit for fixing problems that never happened.

E.g. if the problems are quantifiable and there's a record, like dropping homicides from 100 per year to 20 per year in a city. Those extra homicides "didn't happen", but the improvement is understood.

For an one-off problem, it depends on how clear the path to the problem is. An electrician doing an inspection and noticing and fixing big electrical issues in the installation, would be appreciated, even if the accidents didn't happen.

Like nobody gets credit for avoiding problems or unnecessary things/complexity altogether. In fact the opposite may happen.

Here is another take in s different context.I had a very bad manger who was credited earlier with causing several companies to go out of business while he was taking advantage of having worked for a FAANG company. He worked there for less than 6 months as a business development dude when the that big shot company was new in that market.After he joined us and when I was processing some payments I noticed that he was paying some people for 2 months ahead of their starting dates, it was some $20k.I notified him, and he corrected the date,then I was told by others in the department that my problem was that I should not 'interrupt the enemy when he is making a mistake'. Eventually, the company got rid of him but it was after a very serious damage.

This is especially nice in the age of AI. I (the graybeard senior developer) does all the risky refactoring. I can take a performance issue and turn it into six regressions in half a day ($100). Then everyone is impressed when I let Opus fix these regressions in 20 minutes and $2 worth of AI.

No one notices when you cut 20% of some expensive process but cause no regressions.

And people often get credit for fixing issues they partially created.

Human groups work on shallow signalling and distributed confusion.

Couldn't help noticing:

In other words, it’s not just a tool problem, any more than it’s a human resources problem or a leadership problem. Instead it is a systemic problem [...]

Shades of an LLMism, a bit padded, a quarter of a century ago. These days someone could easily give it a stink-eye. I'm sure that training has ingested this along with countless similar examples.

Since Covid nearly everyone in Germany knows this saying: "There is no glory in prevention."

This is why I'll never be a fire protection engineer

Depends on the business.

When everyone is technical to some degree, I find that credit for technical rescue is forthcoming.

Avengers get the glory, preventers get no story.

"Titanic effect" - No captain gets credit for preventing a disaster!

People do get credit for making things that "just work".

So let's create moments or days of observance to make people aware of preventative measures taken

I'd guess a lot of people here consider this "reality" at this point. Has anyone come up with a response—not a fix for the company or leaders behaving this way, but a response for their own path?

Did you change from a quiet diligent one to manipulating and playing the game (now that you know the game)? Did you go from quiet and diligent to quiet and not diligent (why do good work when meh work does the trick)? Another path?

People don’t get credit for fixing problems that do happen. Maybe possibly in a sales scenario where your fix unblocked the sale. Otherwise nada.

Prevention is hard to sustain because the success is invisible : nobody notice the defects delays or crises that never happened

Chernobyl instantly comes to mind. The giant problem with that particular RBMK design was known to a few people, but nobody fixed it, and if they had... we wouldn't even know, since it would be lost to history.

This is the real problem with performance reviews in companies, which then feeds into opportunities, promotions and compensation. It's just a popularity contest. And this is particularly harmful to people who are neurodivergent, particularly if they're on the autism spectrum, because neurotypical people, who end up making all these decisions, view such people negatively for literally no reason.

You could spin up a team of 6 engineers and have them go away and try some greenfield project. They could come up back in 6 months having shipped nothing. Which of these descriptions fits the facts?

1. The team learned a lot and ultimately decided there was no product-market fit and decided it was best to reallocate resources elsewhere. The learnings from that project will help a whole bunch of other projects across the division; and

2. They failed to ship and get subpar performance ratings for having no impact.

The answer is... both. Or either. How you are treated will depend on how you are viewed by your management chain and that's a social function. We've all encountered people who never shut up about how hard their job is. Often they end up solving problems that they created, often by not listening to anyone that those problems would occur. And they get credit for it.

You could say to people who anticipate problems to stop because it gets you nowhere. Let people fail. If only it worked that way. Instead you'll get blamed for not seeing a problem someone else created because you're viewed as competent but you aren't liked through no fault of your own.

Google seems to be the posterchild for a company that briefly solved this problem and then forgot what made them successful. I am referring to Project aristotle [1], which ultimately determined that psychological safety was the key ingredient in a team's success.

Now amplify all of this with constant rounds of layoffs where the environment isn't just for pay bumps and opportunities but where the cost of failing is losing your income. What you've created is an environment where office politics is everything.

[1]: https://psychsafety.com/googles-project-aristotle/

Human civilization runs on personal sacrifices but money bags will never care about that.

This is very true and applies for everything in life.

Very true! Along with it comes with peace/quietness at work so it’s not too bad.

The best hackers are the ones who never get caught.

Two counter-examples:

- Arnold bought a fleet of mobile hospitals that would have been perfect for covid response, but the next governor didn’t want to pay 1% the fleet cost per year to maintain it, so he scrapped it.

- Under Obama, SARS v1 was stopped by US health workers that Trump fired because it was a “bad deal”. In the absence of that team, we got SARS v2, which was renamed to COVID 19.

There’s also the related category of “never blamed for fixing problems poorly, creating even bigger problems”.

Thanks to 9/11, plane cockpits can now be locked from the inside. Now, we have examples of commercial passenger airline pilots locking the doors and committing mass-murder-suicide by plane crash.

For some reason, these stories don’t make the news.

Its called doing your job.

We know that the squeaky wheel is the one that gets oiled, and we don't want the wheels to come off, so we need the wheel to squeak loud enough to be heard ;)

Boring is Better

But the same person can get paid for it. So there is an incentive to create, or at least pretend problems.

The jokes around Y2K being a nothing burger always annoy me. Nothing happened because a lot of talented people worked their asses off fixing it.

sounds like my day to day job experience.

Making critical decisions without oversight is just as bad, or maybe worse.

If you frame it this way in a meeting, you will get the attention you want. Don't say I didn't warn you because that comes with a lot of scrutiny you might not want.

> The combined expenditure of U.S. companies on management consul- tants and training in 1997 was over $100 billion

erhm, if this figure is close to true i can see what market ai companies is after.

Related. Others?

Nobody ever gets credit for fixing problems that never happened (2001) [pdf] - https://news.ycombinator.com/item?id=39472693 - Feb 2024 (424 comments)

Nobody Ever Gets Credit for Fixing Problems That Never Happened (2001) [pdf] - https://news.ycombinator.com/item?id=8940820 - Jan 2015 (50 comments)