Direct answer
The core move is to anchor authority in a shared, written artifact (a jointly-owned definition of release quality) rather than in the reporting line, so that "who my manager is" stops being the thing that decides whose judgment wins on a given release. Communication happens jointly instead of as a handoff, ownership is split by artifact instead of by person, and releases flow through a pre-agreed gate that both sides helped design.
Structured elaboration
Communication patterns: Replace sequential handoff meetings (engineering finishes, then hands to QA) with joint planning: both functions attend the same sprint and release planning sessions, not separate ones. A shared, always-on channel exists per release so questions surface in real time instead of at a handoff boundary. Because the two functions report to different leaders, a regular cadence, for example biweekly, between the engineering manager and the QA director exists specifically to reconcile priorities and resolve ambiguity before it reaches the individual contributors; unresolved tension at the leadership level otherwise leaks down and gets fought out between ICs (individual contributors, the engineers and testers doing the hands-on work rather than managing others) who have no authority to fix it.
Ownership boundaries: Define ownership by artifact, not by person or by reporting line. Engineering owns the code, the automated test suite, and the criteria for the continuous integration (CI) gate, an automated checkpoint that blocks a build from progressing until its tests pass. Manual QA owns exploratory and edge-case testing that automation doesn't cover, and sign-off against agreed release-readiness criteria. The critical piece is a single, jointly authored "definition of done" for a release, so neither reporting chain can unilaterally lower the quality bar under their own deadline pressure; changing the bar requires both sides to agree.
Release flow: A concrete flow looks like: feature complete, automated CI gate passes, manual QA runs an exploratory pass against pre-agreed risk areas, then a joint go/no-go call happens for anything above a defined risk threshold, with a representative from both the engineering manager's side and the QA director's side present. The risk threshold has to be written down rather than judged in the moment, or the tiering quietly collapses into whatever the person under deadline pressure decides it is. A workable default: a release takes the heavy path if it touches money movement, login and access control, or customer personal data; if it changes the shape of stored data in a way that cannot be undone by redeploying the previous build; or if it cannot be switched off quickly behind a feature flag (a configuration switch that disables a new code path without shipping new code). Everything else, copy changes, additive fields, internal tooling, takes the light path: the automated gate plus a written QA review, with no joint call. Stating the rule as properties of the change is what keeps the tier from being decided by whose deadline is closer. Using a RACI structure (Responsible, Accountable, Consulted, Informed, a way of naming exactly who does the work, who is answerable for the outcome, who must weigh in, and who just needs to know) at each gate prevents escalation from defaulting to "whoever is most senior in the room" and instead defaults to a pre-agreed decision owner.
Alternatives considered: Three other models are worth naming, because the choice between them is what the design really turns on. First, embed the manual testers in the engineering team day to day while their formal reporting line stays with the QA director, a dotted-line arrangement (someone takes daily direction from one leader while performance review and career path sit with another). That buys context and speed, but the embedded tester's incentives drift toward the team's ship date, and the independent view that made the separate reporting line worth having erodes; it is a reasonable choice for low-risk product surfaces and the wrong one for payments. Second, move manual QA under the engineering manager and remove the split entirely: cleanest authority, but a reorganization is rarely something you can make a precondition of your own collaboration model, and it deletes the independent escalation path. Third, leave QA as a pure gatekeeper holding a veto with no joint authorship of the bar: maximum independence, but that is the handoff dynamic this model exists to replace, and it pushes discovery of problems to the latest and most expensive moment. I would pick the shared-artifact model here because it keeps the independence the separate reporting line provides while removing the handoff that makes it expensive.
Trade-offs of this model:
- It prevents either side from unilaterally weakening the release bar under deadline pressure, since changing the bar requires joint agreement, which is the main benefit.
- It adds coordination overhead: joint planning and a cross-manager sync slow down low-risk changes if applied uniformly, so the model should tier itself, heavier process for high-risk releases, lighter for routine ones.
- No process design fixes a genuinely adversarial relationship between the engineering manager and the QA director; the model reduces how much the system depends on that relationship being healthy, but it doesn't replace the need for it.
- Without an explicit tie-breaker above both leaders, a genuine disagreement at a go/no-go call can stall indefinitely, so the model needs to name who breaks the tie in advance, for example a shared skip-level manager (a manager's manager, someone both disagreeing leaders report up to).
Worked example
Picture a fintech company shipping a payments feature. Engineering finishes with the automated critical-path suite passing. Manual QA runs an exploratory pass, deliberately probing retry behavior, and finds a rare but severe edge case: a race condition that can double-charge a customer under specific retry conditions. Under the model, that severity is already pre-classified in the joint definition of done as release-blocking, regardless of which side found it, so the go/no-go call is decided against the pre-agreed rubric instead of becoming a debate about whose deadline is closer. The release is held, a fix is scoped jointly, and the postmortem (a structured review of what happened and why, done without assigning individual blame) documents that retries weren't a tested dimension in automation, then updates both the automated suite and the exploratory test charter, so the fix strengthens both functions instead of becoming "QA's problem" alone.
Trade-offs and pitfalls
Beyond the trade-offs already named in the model itself, the main execution risk is letting the tiered process collapse back into uniform heavy process for everything, which erodes goodwill and gets quietly bypassed under deadline pressure. The other common failure is writing the joint definition of done once and never revisiting it, so it drifts out of sync with what the product actually needs to protect over time.
