[ChrisMarshallNY]

I used to work for a corporation that was legendary for their Quality (note the capital "Q" -I got used to denoting it that way). They have been making precision optical gear for over a hundred years, and fetch many thousands, for their consumer (really, professional) kit. Thousands of successful people have built their entire careers around this company's gear.

If you want to see "stubborn," look no further than their QA Division. In the US, there used to be a running joke, that if you had "Quality" in your job title, it meant your career was dead. At this company, it meant that you were headed for Executive Row. Many VPs and General Managers (a very powerful title, at this company), were former QA people.

And, boy, were they a pain to deal with. They would have 3,000-line Excel spreadsheets, and if even one of those lines was a red "X", the entire product line could get derailed. I had a project that we worked on, for 18 months, get nuked at the last minute, because they didn't like the Quality. I worked with an SV startup, that had a project canned, for pretty much exactly the same reason. The startup folks didn't seem to take the Quality seriously, which was basically a death sentence.

In that company, the kind of "stubborn" the QA people demonstrated, would be considered absolutely essential. I know that most folks around here, would not put up with it for a second.

They wouldn't be wrong. Making superb-Quality stuff is not a big moneymaker. You want lots of money, make lots of cheap, crappy things, and sell them at a small margin. The market is a lot bigger, and most people have much higher tolerance for crap than this company's customers.

As is the case with almost anything in life, "it depends." There's really no one-size-fits-all, "magic elixir." Every end may be reached by a different path.

[com2kid]

When I first joined Microsoft as an SDET back in 2006, the culture was such (at least in my org) that any SDET could halt shipping.

A bit less than a year out of college I found a pretty significant bug in the compiler (I forget the bug! I do remember the one major bug I let slip out into a release though) well after everything had been signed off on. I brought it up in the team meeting and the principle dev asked me directly "Do you think we should cancel the release to fix this bug?" I wasn't sure of myself and he told me that "it's your call", and I said that yeah, we should fix the bug.

For anyone under 35 who is confused by this, was before releases were rolling and shipped online. When Microsoft released a major version back then, it had a (IIRC) ~10 year support contract attached to it (and if you found a bug and were on a good enough of a support contract, the dev team would develop a custom patch for you to fix a bug in a 9 year 6 month old release!), and a lot of gears were set in motion to make a release happen.

This was the norm at Microsoft for a long time. I was originally attracted to the SDET role because they were the last defender of the customer experience, they were the engineers who held the line on quality. The entire industry is worse off for the SDET role having been eliminated across all major software companies.

[cm2012]

The best metaphor for this is the concept of resonant yaw.

Make one small 1 degree mistake on a rocket launch, you will end up hundreds of miles off target.

Make a small mistake in an organic system and you'll be fine, you can just iterate. You'll drive yourself crazy trying to get it perfect.

The trick is knowing which situation is which.

[drBonkers]

This also reminds me of the 1-way vs 2-way doors analogy Bezos mentioned in his interview with Lex Fridman — sweat the 1-way door decisions, not the 2-way door decisions.

[w10-1]

The Quality perspective seems more like persistence to me, attacking every potential issue (like Howard Hughes polishing rivets).

Persistence to me extends the reality principle to even minor and potential issues: they *must* be addressed (the "almost predatory" response) - driving engagement.

Obstinance to me reduces the reality principle to consistent facts, and serves more as avoidance.

(The flaw of the Quality perspective stems more from expanding bureaucratic incentives and achieving scale through excessive punishment driving aversive behaviors.)

[locallost]

Wouldn't nuking a product after 18 months be the opposite of the wrong kind of stubborn if it's the right thing to do? That's exactly my problem with views like these, it's always the other party that is "obstinate" and doesn't listen, but what if after 18 months the product as a whole didn't meet enough expectations? Then it would be very obstinate to insist on releasing it anyway, and a more pragmatic way to reach the goal (which in this case is ultimately to have a successful company) would be to shelve the product and eat the loss. I'm not saying that's the case here, but I am sure those QA people feel like if you asked them.

[ChrisMarshallNY]

It wasn't the wrong kind of stubborn. It was exactly the right thing to do, for this organization.

I'm not sure that it was, in the aggregate, the most beneficial decision for the company, but it was the decision they made, and I had to go along with it.

I do think that we could have addressed the Quality issues, in a couple of months, and the app was something that I think would have been "revolutionary." That "revolutionary" part probably contributed to its demise. Many QA types are very conservative, and risk-averse. I suspect that they wanted to find problems, because they didn't want to deal with a very different (albeit awesome) kind of application. There were also a couple of other reasons, which I won't go into, here, but they weren't particularly well-handled. They did make it easier for the conservatives to sway upper management.

[locallost]

I can't know what's correct there, but I don't need to. Ultimately it comes down to was it a success or not, for a company this basically means does it exist and is it profitable. In the alternate universe where things are done differently it could be better or worse. My main point is that whether it's the right or wrong stubborn depends on your point of view. Now Paul Graham has been very successful in business, but even there you might have different businesses. People took different approaches and were still successful. And business is just a narrow part of life. So what's bothering me here is that there are broad generalizations that in most cases come down to your point of view. This could ironically be interpreted as the wrong kind of stubborn.

[ChrisMarshallNY]

That is exactly why I said "it depends."

My experience, is that folks can't deal with "it depends." We have to have "hard and fast" rules, to be applied in all contexts.

Determining "it depends" almost always requires scars and contusions. Less-experienced folks often have a much more difficult time, making these decisions, than folks that have been around the track a few times.

The folks that decided to cancel that project were very highly-placed executives. It wasn't an easy decision. However, one of my mistakes, was underestimating just how obstinate and change-averse, the QA people could be, and how much real power they wielded. If I had accepted this, I maybe could have saved the project. It was a hard lesson, but one I learned well.

That corporation made some serious mistakes, mainly from being so risk-averse, that they allowed their competitors to eat their lunch, and suffered a pretty big implosion. I suspect that they will do OK, in the long run, but they took a real beating. Ironically, the reason they survived that drubbing, was because of their fiscal conservatism.

"Good judgment comes from experience. Experience comes from bad judgment."

[baxtr]

> They wouldn't be wrong. Making superb-Quality stuff is not a big moneymaker. You want lots of money, make lots of cheap, crappy things, and sell them at a small margin.

Or sell small amounts at a crazy margin. Getting rich is about profits not about sheer revenue.