If you’ve ever been told you’re “too technical” for leadership — or watched your real work quietly disappear behind your job title — this one’s for you. It’s about an QA lead who’d been doing the work of a technical program manager for years, long before anyone handed her the title.
Anna had spent 17 years as an SDET. When she was laid off and started thinking about her next move, the title that had defined her career turned out to be hiding most of the work she’d actually done. Her path forward didn’t start with a better resume — it started with seeing that work clearly, maybe for the first time.
I’d been offering short discovery calls to people navigating today’s murky job market — partly to help, and partly to sharpen my own coaching. Anna and I spoke twice over a few months. She’s also been testing my career tool, Uncover, and giving me the unvarnished version of what works and what doesn’t. Here’s how her transition toward a technical program manager role unfolded.
She found a technical program manager career she didn’t know she had
During our first call, I asked her to stop revising her resume and instead write down everything she’d done over 17 years. Not just what appeared in her job descriptions. Everything.
What emerged wasn’t only a QA career. She had managed programs, started teams, and coordinated across geographies. She had presented to senior executives and mentored people. She had done all of it under an SDET title, and most of it never made her resume — because it hadn’t occurred to her that the work counted.
That’s the pattern I keep seeing. Senior engineers do the program management, the cross-functional coordination, and the executive communication. Then they describe themselves by the title on the org chart instead of the work on their calendar.
The inventory is not a resume exercise. It’s a recognition exercise.
Her former manager told her the same thing in her final review: she should consider technical program management, because he’d watched her do it seamlessly for two years. He even put it in writing. When someone says that about your work, ask for the LinkedIn recommendation that week. Praise has a shelf life.
Technical program manager or product manager? Don’t let the title distract you.
Once Anna started considering the move, she hit the fork many people hit: technical product management or technical program management? The advice was contradictory. People at her old company told her program managers mostly sat in meetings and scheduled follow-ups while development managers made the real calls. She was ready to write off the whole field.
I’d effectively been a technical program manager in my last role at Apple, and I’ve coached others at large technology companies and smaller shops. So here’s what I told her.
Stop optimizing for the title. Ask what the last quarter looked like, and what the next one will.
Titles are noisy right now. One company calls a role technical program management; another calls nearly identical work product management, engineering operations, or delivery leadership. The specific team matters far more than the label. So ask concrete questions. What did this person own last quarter? What decisions did they make? Who has authority when priorities conflict? How is success measured? If the hiring manager can answer clearly, you can decide whether the role fits. If they can’t, that tells you something too.
We also talked about ownership. It’s fluid inside most organizations. You may be handed the wheel, only to have someone ask for it back later. The goal is to stay flexible without becoming a doormat.
Her network reflected her experience back to her
I encouraged Anna to spend more time talking to people and less time feeding job boards and applicant tracking systems. Two things happened as a result.
First, I introduced her to someone in my network who lived nearby and who I knew would recognize what she’d been doing beneath the SDET title. They met for lunch. That person read her resume, saw the program leadership in her background, and referred her directly to a software development manager role. A recruiter reached out within days. Separately, a friend of hers introduced her to a lead TPM at a hardware company, who offered an internal referral.
I want to be precise about my part, because introductions get over-credited. I made one connection. What made it work was that Anna had already done the inventory, so she could describe her experience in the language of the role she wanted rather than the title she’d held.
Applications are a numbers game. Referrals are a relationship game.
She took a break
Then Anna did something that probably felt like terrible timing. Mid-search, she went on vacation with her child — her first real break in years. When she came back, she told me: “You get some time in your brain to think through your own stuff while you’re away.”
That was the mechanism. The transition didn’t crystallize while she was grinding through applications. It crystallized when she stopped long enough to hear herself think. If you’re in the middle of a search and haven’t stopped, consider this your permission slip. And if what’s keeping you from stopping is fear — that you’ll fall behind, or fail again — that’s exactly what I wrote about last week in Moving Forward in This Market When the Fear Won’t Go Away.
She built a filter for technical program manager roles
Anna didn’t return with a job offer. She returned with something she’d been missing: a filter. She wants a role where her judgment is part of the decision, not a seat at the table for headcount’s sake. Visible, technical, customer-facing. Once she knew that, we could talk concretely about what she’d need to demonstrate in interviews.
Own the roadmap and the tradeoffs
Can you manage an end-to-end schedule — dependencies, buffers, vendor timelines, costs, executive commitments? You don’t need to do every piece yourself. You need to know what work exists, where the risks are, and who moves the program forward.
Navigate ambiguity and risk
A vendor pulls out. A dependency slips. A launch is two weeks away and something critical fails. Interviewers aren’t looking for a perfect answer. They’re looking for a process: how you diagnose it, what you can phase or mitigate, and who you involve.
Communicate upward with a recommendation
Escalation shouldn’t sound like an alarm. It should sound like this: here’s what’s at stake, here’s my recommendation, here are the tradeoffs, here’s the decision I need from you. Leaders want to know you’ve thought it through before you bring it to them.
Translate across technical and business contexts
You don’t need to write all the code. You need enough depth to narrow a problem for an engineer and then explain the same issue to an executive in business terms.
What a technical program manager needs to know about AI
Anna asked what nearly everyone asks me now: how much do I need to know about agents and large language models to be credible? My answer is that you should be literate, not fluent. Hiring managers aren’t expecting you to explain transformer architecture. They want to see that you know where the technology is useful, roughly where your company sits on the adoption curve, and how it connects to work you’ve already done.
Anna already had a strong example. As a QA engineer, she’d built staging environments with automated jobs that pulled code, ran tests, and pushed results to a dashboard. That isn’t an AI agent, but the systems thinking transfers. You define a goal, orchestrate steps, pass information between systems, evaluate results, and decide where a human stays in the loop.
So her interview answer isn’t “here’s everything I know about LLMs.” It’s “here’s the pipeline I built, here’s what I’d hand to an agent today, and here’s how I’d evaluate the output and design the handoff.” That lands because it’s honest and specific.
What I learned
At the end of our second call, she turned the questions back on me — what was working in the tools I’m building, what she’d want next, when she’d actually reach for them. That feedback shaped the latest version of Uncover. Which is how this should go: if you’re always the one dispensing advice, you’ve stopped learning. In a market this murky, none of us can afford that.
Do this one thing this week
Take one hour. Write down everything you’ve done in your current or most recent role that wasn’t part of your formal job description. Not for your resume. Just to see it. Look for the work you did repeatedly, the problems people brought to you, and the responsibilities you quietly absorbed. You may find your next role hidden inside the work you’re already doing.
That process — naming the invisible work and turning it into language someone else can recognize — is exactly what I built Uncover to help you do. In about 15 minutes you’ll leave with a clearer throughline, evidence-backed expertise statements, and language you can use in a resume, interview, or promotion case. New this round: you can save your profile and return later to edit, regenerate, or refine it.
If you want the research on how titles have drifted from actual responsibilities, the Bureau of Labor Statistics occupational data is a useful outside reference.
