A HUGE thank you to everyone who attended our latest Sessions…with scale event: GTM Engineering & Signals: The 2026 GTM Playbook! 

This one brought together GTM, RevOps and Sales people for an evening of honest conversation, shared stories, and a lively, question-heavy discussion on how teams are actually building smarter, more connected GTM motions as we head into 2026.

“GTM Engineering” has quickly become one of the most talked-about ideas in modern go-to-market. But with more channels, more data, and increasing pressure to move fast without breaking everything, it’s also one of the most misunderstood.

Which is exactly why GTM Engineering isn’t a trend. As Joe framed it at the start of the panel, it’s a response to growing complexity.

With that in mind, here are the six biggest takeaways from the night:

1. GTM Engineering isn’t really new – it’s an evolution

GTM Engineering didn’t emerge because someone invented a new job title. It emerged because go-to-market has become more complex at an extremely fast rate. This means teams are dealing with:

• More channels

• More data

• More tools

• More pressure to act on signals in real time

Tools like Clay (which popped up a lot during the discussion) may have popularised the term, but the underlying work has always lived at the intersection of RevOps, Growth, Sales enablement, and data.

What’s changed is the scale at which teams are now expected to connect all of it – and do so without slowing the business down.

At its core, GTM Engineering today is about three things:

• Capturing signals (intent, behaviour, timing)

• Designing systems (CRMs, enrichment, routing, automation)

• Activating insights so those signals actually change how teams behave

As Hannah Ajikawo (CEO & Founder of Revenue Funnel) pointed out during the discussion, this is similar to how “growth hacking” eventually became growth teams. 

This wasn’t a term that needed to be invented, but here we are. And the job didn’t change overnight; the expectations did. GTM Engineering is simply the evolution of building and connecting data, technology, and process to support growth in an increasingly complex environment.

Takeaway #1: GTM Engineering is less about a shiny new role and more about the skill of connecting data, technology, and process to drive growth.

2. Whether it’s a role, skillset, or mindset depends on your stage

A big talking point for the evening was whether GTM Engineering should be:

• A dedicated role

• A shared skillset

• Or a mindset embedded across teams

The consensus: it depends. 

For Hannah, GTM Engineering is better thought of as a skillset, with a strong emphasis on restraint. Many teams, she noted, are still working out their fundamentals, and adding technical complexity too early can do more harm than good.

But James Falconer (Global Director of Business Development at Encord) offered a different perspective. At Encord, GTM Engineering is both a mindset and a skill. People come in with a way of thinking – how to spot signals, connect systems, and ask better questions of data – and then develop the technical skills to take that thinking further.

What emerged from the discussion was a clear pattern. For early-stage teams, there’s a tendency to absorb GTM Engineering as a capability spread across RevOps, Growth, and Sales leadership, whereas more complex organisations are starting to justify clearer ownership and specialisation.

Takeaway #2: GTM Engineering isn’t something you “install.” It’s something you grow into – shaped by company stage, volume, and complexity.

3. Signal-led GTM is becoming table stakes – but only when it’s justified

A key question from the panel was whether GTM Engineering is now simply how GTM teams have to operate.

As AI, automation, and tooling accelerate, go-to-market is becoming more technical by default. As Hannah noted, teams that don’t adapt risk missing key moments, particularly around intent, timing, and handoffs. But that doesn’t mean everyone should rush to over-engineer their stack.

Signal-led GTM only becomes table stakes once there’s enough volume, clarity, and repetition to justify it. As Joe pointed out, not every organisation has a reason to double down on GTM Engineering yet. The real risk isn’t not doing GTM Engineering; it’s doing it without a clear purpose.

Takeaway #3: GTM teams need balance. Technical GTM is increasingly powerful –  and in some cases inevitable – but knowing when to invest, and where to draw the line between useful engineering and over-engineering, matters just as much.

4. The real impact shows up in behaviour, not dashboards

When the discussion moved from theory to results, James shared how GTM Engineering has delivered impact in practice and why that impact often comes from access, not perfect systems.

He described an example from earlier in his career where progress came from giving a colleague access to experiment with a new GTM tool. Rather than rolling out a fully designed workflow, the goal was simply to test, learn, and see what was possible.

That moment captured a broader theme. GTM Engineering tends to work best when teams are able to create, drag, drop, and experiment themselves – rather than waiting for centrally built logic to be pushed into the business.

Importantly, this wasn’t about removing structure. James was clear that guardrails still matter. The mindset he described was closer to an engineering or QA function: encourage experimentation, share learnings, and put basic checks in place to avoid chaos.

The biggest changes showed up in behaviour:

• Teams moved faster because experimentation wasn’t blocked

• Ownership increased because people helped build what they used

• GTM Engineering became a way of working, not another layer

Takeaway #4: Real GTM progress is driven by how teams behave day to day, not just what the dashboards show.

5. What’s actually working right now is far less sophisticated than it sounds

When the conversation shifted to what’s working in practice, the tone changed noticeably. The reality check was simple in that most teams just need better basics.

Across companies, the patterns that stick tend to start in the same place:

• A clear ICP

• A coherent overall GTM and marketing strategy

• Alignment on what success actually looks like

As Hannah shared, many organisations are still fixing fundamentals before they ever layer in data or automation. Without that foundation, even well-designed signal systems struggle to deliver value.

A useful framing that resonated with the room was starting with first principles:

• Who are we trying to reach?

• When is the hardest moment in their journey?

• Where do we already have leverage?

• What problem are we trying to solve?

Only then do signals become meaningful. Simple behaviours (like downloading content or attending a high-intent event) can be effective if they’re clearly understood and passed on in a way Sales can act on.

More advanced approaches (such as granular or custom lead scoring) came with an important caveat: generic benchmarks rarely translate well. What works tends to be bespoke, shaped by a company’s stage, motion, and constraints.

Takeaway #5: GTM Engineering compounds what’s already working. Without strong foundations, sophistication quickly turns into noise.

6. Winning in 2026 will come down to adaptability, not perfection

Looking ahead, the panel agreed that “good GTM” in 2026 won’t be defined by the most complex systems – but by how quickly teams can adapt.

The panel highlighted the growing importance of understanding the agentic AI landscape and knowing how to integrate it into teams without losing trust or control. 

A strong GTM capability will be:

• Agile

• Willing to experiment

• Able to spot pattern interrupts early

James echoed this in the final segment on experimentation, sharing how leading teams are testing new signals, workflows, and structures –  including ideas that wouldn’t have felt safe or feasible just 12 months ago.

But we’re still learning how to measure success in systems that learn over time. Quit too early, and you risk missing the payoff. 

Takeaway #6: Preparing for 2026 means building GTM systems that can change direction quickly – and improve over time.

Final thoughts

What made this session special wasn’t just the panel; it was the room.

The small, engaged audience turned the discussion into a genuinely collaborative exchange – with people openly sharing what’s worked, what hasn’t, and what they’re still figuring out. Less theory, more reality.

If there was one meta takeaway, it’s this:

GTM Engineering isn’t about building the “perfect” system. It’s about building the capability to change direction, fast.

Thanks again to Hannah, James, and everyone who joined us. We’ll see you at the next one!