---
title: "After Senior QA: Lead the Release or Own the Platform?"
author: "Harry"
published: 2026-10-31T04:46:55.457Z
updated: 2026-10-31T05:06:52.965Z
category: "Career & Teams"
tags: ["qa-career-path"]
canonical: "https://fxblog.dev/posts/qa-lead-or-sdet-career-path"
---

# After Senior QA: Lead the Release or Own the Platform?

## Key takeaways

- After Senior QA the career forks into a lead path (QA Lead, QA Manager, Head of QA) and an IC path (Senior SDET, Staff, Principal Quality Engineer).
- A QA Lead's output is a release that ships at a known risk; a Staff Quality Engineer's output is a cross-team problem that stays solved after they leave it.
- A Lead escalates trade-offs as options with a recommendation and a decision deadline, instead of absorbing an impossible date.
- Staff work means finding a shared root cause, writing the design doc, getting other teams to adopt it with before-and-after numbers, and handing it over.
- An IC track is only real if the career framework writes it down with pay bands that match the manager equivalent.

> **TL;DR** After Senior, many testers take whichever step their company shows them, usually management, and become a player-coach who never coaches, the classic burnout. Strong SDETs stall at Senior instead, excellent in the codebase and invisible outside it. The SDET career path and the lead path are both promotions with different outputs: a team that works, or a technical problem that stays solved. Try one of each before you choose.
>
> **Do this:** Fill in the five-row table in "How to choose" for yourself, then ask your manager whether your career framework has a Staff level with pay bands that match a manager's.

[Part 4](04-senior-qa-risk-based-testing.md) ended with your risk calls holding and the Senior checklist's question: does coordination work appeal to you, or hard technical problems? At FieldFlow the technical one is in plain sight. Six squads share one staging database that every test mutates, and nobody trusts a red build.

Two people could take that on. A QA Lead makes sure R25 ships at a known risk despite it. A Staff Quality Engineer makes the problem stop.

**QA Career Path, in seven parts:**

1. The QA Career Path: Map Yourself by Scope, Not by Title
2. New QA Engineer? Test the Risk, Not the Ticket
3. Manual to Automation Testing in Six Months: Skip the Tutorial Loop
4. Senior QA: Depth Everywhere Is Depth Nowhere
5. **After Senior QA: Lead the Release or Own the Platform?** (you are here)
6. QA Manager to Head of QA: The Escape Bill That Wins Budget
7. Will AI Replace Testers? Make Your Judgment the Evidence

## Same hands-on time, different output

A QA Lead and a Staff Quality Engineer both spend about half their time hands-on. What differs is what you hand over at the end of a quarter.

|                   | QA Lead                           | Staff Quality Engineer               |
| ----------------- | --------------------------------- | ------------------------------------ |
| Scope             | A team's release                  | A problem that crosses teams         |
| Hands-on          | \~50%                             | \~50%                                |
| Main artifact     | Test plan, triage, sign-off draft | Design doc, RFC, migration plan      |
| Influence through | Running the release               | The teams that adopt your design     |
| Classic failure   | Player-coach who never coaches    | A brilliant platform no team adopted |

## The Lead version: hand over the trade-off

The Lead habit the repo spells out in full is escalating instead of absorbing pressure. Four sentences, on FieldFlow's sync and bulk invoicing:

```text
With current scope we make the 15th at high risk: sync tested to plan,
bulk invoicing smoke-only, two Sev-2s open. Options: (a) ship the 15th
accepting that in writing, (b) slip to the 19th and finish, (c) flag off
bulk invoicing and ship the 15th safely. My recommendation is (c).
Decision needed by Thursday noon.
```

> **Warning**
>
> Agreeing to an impossible date and paying with the team's weekends is a failure mode, not loyalty. The deadline trade-off belongs to the stakeholders, in writing.

## The Staff version: fix it for six squads

A Senior SDET fixes the invoicing squad's suite. A Staff Quality Engineer fixes why all six squads' suites are flaky, through other teams, not around them.

![Staff work at FieldFlow in four steps, from the shared staging database to a handed-over fix](https://fxblog.dev/media/01a19048-0449-7709-8d27-098364c01407/1600)

_The work is mostly persuasion with code behind it_

1. **Find the shared root cause.** Every squad's flakiness comes from the shared staging database. Nobody owns it.
2. **Write the design doc.** Per-test data builders and a database per CI run: cost, migration path, what each squad changes.
3. **Get it adopted.** Pilot with the friendliest squad, publish before and after numbers (flaky rate, pipeline minutes), help the other five migrate.
4. **Leave.** Hand it to a platform team or a named Senior SDET, with runbooks.

## How to choose

If your organisation lets you, try both: lead one release, and own one cross-team technical fix. Then compare:

| Signal                    | Leans IC                                | Leans manager                |
| ------------------------- | --------------------------------------- | ---------------------------- |
| A good day is…            | Solving a hard technical problem        | Unblocking someone else      |
| You lose energy from…     | Back-to-back 1:1s and status reports    | Long solo debugging sessions |
| You want to be judged on… | What you built and its adoption         | What your team achieved      |
| Conflict you can tolerate | Technical disagreement in design review | Performance conversations    |
| What you'd miss           | Writing code daily                      | Nothing much about code      |

> **Tip**
>
> The IC track is only real if it's written down. If the only path past Senior is management, the IC track is a promise, not a ladder.

Switching is allowed: Senior to Lead and back to Staff, or Manager to Principal. On a real dual ladder, Staff and Principal pay on par with Manager and Director. I don't quote salaries here; check levels.fyi and Glassdoor for your market.

## Try it

```text
Here are my last three months at work: <what I did, what I enjoyed, what drained me>.
Map each item to "lead-shaped" or "Staff-shaped" using: unblocking people,
running a release, solving a hard technical problem, writing a design others adopt.
Then suggest one rep of the other shape I could try next quarter.
```

Say you take the lead road, then the step after it: QA Manager, signing FieldFlow's releases. Now the asks come from above. A director wants every tester to log 5 bugs a day, and you want one more SDET, with last quarter's 11 escapes in the records. What do you put in front of them? Part 6, **QA Manager to Head of QA: The Escape Bill That Wins Budget**, does the arithmetic.

## Read this with your AI

```text
Read the post "After Senior QA: Lead the Release or Own the Platform?".
1. Summarise it in 5 bullets for a senior tester choosing a track.
2. Ask me 3 questions to check I understood; wait, then correct me.
3. Interview me with the five signals and tell me which way I lean, and why.
```

> **Success**
>
> You know what each road produces, and how to test both before you commit. Next: **QA Manager to Head of QA: The Escape Bill That Wins Budget**.

## FAQ

### Should I become a QA Lead or a Staff SDET?

Try a rep of each first: lead one release and own one cross-team technical fix. If a good day is unblocking people, lean manager; if it is solving a hard technical problem that others adopt, lean IC.

### Is the IC track a real promotion in QA?

Where the career framework has Staff and Principal levels with pay bands matching Manager and Director, yes. If the only path past Senior is management, the IC track is a promise rather than a ladder.

### Can I switch between the lead and IC tracks later?

Yes. Many people go from Senior to Lead and back to Staff, or from Manager to Principal, and the time on each side tends to make them better at the other.
