← back

GTM Engineering: The Technical Bits — Everett Berry, Clay

1.8K views · Aug 26, 2026 · 19:04 min · Watch on YouTube ↗
Takeaway

Fast GTM execution depends on trustworthy, continuously maintained data and robust orchestration across fragmented tools.

Summary

  • GTM engineering applies software delivery practices to data, automation, and campaigns so commercial teams can ship changes at engineering speed.
  • Account and contact records must reflect changing company hierarchies, firmographics, technology usage, and sales interactions.
  • Waterfall enrichment queries multiple data vendors because no provider offers complete coverage; provider evaluations and entity resolution maintain accuracy.
  • Orchestration must reconcile real-time events, bulk updates, selective refreshes, and failures across CRMs, warehouses, sequencers, dialers, and other tools.
gtm-engineeringdata-enrichmentorchestration
Original description
Ask one data vendor for phone numbers across a set of countries and you get about half of them. Hence waterfalling: layer provider on provider until the field is filled, and run evals to know which to trust. Everett Berry's tour of the hard parts of GTM engineering starts with data, because the goal is a perfect virtual copy of your market and accounts refuse to hold still. A company gets acquired, opens offices, ships products, hires and fires while your own team markets and sells at it, and each of those changes the record. Refreshing everything is expensive when you buy the data, so you pick which fields update and how often.

Orchestration is the second problem, and it is data engineering. Berry usually finds teams running twenty or thirty tools whose views of the world disagree: some need one record in real time, others hundreds of thousands nightly; employee count moves constantly, headquarters almost never. Worse, those tools sync to each other behind your back, so a contact created in the CRM must reach the sequencer before you can act on it. Clay's answer is a graph of general purpose nodes: agents, tool calls, conditionals, code, and a map reduce fan out. Third is agents, one per account, dormant most of the time, woken by a trigger, holding state across a deal cycle of weeks. Fourth is execution, where the constraints turn human. Send as the rep and a campaign that lands badly burns your domain reputation, so you spread across domains and then route the replies home.

Speaker info:
https://x.com/retttx
  / everettberry  
https://retttx.com

Timestamps:
0:00 - What GTM engineering is, and why the role exploded
2:59 - Data, and why accounts never hold still
4:51 - Waterfalling across hundreds of vendors
6:19 - Orchestration across twenty or thirty tools
7:37 - Different systems, different refresh needs
8:27 - When your tools sync behind your back
9:05 - A graph of general purpose nodes
10:23 - One long running agent per account
14:39 - Execution, and the domain reputation problem
17:12 - Q&A: the hardest part is the human interface