Beyond the job description
Most SA job descriptions read like the same paragraph rewritten by different recruiters. "Experienced engineer with a strong background developing full stack applications, communicating technical concepts, and leveraging technology to drive business value." That sentence isn't wrong, but it isn't useful either. You could paste it into a posting for half a dozen different roles and it would fit each of them about equally badly. I suspect there's a single SA job description that escaped from somewhere in 2014 and has been quietly reproducing itself across LinkedIn ever since.
The job description is a recruiting artifact. It's written to attract the right candidates and pass legal review, not to describe the work. If you take it as a definition of the role, you'll spend your first six months confused about why so much of your time is going toward things the description didn't mention.
The actual work is more specific, and stranger.
A Solutions Architect sits at the seam between three different conversations that a deal has to navigate to close. The first is the commercial conversation — what the user is buying, what it costs, what the contract looks like, when it starts. That belongs to the Account Executive. The second is the technical conversation — what the user is actually trying to build, whether your product can do it, how it fits into their existing stack, what the integration looks like. The third is the trust conversation — whether the user believes you can actually deliver on what you're saying, whether your company will be there in two years, whether the people they're talking to know what they're doing.
The SA owns the second conversation outright, co-owns the third, and shows up in service of the first. Most of the confusion about the role — internally and externally — comes from people who think it's only the second one.
The four jobs inside the job
If you watch what an effective SA actually spends their time on across a quarter, the work clusters into four distinct jobs. They share some skills but they're genuinely different activities, and being good at the role means being at least competent at all four. Frameworks with exactly four parts are usually a sign that the writer found three things and reached for a fourth. This isn't one of those.
The translator. Most of what an SA does on a call is translation. The user describes a problem in their own language — their products, their architecture, their organizational constraints — and the SA's job is to translate that into the language of your platform. Then your platform's capabilities have to be translated back into terms that map onto the user's world. This sounds mechanical when you describe it, but it's where most of the craft lives. A good translation makes the user feel understood. A bad translation makes them feel like they're talking to a vendor.
The navigator. Deals don't move in straight lines. There are forks, dead ends, surprises, and moments where the right move is to slow down even when commercial pressure is pushing the other way. The SA is often the person who can see those forks earliest, because they're the ones in the technical detail. Knowing when to push, when to pull in a specialist, when to introduce a new constraint, and when to say "we should take this offline" is navigation. It compounds over time and it's most of what experience buys you in this role.
The expert. You do, actually, need to know things. You need to know your product deeply enough that you don't have to look things up in real time during a call. You need to know the adjacent ecosystem well enough to have a point of view on it. You need to know your category — the patterns, the failure modes, the way smart users think about the problem space. The expert role is the one that's most visible from the outside, and as a result it's the one new SAs over-index on. It's necessary but it's only one of the four.
The trusted advisor. This is the one that takes the longest to grow into and matters the most. At some point in a deal — sometimes in the first call, more often by the third or fourth — the relationship shifts. The user stops treating you like a vendor and starts treating you like someone whose judgment they actually want. They ask you what you'd do in their position. They send you architecture diagrams before the meeting. They tell you about internal politics they wouldn't tell their AE. When that shift happens, the deal almost always closes. When it doesn't, you're working harder for less.
The four jobs aren't a checklist. They overlap and trade off in any given moment. But if you find yourself stuck in the role — feeling like you're working hard without making progress — it's almost always because one of the four has fallen out of balance. Usually it's the trusted-advisor job, because that one only grows when you give it room.
What an SA is not
It helps to be specific about what the role isn't, because the most common ways the role goes wrong in a company are when it gets confused with one of these adjacent functions.
An SA is not a demo monkey. If the job is reduced to "show up to calls, click through the demo, answer technical questions," you've built a function that doesn't justify its cost. Also, the SAs will know. They always know.
The demo is one tool in the SA's kit. It's a means, not an end. A senior SA spends as much time avoiding unnecessary demos as giving them, because every demo that happens before the user is ready is a demo that lands worse than it could have.
An SA is not a free implementation engineer. There's a real temptation, especially in the late stages of a deal, to start doing the integration work for the user. Sometimes a small unblock is the right move. Doing the build for them is almost never the right move, even when it would close the deal faster. It sets the wrong expectation, it scales badly, and it papers over a real signal — that the user might not have the capacity or commitment to actually deploy what they're buying.
An SA is not an SDR with a CS degree. The role is genuinely technical and it should remain genuinely technical. If your SAs are spending most of their time qualifying inbound leads or running discovery calls without an AE, the function has been scoped wrong. They'll burn out, the role won't attract the people you want, and the deals you do close will be smaller than they should be.
An SA is not a product manager. SAs see things the product team doesn't see. They should funnel that signal back. They should not, in general, be making product roadmap commitments to users on the company's behalf. The line between "informed advocate for the user inside the company" and "person who promises features that aren't on the truck" is a line every SA learns to walk carefully.
An SA is not a customer success manager. The post-sales handoff is real and important, and we'll come back to it later in the book. SAs who get pulled into ongoing account management without a clean handoff become the bottleneck for everything — the next deal, the renewal, the expansion. The role only works at scale if the front of the funnel and the back of the funnel are owned by different people.
Why the role exists
If you zoom out, the SA role exists for one reason: complex products are hard to buy.
When a product is simple — a SaaS app with a clear feature set, a well-defined buyer, an obvious price point — you don't need an SA. The user can self-serve, the AE can answer the few questions that come up, and the deal closes on its own merits. The cost of an SA in that motion is pure overhead.
The role earns its place when the product is something the user has to integrate, when the deal involves people the AE can't talk to (engineers, architects, security teams), when the use case has enough variability that the right answer isn't obvious from the marketing site, and when the cost of getting it wrong is high enough that the user genuinely needs help thinking it through.
That last part is the one most companies miss. The SA is there to help the user make a good decision, not just to help them buy. Sometimes the good decision is to buy. Sometimes the good decision is to not buy yet, or to start with a smaller piece, or to solve the problem a different way. An SA who can hold that line — who can tell a user "I don't think this is the right fit for you, here's why" — is worth significantly more than one who can't, because the relationship becomes durable. The user remembers. They come back when the fit is right. They tell other users.
This is the version of the role that justifies its existence. Anything narrower — demo monkey, free implementation engineer, glorified SDR — is a misuse of the function. The cost compounds.
A note for builders
If you're a founder or sales leader reading this chapter, the practical takeaway is that the SA role you're scoping is probably narrower than the role that will actually emerge if you do this well. The first SA you hire will gravitate toward whichever of the four jobs they're most naturally drawn to. The translator hire will end up on every call. The navigator hire will end up running deal strategy for the AEs. The expert hire will end up writing internal documentation. The trusted-advisor hire will end up with three users on speed dial.
None of these are wrong, but none of them are the whole role. The function only works when you build for all four jobs explicitly — by hiring deliberately, by setting the scope, by giving the role enough room to be more than a demo function, and by paying for it like the senior craft it actually is.
We'll come back to the building question in the last part of the book. For now, if you're new to the role, start with the four jobs as a frame. Notice which ones come naturally and which ones don't. Pay attention to where you're spending time. The shape of your week will tell you which job is currently dominant, and whether that's the right answer for the deal you're working on.