How do you build a quality culture in a team that historically saw QA as a gate, not a partner?

Cultural change is the hardest leadership work. The interviewer wants to see patient, sustained, structural moves rather than declarations.

STAR walkthrough — sample answer:

Situation: I joined a 60-engineer org as the lead QA engineer (reporting to the engineering director). The org's working pattern was textbook gate-style: engineers wrote code, QA tested at the end, bugs got bounced back, friction was constant. Engineers viewed QA as people who delayed releases. QA viewed engineers as people who didn't care about quality. Both sides were wrong, but the dynamic was self-reinforcing.

Task: Shift the working relationship from gate to partner over 12-18 months. No magic wand; this needed multiple structural changes.

Action: Five interlocking moves:

1. Move QA upstream into design. Got QA included in product/eng design reviews from day one of features, not "after spec is signed off." QA's contribution at design: testability concerns, edge case raising, observability requirements. Engineers started seeing QA as a useful early voice, not a late blocker.

2. Replace the gate with shared ownership. Removed the "QA approval" step in the release process. Instead, every PR had to include either tests or a written justification. QA became the people who built the testing capabilities engineers used (smoke layers, fixtures, harnesses, framework guidance), not the people who tested last.

3. Share quality data engineers actually use. Built dashboards visible in eng channels: PR pipeline runtime, flake rate per service, escape rate per squad, time-to-detect for new bugs. Made it easy to see "is my squad's quality trending well?" — engineers started self-organising around the numbers.

4. Embed not police. Reorganised QAs to embed in squads (one per squad) rather than sit in a shared QA team. Their goal: enable the squad to ship with confidence, not approve their work. Within a quarter, several engineers were writing E2E tests themselves with QA support.

5. Hire and reward differently. Promotion criteria for engineers got "demonstrated investment in testability and reliability" added. QA promotion criteria emphasised influence — did you raise the team's level — not just personal output.

Result: Over 12 months: PR pipeline trust score (an internal survey metric) went from 5/10 to 8/10. Engineers writing their own E2E tests: from rare to ~70% of new features. Production incident rate roughly halved. The "us vs them" framing largely dissolved — most engineers I worked with by month 12 saw QA as the people who'd helped them ship faster, not slower.

What I learned: cultural change isn't a campaign; it's structural. You change the structures (where QA sits, what data is shared, what's rewarded) and the culture follows. Speeches and edicts don't move it.

Why this works: shows multiple interlocking structural changes rather than a single grand gesture, patience (12+ months), measurable outcomes, and lasting effect. Strong lead signal of organisational thinking.