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
1.**Your team's growth is your output now.** A team that's better at QA next quarter than this quarter is success.
2.**Get into design and planning meetings.** QA has the most value before a line of code is written.
3.**Fix the process before you fix the tests.** Bad tests are a symptom. The process that allowed them is the disease.
4.**Say "I don't know" more often.** It builds trust with engineers who know you can't know everything.