Technical Go-To-Market · Chapter 1 of 6
Four jobs that look like one
Sales engineer, forward deployed engineer, technical account manager, customer success. Different phases, different measures, frequently confused.
Technical go-to-market is 1,426 postings in this atlas and the titles are used loosely enough that candidates routinely interview for the wrong job. Customer-facing language appears in 99% of them and technical depth in 60% — these are genuinely technical roles where the deliverable is a customer's decision rather than merged code.
The questions that establish which job it actually is
- “What number am I measured on?” Deals influenced, time to go-live, account health, net revenue retention. The answer settles almost everything else.
- “Do I have a quota, and is it individual or shared?” Quota appears in a third of these postings, and a shared quota is a very different job from an individual one.
- “Do I write code that ships?” Some of these roles commit to the product; some build throwaway demos; some never open an editor.
- “How much travel, as a percentage?” Travel is named in 38% and ‘as needed’ is not an answer.
- “Am I pre-sales or post-sales?” Frequently unstated in the posting and it determines your rhythm, your compensation structure and your exits.
Why these roles are under-competed
Engineers dismiss them as ‘sales’, and salespeople cannot do the technical half. That leaves a narrow pool for roles that pay comparably to engineering, involve real technical work, and have a much shorter path to seniority because the impact is legible to the business.
The honest trade: you will spend a large share of your time in conversations rather than in code, and if that drains rather than energises you, no amount of compensation fixes it.
Telling the four apart, which matters more than the titles
| The job | You are measured on | The failure mode |
|---|---|---|
| Pre-sales / solutions engineering | Deals won that needed technical credibility | Becoming the person who answers questionnaires. Real SEs shape the architecture of the deal |
| Post-sales / customer engineering | Adoption and renewal, not tickets closed | Being measured on support metrics, which quietly turns the role into support with a better title |
| Forward-deployed / delivery | Something working in the customer's environment | Building bespoke software nobody else can use, then owning it forever |
| Developer relations / advocacy | Developers who can succeed without talking to you | Vanity metrics. Conference talks are not the job; removing the reason for the support ticket is |
The distinction that matters in an interview: the first two are attached to a revenue number and the last two usually are not. That single fact shapes everything — how you are prioritised, whose calendar you live on, and what happens to your role when the company is under pressure. Ask which one you are joining before you ask about the technology.
What all four actually share
Every one of these roles is fundamentally about being trusted by someone who has already been sold to. Customers arrive having heard claims from a salesperson and a website. Your value is being the person who will say ‘no, that will not work’ — and that value is destroyed the first time you say something is fine when it is not.
The counterintuitive skill: saying no is the whole asset
The instinct in a customer-facing technical role is to make things possible. It is the wrong instinct, and it is the one that ends careers slowly.
A technical person who confirms everything is indistinguishable from the salesperson, and the customer knows it within two meetings. From then on you are treated as part of the pitch and your answers stop carrying weight — including the true ones.
A technical person who says ‘that specific thing will not work well, here is why, and here is what I would do instead’ becomes the person the customer calls before making a decision. That is the entire asset of the role and it compounds.
The version that works commercially is never a flat refusal: name the constraint, name what it would cost to work around it, and offer the nearest thing that does work. That is a solution conversation rather than a rejection, and it keeps the deal alive on honest terms.
And a rule worth holding: never commit to a roadmap item you do not control. ‘That is on the roadmap’ from a technical person is heard as a promise, and when it slips, the trust lost is yours rather than the product manager's.
Check yourself