The first thing I do on a new engagement is export the CRM property list and sort it by fill rate. It takes ten minutes, and it usually settles the argument about whether the company has a marketing problem.
It almost never does. It has an engineering problem that nobody was hired to solve.
What is GTM engineering?
GTM engineering is the practice of designing, building and maintaining the systems that run a company's go-to-market motion, with the same rigour an engineering team applies to production software. The data model, the pipeline architecture, the automations, the feedback loops.
It treats revenue as a system with inputs, transformations, outputs and failure modes. And it treats the stack the way you would treat a codebase: versioned, tested, documented, owned by someone with a name.
If you write software for a living, here is the translation table I use with engineering leaders:
| Software engineering | GTM engineering |
|---|---|
| Schema design | CRM object model |
| Data pipeline | Lead to opportunity to revenue flow |
| Observability | Pipeline metrics, leading indicators |
| Tech debt | Property sprawl, duplicate records, dead automations |
| Incident postmortem | Lost-deal and churn analysis |
| CI/CD | Campaign launch process |
The mapping is literal, and it explains why so many GTM stacks fail in ways any engineer would recognise on sight.
The failure mode that has no name on the revenue side
Run the export I described above on your own CRM. Sort by fill rate. Count how many custom properties sit under five percent. Then ask three people on three different teams what "qualified" means, and write down the three answers.
You now have the two measurements that describe most B2B revenue stacks I open. A schema that was never designed, only accumulated, one campaign and one departed employee at a time. Deal stages named years ago by someone who no longer works there. Definitions that live in people's heads and disagree.
Engineers have a word for this. Tech debt. Revenue teams do not have a word for it, so they buy another tool, which is roughly like fixing a broken schema by adding a caching layer.
The cost shows up as leakage at the joints. Handoffs that drop leads, stages that hide stalled deals, attribution gaps that send budget toward channels that are not working. I wrote a longer breakdown of where those leaks hide in revenue leakage: how architecture gaps cost B2B companies growth. The short version is that the money disappears where the system has no seam to catch it, which is never where you go looking.
Three layers, in order
When I rebuild a go-to-market motion, I work in three layers, strictly in order. Skipping ahead is the most common mistake and the most expensive one.
Layer 1: the blueprint, schema before software
Before touching any tool, you need a designed data model. What objects exist, what states each can be in, what event moves it from one to the next. This is schema design, and everything downstream inherits its quality. A CRM built on a bad object model is a database with a UI, and every report you run on it is fiction with formatting.
Layer 2: the execution system, pipelines rather than heroics
Once the model is right, automate the transitions. Routing, enrichment, stage progression rules, handoff triggers. The goal is boring: no revenue-critical step should depend on someone remembering to do it. This is where you recover most of the manual work tax, and it is also where automating chaos becomes tempting. Automating a design and automating a mess look identical in a project plan.
Layer 3: growth R&D, observability and iteration
Then instrumentation. Leading indicators, not only lagging ones. Cohort views, not only snapshots. The test is simple: when a metric moves, can you answer "what changed and why" within an hour? If not, you have a dashboard, and a dashboard is decoration.
Why AI made this urgent
Everyone is bolting language models onto their GTM stack right now. Agents that draft outreach, score leads, summarise calls. The results are bimodal in a way that has nothing to do with the model anyone chose.
Companies with a clean data model and defined processes get compounding leverage, because the agent has real state to read and real actions to take. Companies with undesigned stacks get confident nonsense at volume, because the agent is reasoning over sediment.
An agent reading a CRM with three definitions of "qualified" will pick one, apply it at machine speed, and never mention that it chose.
Which makes this discipline the prerequisite for the whole AI-in-revenue wave rather than a nice-to-have for scale-ups.
Where you stand
Five questions. One point for each confident yes.
- Could a new hire learn your pipeline stages and their exit criteria from documentation rather than from a colleague?
- Do marketing, sales and customer success agree in writing on the definition of a qualified lead?
- If a deal has been stuck for 30 days, does the system flag it, or does a human have to notice?
- Can you trace any closed deal back to its first touch without opening a spreadsheet?
- Has anyone deleted an automation or a property in the last quarter? Deletion is a sign of ownership. Sprawl is a sign of abandonment.
Zero to two: you are running on heroics, and your growth ceiling is your team's stamina. Three to four: you have a system carrying debt, which is normal and fixable. Five: your next lever is AI leverage, not headcount.
The structured version of that diagnostic is free at artefactventures.com, along with the frameworks I use in client work. Most of it has no email wall, because I would rather you use it than bounce off a form.
The part that is uncomfortable
The companies winning right now are the ones whose revenue motion behaves like well-run software. Designed schema, automated pipelines, observable state, and agents operating on top of all three.
That is GTM engineering. It is learnable, and if you already understand systems and how companies make money, it may be the most underpriced skill set of the next five years. I say that as someone who spent a long time being told this work was administrative.
Over the next three months I am publishing a series here that goes layer by layer. The CRM data model that ends data silos, what agents actually need from your stack including the MCP server I built for it, attribution as data engineering, forecast accuracy at the schema level, and finally how to simulate a go-to-market motion before spending on it.
Follow along if that intersection is your thing. And if you are staring at a stack that matches the failure mode above, that is the work I do.
I am a revenue operations consultant at Artefact Ventures. I write about the engineering underneath revenue.
Top comments (0)