Why I wrote this
I didn't know I wanted to do this work. I was a software engineer who they used to put in a suit and send places to go talk to people. This job is incredible — non-stop whiteboarding, solving problems. A mix of all the things I get a ton of energy from.
I was an early member of the Solutions Architect team at Stripe. Early enough that for a while it was literally just two of us, flying all over the place figuring things out as we went.
By the time I left seven years later, the team was over a hundred, organized into specialist tracks, embedded across regions, and structurally important to how the company sold. I had a front-row seat for every version of the role along the way — the version where we did everything, the version where we were trying to figure out what to stop doing, the version where we were teaching others how to do it, and eventually the version where we had enough scale to start specializing.
In that time, I gave a talk. It was an internal onboarding deck — the kind of thing you put together for new hires so they have something to anchor on while they're figuring out the job. It was meant to be useful, not comprehensive. A few dozen slides, a handful of memes, the working theory of how to do the work. I gave it dozens of times. New SAs would join, I'd walk them through it, we'd talk through the tactical bits afterward, and they'd go on to find their own version of the role.
I always thought the contents of that talk would make a decent book. So here it is.
The talk worked because it was short and tactical and specific to where we were at the time. But it left a lot out. It assumed the reader was already inside Stripe, already had an AE counterpart, already knew what an opp team was, already understood why the role existed in the first place. It taught the how and skipped most of the why.
The why is what I want to write about. Because the longer I did this job, the more I came to believe that pre-sales technical engagement is one of the most under-examined crafts in B2B software. Companies build SA teams because their competitors have them. They scope the role badly. They mis-comp it, mis-measure it, and pile on responsibilities that have nothing to do with the actual work. The SAs themselves often pick up the craft by osmosis, and when it works it's because someone who already knew what they were doing took the time to show them. When it doesn't work, the role gets blamed for outcomes it was never designed to produce.
There's a real craft underneath all of that. It's possible to be good at it on purpose, not by accident. That's what this book is about.
Who this is for
The first audience is anyone doing the work — Solutions Architects, Sales Engineers, Pre-Sales Engineers, Solutions Consultants, whatever your company calls the role. The titles are inconsistent across the industry and I'll mostly use "SA" throughout the book because it's what I'm used to. The substance applies whether you're three months in or three years in.
The second audience is the people who work alongside SAs — Account Executives, Customer Success Managers, Solutions Engineers in adjacent functions, the people in the deal channel. A lot of what makes the SA role work or not work has to do with how the people around it engage with it. Reading this gives you a sense of what your SA counterpart is actually trying to do, which helps the deal.
The third audience is founders and sales leaders trying to decide whether to build this function, when to hire the first one, how to structure the team, how to compensate it, and how to know if it's working. This is the audience the original talk wasn't built for at all, and it's the one I've spent the most time with since leaving Stripe. There are a handful of decisions you make in the first two SA hires that determine what the function becomes, and most of them are easy to get wrong.
If you're in any of those three groups, there's something here for you. The book is roughly organized around the work itself — the deal cycle, the calls, the demos, the team — but each section ends with a brief note on what it means for the people building the function, because the craft and the org chart are tied together more closely than most companies treat them.
What this book is, and what it isn't
This is a practical field guide. It's the things I'd tell you over a long coffee if you were starting in the role tomorrow, organized so you could find them again later. It's deliberately short. There are longer books on enterprise sales and on technical product knowledge and on the psychology of complex deals, and many of them are good. This one is meant to sit on your desk.
A few things this book isn't:
It isn't a Stripe book. I'll occasionally use payments-shaped examples because that's the world I know best, but the substance is about the craft of pre-sales engagement, which transfers across categories. The hard parts of the job — discovery, scoping, demo construction, navigating a complex deal, knowing when to slow down — are largely the same whether you're selling payments infrastructure, observability platforms, or developer tooling.
It isn't a sales methodology book. I won't teach you MEDDIC or Challenger or Command of the Message. Those are useful frameworks and I've worked with sellers who run them well. This book is upstream of methodology — it's about the work itself, regardless of the framework your company has chosen to wrap around it.
It isn't a script. I'll give you principles and concrete tactics, but the work doesn't reduce to a script and any book that promises one is selling you something. The craft is in the judgment — knowing which principle applies in this moment, which tactic to reach for with this user, when to hold the line and when to adapt. That judgment comes from doing the work and reflecting on it. The book is meant to make the reflection more efficient.
It isn't comprehensive. I've left out a lot. Channel sales. Deep procurement and legal navigation. Public sector. Most of the post-sales handoff. The book is what fits without padding, and I'd rather write a tight book that respects your time than a thorough one that you don't finish.
The throughline
If there's one idea that runs through the whole book, it's this: the work is in service of the user.
That sounds obvious enough that it's easy to skim past. But the test of whether you actually believe it shows up in small moments — when a deal is going sideways and you have to choose between the answer that's true and the answer that's convenient, when a roadmap commitment would close the deal and you know the team can't actually ship it on that timeline, when an AE wants to push past a real concern because the quarter is closing. Almost every meaningful judgment call in this job comes back to a question that's two sentences long:
Is this good for the user? Is it good for us?
If the answer to both is yes, you're probably on the right track. If the answer to one is no, you have work to do. If the answer to both is no, walk away.
I'll come back to this throughout the book, because it's the only frame I've found that holds up across every situation the job throws at you. Everything else is tactics.
Let's get into the work.