I found out the hard way that "we need technical help in sales calls" isn't a job description. It's two different problems wearing the same job title, and I hired for the wrong one first.
By the time we had ten paying customers, I was running every demo myself. That was fine until deals started stalling in the same two places: buyers who loved the pitch but couldn't tell if the product would survive their environment, and buyers who understood the product fine but didn't believe we'd still be a viable vendor in eighteen months. I assumed both problems needed the same fix — a technical person in the room. So I wrote a job req for "Sales Engineer," posted it, and hired someone excellent at exactly the wrong thing.
The distinction that would have saved me three months
A Sales Engineer's job is technical validation: proving the product works, surviving the security review, running the proof-of-concept, answering "does this integrate with our stack" without flinching. They're closest to the codebase and the architecture diagram.
A Solutions Engineer's job is translation: taking a buyer who's still fuzzy on why this matters to their business and turning your feature list into their outcome. They're closest to the buyer's problem, not your product's internals.
The hire I made was a strong Sales Engineer. He was excellent in security reviews and could out-argue any competitor's SE on latency numbers. But most of our stalled deals weren't stalling on technical trust — they were stalling because economic buyers didn't understand what changed for them if they bought. I'd hired someone to answer questions nobody on the losing deals was actually asking.
The three-question test I use now
Before making this hire, I run every recent lost or stalled deal through three questions:
- When a deal stalls, is it because the buyer doesn't trust the product will technically work in their environment — security posture, integration depth, performance under their load? If yes, that's a Sales Engineer problem.
- Or does the buyer understand the product fine but can't connect it to a business outcome they can defend internally — can't answer "why this, why now" to their own boss? If yes, that's a Solutions Engineer problem.
- Which pattern shows up in more of your last ten stalled or lost deals — not the last three, the last ten, because three is noise and ten starts to be signal?
Pull your CRM notes from the last ten deals that went cold or lost to "no decision." Tag each one by which failure mode it looks like. Most founders find one pattern outnumbers the other by at least two to one. That ratio is your answer, not a coin flip between two job titles that sound similar.
Why the hybrid answer is usually wrong this early
Recruiters will tell you to just hire a hybrid who can do both. At Series A headcount, that's real advice — you can afford someone senior enough to flex between technical proof and business translation depending on the deal. Before that, you're usually hiring your first and only pre-sales technical person, and asking one junior-to-mid hire to be equally strong at architecture debates and executive-outcome framing is asking for someone who's mediocre at both under deal pressure. Pick the sharper skew toward whichever failure mode dominates your ten-deal sample, and hire clearly for that, even if the job title undersells the other half of what they'll eventually do.
What I'd tell myself before that first hire
I'd have looked at our lost-deal notes instead of copying a job description template. Seven of our last ten stalled deals had a buyer who liked the product but couldn't articulate the ROI case to their CFO. Zero had failed a security review or technical evaluation — we hadn't lost a single deal to "it doesn't work with our stack." I needed someone fluent in translating features into a business case a skeptical buyer could repeat upward. Instead I hired someone built to win architecture debates nobody on our deals was having.
The fix cost us a re-hire and about a quarter of stalled pipeline sitting untouched while I figured out what actually broke. The three-question audit takes an afternoon with your CRM open. Run it on your own last ten deals before you write the req, and hire for the failure mode your data actually shows — not the one that sounds more technical and therefore feels more defensible to a board.