A GTM engineer runs three stacks at the same time: a technical stack for building, a commercial stack for choosing what to build, and a communication stack for getting it adopted. Job postings back this up. In Steven Moody's analysis of 433 GTM engineer postings, the most requested technical skill was APIs at 59.4%, ahead of SQL (47.3%) and Python (44.6%) — and collaboration (54.6%) and communication (52.2%) were requested about as often as the code (Steven Moody).
This article maps the full stack, shows how often each piece is asked for, and — more usefully — names the artifact that proves you have it. Claims are cheap in a field this new. Artifacts aren't.
In short
- Technical core: APIs and data structures, CRM architecture, automation, applied AI, SQL. Depth grows with the seat you want.
- Commercial core: ideal customer, funnel math, unit economics, prioritization. Clay's guide calls commercial judgment the thing that separates a GTM engineer from a generic automation person (Clay).
- Communication core: translation, documentation, stakeholder management, saying no.
- Every skill has a proof artifact. If you can't produce it, you can't claim it.
- Tool count is not skill. Moody found pay flat across every level of AI demand in postings, which is a strong hint that buyers are paying for judgment and outcomes, not tool logos.
Layer 1 — The technical stack
| Skill | How often postings mention it | What it really means | Proof artifact |
|---|---|---|---|
| APIs, webhooks, JSON | 59.4% (Moody) | Read docs, authenticate, send and receive payloads, handle pagination, retries and idempotency | A working integration you built without a native connector, with the payload documented |
| CRM architecture | Salesforce 68.4% (Moody); HubSpot 52%, Salesforce 45% (Bloomberry) | Objects, fields, stages, validation, ownership, what breaks downstream when a stage changes | A field and stage map for a real CRM plus one documented cleanup |
| Data and SQL | SQL 47.3% (Moody); 38% (Bloomberry) | Joining, deduplicating, aggregating, and checking whether a number is trustworthy | A query that answers a revenue question, with the assumptions written down |
| Enrichment and data quality | Clay 42.9% (Moody) | Waterfalls, coverage vs. cost, verification, knowing that providers disagree | A verification sample: 25 rows checked by hand, with the error rate before and after |
| Workflow automation | n8n 25.5% (Moody); Zapier 39%, n8n 28% (Bloomberry) | Triggers, branching, rate limits, retries, and what happens when a step fails at 2 a.m. | A screenshot of your error-handling path, not your happy path |
| Applied AI | LLMs 30.3%, agent building 19.6%, prompt engineering 10.9% (Moody) | Prompts as specifications, structured outputs, evaluation, limits on what AI may do | An evaluation table: 30 outputs, scored, with the prompt change that improved them |
| Scripting | Python 44.6%, JavaScript 27.9% (Moody); Python 38% (Bloomberry) | Small transforms, scripts, glue code; not application development | A short script that does one transform a no-code step couldn't |
Two observations from that table. First, APIs outrank every language, because most of this job is moving and reshaping data between systems that were never designed to talk to each other. Second, the two datasets disagree on frequencies (different samples, different periods), which is a good reminder to treat all of these as directional.
Depth requirements vary by seat. Moody classifies postings into pure and embedded software engineering (together 33%), RevOps operator (36%), outbound/growth (22%) and data/analyst (8%). Decide which seat you want before deciding how deep to go — that choice, not the tool list, is what moves compensation, as we cover in GTM engineer salary.
Layer 2 — The commercial stack
This is the layer most self-taught builders skip, and the one hiring managers complain about. Clay's guide is blunt that commercial judgment — knowing whether a workflow actually helps close deals — is what separates a GTM engineer from a generic automation person (Clay).
| Skill | What it means | Proof artifact |
|---|---|---|
| Ideal customer definition | Telling which accounts actually pay, not which ones fit a slide | A one-page ICP written from closed-won data, with the counter-examples |
| Funnel math | Conversion rates per step, cycle time, cost per stage, what a point of improvement is worth | A completed revenue leak map with volumes and money at stake |
| Unit economics | Cost per enriched record, per call, per meeting; when automation stops paying | A build's cost model, all-in, including your own time |
| Prioritization | Choosing the smallest system with the largest effect, and saying no to the rest | A ranked backlog where the ranking rule is written down |
| Experiment design | Baseline, hypothesis, sample size, decision date | One experiment write-up, including a result that disappointed you |
| Domain fluency | How the business actually makes money and what its customers care about | Notes from three customer calls, summarized in the customer's language |
A fast self-test for this layer: pick any system you have built and answer, in one sentence, what would have to be true for this to have been a waste of time? If you can't answer, you built on instinct.
Layer 3 — The communication stack
The frequencies here surprise people: collaboration 54.6%, communication 52.2%, cross-functional work 41.1%, stakeholder management 40.6% (Steven Moody). GTM engineers sit between sales, marketing, ops and engineering, and none of those groups will read your canvas.
- Translation. Explain a system to a non-technical owner in five sentences: what was broken, what you built, what changed, what it cost, what's next. Proof: a one-paragraph result summary a stakeholder forwarded to someone else.
- Documentation. Write so the system survives your holiday. Proof: a runbook another person used successfully without asking you a question.
- Stakeholder management. Get the CRM admin, the sales manager and the data owner to agree before you build. Proof: a one-page build agreement with named owners and a decision date.
- Saying no. Protecting a roadmap from the loudest request. Proof: a documented decision to not build something, with the reason.
- Teaching. Reps adopt what they understand. Proof: a three-minute walkthrough video.
How the three stacks get tested in hiring
Clay describes its own assessment for the role in three parts: a business problem investigation, a systems sketch, and a mini build challenge; it lists the qualities it looks for as technical fluency, commercial bias, curiosity and an experimental mindset (Clay). That structure maps exactly onto the three layers above, and it is a good way to rehearse: given a messy revenue situation, can you interrogate it, sketch a system, and build a small working piece?
Bloomberry's posting analysis adds the market context: an average of 4.11 years of experience requested, with the most common route in being SDR/BDR, then RevOps and sales ops (Bloomberry). If you are coming from outside those paths, artifacts are how you compensate for the years.
The MitHub skill audit
Score yourself 0–3 on each skill above, using this rubric. Be strict; the point is to find the next thing to learn, not to feel good.
| Score | Meaning |
|---|---|
| 0 | I have not done this. |
| 1 | I followed a tutorial or did it once with help. |
| 2 | I did it unsupervised on a real problem, and it worked. |
| 3 | I did it on a real problem, it worked, someone else depends on it, and I can show the artifact. |
Then apply three rules:
- Nothing counts without the artifact. A 3 with no evidence is a 1.
- Fix the lowest score in the layer you're weakest in, not the one that's most fun. Builders default to deepening technical skill because it feels productive; the missing rung is usually commercial.
- One skill per month, with a real deliverable. Twelve artifacts in a year is a portfolio.
This maps onto MitHub's capability ladder: Doer (executes tasks by hand) → Director (directs AI and systems, judges output) → Designer (designs the systems) → Owner (owns the business result). Scores of 2 make you a Director. Scores of 3, across all three layers, make you a Designer heading for Owner.
Skills that matter less than the internet suggests
- Collecting tools. Five platforms at score 1 is worth less than two at score 3.
- Prompt cleverness. Prompt engineering appeared in only 10.9% of postings in Moody's analysis, and pay was flat across AI demand levels. Specification and evaluation beat phrasing tricks.
- Certificates without systems. In this field, evidence of a working build is the credential.
- Speed for its own sake. Sending more messages faster is not engineering; it is volume, and it degrades the asset you're sending from.
Where to start
Pick the seat you want, audit yourself honestly, and close one gap at a time with a real deliverable. If you are early, the highest-leverage sequence is: APIs and JSON → CRM structure → one automation platform → one enrichment platform → SQL → applied AI with evaluation. The commercial and communication layers develop in parallel, through real problems and real stakeholders.
MitHub's Faculty of Revenue Reverse Engineering is built around exactly that loop, free: follow the money to build commercial judgment, prove value fast to choose the smallest useful system, and your case study to turn each build into the artifact that proves the skill. For the step-by-step career path, see how to become a GTM engineer; for the day-to-day, what does a GTM engineer do.