Insights

April 29, 2026 | Blog

Your stack is connected. Your revenue isn’t moving. That’s the GTM engineer problem.

B2B organizations approved the AI budget, bought the tools, and assigned the initiatives. Then pipeline results stayed flat, AI projects stalled in implementation, and signal data piled up without anyone confident enough to act on it.

The tools aren’t the problem. The design is. The work of connecting how signals get enriched, how workflows fire, how AI outputs route into the systems sales and marketing already use—that work falls between existing roles. Nobody fully owns it. And that gap is where GTM results break.

The GTM engineer is the role built to own it. For most B2B organizations, that role is understaffed, assigned to the wrong person, or missing entirely. The organizations that have filled it are already rearchitecting at a pace their competitors cannot match.

The gap between signal and action is where organizations are losing

Buyers now complete the majority of their evaluation before they want to talk to anyone. Revenue teams responded by adding more tools to detect and act on that activity earlier. The result, for many organizations, is a stack generating more data than anyone can confidently interpret, running on workflows no one fully owns.

Gary Survis, Operating Partner at Insight Partners with oversight of more than 500 portfolio companies names the problem thus: data has exploded, and that explosion has not made it easier to act on. “That doesn’t mean people know what to do with it,” Gary observed.

Access to signals is not the edge. Any organization can access signals. The edge belongs to teams that build context from multiple signals, enrich that context, and orchestrate it into precise workflow action. Most organizations have cleared the first hurdle. Almost none have consistently solved the second. Layering more tools onto that gap does not close it, but adds cost and complexity to a design problem.


Why AI initiatives stall and what that reveals about the GTM engineer role

The typical pattern you may recognize: leadership identifies an AI opportunity, a tool gets approved, someone gets assigned to implement it, and the project bogs down because the person tasked with implementation understands the business but not the platform, or the platform but not the business process it needs to serve.

Patrick Spychalski, Co-Founder of The Kiln, recently acquired by 2X, explains: “AI implementation is otherwise pretty much impossible unless you have somebody who understands these tools and is orchestrating this. You can’t just give it to a project manager or a director, because they’ll have to essentially learn all the tools first before even coming up with a semblance of a plan, and the plan falls through completely if the capabilities of the tools cannot match it.”

Gary reinforces the same point from the board level. Organizations desperate to show AI progress handed the initiative to whoever seemed curious, someone who loves tinkering with tools but doesn’t understand business process mapping. “It’s like an organization demands a structured approach,” Gary noted. “If you want impact and you want it quick, you better make sure you’re bringing the right resources to bear against the problem.”

That is a capability problem and it is the exact problem the GTM engineer role is designed to solve.

What a GTM engineer does

The GTM engineer’s mandate is not defined by platform expertise. It is defined by finding where friction lives across sales, marketing, and customer success, and then designing the system that eliminates it by:

  • Mapping how data moves between platforms
  • Identifying what to build first
  • Doing the hands-on work of connecting tools, configuring pipelines, and routing outputs into the systems the team already uses.

Patrick made one principle clear from The Kiln’s implementation work: the GTM engineer’s work should be invisible to the end user. When The Kiln implements Clay for a sales team, Patrick’s team tells the sales reps they will never see it. The output lands in Outreach and Salesforce. The rep just notices cleaner data and better reach. That invisibility is the signal the system is working and the hallmark of a well-orchestrated revenue engine.

How the GTM engineer differs from existing operational roles

The GTM engineer is not a replacement for RevOps, sales operations, or marketing operations. Those roles do essential work. The distinction is in mandate. Operational roles are typically measured on governance, execution quality, and stability. The GTM engineer is measured on continuously redesigning and evolving the system itself.

RolePrimary mandateCore activities
Revenue operationsGovernance and cross-functional alignmentReporting, pipeline hygiene, platform administration, performance tracking
Sales operationsSales team efficiencyCRM management, quota setting, forecasting, enablement support
Marketing operationsCampaign execution infrastructureAutomation platform management, data segmentation, attribution
GTM engineerRevenue system design and continuous evolutionWorkflow design, AI implementation, tooling evaluation, signal infrastructure orchestration

Most organizations have project managers, but not someone combining technical tool judgment with business process mapping.

Gary described it as “someone who’s tech savvy enough to understand which tools to leverage where. And you need someone who knows business process optimization and workflows and how to map those out. Those are not native skills in most organizations.”

A modern GTM strategy now requires someone who can turn strategy into systems, not just plans.

Build internally, hire externally, or both

Most organizations reach the same decision point: build GTM engineering capability internally, engage an external partner, or do both. The right answer depends less on preference than on speed requirements and on how realistic you are about what your current team can absorb.

Model Best fitStrengthsLimits
Internal hireTeams building long-term capabilityDeep business context, sustained ownership, ongoing iterationSlower ramp, harder to hire for a blended skill set
External partnerTeams that need speed and specialized executionFaster implementation, broader pattern recognition, flexible capacityLess embedded context over time
Hybrid modelTeams modernizing while protecting internal focusImmediate momentum plus durable ownership; capacity that flexes as requirements shiftRequires clear role boundaries and governance

The organizations moving fastest do not choose between internal and external. They subscribe to embedded capacity immediately and recruit internally in parallel. The external partner creates momentum and upskills whoever will own it long-term. The internal hire builds context and sustained ownership. Neither replaces the other. The work simply exceeds what one person can manage alongside normal execution demands.

“We often beg clients to hire GTM engineers,” Patrick explained. “There’s so much work to be done. It needs to be sustained.” What clients discover, almost without exception, is that after hiring internally, they keep the external engagement running anyway. The internal hire sees the volume of work. The external partner brings cross-company pattern recognition no internal hire can replicate: access to what is working across dozens of other organizations right now.

This is the argument for treating GTM engineering as a subscription-based operating capacity rather than a staffing project. The organizations winning are not hiring for today’s workload. They are subscribing to an embedded GTM engine that flexes as requirements shift because the requirements will shift, often before the previous hire is even fully ramped. While their competitors debate the build-vs.-hire question in planning sessions, these organizations have already moved six months ahead.


The organizations that win are the ones that never stop

Growth no longer breaks only at the campaign level or in the sales motion. It breaks in the handoffs, the workflow logic, the data movement, and the gap between what the business wants to do and what its systems can support.

Gary painted a picture of the competitive reality: “Organizations that are going to be most successful are going to embrace that we are in a new era of continuous transformation. There is no sitting on your laurels. There is no, ‘I’ve solved this problem.'”

The tools will keep evolving. The model that treats GTM engineering as a one-time project rather than a permanent, orchestrated capability will find itself starting over every cycle.

The title is still settling across the market, whether it’s GTM engineer, AI implementation lead, or revenue systems architect. The label matters less than the need: someone has to own the capability-building that modern GTM demands.

The companies orchestrating that capacity now, while others wait for the role to standardize, are already rearchitecting for AI at scale. Their competitors are still in planning sessions.

If your team has the stack but not the operating model to turn it into results, the GTM engineer is the gap to close first. 2X delivers that GTM engineering capability as a subscription-based embedded team. One accountable partner, variable capacity, no headcount request required.


This article draws on a conversation between Gary Survis, Operating Partner at Insight Partners with oversight of 500+ portfolio companies; Patrick Spychalski, Co-Founder of The Kiln, recently acquired by 2X; and Debbie Murphy, Global Head of Brand and Communications at 2X. The discussion explored why AI implementation stalls without the right operating role, how the GTM engineer function is emerging across B2B revenue teams, and what the build-vs.-embed decision looks like in practice. Watch the full strategic discussion here.

Recent posts

The intent data trap: Why signal abundance is making GTM harder, not easier

Blog

The intent data trap: Why signal abundance is making GTM harder, not easier

Orchestrating your revenue system for the modern B2B buyer journey

Blog

Orchestrating your revenue system for the modern B2B buyer journey

The shift from MQL to ABX in modern B2B

Blog

The shift from MQL to ABX in modern B2B