The TPM Identity Crisis

Ask ten companies what a Technical Program Manager does and you'll get eleven answers. At one company the TPM is a glorified project manager with a Gantt chart. At another they're basically a product manager who can't say no to engineering. At a third they're the person who runs the incident bridge, the release train, the dependency spreadsheet, and the quarterly planning circus — all before lunch.

I've watched this role get redefined roughly every eighteen months for the better part of a decade, and I've started to think the identity crisis isn't a phase. It's the job.

Here's the pattern. A company centralizes its TPMs into one org, because leadership wants "program discipline." Eighteen months later, product teams complain the centralized TPMs don't understand their domain, so the TPMs get embedded into the teams. Eighteen months after that, nobody can see across teams anymore, dependencies start slipping, and leadership centralizes them again. The pendulum swings, the job descriptions get rewritten, and the actual work barely changes. I've seen TPMs survive three reorgs doing exactly the same thing under three different titles.

Part of the problem is the name. "Technical Program Manager" sounds like it should mean something specific, but it's doing a lot of quiet work in that title. Technical how? I've known TPMs who were former engineers and could read a design doc critically, and TPMs whose technical depth topped out at "I can spell API." Both were called TPMs. Both were, at different companies, considered good at the job. The title promises a combination — technical credibility plus program leadership — that the hiring process rarely verifies on both halves.

Then there's the permanent confusion with product managers. The boundary between "what should we build" and "how do we get it built across six teams" sounds clean on a slide. In practice, it's a knife fight. Weak organizations let the boundary blur until the TPM is writing PRDs and the PM is running standups and everyone is mildly annoyed at everyone. Strong organizations draw the line clearly and defend it. Most organizations are neither, which is why the TPM-PM relationship is the most renegotiated border in tech.

So what do the good ones actually do? Stripped of the title inflation, it's unglamorous and specific: they make cross-team dependencies visible before they become surprises. They force decisions out of people who would rather defer them. They run the machinery — planning, releases, incident coordination, compliance gates — so engineers don't have to. They translate between teams that use the same words to mean different things. And they tell leadership the truth about schedule risk early, when it's still cheap to act on, instead of late, when it's a status update.

None of that fits neatly on a job ladder, which is why the role keeps getting redefined. Companies keep trying to hire one person who is simultaneously a project manager, a product strategist, and a credible engineer, then act surprised when the job description reads like three jobs stapled together. The TPMs who last aren't the ones who fit the description. They're the ones who figure out what their organization actually needs — usually clarity and follow-through — and supply it relentlessly while everyone else argues about the title.

The identity crisis will continue. It always does. The good news is that it's mostly a crisis for org charts. The work itself has never been mysterious. Someone has to keep the trains running on time across teams that would rather not coordinate. Call it whatever you want. The trains still need running.

Eleven Months After CrowdStrike: What Actually Changed

Last July, a bad content update from CrowdStrike blue-screened 8.5 million Windows machines in a single morning. Airlines grounded flights. Hospitals went to paper charts. Banks couldn't bank. It was, by most measures, the largest IT outage in history — and it wasn't even an attack. Nobody breached anything. A trusted vendor pushed a trusted update and the world fell over.

Eleven months later, I keep asking people in this industry what actually changed. The honest answer is: less than the think pieces promised.

The loudest legacy was the kernel debate, and to be fair, that one produced real movement. CrowdStrike's sensor ran in kernel mode, which is why a bad update could take down the whole machine instead of just crashing an application. Microsoft convened the endpoint security vendors that September and started the long, unglamorous project of moving them out of the kernel. That's genuine architectural progress — the kind of boring infrastructure work that actually prevents the next one. Credit where it's due.

But here's the part nobody likes to say out loud: almost nobody diversified their vendors.

In the weeks after the outage, every board deck had a slide about concentration risk and single points of failure. And then, one by one, companies looked at what it would actually cost to rip out their EDR platform and replace it — the retendering, the detection-rule retuning, the months of dual-running, the retraining — and decided to renew instead. I don't entirely blame them. Switching endpoint security vendors is one of the most disruptive projects an IT organization can take on, and doing it in a panic is how you end up less secure than when you started. But let's not pretend the lesson was learned. The lesson was admired from a distance.

What did genuinely change is that resilience testing got a budget line. Chaos engineering stopped being a curiosity associated with one streaming company and started showing up in enterprise roadmaps. "What happens when our security tooling itself fails?" is now a question that gets asked in architecture reviews — a sentence that would have earned blank stares in 2023. Update rollout practices got scrutiny too: the industry had a real conversation about staged rollouts and canary deployments for security content. The vendors pushed back, reasonably enough, that threats don't wait for canaries — but there's middle ground between "everyone gets it at once" and "wait a week," and most of the industry now lives somewhere in that middle.

The lawsuits are still grinding along in the background. Delta's case against CrowdStrike and Microsoft is the one to watch — not because of who wins, but because it will establish, in legal language, where responsibility sits when a vendor's routine update breaks your business. Every enterprise contract caps the vendor's liability at some multiple of fees paid. The courts may eventually have opinions about whether those caps hold when the failure mode is this total. That ruling, whenever it lands, will be quoted in every vendor negotiation for a decade.

My take, eleven months on: the industry treated CrowdStrike as a vendor failure when it was really an architecture failure. Any single piece of software with that much privileged access, pushed to that many machines on that aggressive a schedule, can do exactly this. The next one won't be CrowdStrike. It'll be someone else's updater, and we'll all act surprised again.

The fix was never "pick a better vendor." It's "design like your vendors will fail you." Most of us still haven't.