Describe a time you advocated for a structural change to how engineering and QA collaborate.

Structural change at the lead level usually means changing how teams are organised, what roles do, or what process gates exist. The interviewer wants to see you operating at the system level.

STAR walkthrough — sample answer:

Situation: A previous company's QA team was organised as a centralised function — about a dozen QA engineers reporting to a QA manager, allocated to engineering squads on a project-by-project basis. The structure had been in place for years and had served when the company was smaller. With ~50 engineers across 6 squads now, it was creating predictable friction: QA engineers context-switched constantly, didn't develop deep domain knowledge, and squads treated them as external resources rather than team members.

Task: I'd been the QA lead for ~18 months. I'd come to believe the structure was the bottleneck — and that it should change to embedded QAs reporting into squad eng managers, with a "QA guild" for shared practice. This wasn't a tweak; it was an org change requiring senior leadership sign-off and the QA manager's role itself shifting.

Action: Six-month effort.

Months 1-2 — build the case. Pulled six months of data: cycle time per squad, bug escape rate, QA satisfaction (anonymous survey I ran), engineer satisfaction with QA collaboration. Made the case in numbers: squads with more stable QA assignments had lower escape rates and higher satisfaction on both sides. The current allocation pattern was actively eroding both.

Month 3 — coalition before proposal. Talked one-on-one with each of the six engineering managers. Listened to their experience with the current model — many had concerns about the existing dynamic but hadn't connected the dots to the structure. Got verbal alignment from four out of six on the principle of embedding before I formally proposed it.

Month 4 — the proposal. Wrote a 4-page memo: current state with data, proposed structure, transition plan (3 months, phased), implications for QA careers (clearer paths inside squads, guild for cross-squad practice), implications for the current QA manager (their role evolving to head-of-quality, owning standards across squads). Took it to the engineering director.

Month 5 — the difficult conversation. The most uncomfortable part was the QA manager's role change. I'd been transparent in the proposal that this affected them, and we had a long honest conversation. They had concerns I hadn't fully thought through (career identity, how performance management would work for embedded QAs). I revised the proposal based on their input — clarified the head-of-quality role, made performance reviews dual-input from squad EM and head-of-quality.

Month 6 — rollout. Two squads first as the pilot. Measured cycle time, escape rate, both sides' satisfaction over 6 weeks. Pilot data was strongly positive. Rolled out to remaining squads.

Result: A year later, escape rates were down ~40% on average across squads, QA satisfaction (same anonymous survey) had risen substantially, and engineering manager satisfaction with QA collaboration was the highest in three years. The head-of-quality role evolved into a strong organisational function. Two of the embedded QAs were promoted within the first year.

What I learned: structural change requires patience disproportionate to its eventual visibility. Six months of careful work for a change that, once made, looks obvious in hindsight. The hardest part was the conversation about the QA manager's role — not because they resisted, but because I had to confront the implications of my proposal honestly.

Why this works: shows operating at the system level, data-driven case-making, careful coalition-building, willingness to have the hardest conversation honestly, and durable outcomes. Strong lead signal.