The GTM Engineer Taxonomy

The GTM engineer taxonomy (v2026.1) is a framework of 9 capability domains (what a GTM engineer owns) crossed with 4 build approaches (how they build it), used to describe a role or candidate with more detail than the job title. The current corpus contains 9,039 job postings analyzed for GTM-engineering work, and our tracker lists 604 open, direct-employer GTM-engineer roles today. Use the taxonomy to state the work and build methods behind a GTM-engineer title.

Domains 9
Approaches 4
Taxonomy v2026.1
Postings analyzed 9,039

The axes model: what, how, how senior, and whether they manage

A GTM-engineering role is several independent dimensions layered on top of each other. This taxonomy records each dimension on its own axis.

  • What they own: the 9 capability domains below. A role can span one or more.
  • How they build it: the 4 approaches: no-code automation, AI-assisted work, AI engineering, and custom code. This axis cuts across every domain rather than describing a domain of its own.
  • How senior they are: an individual-contributor ladder from junior through principal, independent of whether they manage anyone.
  • Whether they manage people: none, manager, director, or exec. A senior individual contributor and a junior people-manager sit on different axes entirely; seniority and management answer different questions.

The nine capability domains

Nine domains, each a distinct thing a GTM engineer can own. Pick one to read what it covers and where it stops.

Specification · 01 / 09

Outbound

Outbound owns getting the right message to the right person. That starts before anything is sent: turning your ideal customer profile into real targeting criteria, then building or buying the list of who to actually contact. It continues through the reach itself — sequencing, cadence, multichannel touches, and the deliverability work that keeps messages landing in an inbox instead of a spam folder.

Deriving new intelligence about a contact who's already on the list is a different job, and it belongs to Enrichment & Intelligence.

Specification · 02 / 09

Enrichment & Intelligence

Enrichment & Intelligence is where new information about an account or a person gets attached that wasn't already on file. On the simple end that's a verified email or a basic firmographic lookup; on the AI-driven end it looks more like scoring an account's fit from its tech stack, or spotting a hiring signal buried in a company's open job postings. The test is whether the work adds understanding that wasn't already there — if so, it belongs here.

Putting together who to contact in the first place falls under Outbound; changing a value that's already parked in your CRM falls under RevOps.

Specification · 03 / 09

RevOps

RevOps is the domain that decides what your CRM does automatically once data is already sitting inside it. That starts with the data model and integrations underneath everything else, and extends to the rules built on top of them: routing leads and accounts to the right owner, scoring them, managing lifecycle stages, running quote-to-cash, and keeping the data itself clean.

If new data is being appended or inferred for the first time, that's Enrichment & Intelligence's job. Clicking through settings that already exist, with nothing new built, belongs to Systems Admin.

Specification · 04 / 09

Data Engineering

Every other GTM system depends on infrastructure that Data Engineering builds and maintains: the warehouse and its models, the pipelines and reverse-ETL that keep it fed, and the integrations that carry data from one tool to the next. A one-off export or a folder someone maintains by hand doesn't count; this domain means real, ongoing infrastructure work.

Making sense of the data after it arrives is a separate job, and that one belongs to Analytics.

Specification · 05 / 09

Analytics

Analytics is the domain that turns what's already been gathered into something decision-useful: dashboards, attribution modeling, and funnel and cross-channel reporting. Part of the job is translation work too, taking a vague question from a stakeholder and turning it into a report that actually answers it.

Building the pipelines that feed the dashboard belongs to Data Engineering. Watching one channel's own numbers day to day comes with running that channel; it doesn't make the work Analytics.

Specification · 06 / 09

Growth

Growth owns the funnel once someone is already engaged, not the first cold reach. That's activation and conversion work, and the experimentation behind it: structured A/B testing, product-led growth signals, and paid-acquisition programs aimed at moving people forward rather than just getting in front of them.

The cold outbound send is Outbound; the ongoing nurture infrastructure that keeps people engaged over time is Lifecycle Marketing, not this.

Specification · 07 / 09

Lifecycle Marketing

Lifecycle Marketing is the marketing platform's own automation layer: drip and nurture sequences, the lead-scoring and lifecycle rules built inside that platform, campaign-ops and demand-gen tooling, and the infrastructure behind scaled content programs like programmatic SEO.

What decides the split from RevOps isn't the logic itself but where it's built: a lifecycle rule set up inside the marketing platform belongs here, while that same kind of rule, if it's built into the CRM instead, belongs to RevOps.

Specification · 08 / 09

Internal Tools

Internal Tools means building software specifically for the GTM and ops team's own use, not customers': internal portals, custom apps, and the production code behind them. It isn't a data pipeline (that's Data Engineering) and it isn't CRM configuration (that's RevOps); this domain is defined by shipping working applications.

Specification · 09 / 09

Systems Admin

Systems Admin is upkeep, not new construction: making sure the CRM and marketing stack that's already in place keeps running. That means managing permissions, configuring workflows, watching data hygiene, fielding user support, and keeping the platforms reliable. The moment new logic gets built on top of what's already there, instead of just tending it, the job has become RevOps, not this.

A mandate centered on Systems Admin describes platform operation and support. Add another domain when the role is also expected to build new GTM capability.

The four approaches: how they build it

Approach answers how a domain gets built. The same domain looks different depending on which of these four a role uses.

  1. 01

    No-code automation

    Wiring tools together and automating flows with platforms like Zapier, Make, n8n, and Clay, as a central part of the job, not an occasional shortcut.

  2. 02

    AI-assisted

    Reaching for AI inside tools you already use to get through work faster: an AI feature already built into a SaaS product, a model used for research or drafting copy, or an AI-generated column inside Clay. This is the broadest of the four approaches, and none of it requires writing code.

  3. 03

    AI engineering

    Writing real code to build LLM-powered systems and agents: orchestration, retrieval, evaluation pipelines, with genuine software-engineering practices behind them, including testing, evaluation, and operation after deployment.

  4. 04

    Custom code

    Writing general-purpose software (Python, TypeScript, JavaScript, Go, and the like) to build real services, scripts, and integrations, as a required part of the job rather than an occasional favor. SQL by itself isn't enough to qualify.

How many types of GTM engineer are there?

The taxonomy does not define a fixed set of GTM-engineer types. It provides 9 domains and 4 approaches that can be combined to describe the mandate.

Keep the axes independent. A role may require depth in one domain and working knowledge in others, using different build approaches for each. State that mix in the job description and assessment.

Why the taxonomy is versioned

Tools, team structures, and combinations of domains change over time. Versioning the taxonomy means a role or candidate described against v2026.1 today stays comparable to the same description next year, even after the taxonomy itself evolves.

Every revision gets a version number and a published changelog entry.

  • v2026.1 (2026-08-09): Initial public release: 9 domains, 4 approaches, from the internal rubric locked 2026-07-25 after a 7-batch human review.

Frequently asked questions

What is the GTM engineer taxonomy?

It's a framework (version 2026.1) that describes a GTM-engineering role along two independent axes: 9 capability domains (what someone owns: outbound, RevOps, data engineering, and six more) and 4 build approaches (how they build it, from no-code automation through AI engineering). You can describe a role or candidate as a specific combination of domains and approaches.

How many types of GTM engineer are there?

The taxonomy does not define a fixed number of types. It provides 9 capability domains and 4 build approaches that can be combined to describe a specific role or candidate.

Is a GTM engineer the same as RevOps?

No. RevOps is one of the 9 domains in this framework. RevOps means owning the logic your CRM runs on: routing, scoring, lifecycle stages, quote-to-cash. A GTM engineer might carry RevOps alongside Outbound, Enrichment & Intelligence, or several other domains — or might not touch RevOps at all and still be doing real GTM-engineering work elsewhere in the taxonomy.

Why is the taxonomy versioned instead of fixed?

Tools, team structures, and domain combinations change over time. Every revision gets a version number and a changelog entry, so a role or candidate description that cites v2026.1 stays meaningfully comparable over time.

Hiring a GTM engineer?

Are you a GTM engineer?

Get on the radar