> The devs will lie to QA, or withhold the full truth, for a number of reasons

Avoiding a QA silo doesn't automatically fix the root issue. They'll do this with their managers or teammates too if things are sufficiently FUBAR.

As a developer, a good QA team is worth their weight to me in gold. Reach out proactively and engage them about new features you've built that you want 'em to hammer on - they'll be better at finding all the edge cases you didn't think about than you will. By engaging them early, you're more likely to get bug reports for code you still remember, and less likely to have them filing bugs right before launch at the 11th hour where your manager might plead for yet more crunch and overtime. If they're thoroughly testing my code for me, that's less time I need to spend carefully hammering my own code to avoid future blame. They'll help me hammer out good repro cases for strange bugs, and test on more varied hardware with different timings and usage patterns.

> they don't work for QA so QA has no direct authority

If devs aren't held to account for shipping broken shit, embedded QA won't necessairly fare much better.

> QA comes after the fact and it's too late to change things (or at least too late to change them the right way)

You can have quick turnarounds with QA teams. They definitely need to be able to get their hands on builds quick enough to provide devs useful feedback before shipping, though, and can't be siloed to the point of blocking direct communication. Even external QA teams employed by another company can succeed here though.

> QA lacks the engineering background to understand what it is that they're testing (so they test the superficial things and don't test the showstoppers);

Hire better QA and/or educate your existing QA better. They can chase superfical things and checklists, but if you can't explain enough of the basics for them to help chase down a crash or misbehavior you might be worried about, you've got a problem. Poor documentation, poor communication, poor guidance, poor understanding, too much bureaucracy... something fixable.

Perhaps the structure of game development has some tips here - we've often got multiple QA teams:

1. Internal studio-wide QA teams, which help chase down bugs internally so you don't have to - probably in the same building, at least. Rarely gatekeepers in and of themselves, but they do have the ear of your production staff.

2. External second party QA teams - possibly contractors, possibly employed by your publisher, maybe in another city entirely. Slower turnaround, but more vast and a fresh set of eyes not ruined by being too close to the project for too long. Can also include not-quite-"QA" specialty stuff like usability testing. Brought on later into the project.

3. External third party QA teams. Employed by the console vendors, not by you or your publisher. These guys can throw a wrench into your release schedule, and then charge your company for the privilige of having another go if you've failed the certification process a few too many times (or at least, they could at one point.)

Even if you have an adverserial relationship with the console vendor's QA teams, you'll buddy up to your second party and internal QA teams to find enough of the bugs to ship on time with minimal crunch if you have the slighest lick of sense, even if you haven't the slighest bit of shame at shipping broken things. They're the ones who will help you avoid failing certification, after all.