Who this chapter is for
This chapter is written specifically for founders and sales leaders deciding whether, when, and how to build a Solutions Architect function. Most of the rest of the book has been written for the SAs themselves and the people working alongside them. This one steps back and looks at the function from the org-design seat.
If you're an SA reading this, the chapter is still worth your time — partly because understanding how the function gets built helps you understand why your job looks the way it does, and partly because at some point in your career you'll be making these decisions yourself, on a team you're leading.
When to hire your first SA
The most common mistake I see in early-stage companies isn't the timing of the first SA hire — it's hiring them without understanding what the role is supposed to do. Companies often hire an SA because their competitor has them, because a sales leader is asking for one, or because a complex deal seems to require one. None of those are wrong reasons, but none of them is, by itself, sufficient.
The right reason to hire an SA is that your sales motion has reached a point where the AE alone can't carry the technical conversation, and the cost of getting the technical conversation wrong is now meaningful. You'll know this when you start losing deals — or seeing deals stall — on technical questions the AE can't answer credibly. You'll know it when the engineers on the user side are asking for someone they can talk to. You'll know it when the demos your AE is running are landing badly, not because the AE is bad at demos but because the user has questions the AE can't field.
If those signals aren't present yet, you don't need an SA. You might need better sales engineering content, better demo training for your AEs, better technical resources on your website. Hiring an SA before the role has clear work to do produces a person who's busy without being effective, and it sets up the function badly from the start.
When the signals are clear, the next question is what kind of SA to hire first.
The first hire shapes the function
The first SA you hire will, by default, define what the role looks like at your company for years. They'll set the tone, write the early documentation, establish the norms, train the next hires. If you get the first hire right, the function compounds. If you get it wrong, you'll spend years undoing the patterns that got established early.
A few things that matter in the first hire.
Hire someone who's done this job before, at a company with a real SA function. The role is craft-heavy and a lot of the craft is tacit — it doesn't transfer well from a job description, and it's hard to learn from scratch. Your first SA should be someone who has spent enough time in the role at a place that took it seriously to have absorbed the working patterns. They don't need to be senior in years; they need to have seen the function done well.
Hire for judgment, not just technical depth. The depth matters. It's not enough on its own. The SAs who succeed long-term are the ones with good judgment about when to push, when to slow down, when to bring in expertise, when to say "I don't know," when to walk away from a deal. You can train technical depth more easily than you can train judgment. Look for the latter in the interview process.
Avoid the brilliant-engineer-who-wants-to-try-sales hire as your first. I'm not saying these hires can't work; some of them are great. But they're usually not great as the first SA, because they're learning the role from scratch in an environment that needs the role to already work. The dynamic gets ugly when the first SA is also learning to be an SA. Hire someone who can do the job from day one, even if they're slightly more expensive.
Hire someone who can write. A surprising amount of what an early SA does is documentation, internal and external. Writing skill compounds. The SA who can produce a clean recap email, a useful internal playbook, a customer-facing technical doc, is dramatically more valuable than one who can't. This trait is easy to assess and almost no one assesses for it.
The first hire should be someone you'd be comfortable letting set the tone for the next ten hires. That's the bar.
Scoping the role
Once you've decided to hire, the next decision is what the role's scope actually is. This is where most companies make the role too broad, in ways that look reasonable individually but compound into a function that can't do its core work.
The temptation is to give the SA everything. Pre-sales technical engagement, of course. Plus inbound qualification, because they can answer technical questions faster than the AE. Plus implementation support, because they already have the context. Plus competitive analysis, because they're in the deals. Plus content. Plus enablement. Plus partner management. Plus, eventually, watering the plants. Each addition makes sense in isolation. Together, they produce a role that's spread too thin to do any of it well, with the deep technical engagement — the actual reason the role exists — getting squeezed first.
The way to scope cleanly is to be explicit about what the role is not responsible for. Implementation post-close is owned by a different function. Inbound qualification is owned by the AE or an SDR. Content and enablement is a sometimes-output, not an ongoing responsibility. Competitive analysis is a shared input, not an SA deliverable. Partner enablement, if it matters, is its own function.
You'll get pressure from every direction to widen the scope back out. Resist it. The narrowest version of the role is the most leveraged version, and the leverage is what justifies the cost.
Compensation and incentives
How you pay SAs shapes the function more than most leaders realize.
The standard model in most B2B companies is some variant of base plus a variable component tied to deal outcomes — usually attainment of the AE's quota, or a similar attached-deal-volume metric. This works as a baseline. It also creates predictable problems if it's the only signal in the comp package.
The biggest problem: SAs paid purely on attached deal volume will, over time, attach to anything. They'll be on every call, on every deal, regardless of whether the deal is the right use of their time. They'll be reluctant to push back on AEs. They'll be slow to walk away from bad-fit users. The behaviors that distinguish a good SA from a great one — the willingness to make the deal smaller when smaller is right, the willingness to slow down when slow is right, the willingness to surface uncomfortable signals — get suppressed by the comp design.
The fix is to add signals that aren't purely about deal volume. Implementation outcomes. Customer satisfaction post-sale. Expansion revenue in covered accounts. Feedback from AEs and users. Some of these are noisier than deal attainment, and they'll never be the whole comp package, but their presence in the package shifts behavior in the right direction.
The other thing to watch for is parity with the AE. SAs and AEs don't need to be paid identically, but the relative levels matter — if AEs make significantly more for the same revenue contribution, the SA increasingly becomes a service function rather than a peer. The function works best when SAs and AEs are economic peers, with different comp shapes but comparable trajectories.
Career path
This is the question that gets ignored most often and matters most for retention.
In a lot of companies, the SA role doesn't have a clear career path. There's an IC track that ends somewhere around senior or staff, and there's a vague management option, and that's about it. The SAs who stay are the ones who carve out a path themselves; the rest leave for companies that have better-defined growth.
The good versions of this look like:
A specialist track. Some SAs want to go deeper into specific product areas, becoming the recognized expert in payments, in identity, in data infrastructure, whatever your category is. Build the role for them. Make "Principal SA, [domain]" a real position with real authority, real comp, and real internal recognition. These people become the seniormost technical voices in the function and they should be paid like it.
A lead IC track. Some SAs want senior influence and compensation without managing direct reports. The Lead IC role operates at the same decision-making level as management — sitting in deal-strategy conversations, shaping function-wide direction, holding real authority — but the day-to-day is still mentoring other SAs, running the highest-stakes deals themselves, and helping develop the next generation of the team. Build this track deliberately. Without it, the seniormost SAs are forced into management to grow, which means the function loses its deepest practitioners exactly when they're most useful as practitioners.
A management or leadership track. Some SAs want to lead other SAs. Some want to shape the broader function — enablement programs, cross-functional initiatives, how the role works across the company. Both belong on the same track. The transition from individual contributor is non-trivial; develop these people deliberately. Don't promote your best individual contributor into management on the assumption that the management work will come naturally. It usually doesn't.
A graceful exit. Some SAs move into product or engineering after a few years in the role. This is a healthy outcome — they become exceptional product managers and field-aware engineers — but only if your company supports the move. Companies that try to hold their SAs forever in the role end up losing them altogether.
The career path isn't just for the SAs. It's a hiring tool. The first thing a senior candidate asks in an interview is what the path looks like five years from now. If you can answer cleanly, you're competitive for the best people. If you can't, you're filtering for less ambitious candidates.
Ratios
A common question: how many SAs should you have, relative to AEs?
The honest answer is that it depends on the segment, the product complexity, and the deal cycle. There's no universal ratio. What I can offer is a frame for thinking about it.
The right ratio is the one where SAs have enough room in the calendar to do the deep technical work. If your SAs are in five external meetings a day, every day, they're not doing prep, they're not writing useful notes, they're not staying current on the product, and they're not doing the strategic deal work with their AEs. The function looks busy and it's actually under-performing.
A useful test: ask your SAs how much time they had last week for prep, for follow-up, for staying current on the product, for cross-team work. If the answer is "not enough," you're under-staffed. If the answer is "plenty," you might be over-staffed, but that's a problem worth having and easy to fix. If the answer is "enough but barely," you're probably about right.
The ratio shifts by segment. For commercial deals, an SA might support several AEs. For mid-market, the ratio is closer to one-to-one or slightly leveraged. For strategic, an SA might be dedicated to a single AE or even to a single account. These aren't rules, just patterns. The signal is the calendar.
Where it goes wrong
The SA function as demo team. The SAs are scoped narrowly to running demos. The AEs handle everything else. The SAs become a service function with no leverage and no career path. Turnover is high. The function has limited impact on deal outcomes because it isn't involved in the parts of the deal where the impact is.
The SA function as overflow capacity. Whenever something needs doing — a content project, an internal tool, an event — the SAs get pulled in. The deal work suffers. The function has no clear scope and no clear measure. Everyone is busy and nothing is great.
The SA function as mini-AEs. The SAs are increasingly pulled into commercial conversations, contract negotiation, pricing strategy. The technical work atrophies. The role becomes confused with the AE role. The user notices that there's no specific technical advocate, just two people who both seem to be selling.
Each of these failure modes is preventable, and each of them happens because of a series of small decisions that add up. The fix isn't a single intervention; it's vigilance about the shape of the role over time, and the willingness to course-correct when the function is drifting.
What "good" looks like
Done well, an SA function has a few visible properties.
The SAs are deeply respected by the AEs they work with — not as service providers, but as peers and partners. The AEs talk about their SAs by name, are protective of their time, and notice when their SA is unavailable.
The users have the SA's name in their head. They reference past conversations specifically. They forward technical questions directly to the SA, sometimes outside the AE channel. They mention the SA in references.
The function has its own voice in the company. Product asks SAs what users are saying. Engineering takes SA-sourced feedback seriously. The CEO knows the names of the senior SAs.
One way to test whether your SA function is delivering: think about your last twenty closed deals and sort them into three buckets. Some closed on their own — the user was going to buy regardless of who was on the call. Some closed because an SA was attached — the SA was present, helped the deal along, did nothing wrong. Some closed because of the SA — the deal would have stalled, gone sideways, or gone to a competitor without the specific work that specific SA did. The functions that earn their keep are the ones that put deals into the third bucket regularly.
The deals close cleaner. The implementations land smoother. The renewals happen with less drama. The expansions are bigger.
None of this is provable in a quarter. It's visible over years. The function is an investment that compounds slowly, and the companies that build it well end up with a structural advantage. The companies that build it badly end up with an expensive function that's hard to differentiate from what they had before. The cost is similar; the return isn't.
The difference is mostly upstream — in the early decisions about who you hire, how you scope the role, how you compensate it, and how you protect it from the steady pressure to make it broader and shallower. Those decisions are made early and they compound. Make them deliberately.