QA Manager 90-Day Plan: How to Hit the Ground Running

The first 90 days as a QA manager determine whether you're seen as someone who understands the business or someone who's going to be a process bureaucrat. The difference comes down to how you sequence your learning, your relationships, and your early decisions.

This is a practical framework for your first 30, 60, and 90 days — what to do, what not to do, and how to build the credibility that earns you the influence you need to actually improve quality.

Before Day 1: Pre-Work

If you have any time before your start date, use it to read:

• The last 3 months of sprint retrospectives (if accessible)
• Post-incident reviews for any production incidents in the last 6 months
• Any existing test strategy documentation

You won't understand everything, but you'll arrive with context that most new QA managers spend their first two weeks trying to obtain. You'll also know which questions to ask on day one.

Days 1–30: Learn Before You Change Anything

The primary goal of the first 30 days is to understand the current state before forming opinions about what to fix. This is harder than it sounds. New managers who arrive with strong opinions often ship changes that technically improve metrics while breaking relationships or removing things that worked for reasons not documented anywhere.

What to Do in the First 30 Days

Map every stakeholder who has opinions about quality.

This means engineering managers, product managers, developers, customer success, and any existing QA engineers. Schedule 30-minute 1:1s with all of them. Use a consistent set of questions:

• What's working well in how QA operates today?
• What's the single thing you'd change about the QA process if you could?
• Where do you feel most anxious about product quality right now?
• What does a "good" QA function look like to you?

You'll get contradictory answers. That's useful data — it tells you where expectations are misaligned.

Audit the existing test suite with fresh eyes.

Don't rely on the previous QA lead's summary. Run the tests yourself. Look at:

• What percentage are passing, failing, flaky?
• How long does the full suite take?
• Are there obvious coverage gaps in critical paths?
• Are there duplicate tests that run the same thing multiple ways?
• When was the last time tests were actively maintained?

For each area, document what you see, not what you conclude. Conclusions come later.

Understand the release process end-to-end.

Shadow a release cycle. Watch what actually happens vs. what the process document says. Where do people take shortcuts? Where is QA sign-off genuinely blocking? Where is QA sign-off a rubber stamp that everyone ignores?

Identify the QA team's current workload and morale.

If you're managing existing QA engineers, understand what they're spending their time on and how they feel about the work. Engineers who've been ignored or underresourced for a year will have frustrations and context you need to know about. Ask individually. Don't hold a group meeting and expect honesty.

What Not to Do in the First 30 Days

• Don't announce changes to process
• Don't restructure reporting or reassign responsibilities
• Don't criticize the previous QA lead's decisions in meetings
• Don't make promises about what you're going to fix
• Don't accept the existing metrics as accurate without verifying them

The most credible thing you can say in week 1 is "I'm still learning." It's also true.

Days 31–60: Define the Picture and Pick Your Quick Wins

By the end of week four, you should have enough data to form hypotheses. Month two is about testing those hypotheses, communicating a clear picture of current state to leadership, and executing one or two quick wins that demonstrate your competence.

Write the Current State Document

Produce a document (or slide deck) that summarizes:

1. Current quality metrics (defect escape rate, test coverage, MTTR if available)
2. What's working well (name specific things — this earns credibility with the existing team)
3. The top 3–5 risks you see
4. The key dependencies (what QA can control vs. what requires engineering investment)

Share this with your manager and the engineering managers who matter. You're not proposing solutions yet — you're demonstrating that you understand the situation. This document is also your baseline. Every quarterly update will compare against it.

Identify and Execute Quick Wins

Quick wins matter. Not because they have the highest ROI, but because they build trust. Pick things that:

• Can be completed in 1–2 weeks
• Are visibly useful to engineers or PMs
• Demonstrate you understand what the team actually cares about

Examples of real quick wins:

• Fix the three flakiest tests in CI (ask any developer — they'll know exactly which tests they're tired of re-running)
• Add a missing test for a high-visibility path that everyone knows isn't covered
• Fix a bug in the release checklist that everyone ignores because it's wrong
• Set up a simple dashboard that gives the team real-time test pass/fail status they didn't have before

The quick win shouldn't be a flashy process overhaul. It should be something a developer thanks you for.

Set Up Your Stakeholder Rhythm

By the end of month two, establish a regular cadence:

• Weekly 1:1 with your manager — status, blockers, anything they need to know
• Weekly or bi-weekly 1:1 with each QA engineer — workload, morale, technical issues
• Bi-weekly sync with the EM group — QA coverage for upcoming releases, blockers
• Monthly report to engineering leadership — QA metrics, trend vs. baseline

These rhythms are how QA managers stay informed and stay influential. Ad-hoc communication only works when you're small; at any scale, scheduled touchpoints keep you from being surprised.

Days 61–90: Build the Strategy and Get Buy-In

Month three is when you move from understanding and quick wins to proposing a strategy. By now you have credibility from the current state document and the quick wins. You have relationships with the stakeholders. You understand the technical landscape. Use all of that to propose where QA should be in 6–12 months.

Define the 6-Month Quality Strategy

Your strategy document should answer:

Where are we today? (Pull from your current state document — update it with month-two data)

Where do we need to be? (What does good look like? What's the quality bar that enables the business to ship confidently at the pace the engineering team wants to ship?)

What are the top three investments to get there? Be specific. "Improve automation coverage" is not a strategy. "Build automated regression coverage for checkout and account management flows, targeting < 30 minute CI run time, owned by the automation engineer, delivered by Q3" is a strategy.

What does it cost? Time, headcount, tooling. Be honest. If you need tooling budget — for example, cloud-hosted test infrastructure to run tests in parallel without managing your own CI runners — make the case. Tools like HelpMeTest ($100/month, unlimited tests, parallel execution, no infrastructure to manage) are often cheaper than the engineering time to manage self-hosted alternatives. Put the numbers in front of your manager and let them decide.

What does success look like? Specific metrics with targets and timelines.

Get Buy-In Before Finalizing

Don't finalize the strategy in a vacuum. Share a draft with your manager, key engineering managers, and at least one developer lead. Incorporate their feedback. The goal is to ship a strategy that has broad buy-in, not one that's technically perfect but that no one else feels ownership over.

A strategy that three teams helped shape will get executed. A strategy that one QA manager wrote alone will get quietly sidelined when priorities shift.

Deliver the 90-Day Report

At the end of day 90, write a brief summary of:

• What you learned in the first 30 days
• What you did in days 31–90
• The strategy you're proposing for the next 6 months

This doesn't need to be a long document. A one-page summary or a 5-slide deck is fine. The audience is your manager and engineering leadership.

What matters is showing the arc: "I arrived, I learned, I saw these problems, I acted on these quick wins, and here's where I think we should go." That arc is what demonstrates leadership, not just execution.

Common Mistakes in the First 90 Days

Moving too fast in month one. Changes that arrive before trust is established get resistance. Even correct changes. Wait until month two to propose anything significant.

Fixing metrics instead of fixing quality. It's possible to improve defect escape rate by tightening the definition of what counts as a production defect. Don't do this. Your metrics need to reflect reality, or they lose their value as decision-making tools.

Making QA the bottleneck. If the first things you do make QA a mandatory signoff on more things, you'll create resentment fast. Early on, make QA faster and easier for developers to work with, not a heavier process requirement.

Underestimating the existing team. QA engineers who were there before you have context that took years to develop. Treat them as sources of information, not as people who need to be corrected. You'll often find that "problems" you identified had attempted fixes, and understanding why those fixes didn't work saves you from repeating the same mistakes.

Neglecting developer relationships. QA managers who only talk to QA engineers end up isolated. The engineering team is your primary customer. Their willingness to fix bugs quickly, write testable code, and include QA early in planning determines your team's effectiveness more than anything else.

A Note on Tools and Infrastructure

During your first 90 days, you'll form views on where the tooling is and isn't serving the team. Don't make tooling decisions in month one — you don't have enough context. But do document what you observe.

Common tooling gaps in QA teams: no monitoring between releases, no parallel test execution (suites run in serial for no good reason), and test results that are hard to interpret (no clear owner, no triage process for failures). These are worth solving in months two and three if the data supports it.

The 90-day plan works because it's sequenced correctly: learn before concluding, demonstrate competence before proposing changes, and build relationships before trying to change culture. QA managers who arrive and immediately start reorganizing are common. QA managers who spend a month listening and then propose a strategy that the team recognizes as accurate are rare — and far more effective.