How we built Clay’s GTM engineering function

And how to do it yourself

How we built Clay’s GTM engineering function

Today’s post comes from our head of GTM engineering, Everett Berry who breaks down our Clay’s GTM engineering function was built and currently operates.

Most companies treat GTM operations as a support function. Someone to clean up Salesforce data, set up sequences, maybe build a dashboard or two. At Clay, we took a different approach from the very beginning.

At Clay, GTM Engineering sits at the core of how we run go-to-market. The team reports directly to our co-founder Varun, alongside the first line of leadership below the founders. They operate like a product engineering team, with sprints, version control, and release notes. And they’ve automated large parts of our sales process while maintaining the systems that power both our self-serve and sales-led motions.

Here’s how we structured it, why it works, and what we’ve learned building GTM infrastructure at scale.

Two types of GTM Engineers

We split GTM Engineering into two distinct teams:

• Forward-deployed GTM Engineers work directly with customers. They help prospects evaluate Clay, scope implementations, and build out their specific use cases. Many came from rev ops or growth roles before joining Clay.

• Internal GTM Engineers build and maintain all our internal operations. This team operates under Osman Sheikhnureldin and handles everything from deal automation to QBR generation to partnership workflows. They serve our customer experience team, marketing, growth, and partnerships. This is the team most people think of when they picture “ops.”

Both teams could probably swap roles if needed. The main difference is temperament. The more engineering-minded people gravitate toward internal infrastructure. The folks who like podcasts and customer conversations end up forward-deployed.

The tech stack

Our internal team runs on four core tools: Clay, Snowflake, Salesforce, and Gong. Slack rounds out the stack as the actual interface our GTMEs use day-to-day.

We built a Slack app that GTMEs interact with for most of their work. They can trigger campaigns, view signals, get pre-call research, access post-call meeting notes, and send follow-ups. All without opening another tab. The internal GTM Engineering team maintains this application using Clay’s human-in-the-loop workflows deployed to our Slack instance.

The simplicity matters. Most companies end up with 15+ tools in their GTM stack. We’ve kept it tight, which means less integration work and fewer places for things to break.

The philosophy: flexibility within standards

We let GTMEs use whatever meeting tools work for them. Some people run Gong and Granola simultaneously. Some use Attention for their personal notes. The meeting tool space moves fast, and different people have different preferences that will shift and evolve over time. We find that dictating exactly how people should work ends up leaving potential advantages on the sidelines.

We do have one hard requirement: the data has to flow into Clay.

For example, Gong always runs because it pipes into our automation infrastructure. But if someone wants to layer Granola on top for their own note-taking workflow, that’s totally fine—as long as the transcript and key information ends up where our internal GTM Engineering team can transform it in Clay, people have flexibility to experiment.

If you do nothing outside the core tools, you should have a great experience. But since we’re Clay, you should also be able to experiment with new tools that you find interesting.

Operating like an engineering team

The internal GTM Engineering team works in two-week sprints. Other teams across Clay submit tickets for things like automation requests, data quality fixes, or new workflow needs. The team triages these tickets, bundles them into releases, and ships twice a month with full release notes.

They version control their work. The Clay tables and workflows themselves get treated like code. They maintain documentation. When evaluating new vendors (we’re looking at AI sales coaching tools right now), they run the technical evaluation and handle integration.

This structure solves a problem most ops teams face: the endless queue of one-off requests. By batching work into sprints, the team can focus on larger infrastructure projects while still handling the daily asks. And by publishing release notes, the rest of the company knows what’s shipping and when.

What GTM engineers actually build

The automation we’ve shipped falls into a few categories:

• Content generation: Our growth strategy team (post-sales) gets handoff decks automatically generated when a deal closes. We pull credit consumption data from Snowflake, call recordings from Gong, and account information from Salesforce. All of that gets formatted into a Google Slide deck that publishes itself before the kickoff call.
  
  We do the same thing for QBRs now. The deck builds itself from usage data and conversation history. The growth team just shows up and presents.
  

• Follow-up automation: After discovery calls, the system drafts follow-up emails based on the call transcript. We’ve mostly solved this problem at this point.
  

• Signal-based workflows: External GTMEs get notifications in Slack when accounts hit certain triggers. Product usage patterns, intent signals, contract milestones. The Slack app surfaces these moments and prompts the right action.
  

• Pipeline operations: All the standard stuff around lead routing, data enrichment, territory assignment. But because the team operates in sprints with clear prioritization, this work doesn’t crowd out the higher-value automation.

The next frontier is harder. Moving from a pretty good follow-up email to a great follow-up email, and doing that consistently over a multi-month sales process while building a comprehensive deck as you go is a 90th-to-95th percentile problem. So is doing something like taking information from multiple calls and turning it into proposals, one-pagers, case study drafts that actually sound like they came from a human who understands the customer’s business. We’re working on all of that right now.

Why this structure works for Clay

Clay is roughly 50/50 self-serve and sales-led. That split creates complexity.

On the self-serve side, everything runs through pure automation. No human touches these deals until they’re ready to expand. On the sales-led side, we have a traditional enterprise motion with forward-deployed GTMEs, discovery calls, multi-threading.

A lot of top-of-funnel activity for our sales-led business actually happens in our self-serve customer base. Someone starts using Clay on their own, gets value, then brings it to their company. The internal GTM Engineering team owns the systems that identify these expansion opportunities and route them appropriately.

This means they can’t just focus on supporting the sales team or the growth team. They need to maintain infrastructure across both motions and build the connective tissue between them.

Right now, moving customers from self-serve to sales-led isn’t as smooth as we’d like. That’s a major company priority. The fact that one team owns the systems on both sides makes that transition easier to improve.

Applicability outside tech

People assume Clay only works for tech companies doing PLG motions, but consider this: Waste Management uses Clay. They’re completely outside our usual world of SaaS and tech buyers. But the use case was rock solid. The flexibility of the platform means GTM Engineering as a discipline can work across different industries and sales models. You’re not locked into one type of motion or one type of buyer.

The reporting structure

Internal GTM Engineering reports to Varun, our co-founder and head of ops. They sit alongside executives running major functions, not buried under a VP of Sales or inside a rev ops org.

This matters for prioritization. When the team that builds your GTM infrastructure has a direct line to founder-level leadership, they can make architectural decisions without getting stuck in departmental politics.

We don’t have a traditional CRO structure at Clay. There’s no single leader with sales, marketing, post-sales, and ops all reporting up through them. Revenue ownership is more distributed. The growth team owns self-serve. The sales team owns sales-led. GTM Engineering facilitates both.

That structure works at our current scale (around $100M in revenue). As we grow into a couple hundred million, we’ll probably need to consolidate under a CRO or adopt something like Stripe’s multiple-CRO model. But the GTM Engineering function will likely stay close to the top of the org chart regardless of how we restructure around it.

RevOps vs GTM Engineering

We still have a RevOps function, but it’s split between GTM Engineering and finance.

Finance handles forecasting, sets pipeline targets, and owns quarter-over-quarter sales planning. They work with GTM Engineering to align on the numbers and set targets across the organization.

Anything involving systems, data quality, or automation lives with GTM Engineering. Territory carving, sequence deployment, dashboard creation, tool evaluation.

It’s a matrix structure. Pipeline targets are set by finance but delivered through combined efforts from growth, marketing, and GTM Engineering. The internal GTM Engineering team facilitates the execution. This setup works because both teams have clear swim lanes. Finance focuses on what the numbers should be. GTM Engineering focuses on the infrastructure that delivers those numbers.

Tools beyond the core stack

The internal team uses Clay, Snowflake, Salesforce, Gong, and Slack for most of their work. But we’ve layered in some AI tools that have proven valuable:

• Dust acts as an agent layer on top of our company information. Notion, Gong, Salesforce, all of Slack. People use it for Q&A about internal processes, past conversations, and customer context. The feature we use most is Slack search with references to other conversations.
  
  We’ve started migrating some common Dust queries into Clay workflows. Once we see patterns in what people ask, we’ll automate those specific questions. But there’s still a long tail of ad-hoc questions where Dust shines.
  

• Crosby handles our contract redlines. They do the first pass on every legal negotiation. In many cases, deals close without ever escalating to our legal team. We’ve cut redline response time from days to hours.
  
  The Crosby team has done impressive work making LLMs reliable for black-and-white legal language. No hallucinations, no made-up clauses. Getting that level of reliability for legal documents is harder than it looks.
  

• Granola and Gong both run on calls, depending on what team members prefer. Gong is standard across the company (it feeds into all our automation). Some people layer Granola on top for personal note-taking. We’ve given teams flexibility to use what works for them, as long as the data ends up in Clay where the internal GTM Engineering team can transform it.

The sequencing challenge

We’re experimenting with Clay’s native Sequencer for lower-volume, high-touch messaging. It’s not ready for 50,000+ emails per month yet, but for the messages that matter—strategic outreach, expansion plays, partnership development—having everything end-to-end in Clay removes a lot of friction.

For high-volume outbound, we use Gong Engage. Their new API changed how we think about sequences.

The new Gong Engage API lets you customize every message and subject line in a multi-step sequence with a single API call. You can create a fully custom sequence per contact. Not template-with-variables custom. Actually custom.

For GTM engineers, this is a step function improvement. You can pull data from anywhere, generate fully personalized messaging using LLMs, and deploy multi-touch sequences without template constraints. We use this API internally at Clay, and it’s available as an action in Clay for customers building their own workflows.

Where deals actually happen

Here’s something that doesn’t show up in Salesforce: most of our executive-level sales happen over iMessage.

Our sales process is designed to find the executive buyer and get their phone number. Then someone from leadership—myself, our sales lead Becca Lindquist, or our co-founders Kareem and Varun—texts them directly. We schedule calls, negotiate terms, and close deals over text. One of our largest deals this year happened entirely over Slack DMs. Also not synced to Salesforce.

This creates a gap between our automation infrastructure and where work actually happens. The systems are built around email, Salesforce, and Gong. But real conversations happen in iMessage, WhatsApp, Slack DMs.

We haven’t solved this yet. It’s manual. I add contacts to my phone, copy in their number, send texts from iMessage on my laptop. None of it syncs back to our systems.

The same thing happens with Slack. Slack is a Salesforce product, but Slack DM conversations don’t flow into Salesforce records. There’s infrastructure work to be done here, and whoever figures out the DM channel problem will unlock a meaningful advantage.

When to hire a GTM Engineer

If we were starting from scratch today, the first GTM hire would be a GTM Engineer. Before the first AE. Definitely before building out a full rev ops team. (And if you’re curious, we have an entire guide on how to hire a GTM engineer here.)

How to hire a GTM Engineer

You’d pair them with a founding AE and either a solutions engineer or a former customer who knows the problem space. Then you’d hire an outbound agency to handle volume. That team could do real damage finding early signal and building the foundation for scale.

The first project for that GTM Engineer: build the golden list.

This is the set of accounts where, if you got a magical intro tomorrow, you’d be thrilled. Each account has the right contacts, with up-to-date information, and clear reasoning for why it made the cut.

Most companies don’t have this. They start selling, build up a messy account list, and then six months later when they need to do territory carving, they realize they don’t actually know how to structure their market. You end up with duplicate accounts, unclear segmentation, and territories that make no sense.

Starting with clean account architecture makes everything easier as you scale. You know your segments. You know your ideal customer profile. You can build territories logically because you understand the shape of your market.

The iterative nature of GTM Engineering is most valuable early. You can try different approaches every day without fighting through tech debt or organizational inertia. Later, the function is still critical, but you’re engineering around constraints instead of building in a green field.

What’s next

We announced several new products at our Sculpt conference. Sculptor, the native Sequencer, Audiences. A lot of that functionality is still rolling out to customers, which means the internal GTM Engineering team is actively building the workflows that take advantage of these new capabilities.

Content generation is the current frontier. The gap between a good follow-up and a great proposal that synthesizes months of conversation is where we’re pushing.

And we’re watching the sales interface space closely. The world of external GTMEs toggling between eight Chrome tabs is ending. What replaces it will probably be some single pane of glass that agents and ops teams can orchestrate behind the scenes. We’re building toward that future, even if we don’t know exactly what the final interface looks like.

The core thesis

GTM Engineering works at Clay because we treat it like engineering. Clear ownership, sprint-based delivery, version control, release notes. The team has space to build real infrastructure instead of fighting fires.

The reporting structure gives them authority to make architectural decisions. The tech stack stays simple enough that they can actually understand the full system. And the work they do—generating decks, automating follow-ups, routing signals—directly impacts revenue in ways everyone can measure.

You don’t need to be a data platform company to run this playbook. You need to believe that GTM infrastructure deserves the same rigor you’d apply to product engineering. And you need to hire people who can build, not just administer.

Start early. Keep the stack tight. Give the team real engineering practices. Let them sit close to the top of the org chart.

That’s how you build GTM infrastructure that scales.