I want to make a prediction. I think two years from now, there will be a job title at most B2B SaaS companies with more than 200 employees that doesn't widely exist today: Head of GTM Engineering.
Not RevOps. Not Marketing Ops. Not Sales Engineering. Something different that absorbs the architectural questions none of those functions were built to answer.
Let me explain why I think this is coming.
Right now, most enterprises that have started building skills, agents, custom GPTs, and AI workflows inside their GTM motion are running into the same wall. The skills work individually. The agents work individually. The workflows work individually. But they don't compose.
A skill that scores deal risk doesn't know about the skill that drafts follow-up emails. The agent that generates competitive battle cards doesn't talk to the agent that surfaces them in flow. The workflow that triggers a coaching moment after a discovery call doesn't know which content the rep is sending into the deal afterwards. Each piece optimises its own loop. Nothing optimises the whole.
Three months ago I would have said this is a tooling problem. We need better integration, better APIs, better connectors. Now I think it's an architecture problem. And architecture problems require an architect.
Here's what I think a GTM engineer actually does.
This is from watching the work emerge inside customer accounts and inside our own team, not from a job description anyone has written yet.
They own the skills hierarchy. Which skills exist in the org, what they do, who built them, who maintains them, how they version, how they retire. The same way a DevOps engineer owns infrastructure. The same way a Salesforce admin owns objects and workflows. Skills are the new object.
They own the interdependencies. When skill A invokes skill B, which invokes skill C, the GTM engineer is the person who can draw the diagram and explain what happens when one of them changes. They prevent the silent breakage that happens when someone in the marketing team updates a skill and breaks an analysis the RevOps team relied on.
They own the orchestration. Which skills run synchronously when a trigger fires. Which skills run autonomously on a schedule. Which skills get parameters from elsewhere. Which skills feed their outputs into downstream skills. The whole flow has to compose into a coherent revenue motion, not just a collection of clever individual functions.
They own the volume questions. When the CRO asks for an analysis across 1,000 calls, the GTM engineer is the one who knows whether the architecture supports it, what the memory management implications are, where the analysis might lose quality, and how to design the run so the outputs are trustworthy.
They own the boundary with traditional engineering. They're not data engineers. They're not backend engineers. They're not ML researchers. But they can talk to all three and translate to business stakeholders. They're the diplomat between the technical infrastructure that makes agentic AI work and the GTM functions that consume it.
The closest analogy I can find is the Sales Engineer role that emerged in the 2000s. Pre-2005, most B2B SaaS sales motions tried to sell complex products without a technical translator on the team. The result was deals that closed and then died in implementation because the buyer and the vendor never really understood what was being built. The Sales Engineer emerged because the gap was real.
GTM Engineering is the same shape of gap, one layer up. The complexity is no longer in the product. It's in the operating layer above the product, where skills and workflows and agents compose into a revenue motion. Someone has to architect that. Right now, in most companies, nobody owns it. Everybody assumes RevOps does. RevOps wasn't built for it.
If you're a VP of RevOps reading this, I'm not saying this is something you can't do. I'm saying it's an emerging discipline that probably deserves its own dedicated role on your team, with its own competencies, its own seniority track, and its own seat in architecture conversations. The same way you wouldn't ask your sales operations analyst to also run forecasting science, you probably shouldn't ask your operations generalist to also be the skills architect.
If you're an early-career analyst with technical interest, this is the role I'd be raising my hand for. It doesn't formally exist yet. It will. The people who define it now by being good at it before there's a job description will own the discipline.
If you're a CRO or COO, this is a hire I'd start scoping in the next four quarters. Not urgently. But thoughtfully. The teams that have it in 2027 will have a structural advantage over the teams that don't.
Categories form when the work emerges before the role does. Customer Success was a feeling some companies had in 2010, and a discipline most companies hired for by 2015. RevOps was a job at maybe forty companies in 2015 and is a function in thousands today.
GTM Engineering is the next one. I'm naming it early so the people doing the work have something to call themselves.
.png)
