The honest version
A lot of pre-sales content treats the job like it's mostly fun. Interesting problems, smart users, a great team, the thrill of closing a complex deal. All of that is real. I've put in seven years and I'd do it again. It's also true that by Thursday afternoon you sometimes find yourself staring at a wall, unsure which deal you're currently on, mildly concerned that your brain has stopped indexing the names of payment processors.
But if you only hear that version, you'll hit the hard parts and assume something is wrong with you. Something isn't wrong with you. The job is genuinely difficult, in specific ways that are worth naming, and most of the difficulty is structural rather than personal. Knowing where it comes from is the first step to handling it well.
Four things make this job hard. Three of them are properties of the work itself. The fourth is the way the work interacts with the rest of the company.
The product is always moving
If you're an SA at a company that's actually shipping product, the surface area you're responsible for changes every quarter. New features ship. Old features get deprecated. Pricing models shift. The roadmap you presented to a user in March is not the roadmap you'd present to them in September. The integration pattern you recommended last year is no longer the recommended one.
This is good for the company. It's hard for the SA, because the job requires you to be confidently expert about a thing that's moving under you in real time.
There are a few coping moves that help. The first is getting comfortable with a moving baseline. You will never know everything about your product. You will know less, in absolute terms, than you knew six months ago, because the product has grown faster than your knowledge has. This is a normal feeling. It's also a permanent one. Make peace with it now. The goal isn't completeness; it's coverage of the parts that actually come up in deals, plus enough awareness of the rest to know who to ask.
The second is treating product knowledge as a maintenance task, not a one-time investment. Block time on your calendar — weekly, ideally — for staying current. Read the changelog. Skim the new docs. Try the new feature. If you don't put it on the calendar it won't happen, because the deals will fill every available hour and there will always be a meeting that feels more urgent.
The third is letting go of the need to know things you don't yet need to know. Some SAs try to read everything, including the parts of the product they've never used in a deal. This is a low-yield activity. The product knowledge that compounds is the knowledge tied to a real user problem you've actually worked through. The rest is trivia, and you can always pick it up the first time it shows up in front of a user.
The context-switching is brutal
In any given week, an effective SA is working across multiple deals at different stages, plus internal projects, plus the occasional team or organizational thing. Each of those deals has its own user, its own architecture, its own history, its own open questions, its own pace.
You finish a call with a payments user thinking through a marketplace flow, and ten minutes later you're on a call with a SaaS user thinking through subscription billing, and an hour after that you're on a call with a developer-tools user thinking about authentication. The technical context is different each time. The user's nomenclature is different. The deal stage is different. The open questions you're carrying are different.
The cognitive load of this is real and it's hard to convey to people who haven't done it. Engineers context-switch between branches. SAs context-switch between worlds. The difference is roughly the difference between juggling balls and juggling flaming chainsaws. By Thursday you can feel it. By Friday afternoon, if you've been undisciplined, you can be on a call referring confidently to someone else's architecture, which is a memorable way to lose a deal.
The defense against this is structural, not heroic.
Notes are non-negotiable. Not because anyone else is going to read them, but because future-you needs them to come back into the deal. Fifteen minutes before a call, you should be able to read your own notes from the last call and reload the entire context — what was discussed, what's open, what the user is worried about, what you committed to follow up on. If you can't do that from your notes, the notes aren't good enough. Fix the notes, not your memory.
Pre-call prep is the highest-leverage time you have. Ten minutes of prep is worth an hour of recovery during the call. Read the notes, scan recent emails, check the deal channel for anything new, look at the user's site if anything's changed. Walk into the call already in their world.
Protect the seams between calls. Back-to-back calls without a buffer is the failure mode. You finish one call still mentally inside it, and you start the next call before you've fully left. A fifteen-minute buffer between calls — used to write notes from the call you just finished and prep for the next — is worth more than the meeting it might displace.
The context-switching gets easier with experience, but it never goes away. Senior SAs aren't switching less; they're switching with more discipline.
The role is a performance
This is the one most new SAs underestimate.
A lot of the job happens on calls and in meetings, in front of users, where you are the visible representative of your company on a question that matters to them. That's a performance, in the sense that an actor's role is a performance. You're not pretending — what you're saying is true, what you know is real — but the delivery is part of the job. The pacing, the calm, the comfort in your own answers, the recovery when something goes sideways. All of it is performed in real time, in front of an audience, with consequences attached.
Some people take to this naturally. Many don't, including some of the best SAs I've worked with. The good news is that performance is a skill, not a personality trait. It can be trained.
A few things that help.
Practice your introduction. The first thirty seconds of a call set the tone. If you're fumbling with who you are and why you're there, the call starts on uncertain ground. If you have a clean, calm, twenty-second introduction that you've said out loud enough times that it sounds natural, you've already done half the work of the meeting.
Pace is a tool. When the meeting is moving too fast — questions stacking up, the user getting ahead of you, your own brain starting to chase — the move is to slow down deliberately. Pick up a pen. Take a note. Pause. The room will follow your pace if you set it. New SAs almost always rush; senior SAs almost always slow down.
Recovery matters more than perfection. You will have bad calls. You will say something wrong. You will draw a blank on a question you should know the answer to. The performance isn't ruined by the mistake; it's ruined by the panic afterward. The move is always the same: name the thing, take it offline, move on. "I want to make sure I give you the right answer on that — let me follow up after the call." That sentence costs nothing and recovers everything.
Rate your own calls. After a call, give it a number from one to ten and write down what you'd do differently. This sounds obvious and almost no one actually does it. The ones who do are the ones who get better fastest. Honest reflection is the cheapest training resource you have, and it compounds.
The performance frame can feel uncomfortable at first, especially for SAs who came into the role from engineering. There's a temptation to think the work is the technical content and the delivery is somehow superficial. It isn't. A correct answer delivered badly costs you the deal. A confident answer delivered well, even if it's a little less precise than it could be, often closes it. This isn't unique to sales — it's true of teaching, of management, of any job where part of the work is being understood by other people.
The ambiguity of the role inside the company
This is the structural one, and it's the hardest to navigate because it's mostly outside your control.
The SA role sits between sales, product, engineering, and customer success. Every one of those functions has its own incentives, its own metrics, and its own opinions about what the SA should be doing. When the four functions agree on what the SA's job is, the work is great. When they disagree — which is more often than you'd think — the SA is the one absorbing the friction.
You'll see this when an AE wants you to commit to something on a call that you don't think is true. When product wants you to push a feature the user doesn't actually need. When engineering wants you to filter out user requests that they consider noise. When CS wants you to stay involved in an account three months after the deal closed. None of those people are wrong from where they sit; they're optimizing for their own scoreboard. You're the one whose scoreboard isn't fully defined.
The defense against this is internal clarity about what your job actually is. The version of the role I described in Chapter 1 — translator, navigator, expert, trusted advisor, all in service of the user — is something you can hold onto when the pull from adjacent functions gets strong. When someone asks you to do something that's outside that scope, you don't have to refuse aggressively, but you do have to know it's outside the scope, and you have to be willing to push back when it matters.
The "users first" frame from the introduction is the version of this that holds up under pressure. Is this good for the user? Is it good for us? If both, do it. If not, raise the flag. The flag isn't always heeded, but raising it is part of the job.
Why the difficulty is the point
The reason this job is hard is also the reason it's worth doing.
Easy jobs aren't leveraged. If the role were simple — show up to calls, click through demos, answer questions — it wouldn't be worth what good SAs get paid, and it wouldn't matter who did it. The fact that it requires real product depth, real cognitive endurance, real performance skill, and real judgment is why the role exists at all. It's also why a great SA is worth significantly more than an average one.
The difficulty is also where the satisfaction lives. Closing a deal you genuinely earned — where you saw the technical fork early, made the right call, helped the user think through something hard, and ended up with a customer who's better off for the work — is one of the most satisfying things in software outside of shipping a great product yourself. You don't get that satisfaction from easy work. You get it from work that demanded something of you.
If you're new to the role and finding it hard, that's not a sign you're in the wrong job. It's a sign you're in the right one and you haven't yet built the muscles. The muscles come from doing the work, reflecting on it, and putting yourself into the calls where the difficulty is highest. There's no shortcut, but there's a method, and most of this book is about the method.
A note for builders
The hardest thing to do, when you're standing up an SA function, is to resist the temptation to make the role easier than it should be. The pressure to do this is constant. The AEs will want their SAs more available. The CS team will want them more involved post-sale. Finance will want a higher deal-to-SA ratio. The SAs themselves, if you don't watch for it, will quietly accept all of these because they're trying to be helpful.
What you'll get, if you give in to all of it, is a function that's busy without being effective. The SAs are on every call, doing every handoff, supporting every renewal — and they're not actually doing the deep technical work that justifies the role. The deals they support close anyway, because deals close for lots of reasons, but you've built an expensive function whose contribution is hard to identify.
The way to prevent this is to scope the role narrowly and protect the scope deliberately. SA time is a scarce resource. Treat it like one. The hard parts of the job — the deep technical engagement, the trusted-advisor relationship, the navigator role on complex deals — only happen when there's room for them. If your SAs are over-allocated, those parts of the job get squeezed out first, because they're the ones that don't have a meeting on the calendar demanding them.
The job is supposed to be hard. Build the function so the difficulty lives in the right places.