Writing a GTM engineer job description
A good GTM engineer job description states the mandate in its first paragraph: the two to four capability domains the role owns, which one leads, and what the hire is expected to change in year one. Everything else in the document supports that paragraph. Written this way, the JD does real screening work before a single resume arrives — the right builders recognize their job in it, and everyone else self-selects out.
The JD is the mandate, translated
The job description is downstream of a decision, and it can't substitute for it. Define the domain mix first (where the business is, what must change next, what the hire inherits) and the JD becomes a translation exercise: the same spec, written to be read by a candidate instead of a hiring committee.
Translation still takes craft. Candidates read a JD asking three questions: what would I actually own, is this team honest about the state of their systems, and would this role grow me. A JD built from the mandate answers all three; a generic responsibilities list tends to leave all three open.
Keyword soup: the classic failure
The failure mode is easy to recognize once named: a JD that lists every GTM tool the team has heard of and every domain the taxonomy names, as if breadth of vocabulary were breadth of thought. Clay, HubSpot, Salesforce, n8n, Python, "AI-native," outbound, RevOps, analytics, enablement — all of it required, none of it prioritized.
A JD like that pulls in nearly everyone and convinces almost no one you'd actually want. Applicants who match keywords flood in, because matching keywords is exactly what resume optimization is for. Meanwhile the practitioners you want read the same posting and see a team that hasn't decided what it needs — which predicts a first year spent arguing about priorities. The strongest candidates have the least patience for that.
What should a GTM engineer job description include?
Six sections, annotated. This is a skeleton to write against, not boilerplate to paste.
-
01
The mandate paragraph
Open with what this person owns: the lead domain, the supporting domains, and why the role exists now. This is the paragraph a strong candidate reads twice; write it last, after the rest of the JD has forced the thinking.
-
02
What they inherit
The stack as it actually is: which systems run today, which are half-built, what's known to be broken. Honesty here reads as self-awareness, and it attracts the builders who like fixing things over the ones who need a clean slate.
-
03
Year-one outcomes
Two or three results, stated as changes in the business: outbound running without manual list work, reporting the leadership team trusts. State them as outcomes so the candidate can judge feasibility — an activities list just restates the mandate paragraph with less commitment.
-
04
Domain boundaries
Name what the role does not own. If enablement, paid acquisition, or the data warehouse belong to someone else, say so — the sentence costs nothing and prevents both sides from discovering the mismatch in month two.
-
05
Approach and stack
State the build approach the role requires (no-code automation, AI-assisted, AI engineering, custom code) and separate tools they must know from tools they'll pick up. Requiring your exact stack screens out people who could learn it in a week.
-
06
What to leave out
Years-in-title requirements (the title is too young for them), generic competencies, and any tool list longer than the systems the role will actually touch. Cutting those leaves more room for the parts that matter.
Titles, seniority, and the comp line
"GTM Engineer" is the consolidating title and usually the right one to post under; the mandate paragraph does the differentiating work the title can't. Seniority belongs in the outcomes: a role that expects self-directed system design in quarter one is senior whatever the title says, and pricing it junior is how searches stall.
On compensation, benchmark against the mandate rather than the title. Salary data pulled from every posting that says "GTM engineer" mixes jobs with different domain mixes and build approaches. Price the role you defined, in your market, for the approach you require.
Frequently asked questions
What should a GTM engineer job description include?
Six things: a mandate paragraph naming the domains the role owns and why it exists now, an honest account of the systems the hire inherits, two or three year-one outcomes, explicit domain boundaries, the required build approach with a short tool list, and a deliberate absence of filler like years-in-title requirements.
What's wrong with listing all our tools in the JD?
A long tool list turns the JD into a keyword-matching game. Resume-optimized applicants will match it; strong builders will read it as a team that hasn't prioritized. List the systems the role will actually own, mark what's required versus learnable, and let the mandate paragraph carry the screening.
What title should we use for a GTM engineering role?
"GTM Engineer" is the consolidating title and the one to post under in most cases, though the same work still appears as growth engineer, RevOps engineer, or sales automation manager. Whatever the title, the mandate paragraph does the real work: candidates decide from the first paragraph, not the job title.
Should we put a salary range in the JD?
Where regulation requires it, yes, and it's usually worth doing anyway — employed practitioners rarely engage with a posting that hides the range. The harder part is setting it: benchmark against roles with a comparable domain mix and build approach rather than against every posting sharing the title, because those describe different jobs at different prices.