GTM Engineering AMA Recap #1: How Clay builds GTM systems at Clay

Alex Lindahl | GTM Engineering — Sun, 30 Aug 2026 12:01:47 GMT

New here? Hi, I’m Alex Lindahl, Creator in Residence at Clay.

Join 8,300+ GTM operators from OpenAI, Reddit, a16z, Figma and some of the fastest growing companies who are a part of the community.

Hey GTM Engineers & Operators,

A customer recently asked me, “how does Clay figure out what GTM systems and workflows to build next?”

It hit me. I couldn’t answer the question as well as before. Clay grew from less than 30 to over 500 colleagues in ~2.5 years. A LOT has changed since the OG days where everyone knows everything that’s happening. Every quarter we are forced to rethink how we build to support the next few months of rapid growth.

This question paired with “how does Clay do GTM engineering” left me wanting a better resource to provide customers & ya’ll. So, I hosted the a Reddit GTM Operator’s AMA and invited Spencer Chemtob, who’s one of our internal GTM Engineers, to answer these questions and others from the community.

Below is a recap of the first one, How Spencer Chemtob builds GTM systems at Clay to scale from $25M to $250M?

What is Reddit GTM Operator’s AMA?

Every week, one operator, founder, or builder opens the floor to real questions from the community. No fluff. No vendor pitch. Just the actual thinking.

AMA insights

How does Clay decide what its GTM engineers should build?

Spencer’s team tries not to operate like a reactive service desk. Instead of waiting for sales, marketing, or post-sales to file one-off requests, his engineers sit with those teams and watch for problems that keep showing up.

When the same need appears across two or three groups, that repetition is the signal to build something reusable rather than another point solution. His example: pre-meeting notes for post-sales teams. Instead of a separate workflow per function, Clay builds one shared foundation and personalizes the output per user. This is how we reduce redundant builds. Read the full answer →

Where should someone new to GTM engineering start?

It’s counter intuitive, but don’t start with a tool. Spencer’s advice is to pick a functional specialty (marketing, sales, data, RevOps, growth) and learn which metrics actually matter, how they move, and what levers control them.

In his view, this is what separates automation from engineering: automation finishes a task, GTM engineering ties a task to a business outcome. The best practitioners can explain why a system should exist before they touch how to build it. Full answer →

Should you start with CRM cleanup?

Spencer’s answer was close to no. A broad cleanup can burn months with no clear line back to revenue.

His suggestion: figure out first where the company is winning and losing. Once you know which segments, signals, or behaviors correlate with success, clean the CRM data that supports those specific findings. You don’t need to do the whole database. And the data you need might not even live in the CRM; it could be sitting in product usage, seller notes, call transcripts, or enrichment sources. Pull that, show sellers what you found, form a thesis, and let the system catch up as evidence builds.

If you want the unedited back-and-forth, the whole thread is worth the scroll: r/gtmengineering AMA with Spencer Chemtob.

What does Clay’s GTM data architecture actually look like?

Clay joins CRM and product-usage data into shared audiences, segmented by deal stage across objects. Those audiences feed an orchestration layer: land in a stage-two opportunity and you might enter a targeted ad audience; hit stage three and a Slack notification pings a sales leader to help the rep multithread the account.

Spencer’s framing: this is the shift from static lists to active audiences that respond as an account’s context changes, not just when someone remembers to update a field. Full answer →

How does Clay keep AI-assisted outreach from sounding like AI?

Agents can automate the research. They pull ICP signals, reverse-engineer prospecting triggers, find lookalike accounts, and can match each one to a use case or customer story. Spencer’s point is that none of that should show up in the message itself. Prospects clock generic AI output instantly, so what reaches the inbox should be a short, specific line, not a paragraph of synthetic personalization.

Clay also caps daily send volume per inbox and pays for verification when sending from its own domains. Better data doesn’t buy you out of deliverability discipline. Full answer →

How do these systems get maintained once they’re live?

Every six months or so, Spencer’s team runs a formal review: each system gets rebuilt, reimagined, or explicitly signed off as still fit for purpose. Growth changes what a system has to handle (more data, more headcount, more product complexity) and last year’s fix tends to break again in a new shape.

The number that stuck with me: only 15 to 20 minutes of his typical day goes to maintenance. Not because nothing breaks, but because maintenance gets designed into the system up front instead of becoming a permanent fire drill. Full answer →

What actually kills a GTM play?

Three patterns, by Spencer’s account:

The audience is too small to produce a real sample
It’s sliced into so many microsegments that the results stop meaning anything
Everyone else in the market starts running the same play, and the edge disappears

His fix: start with enough volume to actually learn something, segment once patterns show up, and retire a play the moment it stops converting instead of letting it quietly burn through the addressable market. He also pointed out that the best plays run always-on in the background — success stops depending on convincing every rep to adopt a workflow, because the system is doing the work for them. Full answer →

Excerpt from our sister publication, The GTM Engineer by Clay.

How should GTM engineering performance get measured?

Clay’s GTM engineering org sits across multiple revenue functions on purpose, so the line between GTM engineering, marketing ops, and sales ops stays blurry. Spencer measures stakeholder satisfaction and how much low-value work gets eliminated; for growth-facing teams, pipeline generation still matters most. He also flagged a subtler signal: whether the team finds creative, responsible ways to say yes to real business needs instead of defaulting to gatekeeper mode.

An insight that might surprise you: Clay keeps CRM writes deliberately thin. Routing might touch one or two fields. An inbound conversion can justify 30 to 40 enrichment fields. Records get re-enriched at real touch points, with a full refresh roughly every 90 days.

What’s actually worked?

Chemtob’s favorite build is natural-language audience building, which lets sales leaders pull their own audiences and reports without filing a ticket. This collapses the loop between a leadership question and an answer. Close behind it: social listening tied to ad retargeting, so someone who shows up on a platform gets advertised back to in that same environment. Further down funnel, product-usage analysis feeds expansion plays. Taken together, it’s a reminder that GTM engineering isn’t just a prospecting discipline. GTM engineering touches acquisition, pipeline, expansion, and almost any leadership initiative related to growing the business.

👇 Cont’d reading on my learnings from inside Clay:

Next AMA: how to build a $1M solo AI GTM agency

Event details:

Where: r/gtmengineering
Date: Wednesday, Sept 2
Time: 12pm EST
Who: , a former VP RevOps and founder of RevOps Impact, an AI GTM agency. Jeff is also the author of (one of my most recommended newsletters).

Want your question answered?

Comment on the post and I’ll be sure to include it!

The GTM Engineering Newsletter: Reddit AMAs w/ GTM Operators