The GTM Engineer Job Description: What to Actually Put in the Req (With a Real Scorecard)

Most GTM engineer job descriptions are a tool list wearing a job title. Clay, Zapier, SQL, some HubSpot admin, a line about "AI-native automation" nobody defines, and a closer about wearing many hats. A strong candidate reads that in ten seconds and closes the tab.

Not because the tools are wrong. Because the req never says what problem this person exists to solve. List the tools without the outcome and you've written a task list, not a role. And task lists self-select for the wrong people: candidates who've heard of Clay versus candidates who can explain why an enrichment waterfall is quietly dropping good leads before they ever reach a rep.

I've scoped this hire for clients enough times to recognize the pattern before I finish reading the first paragraph. The req gets written by whoever's most annoyed that outbound is broken, usually a sales leader or a founder, and it comes out sounding like a wish list. Eight tools. Zero outcomes. No sense of what "good" looks like six months in.

Compare that to a req that opens by naming the actual business problem, not the tools that might fix it. That's one sentence. It's specific. And it tells a candidate exactly what they'd be measured against, which is the whole point of writing a job description in the first place.

What a GTM engineer req is actually for

A GTM engineer req exists to solve one problem: your revenue team is spending time on work that should be automated, and nobody currently owns fixing that. That's not outbound copywriting, and it's not running enrichment by hand in a spreadsheet until the list goes stale. If you're still working out what GTM engineering actually is as a discipline, this role is the person who builds and owns that system, not the person who executes a checklist inside it.

Say the business problem in plain language before you say anything about tools. "Our SDRs are burning real hours on manual research instead of calling" is a sentence a candidate can act on. "Looking for a GTM engineer to own our tech stack" is not. The first frames a mandate. The second describes a job title looking for a person to justify it.

Write the req around the outcome, then let responsibilities and tools explain how that outcome gets built. Everything downstream of that opening paragraph should trace back to it.

Scope it to your stage first, the req changes at 10, 50, and 200 people

A GTM engineer req at a 10-person startup and one at a 200-person company shouldn't share much more than the job title. Nobody in the field seems to write it that way. Every template collapses into one generic list of tools and responsibilities regardless of company size, and that's exactly why so many of these reqs get filled by the wrong person: a 10-person startup doesn't need a specialist, and a 200-person company doesn't need a generalist who reinvents infrastructure that already exists.

At 10 people, the GTM engineer is closer to a founder's second brain than a specialist. They build the enrichment logic, write the outreach, watch the numbers, and fix what breaks, often alone. Don't ask for deep dbt or data-warehouse experience here. You don't have a warehouse yet, and asking for one just filters out people who'd actually be great at the job you have.

At 50 people, the role starts to specialize. There's usually a RevOps function forming, maybe a data stack beyond spreadsheets, and the job shifts from "build everything" to "build and maintain the automation layer that RevOps and sales rely on." This is also the stage where the question of whether to build this in-house or hire it out gets real, because the scope is finally big enough to price against outside options.

At 200 people, the GTM engineer usually sits inside a broader RevOps or growth org, working against a real data warehouse, a defined tech stack, and cross-functional stakeholders who have opinions. Don't ask for someone who can "wear many hats" here. That's a 10-person requirement bleeding into a req where it doesn't belong, and it tells senior candidates you haven't thought about what the job actually requires at your size.

If you're still unsure whether this should be a full-time hire at all versus something scoped in from outside at your stage, that's a decision worth making before you write the req, not after you've posted it.

The technical bar, and what it actually costs you

"Proficient in SQL" isn't a requirement. It's a placeholder for one. There's a real difference between someone who can write a SELECT statement to pull a list and someone who can write a CTE with window functions to build a scoring model, and your req should say which one you need. Same with Python: is it for one-off scripts that clean a CSV, or for production workflows that run unattended overnight? Naming the actual bar filters out candidates who'd be underwater in the role, and it filters out candidates who'd be bored and gone in six months.

That specificity matters more than most hiring managers assume, because the technical bar has a real dollar figure attached to it. In OneGTM's 2026 State of GTM Engineering survey (self-selected, n=228, 30+ countries; the authors' own words: "meaningful but not statistically representative"), low-code operators reported a median salary around $90K, and code-capable operators reported a median closer to $135K, roughly a $40K to $45K premium for the code-capable tier.

That's not a reason to always hire for the top tier. A 10-person startup running everything through Clay and Zapier doesn't need someone who can build a dbt model. You'd be paying $40K extra for a skill nobody's going to use. But a req that just says "SQL" without naming which SQL will either underpay for the bar you actually need or overpay a candidate who read the word and assumed you meant something they could deliver in an afternoon. The tier you're hiring for isn't a nice-to-have detail. It's the line item most likely to make your comp range wrong.

Write the bar the way you'd want it written to you: SELECT-statement SQL or CTE-and-window-function SQL. One-off-script Python or production-workflow Python. Two sentences, and it saves everyone downstream a round of misaligned interviews.

What to put in the tools section (and what to leave out)

Naming Clay by name in a GTM engineer req isn't just fine, it's expected. In the same OneGTM survey (self-selected, n=228), 84% of GTM engineers report using Clay, climbing to 96% among agency operators. If your req says "CRM and enrichment tools" instead of naming the tool your team actually runs, you're being vague where specificity would filter better candidates in, not worse ones out.

Where this goes wrong is the opposite mistake: listing the entire stack. A requirements section that reads like the company's full tool inventory tells a candidate the company doesn't know what this seat actually needs, and it turns off exactly the people you want, because a senior GTM engineer knows tool count isn't a proxy for seniority.

Name the two or three tools that matter for this specific seat, not the company's whole stack. If the role is mostly Clay work, say Clay and stop there. If it also owns the sequencer, name that tool too and leave the rest for the interview. Someone who's run a real Clay waterfall can pick up Zapier or a CRM's automation layer inside a week. That's not what you're screening for. You're screening for judgment about how the pieces fit together, and ten tool names on a job posting don't tell you any more about that than two do.

Compensation, put a real range in, and here's what "real" means

Every competitor page in this field cites one salary number, unattributed. That's not a compensation range, it's a guess with a dollar sign on it, and candidates can tell the difference.

Two real numbers exist here, from two different sources, using two different methods, current as of this writing in July 2026, and they roughly agree with each other. That agreement is itself worth something.

OneGTM's 2026 survey (self-selected, n=228, 30+ countries; the authors call it "meaningful but not statistically representative") puts US in-house median base salary around $135K. Separately, Bloomberry's Henley Wing Chiu ran an independent analysis of 1,000 GTM engineering job postings and found a median advertised salary of $127,500, with SQL and Python each appearing in 38% of those postings. These are two unconnected data sets. Don't blend them into one number when you cite them; cite each by name.

Neither number is perfect. A self-selected survey skews toward people motivated enough to answer it. A job-postings analysis captures what companies advertise, not necessarily what they end up paying. But $135K and $127,500 landing within $8K of each other, from two methods that never talked to each other, is a stronger signal than either number alone.

Put a real range in your req, and anchor it to one of these two sources instead of a number pulled from a recruiting blog with no methodology attached. If you can't commit to a number yet, that's a real answer too. It just means you're not ready to post the req.

The interview scorecard, score the exercise, don't just ask about it

Nobody in the field publishes this part. Two competitor pages get as far as a job description template. One of them includes a solid take-home exercise, build a DAG plus a reverse-ETL mapping. None of them tell you how to grade it. A hiring manager staring at two finished exercises has no way to tell a 3-out-of-5 answer from a 5-out-of-5 answer, so the decision comes down to gut feel dressed up as process.

The fix is scoring the work, not the resume line about the work. Hand the candidate a broken enrichment waterfall, sanitized, ideally from your own stack, and watch what they do. Do they check whether the input data is actually the problem before touching the logic? Can they explain the fix to a non-technical stakeholder, or do they retreat into tool jargon the moment it gets uncomfortable? That's the signal. The tool names on their resume aren't.

Below is the rubric I use when scoping this hire for clients. Six competencies, scored 1 to 5, with a one-line anchor for what a weak, middling, and strong answer actually looks like. Adjust the weighting to your stage; a 10-person startup should weight AI-workflow judgment and cross-functional translation heavier than deep SQL, for the same reasons covered in the stage section above.

Run this against a real exercise, not a hypothetical one. A candidate who scores a 4 or better on waterfall logic and AI-workflow judgment, and at least a 3 everywhere else, is worth an offer. A candidate who's a 5 on SQL and a 1 on cross-functional translation is going to build systems nobody else on your team can maintain, which is its own kind of expensive.

Red flags in the req itself

Some phrasing in a GTM engineer req actively repels the candidates you're trying to attract, before they ever get to an interview.

• No comp range at all, or "competitive salary" standing in for one. Strong candidates read this as either a role you haven't scoped or a number you're trying not to commit to yet.
• "Wear many hats" as the entire scope description, with nothing underneath it.
• Ten-plus tools listed as requirements instead of the two or three the seat actually touches, as covered above.
• "AI-native" or "agentic workflows" used as a checkbox line with no example of what that looks like on a real Tuesday.
• No named reporting line, just a department. Candidates want to know who they answer to, not which org chart box they land in.
• A years-of-experience requirement for a job title that's only existed at any scale for a couple of years, which just filters out the people best positioned to have grown up doing this work.
• Responsibilities written as a flat task list with no business outcome attached to a single line of it, the exact pattern this piece opened with.

If none of this rubric matches what you're actually trying to fix, it's worth checking how this role compares to an AI SDR before you post anything. Some teams write a GTM engineer req when what they actually need is a different kind of solution entirely.

The job description template, ready to copy in

You don't need a spreadsheet or a gated PDF to use any of this. Below is the structure I use when scoping this hire for clients, stripped down to the fields that matter. Copy it into your ATS, fill in the brackets with your stage's answer from the table above, and drop in a comp range anchored to one of the two sources from the compensation section.

GTM Engineer, [Company Name]

Role summary (1-2 sentences, outcome-framed, not tool-framed):
[Name the actual business problem this role exists to fix.]

Reports to: [name a person, not just a department]

Core responsibilities (stage-scoped per company size, see table above):
- [Responsibility 1]
- [Responsibility 2]
- [Responsibility 3]

Technical bar (name the specific tier, not just the tool):
- SQL: [SELECT-statement level / CTE-and-window-function level]
- Python: [one-off scripts / production workflows]
- Primary tools for this seat (2-3 tools, not the full stack): [tool names]

Nice to have (optional, not scored in the interview):
- [Skill]

Compensation range: [$X-$Y, sourced to a real number, not "competitive"]

Once applicants are in the door, the scorecard from the section above is what you run the interview against.

It's the same standard we hold ourselves to on the engagement side: prove the work before you ask for the meeting, not the other way around. Scoping a hire is no different.