What I Thought the Job Was
I thought being a QA Lead meant doing QA, better and faster, with more authority.
More test cases. More automation coverage. More say in what goes into the release.
That's not what it is.
What the Job Actually Is
The QA Lead job is almost entirely communication and process design.
It's working with developers to catch things earlier. It's working with product to understand what "done" actually means. It's building the systems that let your team work confidently without asking you every ten minutes.
The actual testing (running it, reviewing it, writing it) is a smaller and smaller part of the job the further along you go.
I wasn't ready for that. I had to learn to get value out of work I didn't do myself.
The First Big Mistake
I tried to review everything.
Every test case written by the team. Every bug report. Every automation PR.
This doesn't scale. It also sends the wrong message. It says "I don't trust you to do this without me."
What works better: review the framework and standards, not every instance. Invest in making the team good at the job, then let them do it.
On Metrics
Every manager eventually asks for metrics. I had to figure out which ones meant something.
Test execution counts: mostly vanity. Code coverage percentages: useful ceiling, useless floor. Bug escape rate: this one matters. Flaky test count: matters a lot.
The metrics that matter most are the ones that connect to what customers actually experience.
What I'd Tell Myself at the Start
Your team's growth is your output now. Not your test case count, not your automation coverage number. A team that's genuinely better at QA next quarter than this quarter? That's what success looks like from this seat.
Get into design and planning meetings, and get there before any code is written. That's where QA has the most leverage. Once the sprint is running and decisions are locked in, you're mostly playing catch-up.
Fix the process before you fix the tests. Bad tests are a symptom. The thing that allowed them to be written, merged, and kept around without question? That's the disease. Fixing individual tests without touching the process means you'll be fixing tests forever.
Say "I don't know" more often. It feels risky early on, like it undermines your authority. It doesn't. Engineers who know you're being straight with them will trust you more for it, not less.