What Most TAMs Get Wrong About Customer Success
For years as a PSE at Twilio, I worked alongside TAMs — covering their enterprise accounts across APAC and EMEA, jumping into escalations, sitting in their QBRs. I watched the role from arm's length before I was in it myself. Six months into being a TAM, these are the patterns I was determined not to repeat.
I became a TAM about six months ago. But I’d been working alongside the role for years before that.
As a Personalized Support Engineer at Twilio, a big part of my job was supporting TAM-owned accounts — covering when TAMs were unavailable, handling technical escalations on their behalf, joining customer calls across both APAC and EMEA. I had a front-row seat to how different TAMs operated. Some were exceptional. Others were technically brilliant but repeatedly made the same avoidable mistakes with their customers.
When I finally stepped into my own TAM role, I had a clear list of things I didn’t want to do. This article is that list — written honestly, from someone still early in the role, not from someone who has it all figured out.
Mistake #1: Measuring input instead of outcome
The default metric for a new TAM is tickets. How many were opened. How many were closed. How fast. It’s a clean number, it’s easy to report, and it tells you almost nothing about whether you’re actually helping your customer’s business.
I fell into this trap myself as a PSE. I spent months feeling good because I was resolving issues quickly. Customers were satisfied. Surveys looked fine. And then in one of my quarterly reviews, a customer’s CTO said something that stuck: “You’re great at fixing things. But I always feel like I’m coming to you after something’s already broken.”
He wasn’t being unkind. He was being precise. And watching TAMs from the PSE side, I saw the same pattern play out repeatedly — technically excellent people who were always reacting, never anticipating. The best TAMs I observed operated differently. They were in the customer’s planning conversations before the fire existed.
The best TAMs get invited to planning meetings. The rest get invited to incident calls.
The shift requires changing how you think about your calendar. Reactive work fills itself — you don’t have to schedule it. Proactive work requires you to carve out time for conversations that don’t have a ticket number attached. Most TAMs under-invest here not because they don’t know it matters, but because the urgent always crowds out the important.
Mistake #2: Confusing technical depth with strategic value
This one is more painful because it’s a trap that good engineers fall into. You come from a technical background, you’ve worked hard to build genuine expertise, and so naturally you lean on that expertise. You become the person who can explain every edge case in the API docs. Every customer escalation, you’re there with the detailed answer.
The problem is that technical knowledge isn’t what your stakeholders are ultimately buying. The VP of Engineering cares about uptime and velocity. The CFO cares about ROI on the platform spend. The CTO cares about whether the platform choice they championed internally is paying off.
None of these conversations are primarily technical. They’re business conversations that require technical fluency as a foundation — not as the centrepiece.
A useful exercise: Write down the top three outcomes your largest customer is trying to achieve this year. Not their technical goals — their business goals. Revenue targets, customer experience metrics, operational cost reduction. If you can’t write that list from memory, you’re probably operating one level too deep in the technical weeds.
I’m not saying technical depth doesn’t matter. It absolutely does — it’s the thing that earns you the right to be in those business conversations in the first place. Customers can smell a technically hollow TAM from a mile away. But depth is the entry ticket, not the destination.
Mistake #3: The “trusted advisor” label without the honesty to back it up
“Trusted advisor” is probably the most overused phrase in the TAM playbook. And most of the time it means: we have a good relationship, the customer likes me, they renew.
That’s fine. But it’s not the same thing as trust.
Real trust — the kind where a customer calls you before they’ve made a decision rather than after — requires one thing that’s genuinely uncomfortable: you have to be willing to tell a customer when they’re wrong. Or when your platform isn’t the right tool for what they’re trying to do. Or when the implementation plan they’ve proposed is going to create problems six months down the line.
I’ve sat in meetings where a customer described a technical architecture that I knew was going to cause them pain. The easy move is to nod and say “let’s work through it together.” The harder and more valuable move is to say “I think there’s a better approach here — can I show you what I’ve seen work in similar situations?”
Customers remember the TAMs who told them a hard truth that saved them. They forget the ones who smiled and said yes.
Mistake #4: Not understanding who you’re really talking to
In enterprise accounts, there are usually at least three distinct audiences: the technical team who uses the product daily, the operational managers who care about reliability and cost, and the executive sponsor who made the procurement decision and needs to defend it internally.
Most TAMs get comfortable with one of these groups — usually the technical team, because that’s the most natural fit for someone with an engineering background — and neglect the others. This is a significant mistake, not because it makes the relationship feel incomplete, but because the renewal and expansion decisions almost never happen at the technical level.
If the only people who know your name are the developers in the trenches, you’re not protected when the contract comes up. And you’re also not positioned to help when the customer’s business goals shift and they need to think about expanding what they’re doing with the platform.
Building multi-threaded relationships is uncomfortable because it requires different styles of conversation. You have to be able to talk architecture with the engineer and commercial impact with the CFO, and neither conversation should feel like a translation exercise.
What the best TAMs actually do
The TAMs I most admired during my PSE years shared a few things I don’t see written about enough — and that I’m actively trying to build into my own habits now.
They asked about the customer’s business calendar before their technical roadmap. They knew when the customer’s big product launches were, when their fiscal year ended, when the board presentations happened — because all of those moments represented either risk or opportunity for the relationship.
They kept their ego out of it. If a customer problem was better solved by escalating to someone more expert, they escalated quickly and without performance anxiety. Their goal wasn’t to be the smartest person in every conversation. Their goal was for the customer to succeed.
And they wrote things down. Notes from every meaningful conversation, decisions made, concerns raised, context about what was happening in the customer’s organisation. Six months into a relationship, that documentation is the difference between an advisor with continuity and institutional memory, and one who asks the same questions at every call.
I’m six months into my own TAM role. I don’t have everything figured out — but watching this job from the PSE side for years gave me a clearer-than-usual picture of what good looks like. The mistakes in this article aren’t hypothetical. I saw them cost real relationships. I’m just trying not to repeat them.