I Became a QA Engineering Manager — Here's What Nobody Told Me

The Transition Nobody Prepares You For

I'll be honest: when I made the move from senior QA engineer to engineering manager, I thought I was ready. Twenty years of building test frameworks, leading automation initiatives, shipping quality releases at companies like Amazon, Ring, and Tinder — surely that made me qualified to lead a team, right?

Wrong. Partially.

The technical depth absolutely mattered. But the moment I stepped into management, the skills I had to lean on most were ones I'd barely developed: influence without authority, navigating ambiguity at scale, and the discipline to stop writing code when my team needed a strategist more than a contributor.

This post is the honest debrief I wish someone had handed me before I took the leap.

The Hardest Part: Letting Go of Being "The Expert"

As a senior IC, your credibility comes from what you can do. You write the Playwright script that unblocks the team. You spot the flaky test root cause in 20 minutes. You're the one people ping when things break at 2 AM.

Management inverts that model almost completely.

Your value now comes from what your team can do — and your job is to remove obstacles, set context, and build the conditions where they do their best work. The first time I jumped into a technical problem to "help," I realized I was actually signaling that I didn't trust my engineers to solve it themselves.

The fix? I started asking questions instead of giving answers. "What have you tried so far?" "What would need to be true for this approach to work?" It felt inefficient at first. Six months in, my team was solving harder problems faster than I could have alone.

Shifting from Test Cases to Test Strategy

One of the clearest value-adds I bring as a manager is owning the why behind our test strategy — not just the what.

When I was an IC, I was deep in Playwright configs, CI pipeline optimization, and coverage metrics. As a manager, I need to zoom out: What does the business actually need from QA right now? Which quality risks are we systematically underweighting? How does our test investment map to the company's release velocity goals?

At Motorola Solutions, that meant reframing how we talked about quality to product and engineering leadership. Instead of "we have 87% code coverage," the conversation became "here's how our testing strategy reduces hotfix frequency — and here's the 30% reduction in production incidents we drove last quarter."

That reframing — from activity to outcomes — was entirely a management skill. And it required me to speak the language of the business, not just the language of QA.

The AI Disruption Is a Management Problem Too

Here's the thing nobody in the management books is talking about yet: AI is changing the QA engineering role faster than it's changing almost any other discipline. AI-generated test cases, self-healing automation, LLM-assisted exploratory testing — these aren't future-state ideas anymore. They're in production today.

As a QA manager in 2026, I have to think about:

• How do I upskill my team on AI-native testing tools without creating chaos?
• How do I evaluate whether AI-generated tests actually provide meaningful coverage, or just confidence theater?
• How do I make the case to leadership for investment in agentic QA infrastructure before the lack of it becomes a bottleneck?

The engineers who report to me are asking these questions. My job is to have a point of view, build space for experimentation, and protect the team from being handed a mandate to "just automate everything with AI" without the resources to do it thoughtfully.

What Actually Worked: Three Honest Lessons

1. Build relationships before you need them. Cross-functional credibility — with PMs, dev leads, DevOps — is the currency of effective QA management. I started having informal 1:1s with stakeholders long before I had specific asks. When I needed to push back on a release timeline for quality reasons, I had context and trust built up. That made the conversation possible instead of adversarial.

2. Make your team's wins visible. ICs often assume good work speaks for itself. It doesn't — not at the organizational level. I started writing a brief weekly quality summary for our leadership channel: what we shipped, what we caught, what we're improving. The visibility created budget conversations I'd never been invited to before.

3. Protect your engineers from velocity theater. There's always pressure to move faster, ship more, test less. The manager's job is to hold the line on quality when it matters and to articulate why — in business terms — when it's being sacrificed. Not every battle is worth fighting. But the ones that protect your team's ability to do good work? Those are non-negotiable.

The Part I'm Still Figuring Out

I won't pretend I've got this all solved. The hardest ongoing challenge is calibration: knowing when to be hands-on versus hands-off, when to challenge my team versus shield them, when to escalate versus absorb.

Two decades of QA gave me an instinct for software quality. Management requires building a second set of instincts — for people, systems, and organizational dynamics. That's a longer feedback loop. The iteration cycles are measured in quarters, not sprints.

But here's what I know for certain: the QA engineers who are going to lead in 2026 and beyond are the ones building both skill sets simultaneously. The technical foundation matters enormously. And the ability to translate that foundation into organizational impact is what separates great engineers from great engineering leaders.

If you're thinking about making the leap — do it. Just go in with clear eyes about what changes, what stays the same, and what you'll need to build from scratch.

Suneet Malhotra is a Sr. Manager of Test Engineering at Motorola Solutions with 20+ years of experience in QA automation and AI-driven quality engineering. Connect on LinkedIn or follow along at suneetmalhotra.com.