GTM engineer
A GTM engineer is the person who builds and owns a company's automated go-to-market systems: enrichment waterfalls, scoring rules, and sequencing logic, as opposed to executing outbound tasks by hand inside tools someone else built.
Most job postings titled GTM engineer are a tool list dressed up as a role: Clay, Zapier, some HubSpot admin, a line about "AI-native automation" that nobody defines. That's a task list, not a job description, and it self-selects for the wrong candidates: people who've used Clay versus people who can explain why an enrichment waterfall is quietly losing good leads before a rep ever sees them.
What the role actually exists to solve
A GTM engineer req exists because a revenue team is spending real hours on manual research, list cleanup, or spreadsheet handoffs that software could do instead, and nobody currently owns fixing it. The job isn't outbound copywriting and it isn't running enrichment by hand until the list goes stale. It's building and owning the system that replaces that manual work: the waterfall that chains data providers, the rules that score a lead, the logic that decides which sequence a prospect lands in.
The role changes shape with company size
At a ten-person startup, a GTM engineer looks like a founder's second brain: one person building enrichment logic, writing outreach, and fixing what breaks, often alone, with no need for deep SQL or a data warehouse that doesn't exist yet. At fifty people, the job specializes into maintaining the automation layer a forming RevOps function and sales rely on. At two hundred, it usually sits inside a broader RevOps or growth org, working against a real data warehouse and stakeholders who have opinions. The same job title covers three different jobs, and hiring against the wrong one is how companies end up either overpaying for a generalist or underusing a specialist.
In practice
The technical bar splits the role into two real tiers, not one. A low-code operator running everything through Clay and Zapier is a different hire than someone writing a query with window functions to build a scoring model or a production workflow that runs unattended overnight. Naming which tier a role needs, before writing the req, filters out candidates who'd be bored and gone in six months and candidates who'd be underwater from day one.
What people get wrong
Teams write the req around tools instead of the outcome, so it reads as a wish list: eight tools, zero sense of what good looks like six months in. The other common mistake is treating the title as a proxy for the discipline. A company can practice GTM engineering informally with no one holding the title, and a company can have a GTM engineer on the org chart who spends their day pushing data between two tools by hand because the systems were never actually built.
