I don't see that as mutually exclusive. A QA team can be more effective if you're taking steps beforehand to limit the scope of their work, which means your engineers need to start getting more hands on with that kind of work (code reviews, automated testing, whatever...)
Your quality problems might well come from poor or non-existent architectural decisions and tech-debt, and QA won't pick up on that stuff unless it manifests as a faulty requirement.
The earlier you catch a problem, the easier it is to fix.
Your quality problems might well come from poor or non-existent architectural decisions and tech-debt, and QA won't pick up on that stuff unless it manifests as a faulty requirement.
The earlier you catch a problem, the easier it is to fix.