4 ms·

> Create an environment where your Quality Team can't get purchase to get everything they need done, then look to the top for what's more important than Quality

> Create an environment where your Quality Team can't get purchase to get everything they need done, then look to the top for what's more important than Quality. The answer usually isn't hard or long in terms of being found. This sounds more like a failure of QA to recognize their role in a larger picture. It's a general problem, not specific to QA. I work on reliability engineering and have certainly been guilty of it. The company's bar for "enough quality/reliability" is likely lower than yours and mine. The company's is pragmatic and ours is likely ideological. I probably don't even care about quality control as much as you, and you likely don't care as much about reliability as me. We each over value our own niche because it's what we're trained to inspect, and we know how easy it is to fix some of those things. My tools for dealing with it mostly involve realigning my work with what the business wants, rather than what I'd ideologically prefer, and working to see why the business wants that. It's probably not to improve reliability, but it cuts costs somewhere or something I can get behind.

salawat 3y ago
Your reliability goal, falls under my definition of quality. See, that which is not reliable has ill-defined behaviors/specs/implementations somewhere. My QA groups would be working hand-in-hand with you in order to not only meet your goals, but the rest of the org's. 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; another aspect of organizational Quality that is often an issue except maybe in as much as there may be a token word thrown in edgewise or a backlog item from time to time to shore up tools needed by other departments. Quality assurance is often a level higher in that we're analyzing "is there a missing signal that needs to be propagated here. When the org makes it abundantly clear "Quality" is no longer a first order objective. "Pragmatism" is orthogonal to Quality, one can make a pragmatic decision without detrimentally effecting overall Quality as long as one is addressing all the points and dependencies one needs to in making the decision. That need is not used in the rhetorical, but mechanical sense. 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. If you wonder what it takes for a person to come in and spend day-in, and day-out, looking over every minute detail, pointing out faults, braving the risk of social stigma to keep orgs honest, and to do well at it; it's largely compassion, pride in a job well done, and a concern about who suffers down the road. The end result is the person being faced with a question: Am I okay with being responsible for this? Is this a cause I'm okay with perpetuating? Presto. Instant excessive turn-over. And short of being a player at the C-table or Board layer, there is nothing to be done about it. Quality cannot prevail without being an existential concern. Period.
- everforward 3y ago
  > 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.

salawat 3y ago

Your reliability goal, falls under my definition of quality. See, that which is not reliable has ill-defined behaviors/specs/implementations somewhere. My QA groups would be working hand-in-hand with you in order to not only meet your goals, but the rest of the org's. 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; another aspect of organizational Quality that is often an issue except maybe in as much as there may be a token word thrown in edgewise or a backlog item from time to time to shore up tools needed by other departments. Quality assurance is often a level higher in that we're analyzing "is there a missing signal that needs to be propagated here. When the org makes it abundantly clear "Quality" is no longer a first order objective. "Pragmatism" is orthogonal to Quality, one can make a pragmatic decision without detrimentally effecting overall Quality as long as one is addressing all the points and dependencies one needs to in making the decision. That need is not used in the rhetorical, but mechanical sense. 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. If you wonder what it takes for a person to come in and spend day-in, and day-out, looking over every minute detail, pointing out faults, braving the risk of social stigma to keep orgs honest, and to do well at it; it's largely compassion, pride in a job well done, and a concern about who suffers down the road. The end result is the person being faced with a question: Am I okay with being responsible for this? Is this a cause I'm okay with perpetuating? Presto. Instant excessive turn-over. And short of being a player at the C-table or Board layer, there is nothing to be done about it. Quality cannot prevail without being an existential concern. Period.

everforward 3y ago
> 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.