Most Solutions Architect 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. It's just useless. Paste it into a posting for half a dozen different roles and it fits each of them about equally badly.
I suspect a single SA job description escaped from somewhere around 2014 and has been quietly reproducing across LinkedIn ever since.
The actual job is more specific, and stranger.
The seam between three conversations
A Solutions Architect sits between three conversations every complex deal has to navigate:
- The commercial conversation. What the user is buying, what it costs, when it starts. The Account Executive owns this.
- The technical conversation. What the user is actually trying to build, whether your product can do it, what the integration looks like.
- The trust conversation. Whether the user believes you can deliver, 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 outright, co-owns the third, and shows up in service of the first. Most confusion about the role 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 does over a quarter, the work clusters into four distinct jobs.
The translator. The user describes a problem in their language. You translate it into yours. Your platform's capabilities have to get translated back into theirs. This sounds mechanical. It's where most of the craft lives. Good translation makes the user feel understood. 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, and moments where the right move is to slow down even when commercial pressure is pushing the other way. The SA is often the first person who can see the fork, because they're in the technical detail. Knowing when to push, when to slow, when to pull in a specialist — that's navigation. It's most of what experience buys you in this role.
The expert. You actually need to know things. Your product, deeply enough that you're not Googling it on the call. The adjacent ecosystem, well enough to have a point of view. The category — its patterns, its failure modes, how smart users think about the problem space. New SAs over-index on this one because it's the most visible from the outside. It's necessary, but it's only a quarter of the job.
The trusted advisor. This is the one that takes the longest to grow into and matters most. At some point in the deal — sometimes the first call, more often 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 what you'd do. 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.
The four jobs aren't a checklist. They overlap. If you feel stuck — working hard without progress — one of the four has usually fallen out of balance. Usually the trusted-advisor job, because that one only grows when you give it room.
What an SA is not
The role goes wrong when it gets confused with adjacent functions. A few worth naming:
Not a demo monkey. If the job is "show up, click through the demo, answer questions," you've built a function that doesn't justify its cost. Also, the SAs will know. They always know.
Not a free implementation engineer. There's a real temptation late in a deal to start doing the integration work for the user. Sometimes a small unblock is right. Doing the build for them almost never is, even when it would close the deal faster.
Not an SDR with a CS degree. The role is genuinely technical. It should stay that way. If your SAs are spending most of their time qualifying inbound leads, the function has been scoped wrong.
Not a product manager. SAs see things the product team doesn't see, and that signal should flow back. SAs should not, on the other hand, be making 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 one every SA learns to walk carefully.
Why the role exists
Complex products are hard to buy.
Simple products — a SaaS app with a clear feature set, an obvious buyer, a fixed price — don't need SAs. The user self-serves. The AE handles the rest.
The role earns its place when the product has to be integrated, when the deal involves people the AE can't credibly 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 clause 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 it's to not buy yet, or to start smaller, or to solve the problem a different way. An SA who can hold that line — who can say "I don't think this is the right fit for you, here's why" — is worth significantly more than one who can't. The relationship becomes durable. The user remembers. They come back when the fit is right. They tell other users.
That's 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.
So what is the job, really?
A craft. A specific one, with its own discipline, its own failure modes, and its own muscle to develop.
It's also one of the most under-examined crafts in B2B software, which is why this blog exists. The job descriptions don't help. The training material is mostly absent. Most SAs pick up the craft by osmosis, and when that works, it's because somebody who already knew what they were doing took the time to show them.
If you're new to the role, the four jobs are a starting frame. Notice which ones come naturally. Notice which don't. Pay attention to where your week actually goes. The shape of your time will tell you which job is currently dominant — and whether that's the right answer for the deal you're working on.
Adapted from Solutioneering*, available at seperformancetoolkit.com/solutioneering.*