Focal

Clay pioneered GTM engineering and went from $1M to $100M in ARR in 2 years.

I talked to the person who invented the role of GTM Engineer at Clay.

Yash Tekriwal, Clay’s first GTM engineer - back when the $3B company was still figuring out what that even meant.

What started as one person drowning in too many jobs (RevOps + Sales + BDR + data analyst) has since become a new category that’s now reshaping how startups think about go-to-market.

Here are 6 lessons from my conversation with Yash - listen to the full podcast episode here:

1. What is a GTM Engineer

A technically skilled role that blends data engineering, systems thinking, and go-to-market strategy to design and execute growth at scale. It emerged at Clay around August 2023 when Yash was tasked with simultaneously handling CRM maintenance, inbound scoring, deal tracking, sales playbook creation, and selling - work that would normally require a RevOps person, a sales engineer, and an AE combined.

Key distinction from RevOps: RevOps is fundamentally a maintenance function - keeping the ship running, managing forecasting, territory planning, and data hygiene. GTM engineering turns ops from a support function into a growth engine by adding experimentation capabilities.

As Yash frames it: RevOps is “keep the plane flying” while GTM engineering is “constantly innovating to stay ahead of the market.

In practice today, GTM engineers are deep experts at tools like Clay and can “vibe code” prototypes even without a coding background. The role has evolved from its original sales-heavy definition to more commonly being a blend of RevOps + data analytics/engineering + growth hacker.

Clay’s CEO calls it “the first true AI-native profession” - the role only exists because AI and automation tools have collapsed the manual work that used to require three separate people.

2. Treat GTM like a product

GTM Engineering is “treating GTM like a product - with releases, analytics, and automation at its core.”

Product teams have to be collaborative. You can’t have engineers working on the same codebase without talking to each other. The changes one person makes affect everyone else.

Sales has historically worked the opposite way. Everyone does their own thing. But when you think of GTM as a product, suddenly your salespeople become product managers. They’re on the front lines, collecting feedback from customers. And your GTM engineers are the ones building systems to act on that feedback.

This reframing matters because it changes who owns experimentation. In the old model, experiments happened randomly across twenty salespeople, and you couldn’t tell if results came from the experiment or from individual charisma.

In the new model, you deploy changes systematically and actually measure what works. GTM is constant experimentation.

3. Two ways to organize GTM engineering

Centralized Hit Team:

All the feedback from sales, marketing, and customer success flows into one group of GTM engineers. They prioritize based on business impact, deal size, velocity improvements. Then they work through the list.

This is how Clay operates. Every morning, their salespeople get a Slack digest with pre-call research—who they’re meeting, what the company does, relevant signals, even recommendations on which demos to show. One central team built and maintains that system.

Embedded engineers.

Instead of one team serving everyone, you assign GTM engineers to specific functions. One person works only on education systems. Another works only on marketing workflows.

The tradeoff is obvious:

Centralized teams get pulled toward sales and enterprise because those dollars are most visible. Marketing and education struggle to get resources.
Embedded engineers lose visibility into the whole organization. They’re deep in their silo but disconnected from everything else.

Here’s the practical advice: if you don’t know which to pick, start centralized.

It’s easier to peel off and embed someone in a specific team later than to consolidate embedded people into a central function. Centralized is also simpler, and it forces you to prioritize across the whole company rather than letting each team optimize locally.

4. In GTM Engineering, the only limit is your creativity

A Clay customer recently figured out how to estimate warehouse staffing capacity by analyzing Google Maps satellite images. They looked at how many trucks were parked at a warehouse during operating hours, used that to estimate total frontline worker capacity, then used that in personalized outbound.

That’s not in any playbook. Someone just got creative about what data they could find and how to use it.

I’ve seen similar creativity in healthcare, where people estimate hospital bed availability by analyzing floor plans and booking sites. And in education, where people parse publicly available government budget documents that no one else wants to read.

The pattern is always the same: there’s valuable information sitting somewhere public, but it’s too tedious to gather manually. AI web scraping makes it possible to automate what used to be impossible.

And the more personalized and insightful the outbound message is, the higher the odds of success.

5. Don’t automate the important stuff

This sounds contradictory, but it’s crucial. Early on, you want to automate the boring manual work. But you don’t want to automate away the value of actually seeing your data.

At Clay’s early days, they had a Slack channel dumping every social mention. Nobody could read every thread. But they tried to read as many as possible. They had another channel showing every product signup. Early on, someone looked at every single person who signed up, and if the domain looked interesting, they emailed them within seconds.

That’s not scalable. That’s the point. The most valuable thing you can do early is stay close to your customers. You can automate the aggregation of information, but don’t automate away the processing of it until you’re big enough that you have no choice.

6. The best GTM engineers are “figure-outers”

Here’s something counterintuitive: software engineers are often not the best fit for GTM engineering. They tend to be really good at one specific tool or language but struggle to translate those skills to new systems.

The best GTM Engineers are tinkerers. They’re always playing with new tools. They have “shiny tool syndrome,” which is both good and bad. But if someone is constantly asking what’s on the cutting edge, that’s a strong signal they’re good at picking up new things.

Specifically, look for people who are experts in no-code tools like Zapier, Make, or Bubble. Look for data analysts who think from first principles. Look for CRM admins who’ve learned to solve boring problems in systematic ways.

The pattern is flexible computational thinking. You want the person who, if they don’t know how to do something, will research it, ask questions, and figure it out.

Subscribe now

Enjoyed reading this?

Then check out my conversation on the focal podcast with Clay’s First GTM Engineer and now Head of Education with Yash Tekriwal

Youtube | Apple Podcast | Spotify