What a GTM Engineer Actually Does
Outcome: a one-page scope for a workflow you actually need, answered against the four questions every build starts from. You carry it through the remaining nine lessons.
- Surface
- App and MCP server
- Level
- Beginner
- Uses
check_credits- Credits
- 0
- Prerequisite
- A Sync GTM account
The situation
A sales team’s real bottleneck is rarely selling. It is that the list is stale, the research takes twenty minutes per account, the CRM disagrees with itself, and the “personalized” first line came from a merge field that fired blank on a third of the rows.
Each of those is a data problem wearing a sales costume. GTM engineering is the practice of solving them as data problems — with a pipeline, not with headcount.
What the role owns
The data layer
Which accounts and people exist in your world, where they came from, and whether the record is still true. Sourcing, enrichment, verification, dedupe, refresh.
The decision layer
Which of those rows deserve time and money. Scoring, filtering, gating, routing. This is where most of the value is, and where most teams have nothing at all.
The execution layer
What actually leaves the building. Sequences, CRM writes, alerts, digests. GTM engineering does not write the message strategy — it guarantees the message has real evidence to draw on and reaches the right person while the reason is still true.
Notice what is missing: quota, positioning, pricing, brand. Those belong to sales and marketing. The engineer’s job is to make the system underneath them fast, cheap and correct.
How it differs from the adjacent roles
| Role | Optimizes for | Typical artifact |
|---|---|---|
| RevOps | Process integrity and reporting | Clean stages, accurate forecast, working CRM |
| Demand gen | Volume and cost per lead | Campaigns, channels, budget allocation |
| SDR / AE | Conversion on the accounts in front of them | Conversations, meetings, pipeline |
| GTM engineer | Throughput of the system that feeds all three | Automated pipelines that produce contactable, qualified, timely rows |
The overlap with RevOps is real and it is fine. The practical split: RevOps owns what happens after a lead is in the CRM; GTM engineering owns everything that gets it there and everything that decides it was worth getting.
On small teams one person does both. The distinction still matters when you are debugging — a broken forecast is a RevOps problem, an empty list is a GTM engineering problem, and treating one as the other wastes a week.
The four questions
Every build in this library, whether it takes ten minutes or a quarter, starts by answering these. Answer them badly and the workflow will be expensive, brittle, or both.
Who counts?
Not “mid-market SaaS.” Something a filter can evaluate: headcount range, geography, funding stage, a tool in the stack, a role that exists on the team page. If a criterion cannot be checked without a human reading a website, it is not yet a criterion — it is a hunch. Lesson 05 splits these into attributes and signals.
Why now?
The reason this account is worth contacting this week rather than any other week. A funding round, a hire, a product launch, a champion changing jobs. Workflows without a “why now” produce lists that are technically correct and commercially dead.
What do I need to know?
The minimum evidence needed to write a message that could not have been sent to anyone else. Usually two or three facts. Teams routinely enrich fifteen fields and use two of them — you pay for all fifteen.
How do they get reached?
Verified work email, mobile, LinkedIn, or a CRM record that routes to an owner. A perfectly qualified row with no contact path is a row you paid for and cannot use. Lesson 08 counts these honestly.
Worked example
A team selling a developer tool answers the four questions like this:
| Question | Answer |
|---|---|
| Who counts? | 50–500 employees, uses a competing CI tool, has an engineering org above 20 |
| Why now? | Posted two or more platform/infra roles in the last 30 days |
| What do I need to know? | Which competing tool, how many infra roles, the role title of the likely owner |
| How do they get reached? | Verified work email for the engineering leader, LinkedIn as fallback |
That table is already a workflow design. Reading it top to bottom: source companies on the firmographics, check the stack, check the job posts, gate on both, then find people only at the survivors and get emails for them.
The ordering is not incidental. Every cheap check runs before the expensive one — the principle lesson 06 formalizes.
Do this now
- Pick one workflow your team currently does by hand and hates.
- Answer the four questions for it in a table like the one above. Write real values, not categories.
- Mark any answer you cannot check without a human reading something. Those are your research steps — Research & Web Scraping handles them.
- Ask your MCP client to run
check_credits, or open Credits, and note your starting balance. Lesson 08 uses it.
Keep the table. Lesson 10 turns it into a full system design.
Check your work
- Every “who counts” criterion could be evaluated by a filter or a single enrichment
- Your “why now” is an event with a date, not a standing condition
- Your “what do I need to know” list is three facts or fewer
- You named a specific contact path, not “we’ll figure out outreach later”
Where this breaks
The most common failure is answering “why now” with something that is always true — “they’re in our ICP,” “they use HubSpot.” That is an attribute, not a trigger, and it means your list has no natural ordering and no expiry. Every account looks equally urgent, so nothing gets worked. If you cannot name an event with a date, your first build should be a signal workflow rather than a list build. See Signals & ABM.
Further automation
Once the four answers are stable, the workflow that produces them is worth scheduling rather than running by hand. A weekly re-run of the same four criteria is how a list stops being a project and becomes infrastructure. Lesson 07 covers what that re-run must not break.
Next lesson
02 — The data model: rows, columns, actions, where the four answers become a table structure.
Reference for this lesson: Core Concepts, Tables, Credits, Signals.