> if you say you want quality software but reward people for pushing out barely functioning rubbish, people are smart enough to figure out you don’t really mean that
It's even worse than that in a lot of places. Sometimes, you know your management doesn't understand quality to the extent that they would prioritise it over their other desires. However, they say that quality is the most important thing. The programmer thinks, "OK, maybe I won't be rewarded for quality, but since they say that they want it, I'm just going to do it. I want it, and that is good enough". But in reality, the programmer is often punished for implementing quality above what management thinks is necessary. You sometimes get into a situation where management no longer trusts the developers because the developers are working on things that management doesn't understand (quality related). Management then resorts to micro-management to force the developers to do what they want.
I'm in management, product management, and have never heard management say quality is most important.
What is most important is sales, without sales you have no revenue, you can't pay the bills, you can't pay your employees, and you will go bankrupt.
Next, is customer success. For repeat sales you need customers succeeding with your software. You need to bring the value your customers are looking for. Otherwise, long term, you don't have sales.
Quality is important, as it is one aspect that is valued by customers and that will help them succeed with your software. Features are another important aspect required to ensure benefits for customers. Quality without features is nothing.
Of course there are many benefits from having quality, most importantly reducing risks, lowering costs, and improving time to market, so it is really important, but not the most important thing.
Actually, this is a super important point. One time when I was working in a fairly large software company (about 1400 people), my division somehow got placed under sales. We had quarterly company meetings where upper management would try to drive home the important things to the company. The thing was that they split up these meetings into 3 groups: IT, Sales and Business. I was used to going to the IT meetings where they would talk to us about the company values -- especially quality. When I went to the sales meeting, apparently nobody told upper management that there was a group of programmers there because they went on and on about how they knew the product was crap and how they didn't care one iota. Sales job was to sell. A good sales person should be able to sell anything -- even actual crap. Good management knows how to say what it needs to for every audience ;-)
But the problem is that quality and sales go together, no? You can't really separate the two, unless your business model involves actively deceiving customers. This dichotomy is analogous to how UX is sometimes thought of as lipstick put on functionality, where in actuality it should be integral to the design and implementation of said functionality
Probably what you meant is that level of quality needed is only as much as is needed to generate the requisite level of sales. The problem then becomes one of judgment: management consistently under-estimates the level of quality required, or they focus on the wrong sort of quality. The world is full of bad products simply because of such issues.
Or you make quality explicit and let the customer decide: do you want Ikea furniture, or do you buy your furniture from a top tier furniture brand? Do you buy kia, ford, Rolls Royce?
You want the level of quality the customer cares about.
Quality is not an absolute thing: you either have quality or not. Quality is a range, from very bad quality with no validation to 100% full coverage, full testing, works in all situations.
Usually customers are not willing to pay for 100% and as a business you do not have the time nor budget to build for a 100% quality.
Look everyone! We found a product manager for the Boeing 737 Max!
How was your tenure at Equifax?
Seriously, though... A workplace with this mentality has a high-turnover rate from burnout. Things keeps breaking, things are perpetually behind schedule, and a toxic work culture usually clouds the office. This perspective drives companies into the ground and pushes engineering teams towards mental breakdown. This is not a sustainable model.
However, there is a reckoning happening (right now) for all of these shitty businesses in the form of security breaches. Your lie "Quality is important" will bitch-slap you in the face when there are serious economic penalties for bad quality. GDPR is that reckoning and the US will soon follow.
It's even worse than that in a lot of places. Sometimes, you know your management doesn't understand quality to the extent that they would prioritise it over their other desires. However, they say that quality is the most important thing. The programmer thinks, "OK, maybe I won't be rewarded for quality, but since they say that they want it, I'm just going to do it. I want it, and that is good enough". But in reality, the programmer is often punished for implementing quality above what management thinks is necessary. You sometimes get into a situation where management no longer trusts the developers because the developers are working on things that management doesn't understand (quality related). Management then resorts to micro-management to force the developers to do what they want.