My manager was a TPM before becoming an SDM, what are they good for?

The real question, originally posted by Blind user AmzKng, was actually: How do you get them fired? But that title felt a bit too provocative, even for me. Instead, we’re going to dive into one of Blind’s most heated debates: Why do TPMs transition into SDM roles? Do we even need TPMs? And what do Blind dudes really think about them?

If you haven’t already, check out my previous post, where I explored an even bolder question: Can we just get rid of managers altogether?

What’s your manager’s first reaction when you tell them you’re stuck—struggling with a bug or trying to figure out how a certain flow works? Do they immediately ask for an ECD (Estimated Completion Date) and alternatives? Or are they just curious about the symptoms and eager to know what have you tried so far to solve the issue? Do they focus on whether the task status has turned "red" from ¨yellow¨ or do they get excited about jumping into a debugging session? Their reaction might give away their dark past.

It turns out that no one is born an SDM (or an EM, or whatever your company calls people who manage software engineers). And there’s no BSc in "Software Development Management" that magically ramps someone up for the role. Instead, people become SDMs after years of experience in the tech industry. But what kind of experience is it, exactly?

According to data from LinkedIn, there are approximately 54,000 SDMs in the U.S. While most of them, 67%, come from a software engineering background, a significant number didn’t take the traditional SDE route. Instead, they started as business analysts, QAs, web designers, lab engineers or hardware developers.And then there’s the small but intriguing minority—about 1%—who made the jump from Technical Program Manager to SDM without ever working as an SDE.

Since I was already deep into LinkedIn queries, I decided to take a closer look at Amazon’s tech workforce. It turns out that Amazon SDMs are even more likely to come from an SDE background—80% (7,300 out of 9,200 SDMs worldwide) started as software engineers. The percentage of TPMs making the jump to SDM without ever being SDEs is slightly higher than the industry average at 1.7% (163 individuals holding SDM positions at Amazon Feb 25).

For curiosity’s sake, I also checked Product Managers (PMs) turned SDMs, and they make up a similar 1.8%. But here’s the interesting part: while Blind is flooded with engineers complaining about their former TPMs becoming SDMs, no one seems to care as much about PMs or other tech roles making the same transition.

So why don’t SDEs like TPM-turned-SDMs?

Most Blind users argue that these managers lack technical depth—they don’t understand the team’s products, don’t know how to code, and fail to grasp the real challenges their engineers face. This tech gap often leads to "paralysis by analysis"—a reluctance to make technical decisions that could unblock their teams and help them step towards success.

Many engineers on Blind describe TPM-turned-SDMs as passive intermediaries: Managers who merely relay requirements from "above", pass estimates back up, and avoid taking a stand. Instead of adding value, showing backbone, or challenging stakeholders when necessary, they become a human pass-thru function, moving information back and forth.

nashedi thinks TPMs turned SDMs avoid making decisions and just pipe messages from team to management.

eXxk75 calls out lack of trust in TPM SDMs and wonders if they can add any value apart from just asking for delivery dates.

At last, some ❤️ from 123asjgv, but perhaps not for the right reasons…

Interestingly, some Blind users dislike TPM-turned-SDMs not just for their lack of technical depth, but because they find them lacking in empathy—even calling them "toxic." The complaint? These managers care only about the "mission" and see people as resources deployed to execute tasks, rather than as individuals with needs, challenges, and growth aspirations.

But here’s what I find ironic: Shouldn’t TPMs be better at working with people than engineers? After all, TPMs spend most of their time coordinating across teams, managing stakeholders, and handling interpersonal dynamics. Meanwhile, SDEs primarily interact with their shell terminals, keyboards, and mice. On a good day, their peak collaboration might be making a curl request to a sister team’s service.

cRio41 is upset for lack of empathy and suggests SDEs whose manager was a TPM to consider making jumping ship.

So why do TPMs even become SDMs?

Honestly, I still don’t understand why people become TPMs in the first place. I’ve tried asking them, but every time, the answer leaves me even more confused. It usually involves some kind of conviction of a purpose to "look around corners" to find problems that don’t officially belong to any team, writing outstanding executive summaries, and—of course—asking engineers for ECDs. But, do we need to hire dedicated people to look behind corners and communicate dates and plans? I believe that excellent SDEs and SDMs should already be doing all of that.

Toxic Blind folks say that TPMs transition to SDMs simply for the money. According to Levels.fyi, an L6 TPM at Amazon in the U.S. makes $282K per year on average, while an L6 SDM pulls in $457K—a 62% raise. That’s a serious jump. The gap remains significant at L7, where TPMs earn $453K, but SDMs make $690K—a 53% increase.

And here’s the kicker: making the transition doesn’t require demonstrating consistent technical skills - just getting a "transition doc" approved by their manager. That’s one very lucrative career move.

I’m sure money isn’t the only reason—though let’s be honest, it’s definitely a factor. But for many, the move might be about having real influence over execution and actually delivering value for customers, which sounds far more engaging than the mundane, paperwork-heavy world of TPMs. Some of them—God forbid—might even enjoy helping their team succeed, rather than just chasing them to provide timelines and adhere to them.

I think that large tech organizations, where multiple teams build deeply interconnected products, should absolutely staff TPMs for high-risk high-impact programs. But in my experience, truly great TPMs—those who proactively mitigate risks, unblock teams, and free up engineers from coordination overhead—are rare. They exist, but they’re not common.

And here’s my theory why: the best TPMs don’t stay TPMs for long. Once they prove their ability to drive impact, they move on to more engaging roles—ones with more ownership, influence, and direct execution impact.

I remain, however, open to being proven wrong, while giving every TPM a fair shot. This is just my take, but I’d love to hear yours—leave a comment and let me know what you think.