The First 30 Days as a New QA Lead, Week by Week
The first 30 days as a QA lead set the trajectory of the next two years. Not because anyone expects you to fix the test suite in a month — they do not — but because the people around you are quietly cataloguing what you notice, what you defer, and what you announce. A lead who shows up swinging a framework rewrite teaches the team to hide problems. A lead who reads, watches, and asks better questions teaches them to surface them. This playbook is the second version.
Key takeaways
- Week 1 is for listening, not changing. Read the last 50 bug tickets, shadow standups, pair-test with one engineer a day. Decide nothing.
- Week 2 is for mapping. Build a single-page picture of test environments, automation surface, manual coverage, bug intake, and on-call. If it does not fit on one page, you do not understand it yet.
- Week 3 is for 1:1s. Every QA, every EM, the product lead. Same five questions of each. The patterns are the answer.
- Week 4 is for naming one to three changes — not ten. The shortlist your data supports. Everything else goes on a 90-day list.
- The metrics you baseline in month one are the only ones you can credibly improve in month three. Escaped defect rate, mean time to triage, CI red rate, flaky-test percentage. Write them down before you touch anything.
A QA lead has less formal authority than the role implies. Usually no budget, no headcount, no seat in roadmap planning. Influence runs through trust — of the QAs reporting to you, the EMs next to you, the product leaders who decide what ships. The first month is when the compounding rate is fixed. The playbook below is the narrow path between changing too much, too fast — and changing too little to be seen.
Week 1: listen, do not change
The first week has one job — answer "what is actually going on here?" — and the worst thing you can do is interrupt the answer with your own opinions. Five concrete actions fill the week:
- Read the last 50 bug tickets in the tracker. Not the ones the team flagged for you — the actual last 50 in chronological order. Severity, priority, assignee, time-to-triage, time-to-fix, comment threads. The shape of the backlog tells you what the team prioritises in practice, regardless of what they say.
- Shadow standups for every squad QA touches. Sit quietly. Note who talks about quality voluntarily, and whether QA is treated as a blocker, a partner, or invisible. Standups are the lowest-friction window into how engineering treats testing day to day.
- Pair-test with one engineer per day. Sit next to a developer and ask them to walk through how they verify their own code. You will learn more in five sessions than from any wiki document. Engineers test what they have been taught matters; what they skip is what nobody has ever rewarded them for.
- Audit CI bug-pass rates. Pull the build history. What share of builds are red? What share are flaky tests rather than real regressions? A pipeline that is red half the time has stopped functioning as a quality gate — the team has already adapted by ignoring it.
- Read the test-plan inventory. Test cases, manual checklists, automation suites, release checklists. Note the dates. A test plan last edited in 2023 is not a test plan. It is folklore.
Document everything in a single notes file — you will reread it in week four. What you do not do in week 1: announce changes, criticise tooling, or rewrite a single line of test code.
Week 2: map the system on a single page
Week two turns listening into a model. The deliverable is a single-page picture of the quality system — environments, surface, coverage, intake, on-call. If it does not fit on one page, keep cutting. A system you cannot describe on one page is one nobody on the team can describe either. The five things to map:
- Test environments. Local, dev, staging, pre-prod, production. Which one does QA run against? How fresh is the data? Who owns it? An environment that takes a day to refresh reshapes everything downstream.
- Automation surface. What is automated, in what framework, owned by whom. Pull the test counts against the product's surface area. A 600-test suite that exercises 12% of user-facing flows is not coverage — it is theatre. Be specific: "60% of our tests cover the admin dashboard, which represents 8% of revenue" is the sentence that earns you the right to propose a change later.
- Manual coverage. What gets tested by hand, by whom, on what cadence. Manual coverage is almost always under-documented — which means it walks out the door the day someone leaves.
- Bug intake channels. Where do bugs enter from — engineers, support, sales, founder, customers, monitoring? What share are filed with enough to reproduce? Teams that ship cleanly almost always have one canonical intake channel and zero tolerance for Slack-thread bugs.
- On-call and escalation. Who gets paged when production breaks? Is QA on the rotation, and should they be? Does the post-incident process produce learning, or just a Slack message that says "fixed"?
Most leads who skip the map redesign the same thing twice in their first quarter. Three days drawing the system is the cheapest insurance you can buy. For broader 2026 context, the Crosscheck team's state of QA 2026 trends brief is a useful companion.
Week 3: the 1:1 round
By week three you have enough context to ask real questions. Not "tell me about yourself" — every QA in the building has answered that for six different leads. Specific questions, anchored in what you noticed in weeks one and two. Run 1:1s with three groups.
Every QA who reports to you
The QAs already have answers — they have been waiting for someone to ask. These are the most important conversations of the month. Ask roughly the same five questions of each:
- What is one thing about how QA works here that you would change tomorrow if you could?
- What is one thing you hope I do not change?
- Where do you feel your work is invisible to engineering?
- What did the last lead do well, and what did they get wrong?
- What does success look like for you over the next 12 months?
The patterns across answers are the answer. If four out of five QAs say the same thing about an automation framework, a release process, or an engineering manager — that is signal. If they all dance around one specific topic, that is also signal.
Every engineering manager whose team QA touches
EMs are your peers and partners, not your reports. Distant EM relationships are the single biggest predictor of QA leads who burn out at six months. Ask each: how does your team honestly think about quality, where does QA help you most and where does it slow you down, and what is the next big risk on your roadmap? The answers that surprise you are the ones to revisit.
Product and design leadership
Spend an hour with the product lead and one with design. A QA function that operates in isolation from product gets permanently relegated to the end of the pipeline. Ask what quality means to them right now and what the biggest risk on the roadmap is. By the end of week three you should have 12 to 25 1:1s logged — the most valuable artefact of your first month.
Week 4: name one to three changes
The temptation in week four is to write a 10-point plan and announce yourself as the leader who is finally going to fix QA. The 10-point plan is the most reliable signal of a lead about to lose the team's trust by quarter two.
Pick one to three changes. The ones your data from weeks one through three actually supports — not the ones a senior leader hinted at on day one, not the ones your last company made. The shortlist your current team would, if pressed, endorse as the highest-impact next moves.
Examples of what a one-to-three list looks like:
- A flaky-test taskforce. Two QAs and one engineer, four weeks — bring the CI red rate from 40% to under 10%. Concrete, measurable, finishable.
- A bug-report quality bar. A short standard for what a tracker ticket must contain before triage, plus tooling to make hitting the bar painless.
- A weekly triage cadence. Thirty minutes, every Friday, with QA, EM, and product. Every new bug gets a severity, an owner, and a target sprint.
What does not belong on a 30-day shortlist: a framework migration, an org restructure, a metrics dashboard nobody asked for, or any change whose first visible effect is more than 90 days out. Present the shortlist to your manager first, then the QAs, then the EMs. By end of week four, the plan should belong to the team — not just to you.
Anti-patterns to avoid in the first 30 days
A few moves new QA leads make consistently put them on the slow track for two years. They share one quality — each lets the new lead skip the hard work of listening.
Rewriting the test framework on day one. A migration proposed before understanding why the current one was chosen teaches the team you do not respect the work they did before you arrived. It may still be right in month three — by then you will know what to migrate and who to take with you.
Firing or restructuring before listening. Half the leads who restructure in the first 30 days admit later that they were resolving their own discomfort, not a real problem. The QA you would have let go in month one is sometimes the one carrying institutional memory in month four.
Importing your last company's process whole-cloth. A process that worked at a 200-engineer fintech with a dedicated SDET team rarely lands the same way at a 30-engineer SaaS with two manual QAs. The last playbook is a reference, not a transplant.
Announcing a metrics dashboard nobody asked for. Dashboards that exist before the team agrees on what they measure become wallpaper. Dashboards that emerge from a question stuck on the wall become the compass.
Skipping the founder, CTO, or customer-success lead. Even if QA does not report to them, they define what "quality" means to the business. A lead invisible to them spends two years fighting to be heard.
Metrics to baseline early
The metrics you write down in month one are the only ones you can credibly improve in month three. A lead whose first quarterly review claims "we reduced escaped defects by 40%" gets believed only if "escaped defects" was a number they captured before they touched anything. Five worth capturing around day 15:
- Escaped defect rate. Bugs that reached production last quarter, divided by total bugs filed. The cleanest single measure of the prevention machine.
- Mean time to triage. Hours between a bug entering the tracker and getting a severity, owner, and sprint target. Long queues are the leading indicator of a broken intake culture.
- CI red rate. What share of merges to main land on a red build. Above 20% means the gate is leaking.
- Flaky-test percentage. What share of test failures are not real regressions. Above 15% and the team has started ignoring the suite — once they have, getting trust back is a six-month project.
- Manual regression hours per release. How much engineering and QA time is absorbed hand-running the same flows. This is the number that justifies — or rejects — automation investment.
Write the baseline down with a date, share it with your manager, and resist the urge to optimise any of them in the first month. The point of the baseline is not to tune — it is to know. For context, see the QA engineer salary guide for 2026 and how to set up a QA workflow for small teams.
Reading list, communities, mentor
Nobody learns to lead a QA function entirely on the job. The leads who level up fastest joined two or three communities, picked a small reading shelf, and found one mentor a few years ahead.
Communities (2026): Ministry of Testing is the central QA community — a Slack with ~25,000 members, events through MoTaCon and TestBash, and a leadership chapter that explicitly addresses the lead-and-manager transition. Testing Peers runs a long-standing podcast and community focused on test leadership. The QE Unit is where to go when the role conversation in your org shifts from "QA" to "quality engineering." r/QualityAssurance has limits but the hiring and "is my company normal?" threads are useful pressure-testing.
Books worth one weekend each: Lessons Learned in Software Testing by Kaner, Bach, and Pettichord. The Unicorn Project by Gene Kim, which shows what a healthy QA function looks like inside a broken engineering org. The Essential Deming is older and broader than software, but the underlying ideas about variance and systems hold up. The Manager's Path by Camille Fournier translates almost directly to the QA-lead transition.
Find a mentor. Ask someone two or three rungs ahead for a 30-minute call once a quarter. Most senior QA leaders will say yes. LinkedIn cold messages with a specific ask work better than people expect.
For industry context, the Capgemini World Quality Report 2025-26 and the PractiTest 2026 State of Testing Report are worth reading cover to cover.
What month two looks like
By day 30 you should be able to describe, in under five minutes: what kind of QA function this is, the one to three changes you have committed to for the next 60 days, the metrics you have baselined, and the people whose trust you most need to build. If you cannot, extend the listening phase by two weeks and skip the announcement until you can. Month two is when the first change ships. Month three is when you find out whether your read was right. Month four is when the team starts treating you as their lead rather than the new lead.
FAQ
Should a new QA lead introduce automation tooling in the first month?
No. Tooling decisions made before you understand the existing test surface, the team's skill set, CI constraints, and the product's risk profile are decisions you will reverse within a quarter. The shopping list belongs in month three at the earliest.
How do I handle a team that wants sweeping changes immediately?
Acknowledge the urgency, name your discipline, and commit to a date. "I hear the flaky-test problem is urgent and I agree — let us meet on the 15th with a concrete plan." Teams accept a date and a reason. What they cannot tolerate is a vague "I am still listening" that stretches into month three.
What if I inherit a QA team much stronger or weaker than expected?
Strong teams need a lead who clears obstacles, defends headcount, and gives air cover when they push back on engineering. Weak teams need a lead who coaches, raises the hiring bar quietly, and lets attrition do part of the work. You will know which by the end of week three — and your shortlist should reflect it.
Should I present a formal 30-60-90 day plan to the company?
A short written plan shared with your manager and your team is useful. A polished slide deck for the whole engineering org rarely is — the lead who presents one in week four is usually the one who has not yet earned the right to make most of its promises.
How do I know if the first 30 days went well?
Three signals. Your QAs bring you problems unprompted. Peer EMs invite you into conversations earlier than they used to. Your notes file has more open questions than confident answers. If all three are true, you are on track.
Where Crosscheck fits
A new QA lead inherits whatever bug-reporting culture the previous lead built — usually the biggest constraint on how fast issues get triaged. Crosscheck is a free Chrome extension that captures screenshots, screen recordings, console logs, and network requests in one click, then sends them into Jira, Linear, ClickUp, Slack, or GitHub. It turns every founder, designer, support agent, and engineer into a competent bug reporter without a process change — the easiest first lift a new lead can make on the bug-report quality bar.
