> Your experience as an SRE doesn't even necessarily encompass the integrations that have to happen with other operational departments; or even extra-organizati

> Your experience as an SRE doesn't even necessarily encompass the integrations that have to happen with other operational departments; or even extra-organizational interfaces; I promise you it does; these are often the hardest part of my job. I interface with a half-dozen other operational departments, though no external teams at the moment. > Once your management looks at you when you have a high quality culture, and then goes "Good, now find things to throw out to make it cheaper. We don't care what it takes. Or starts tacitly encouraging people to short circuit your Quality group, you have a cancerous growth that a Quality group is hierarchically unable to do anything about. Right, and this is what I'm saying is a fundamental misunderstanding about QA's role (and mine, and virtually every role). Your role is not to provide the best QA possible at any price. Your role, in the company, is to provide acceptable quality at the lowest price possible. Mine is to provide acceptable reliability at the lowest price possible. If managers are trying to get you to cut corners, what they're saying is that you're spending money on guaranteeing quality that clients (not the business) don't value enough. Clients are not willing to pay the premium for higher quality. They'd rather get the product for 10% cheaper and accept occasional bugs. > Am I okay with being responsible for this? Is this a cause I'm okay with perpetuating? I think we're on different ideological grounds here. For me, reliability and QA is a means to an end: providing value to the customer. QA and reliability don't have any intrinsic value; that is to say their value is defined by the customer. I don't get warm and fuzzy feelings for building out reliability the customer doesn't want. It doesn't do me any good to build out a 99.999999999% availability cluster if no one is going to pay $12M/month to use it. If the customers want low reliability and low costs, that's fine, I'll give them as much reliability as I can for what they want to spend. I can be proud of the reliability I achieved on the budget customers gave me. QA is the same way. QA only has value as far as customers decide it does. The pride comes from giving them as much quality as I can for what they're willing to spend on reliability. Customers aren't sheep. If they wanted incredible QA and were willing to pay for it, they'd find someone who could provide it. But they don't, because they don't value the level of QA you want at the price it costs to achieve. Look at Windows. The patches break stuff all the time, to the point that many orgs delay Windows updates for months. And yet people keep buying Windows licenses. The market doesn't value Windows' QA process enough to demand a more bug free update channel and pay commensurately. Shit, we basically are Windows' QA at this point on the non-business consumer side. People want Windows bad enough to basically volunteer to QA releases for businesses as part of their Windows licenses. Broadly speaking, the market is willing to pay for enough QA to prevent bugs with permanent damage (data loss) and that's about it. Frequent bugs are tolerable as long as they don't cause data loss, or break integral workflows too often. Nobody really cares that your app has a 4th bug that causes window resizing to break, or some config option to not apply. I mean, it would be great if those bugs didn't exist, but I'm not paying 20% more to cover enough QA salaries to prevent those bugs. > Quality cannot prevail without being an existential concern. Period. A business cannot exist with quality being it's existential concern, because it's existence is denominated in dollars, not bugs. QA and most other facets of the business are only valued so long as they are positively correlated with profit.