How We Track the GTM-Engineer Market
GTM Engineer Search's market data comes from a corpus of GTM-engineer job postings collected daily and classified against a rubric locked after a human review loop. This page documents the collection, the classification, and the limits, so every number we publish traces back to a method you can check.
Where the postings come from
The corpus is built from three live sources pulled daily: JobHive, LinkedIn, and Blitz. Those pulls land in a jobs database kept isolated from the rest of the platform, so a missed day of collection can't be silently papered over later. A daily pull that doesn't run is a day of data that's gone for good, not a gap that gets backfilled. According to GTM Engineer Search's tracking, 4,199 postings have been collected and classified under the live rubric so far.
Each source contributes independently rather than one deferring to another: JobHive supplies the broadest sweep, LinkedIn targets phrase-and-region searches, and Blitz fills in company-specific postings the other two miss. A posting seen by more than one source is deduplicated before it ever reaches classification.
How a posting gets classified
Every posting goes through two passes: an extraction pass that pulls structured facts out of the raw job description (title, seniority signals, tools mentioned, compensation if the employer disclosed it), and a classification pass that runs those facts against a written rubric to decide whether the role is genuinely GTM engineering, and if so, which of the 9 domains and 4 approaches it touches.
The rubric is the output of a structured human review loop: 7 batches of postings judged by hand and 35 individual gate rulings on the hardest edge cases (a title that mentions "GTM" but means something else entirely, a role that's really systems administration wearing an engineering title), with the rule refined each round until the final batch reached full agreement. That rubric was locked on 2026-07-25, and every current classification runs against that locked version.
Scope and reliability
The corpus is English-only by design: postings written in another language are filtered out before classification ever sees them, rather than being classified badly and left in the count. That's a scope limit — a rubric tuned on English job descriptions has no business grading postings it wasn't built to read.
Reliability differs sharply depending on what grain you ask about. Aggregate distributions (how big a domain is across the whole tracked population, how the four approaches split, which domains tend to pair together) are steadier than any one posting's labels, and that's the grain this site publishes at. Two independent passes over the same job description line up tag by tag more often than they agree on a single posting's complete label set; the agreement figures that would quantify that gap are classifier-derived, so they're held along with the shares and comp cuts until the recalibration described below lands. The gap itself is why every number on this site is a population statistic ("N% of tracked roles…") and never a claim about what any single posting requires.
Why some numbers are held back right now
The classifier that assigns domains, approaches, and every downstream share or comp cut is mid-recalibration: the rubric is being revised again, and until that revision finishes and a fresh pass runs across the corpus, every classifier-derived percentage, average, and compensation figure stays off this site. That's a conservative call — publishing a number now that we already know will move once recalibration lands would cost more trust than the number is worth.
Two figures are still published through the hold. The first is postings analyzed: it counts every posting classified under the live rubric regardless of the verdict, so it doesn't move when the verdict logic gets recalibrated. The second is the count of open, direct-employer GTM-engineer roles our tracker lists, and that one does pass through the part of the classifier being revised. We publish it anyway, labeled for what it is: an operational count of what the tracker lists today, not a precision claim. When the recalibration lands, this section updates and the fuller stat set returns.
Frequently asked questions
Where does GTM Engineer Search's data come from?
It comes from a corpus of GTM-engineer job postings pulled daily from three live sources (JobHive, LinkedIn, and Blitz) into a jobs database kept isolated from the rest of the platform. Each posting is deduplicated across sources, then run through an extraction and classification pass before anything reaches this site.
How reliable are the numbers?
Aggregate numbers (domain shares, approach mix, how domains pair together) are steadier than any single posting's labels, which is why this site publishes at that grain. A single posting's exact label set is noisier, so we never make a claim about one specific posting; every published stat describes the whole tracked population.
Why don't you publish salary benchmarks yet?
Compensation cuts are classifier-derived, and the classifier is mid-recalibration — a rubric revision is in flight, and every downstream number it feeds (comp cuts included) is held back until that revision lands and a fresh pass runs across the corpus. That's a deliberate call to avoid publishing a figure we already expect to move.
How is a posting classified as a GTM-engineer role?
It's judged against a written rubric locked on 2026-07-25, the product of 7 batches of human review and 35 individual rulings on edge cases. The rubric decides whether a role is genuinely GTM engineering and, if so, which of the 9 capability domains and 4 build approaches it touches — see the GTM Engineer Taxonomy for what those domains and approaches mean.
Hiring a GTM engineer?
Are you a GTM engineer?
Get on the radar