From SDET to QA Lead: the shift no one warns you about

This is the third transition on the QA career arc. Manual to automation is the first: learning to code, learning a framework, getting your first automation job. SDET is the second: deepening infrastructure skills, owning test architecture, interviewing into senior individual contributor roles. QA Lead is the third, and it's the one that breaks the most people — not because it's the hardest technically, but because the skills that got you here stop working.

The metric shift

As an SDET, your value was legible. You wrote tests. The tests ran. They caught bugs. The suite coverage grew. Your commit history was the evidence of your contribution. Performance reviews were easy to prep for: "I wrote 40 tests this quarter, reduced flake rate from 18% to 2%, implemented the fixture system."

As a QA Lead, your value is what your team ships. If your team writes good tests, you're a good lead — even if you haven't written a test yourself in two months. If your team's test suite is a mess, you're accountable — even if your own code is spotless.

This is a complete inversion of the contribution model, and most people don't internalise it for the first six months. They keep optimising for individual output (writing tests, reviewing code, fixing flakes) while the thing they're actually being evaluated on (team output, team health, team velocity) drifts.

The moment this clicked for me: I spent a week fixing a particularly nasty set of flaky tests. The suite went from 12% flake to 3%. I felt great. My manager pulled me aside and said "that's great, but who on your team learned how to fix flaky tests this week?" Nobody had. I'd done the work myself, efficiently, and taught nobody anything. A good week as an IC; a weak week as a lead.

Three things to stop doing immediately

Stop writing tests. This is the hardest one. Writing tests is comfortable, visible, and gives you the direct feedback loop you're used to. But every test you write is a test a team member didn't write — and didn't learn to write. Your job is to multiply your team's capability, not to add your own capability to theirs. Reserve coding time for architecture decisions, proof-of-concept work, and pairing sessions where someone else is at the keyboard.

Stop reviewing every PR. You'll be tempted to be the quality gate on everything. Don't. It creates a bottleneck (your review is on the critical path for every merge), a single point of failure (you're on vacation, nothing merges), and a learned helplessness in the team ("the lead will catch it"). Define standards, hold code review training, spot-check rather than reviewing everything. Let the team own quality.

Stop owning the flaky-test list. On the SDET career arc, flaky tests are your problem to fix. As QA Lead, flaky tests are your team's problem to fix — your job is to build the system that makes them fix them. Create a rotation. Define what "flaky" means in your team's terminology. Set a threshold that triggers an automatic investigation. Celebrate when a team member finds and fixes a root cause. Don't fix the flakes yourself.

Three things to start doing

Weekly 1:1s. No skipping. No combining. One per person, thirty minutes minimum. The 1:1 is not a status meeting — your Jira board handles status. It's a dedicated space for your team member to tell you what they can't say in a standup: what's frustrating them, what they feel unprepared for, what they want to learn. Ask open questions. Take notes. Follow up next week on what they said this week. The 1:1 is how you learn what's actually blocking your team before it becomes a crisis.

Hiring involvement. Even if you don't have open headcount, you should always be thinking about the team you're building. Who are you trying to hire next? What skills gap are you trying to fill? Have you updated your interview loop since you inherited it? Talk to your manager about headcount planning before it's urgent. The best time to think about hiring is when you don't need to hire.

Calendar audits. Every two weeks, open your calendar and categorise every event from the last two weeks: coding, reviewing, 1:1s, cross-functional meetings, planning, hiring, admin. If more than 40% of your time is in coding and reviewing, you're still operating as an IC with a different title. If less than 15% of your time is in 1:1s and team development, you're underinvesting in the thing that actually compounds. The calendar doesn't lie. This audit is what saved me in month three — I looked at two weeks of calendar history and realised I'd spent 60% of my time in Jira tickets and code reviews. That's not a lead's job.

The contributor's trap

There's a specific failure mode I call the contributor's trap, and it's the one that ends most first-time QA Lead tenures in quiet disappointment.

You were, before the promotion, the most capable engineer on the team. You got the promotion because of that capability. On a hard technical problem, you're still the fastest path to a solution. This is a trap.

Every time you solve a problem yourself instead of developing someone else's ability to solve it, you get a short-term win and a long-term loss. Short-term: the problem is solved quickly. Long-term: your team doesn't grow, you remain a bottleneck, and you burn out being the person who does everything. The job of a lead is not to have the highest personal throughput. It's to have the highest team throughput.

The reframe that helped me: your job is to make your team not need you. A team that runs well when you're out sick, takes holiday, or moves to a different project — that's a well-led team. A team that falls apart when you're unavailable is a team with a single point of failure named after you.

What to do in month one

Don't change anything. This is the advice I ignored and regret ignoring.

You'll arrive with ideas. Things you'd do differently. Process improvements you've been wanting to make since you were an IC. Resist. Spend month one observing: attend every meeting without agenda-setting it, review how the team works without redirecting it, ask questions instead of proposing solutions.

At the end of month one, you'll have a much more accurate model of what the team actually needs versus what you thought it needed from the outside. The changes you make in month two will be better calibrated and will face less resistance because they'll be grounded in observed reality rather than external assumptions.

The team you inherited is doing things a certain way for reasons — some good, some bad, some legacy. You won't know which is which until you watch for a month. Changing things before you know the reasons is how you accidentally remove the one good process while keeping all the bad ones.

The QA Lead role is the hardest transition in the QA career arc because the feedback loop is longer, the metrics are softer, and the skills are orthogonal to what you've been building. Give yourself a full quarter before you evaluate whether you're doing it right. The first month you'll feel lost; the second you'll start to see patterns; the third, if you've done the calendar audits and the 1:1s and resisted the contributor's trap, you'll start to see the job for what it is: a force multiplier, not an individual performer.