E45: The inside scoop on GTM engineering with Clay's Everett Berry

Hello and welcome to the Revenue Leadership Podcast by Topline. I'm your host, Kyle Norton, CRO at Owner.com, and every Wednesday we dive deep into the strategies and tactics being used to drive success by the best revenue leaders in the world. So join me as I sit down with revenue operators to discuss actionable frameworks that you can implement in your business today with no fluff, no sales pitches, and no platitudes.

If you're measured on pipeline, win rates, and forecast accuracy, listen up. When your product doesn't show up until the second or third sales call, you lose momentum and deals. Walnut fixes that. Gives your reps interactive demos they can personalize and use early so every buyer sees a consistent story every time. The result? Faster cycles, higher conversion from demo to op, and better forecasting based on real product engagement. Measurement, not guesswork. You ramp reps faster and close more without adding SE headcount. Go to walnut.io and hit the Get Started button to see how you can turn revenue targets into reality with the team you already have.

Today's guest is Everett Berry, who is the head of GTM engineering at Clay. Uh, everybody listening should know what and who Clay is. They're the, uh, vanguards of the GTM AI movement in many, many ways, massively successful in the space, growing like crazy with marquee investors like Meritech, the best of the best. I say that because there we go. Kerlin's on our board too, and we're big fans. And Everett, who's been at the company for a little over a year, comes from a pretty unique background, having started his career as a software engineer, CTO, CEO, then he was a growth leader, uh, and now is running sales and revenue. You can explain what the head of GTM engineering is, uh, Clay, but appreciate you joining me today and I'm excited for this one.

Thanks, Kyle. It's super nice to, uh, to be on. I, I feel like my career is a bit, uh, varied in terms of background, but actually a lot of it leads into this GTM engineering thing. So started out with my own company. We were basically analyzing foot traffic in retail stores. We were actually building cameras and installing them in the ceilings of retail stores. And so very kind of heavy technical work. Unfortunately, I learned the hard way that if you have no go-to-market plan, you really cannot make progress no matter how cool your tech is. So that's kind of what happened with Perceive. But after that, I had the good fortune to begin to work in these different operator roles. And in fact, what actually happened, and this is kind of, I like telling the story for folks that are too worried about career planning, is I joined my friend's company to help him basically close out his seed round and do the sort of paperwork for it and some of the operations around hiring people and setting up a company. And I was doing that while I was shutting down my previous company. And we had hired this great growth guy named Derek who was great. He wrote a lot of the initial content for us. He was successful in terms of driving the numbers up. And then a couple months into the role, he just like left and we didn't hear from him for a long time. In fact, I was trying to text him to like roll over his 401(k) and so forth. Turned out he became a contestant on the CBS reality show Big Brother. And the reason he wasn't responding to me was because they take your phone. And then on that show he met his now wife and the two of them won The Amazing Race like 2 years later. And so, Um, and so that is why I am in growth. Um, and, um, and at Archetype, it was actually successful. We, we grew the user base quite a bit. The company was acquired by ClickHouse. Um, and I joined a cloud cost company called Vantage where we were trying to target engineering leaders to help them, uh, save money on AWS effectively. And I learned a lot of great techniques doing that. One of them was Clay. So I found Clay. I heard about it, um, at this like Brooklyn growth meetup in like early 2022, and I used it to enrich GitHub repositories to figure out what companies were using specific kinds of Kubernetes technologies. And then we would outbound those companies and their leader, their engineering leadership, very targeted messaging. And that worked insanely well. Um, in fact, that was like a hugely successful, uh, set of campaigns for us. I ran those continuously. Automated big parts of it. And in doing that, I got to know the Clay team really well, um, and eventually ended up sort of leading what is effectively our sales team at Clay. Although to kind of, um, to kind of speak to your initial point, we follow the same like forward deployed AI engineer model that a lot of AI companies follow. And so my team of go-to-market engineers are people that go into customers and help them basically scope and implement Clay. And because Clay is a consumption product, it's a no-code product, and it's a product for basically ops folks and expert-level users, that has turned out to be the right setup for us. But we didn't know that a year and a half ago. And so when I joined, it was very much like, hey, let's just go help people build stuff in Clay, which, since I was already doing that for 2 years, was a really good fit for me.

So never led a sales team before you become the head of this one at Clay?

That's right. Yeah. And in fact, um, in fact, Clay is actually hiring a real sales leader who starts very soon, which I'm quite excited about because as we've gotten to a certain scale, there's— you, you could probably know this better than most. Uh, there's these thorny organizational problems that come up that I could really use someone to, uh, to help me, help me solve. So, um, so, so we are, we are kind of like headed in that direction, but the core of it still remains like. You, you gotta help users build stuff in Clay. You gotta scope them correctly on the number of credits that they need. And then, you know, when they get in there, they, they gotta see results. You gotta see pipeline numbers move up. You've gotta see, you know, data, data costs go down, systems get simplified. If those things aren't happening, then you've, then, then we haven't really succeeded as a, as a team.

Yeah. And this is the Palantir model, you know, like that's right. Embed, embed an engineer in the customer. Have them build things and, and, uh, create value and good things, good things will happen.

Yes. In fact, we have go-to-market engineers at Clay who are kind of real go-to-market engineers that are internal and they build our scaled-out pipeline generation systems. So we consider calling our team for deployed go-to-market engineers, but then we kind of thought that was getting a little lengthy. So, um, so yeah.

Yeah, it's, uh, back in the day Shopify chose to call its sales reps sales hackers. And, uh, that was cute and funny for a while. And then we're like, let's just call them account executives.

Yeah.

Yeah.

And you know, I could see, I could see a couple evolutions of what we have today, but 30, 30 people later and 5 go-to-market engineering teams later, it is working for customers. So we, um, if anything, we're thinking about how we can scale this model more for longer.

Yeah. Yeah. And I mean, for a product with such depth and, you know, it's no-code, but still quite complex. There's just, you know, you can go as deep and as sophisticated as you want with it. That model makes a lot of sense. And I think where sales is going in general, you know, that is a very sensible approach. If it's consumption-based and if it, it, it, you know, the success of the company is driven by, uh, the success of your customers. Like it's a, it's a very modern, modern take on it, which is awesome.

I do think there's a lot of work in the sales process that is more or less, um, things like asking for updates and, and it should be possible in the near future to have more of like an expert level salesperson that is just surrounded by automation, which does a lot of that grunt work for them. In fact, today we do things like we do pre-call research for all of our accounts. We automate the follow-up. We even automate the Salesforce stage update, which is a little bit of an interesting, interesting thing. But we don't do all of the kind of routine stuff we could do. But I think we'll, we, I think, I think we might actually get there soon. And, and you know, if you're just kind of proactively suggesting next steps to your sales reps and, and it's defined based on the, process that you run and you know how that works, then actually the sales rep maybe doesn't need to be as sort of like med pick oriented. They can really focus on deep product knowledge. Um, that, that's a hypothesis that still needs to be kind of tested broadly in the market, but it does feel like that's where things might be headed.

Yeah, it's, it's interesting because it feels like it's going to go one of two ways. Either you automate a bunch of that stuff and then, you know, the product expertise and the subject matter expertise matters. Or you end up delivering the subject matter expertise to people through, you know, an AI solutions engineer, somebody who knows everything you could possibly know about the product and the customer base, and, and which is sort of impossible to replicate. And then the job of the rep becomes more sales-centric and more relationship-driven. And, and, uh, I don't have a strong sense on where we're going. We're doing similar things. Automating as much of the groundwork as humanly possible, um, through a set of different tools. So I think we see the world fairly similarly.

Yeah, there is a, yeah, there is a counter narrative here. Uh, for example, Jason Lemkin would tell you that actually what you just said is, is the right vision of the future. Um, that there will be these, these like sales engineer companions on sales calls with just friendly, um, you know, uh, helpful, helpful sales reps. I'm, I'm probably a little more in, in my camp and, and your camp on more of an expert person. Um, but I do see, I do see some companies actually, for example, um, working on hiring SDRs once they have exhausted their sort of like auto outbound channels. Um, you can think of some companies that are famous for outbound that are actually doing that. Um, and so, and so it is, um, it is a space where I think like the further removed you are from what's actually happening on the ground with the field, the, the, it's much harder to make like projections about what's gonna, what's gonna play out. I actually think something like engineering and writing code is easier to kind of reason about with where AI capabilities are than something like, something like sales.

Yeah, very true. Um, so one of the, one of the things that was flying around Twitter and LinkedIn last year, or last week, was this MIT study. That said 95% of AI deployments are failing to produce ROI. And you sort of like start to pull it apart and it's a pretty selective sample and they're trying to grab a headline. And a lot of what was written about it was clickbaity in nature. And you and I both know a bunch of people that are getting tremendous amount of value out of their AI deployments. Both of our companies, uh, being, being good examples of that.

Yeah.

Where— why do you think companies are in this place where some of their deployments— and we can talk specifically about the, the GTM, um, deployments— are, are failing to maybe produce what was anticipated?

Yeah, well, a great example of this is the, as the AI SDR. Um, you know, that's not something that, um, most most folks are having success with. It is, it is working for some companies. Actually, most often what happens is it works for a while and then it, and then actually you end up in a place where you're, you're worse off than you were before because you, you've like crunched your domain and so forth.

Um, but you've burned your market, you've, you've hired them out, you know.

Yeah, but there's a couple things about AI SDR that it's like worth actually unpacking that because I think that speaks broadly to to challenges that folks are facing on other types of AI deployments. So one of them is, in my opinion, giving too much control and work to the AI. I actually think today's AIs, you have to prompt them incredibly carefully for them to kind of really capture all the context. You have to use these tricks like you have to tell them, hey, think about this for a while. Mm-hmm. You have to do stuff like this in order to make sure the model like really doesn't skip any steps. And so, um, a full end-to-end AI SDR, I think is a very tricky thing because, because typically there is a lot of hidden context in what an SDR is doing that, um, that is hard to capture. And it's much especially hard to capture if all you're doing is giving, uh, this kind of agent thing, a, a rough description of your ICP and the target account list and just telling it to, to go email folks, send emails, which, right, which, which to me is, is a recipe for disaster basically. Um, and like to give you an example of this, at my previous company, we, we learned a couple kind of subtle things about our customers that our SDRs were trained on that, that it's not clear to me that a, it would have to be a very carefully tuned AI SDR to capture some of this. So for example, um, we learned that when we were outbound engineering leaders, if the engineering leader came up through the kind of backend ops part of the organization, they were much more receptive to our pitch than if they came up from kind of like the, the frontend or like the app development side of the organization. If that was the single engineering leader, then we would actually go one level down and look for the kind of like backend DevOps leader and, um, and not worry about the, the VP of Eng. And so, um, and so the, if you think about the kind of like reasoning and steps that a model would have to take to to go through that, you would have to prompt it very specifically in order to do that. And you'd almost end up in a situation that looks more like, I think, what Clay is, where it's kind of this like human-in-the-loop, guess-and-check type setup where, where each step is actually like a, you know, there, there's more detail that's put into it versus kind of this like give an agent a task and have it, and have it go do it. And so, um, that's, that's sort of like one thing that I think is happening with these AI pilots is they're given they're given too broad a scope, which is a classic problem that even humans encounter. The other thing that I've observed is that people are expecting the AIs to do the wrong things. So I talk to customers who are like, okay, great, I'm sending all this messaging out from Clay. Now I want Clay to actually monitor the like replies and responses to this and adjust the messaging based on on the, you know, what's, when messaging is working. And my feedback to those folks is that I think that is actually putting AI in the wrong place. Um, I think you should use AI to generate the message, to, um, use the agents to help find data points in your accounts and contacts. Um, but you should not use agents to kind of like analyze a messaging campaign and then make adjustments to prompts to generate different types of messaging because there's so many factors that go into, um, that go into that messaging that a, that an AI is probably not aware of, including things like, you know, brand perception, product efficacy. Um, in many cases, like even things like history of the account might get lost. And so a really professional marketing demand gen person will do a much better job of taking an initial campaign and adjusting the copy on that than an AI. And so, um, and so anytime you're kind of introducing an AI into like a system that has a feedback loop, I actually think the, the back part of that should involve a human versus an AI. And I think that's another reason that like a number of these, a number of these pilots are failing. Um, and so yeah, so, so maybe this is kind of on us as an industry, but I think people are actually overhyped on what AI can do, and they're actually missing some of the very basic like data labeling, data cleaning, message drafting tasks that AI is really good at. They kind of don't seem like big picture high value, but when you start to stack up all the wins on those things, you actually get to a successful place versus some of these like agentic things that just are not, just are not fully baked yet.

Yeah. Yeah. And, and the, the agentic, and we're gonna get it deep into this, but the agentic stuff doesn't work without great data underlying it. Right. And, and so I have a half-written Substack post on this. And so it's, it's very topical. I'm curious to get your opinion. I think one of the main problems that people have is, is this issue of like much too broad of a problem to go solve. And so you're actually giving an AI multiple problems to solve at the same time without an intervening human in the loop or like deterministic step. And so I think the problem in, so in, in the more technical language, people call it lossiness. And so if you're taking like one set of prompts and handing it to another set of prompts or workflows and another one, well, every layer of that stack has some lossiness, you know, your, your ability to control and to direct and to be specific. Because this is generative technology, it's, it's, it's, it can go many different directions, which is strength and weakness. I find that the, when I see a demo of a really cool product that doesn't work in production, oftentimes it's because there's no deterministic checks and balances. There's no human in the loop in a chain of like multiple workflows or agents. And so a good example is like you see a product like, oh, all you have to do is like enter in your domain. And we'll find your target market and we'll come up with your positioning and we'll do this and we'll do this and we'll do this. Well, all of a sudden there's like slight hallucination invariance at each step. And then what you get out of it is just like slop. That's where the slop comes down in my mind versus like we are so thoughtful about what our positioning is at Honor with specific language and specific words. And we can be very semantic about it, but like the specificity around language matters. So I would never trust an AI tool to be like, oh yeah, just like type in your website and then give me the customer and I'll give you a target, like a target account plan. It's like, whoa, whoa, whoa, whoa, whoa. You know, like I want to say in the prompt, here's the specific, like, you know, this is the context engineering thing. I want to stuff that very specific context of how we position the words we use, the words we don't use, the tone of voice. And so that you're sort of engineering it that way. And this is like my observation. I'm curious to get your reaction though.

Yeah, well, I think that's true. And I think one thing that, one reason this happens is because the models are confidently wrong as well. And so if you get a confidently wrong output from one model and you feed that into another model, which kind of takes the prompt as gospel, then you end up with like a doubly confidently wrong output down. Down the line. And it's, I think a lot of us have had this experience where you are using a like ChatGPT and you can just ask it like, hey, is this right? And it'll actually be like, oh no, you're correct. Like this is— Oh wait, hold on a minute. Yeah, I actually had this experience. I was on the way, flew into Chicago to do a demo for a customer. I was in the Uber from the airport. I was trying to get this Gon Engage API to work. Gon has a brand new API for injecting custom messaging into Gon Engage, which we're all super excited about. And the first pass of the, um, you know, generate the, the POST request, like half the fields were just hallucinated. Uh, they were, they just didn't exist. And I actually had to point it to the URL of the docs where that happened. And I'd be like, please inspect this URL to actually do this correctly. And, and then it did it correctly. And so, um, and so, you know, when you're dealing with a system like that where not only can you, um, not tell sometimes if the answer is correct. Sometimes the model will like really convincingly tell you this answer is correct. And as a human, you're sort of like a trusting person and you believe it. And then you chain multiple of that together. That is, that is a recipe for, for disaster. And I, I give this advice to customers all the time, which, um, a lot, like one thing people try to do in Clay is they stuff a lot of context into one prompt. And I, I say, first of all, you know, break it up. And then as you're breaking it up, In Clay, there's, you know, the ability to, to create these web research agents, but then you can sort of like gut check them against the databases of data that Clay has. So you can gut check like, you know, revenue number from Clearbit against the revenue number that an agent kind of pulls from the web. And so this is definitely a best practice to kind of like get these models to, um, to, to perform correctly. There's also a ton of prompt engineering in here. If you, if you look at some of the prompt templates inside Clay, there's like multiple like checks and validation and, and things like this. And, and, you know, this comes back to my core argument of like, if you have a system where you really do have to constrain it quite strongly, um, in order to kind of make it perform right, then you really should wonder about products which hide some of that customization from you. Um, because, because, you know, you just don't know if all that is in the product or in you know, more commonly, you really can't say that, that it's being tuned to like your actual thing that you're trying to do. And my experience is like, is like, you know, the best prompts take multiple iteration loops, and that's just the state of the technology today. Um, the, the kind of the fun thing that we've done with this is we now have this meta prompter in Clay where you can give it this very general directive and then it will generate a prompt. But I advise customers not to take that prompt for gospel. I advise them to go through it and actually read it. And almost always when I do that, I fix a couple of things.

Yeah, yeah. Even for my podcast, you went through this flow that people fill out a tally intake form, which webhooks into my personal clay research table. And even with that, it took a bunch of different playing around with one person who I know well and sending it through a series of of the agents, one that looks at their background and summarizes stuff and one that looks at content. And then I put my own questions in and your answers go into it. But it took so many rounds of like, no, I don't want it to sound like that. And I go back and fix the prompt in the column and then like run it again and run it again. And just this, I felt like I was doing something silly. I was like, man, like I wish I was better at this stuff because I'm just like, trial and error, trial and error. And then I talk to AI people and they're like, no, that's sort of how you do it. It's in, you know, people call it the fancy word would be like evals. Like, do you have an eval for the output to measure if it's good? But it does feel like there is a lot more of this artistry that's needed and like a taste for it. Somebody, I was interviewing an AI lead candidate yesterday and he goes, you know, you just develop like a, there's like a mouthfeel to these things. And like, you just have a sense for like where Claude is good and where OpenAI is good or where ChatGPT is good and like a sense for like their relative strengths and weaknesses that you, you just have to be in the tools.

Yeah.

Yeah.

That, that's totally correct. And like a great example of this is my, my favorite sort of like, how should I get started thing is industry classification. So. You know, most companies have these like boutique industries that they think about when they think about their market. So for Clay, we take the entire tech market and we segment it into like a dozen different things. And then we take basically the whole rest of the business world and we kind of like, we, you know, there might be like financial services or real estate, but it's very broad. And that's because Clay's ICP right now is a lot of, you know, growth stage, growth stage tech companies. And, um, and so most customers, they, they just have the industries that they get from, You know, at a data provider, D&B or whatever, D&B or LinkedIn, and it's like telecommunications or telecommunications and internet, and it like doesn't really mean anything. And so what a great initial starter task for a lot of teams is just to correctly segment all the accounts in your CRM. And that's, that's an easy prompt too, because it's just like description of the company plus visit the website plus here are the categories of industries that we think about and how we, how we define them. And so I always recommend customers use ChatGPT for that. For whatever reason, I always find ChatGPT in terms of just like, let me bucket something into something, is, is really good. But then at the back end of that, you might actually want to, um, generate a message or something, or, or actually write some content. And I always, I tend to prefer Anthropic models for that.

They seem to be, yeah, same.

They seem to be, you know, um, a more natural in many ways they seem to kind of like be a little bit more like liberal arts of ChatGPT is like math and science.

And so, um, breath is what I say, right?

Right. And so what you say is, is totally correct. And, and, um, and it's, it's kind of the, like, it's kind of why I think this go-to-market engineer role is a legitimate role because this detail is just not captured in most other roles. Most RevOps, most sales ops folks aren't thinking about this and in many cases don't care to think about it. You kind of need these like automation people that are in these tools and keeping up with the models and understand how to prompt GPT-5 differently versus GPT-4. And those are the people that get a lot of these like 10x results that, that you kind of hear about. Um, but it, you know, for leaders or others listening to, to this, um, it's, it's just important to understand the details on these things. And, and we all know when go-to-market, the like, percentage point or like basis point differences in campaigns and throughout your funnel, like those actually are where the difference is in your entire business.

Are you ready to level up your go-to-market strategy for 2026? Then don't miss GTM 2025, the only B2B tech conference exclusively for go-to-market executives. Join 1,000 other revenue leaders this September 23rd to 25th in Washington, D.C. For an exclusive executive-only experience. This 3-day event is hyperfocused on connection, strategy, and execution. Expect hands-on workshops, in-depth strategy sessions, and curated opportunities to build relationships with VPs, CXOs, and founders facing the same challenges you are. You'll stress test your GTM approach, align your team, and leave with actionable insights from top-performing leaders. Don't miss the must-attend conference designed to help you boost your go-to-market results in 2026. Visit attendgtm.com. That's attendgtm.com to secure your spot today. And don't forget to use code Topline for 10% off your GA ticket.

Yeah. So, so I want to talk about the foundation. So like if I'm a, if I'm a CRO and I want to go on this like AI transformation journey. Everybody's talking about AI. I'm feeling left behind and I, I need to get started. What, what, and maybe we can break these into 3 categories, like infrastructure being one, people being one, and maybe strategy being the third. And, and if there's like another pillar of like GTMA Foundation, uh, throw it out there. So how, just at a high level, if you're talking to a CRO who's just starting on this on this journey, they've been under a rock for the last 24 months, how would you tell them to think about building this thing? Is like job one, hire a GTM engineer or what the people, people, infra and strategy?

I think job one is to get AI in the hands of as many people in the company as you can. Because if you just hire a GTM engineer, some of the things they're going to need to do are going to need to require kind of buy-in from others. And in my opinion, the easiest way to get that buy-in is to just buy, you know, 100 ChatGPT or Claude or, or, you know, whatever licenses for, yeah, for the sales reps, for the ops folks, um, and then for the CRO themselves. They should, uh, try to kind of use this for like meeting prep and quick research and so forth. Everybody should kind of gain a base level understanding of some of the, some of the capabilities. And then, you know, sales reps get, uh, a lot of flack these days, but, but usually within every organization you can find a couple of just insanely creative, um, really on top of it, on top of it sales reps. And they will actually come up with, um, Claude projects or custom GPTs or things that you will actually wanna look to for inspiration for things that you should think about centralizing. And so that's kind of like the next step. So step 2, in my opinion, is once everybody's got their hands on AI and you have some real usage going and you have some folks raising their hands saying, wow, you know, I just did this thing with ChatGPT that I used to spend 4 hours a week, you know, preparing for whatever this was, or, you know, like pipeline reviews. I used to spend an hour preparing for my pipeline reviews, and now I can just quickly get all the data that I need through, through some like MCP connection or something like that. Um, that's where you start to say, okay, my best people are doing this. Some of my most creative people, some of my most forward-thinking people, but what if I brought what they're doing and I actually just gave it to everybody and they didn't, but they didn't need to use the tools. They could just have it done for them. And that begins kind of the centralization journey where the go-to-market engineers get involved. And so that's where you start to buy, or, you know, and not to pitch Clay so aggressively, but you start to think about Uh, like orchestration tools or, or, um, AI agent tools or places where you can kind of stick one or two people in there and they can do things on behalf of everybody else. Um, and of course, like the most basic way to, to do this would be you could, you know, if you've got a contract with OpenAI for ChatGPT, you could add on an API key and have your organization do it. The problem with doing that is, you know, there's, there's really not a lot of tooling that is offered by the model companies for like for this. Uh, and so Clay, in my opinion, is actually kind of like this go-to-market development environment where you can plug in these models, you can try the different models, and you can get all the data you need and then begin to automate things on behalf of everybody else. And when that happens, you should see some like organizational shifts in, in metrics, in my opinion. Um, one of them should be just like number of leads worked. This is a classic one where If you're able to do research for everybody, then they should be able to work more leads and, and you should be able to look at that and say, okay, you know, we started with step 1, which was getting AI in everybody's hands. We then moved to step 2, which was centralizing this. Now we're kind of seeing the impact of step 2, which is we're starting to see some actual business metric changes. Of course, you could also look at things like pipeline. You could also look at headcount. You might see some, some headcount curves start to bend down if folks are able to work more leads and be more productive. And a company like ClickUp is a great example of this. I, um, I, I talked to their chief business officer about this just, just recently. And then, and then step 3 is to say, okay, the existing stuff that we're doing is better and automated and centralized, and we're serving that up for people. Now let's actually do some new stuff. And so this is where the, like, agentic workflows come in. This is where you might start to say, Okay, we're gonna build, you guys already heard my thoughts on AIs, but we're gonna build a sort of like agentic driven messaging system for inbound, or we're gonna build this like signal driven alerting system, or we're gonna build a like early alert deal is like trending negative system using on data and Salesforce and activity data and stuff like that. Those are net new things, net new capabilities that you can begin to add in. But I think where folks might make a strategic error is trying to add those on top of a bunch of manual processes with a bunch of people that actually don't understand the AI technology and haven't really been exposed to it in like a work setting. And so that would be kind of my order of operations for a CRO starting from scratch.

Mm. And, and so it's really about eat, like eating your vegetables in, in many ways.

Like, I think so. And a lot of my work that I do at ChatGPT, uh, with Clay is just like customers, like, you know, um, um, hey, I'm trying to, I'm trying to get my Sixth Sense data into Clay. And it's like, well, okay, how are you, how are you planning to do that? Well, Sixth Sense doesn't actually have an API that allows you to pull your list of accounts out of 6Sense. And when they sync to Salesforce, they actually sync to it in an iframe. And so, and so there's a lot of detail around this working versus this not working, uh, in this kind of go-to-market engineering world. And the same with AI around these details of like what the prompts do and what the models do and what they're good at. And if, if very few people at the org are kind of tuned into that, um, then I think it's gonna be it's gonna be something that is, that is a challenge. I would actually compare it to like maybe like APIs, you know, like I think if you reversed 15 years ago, not everybody really understood what an API was. A lot of services were still weren't hooked up that way. Stripe didn't exist yet. All of this. Now everybody knows what an API is. Everybody's familiar with it. Everybody kind of imagines that, oh, if I want to get some data from somewhere, I can probably plug into it. A lot of customers always ask me, what's your API connection like? They, they actually have internal programs around building APIs for all their systems and having all their data in a central place. And, and so, but that understanding took a while. And, and, and AI I think is, is the same where you've, there sort of have to be a, a common cultural understanding of like what it can do before you start to automate things. And then especially before you start to do net new things that only AIs can do.

Yeah. One of the pieces of advice I give the most, most commonly is you just have to start with the data quality and you need a lot of buy-in from your data team because, you know, in the Sixth Sense example, it's like, okay, so if it iframes into Salesforce, then does that mean we need to go Sixth Sense to Snowflake, Snowflake to Clay? Is that, you know, and like, that's not really the realm of RevOps anymore. More. And so I'm going to ask a question about like where, where some of this should live. But, um, it feels like everybody wants to go to the exciting fun stuff like carpet bombing their market with AI SDR before they do the hard things, which is like, dude, you just got to spend 4 to 6 months on making sure the baseline data quality is good and using AI to do that. Like you gave the example of of industry categorization, but it feels like that might be the best place to orient people. Is, is that a fair argument?

Well, I, well, I totally agree cuz that's Clay's pitch as well. And so, and you know, when we go into a conversation with folks, we say, hey, like, um, let us, you know, send us a sample of your data, we'll send it back and we'll, we'll prove it's better. And then we'll do that same thing for your entire, for your entire CRM. But the, the, The reason that that's, um, that that's important is because you need, you're gonna end up in a place where you need to kind of have the AI like, um, make, do some logical things, like make some decisions, like qualify a customer, qualify a lead, um, or, you know, put together a reasonable piece of copy. If you have a bunch of contacts in your CRM that don't work at the places that they're listed at anymore, or you have a bunch of accounts which have employee accounts, sparse data, you know, you can run these reports where you can see the kind of fill rates across your CRM. If that's your state of the world, it's just going to be really tough to, to do a lot of the more interesting things. Um, and because like we talked about, the more you can constrain these models and these prompts with information, the better they perform. So if you're able to say, hey, here are like 50 filled in data fields, um, and you give that to a model and you give it some instructions, that's going to be a better situation than here are like 10 filled in data fields and then in the next record there's 12 and the next record there's 6. And then by the way, of the ones that are filled in, some of them are out of date, some of those companies have merged, some of them are out of business, some of those contacts are like at a different company or retired or been promoted or which is just really nasty and and, and if you go down the sort of like rabbit hole of this, I, I think most, most folks, if they were begin to click through their, their CRM, they could almost do this like Wikipedia thing where they could just click between objects and they would see bad data like everywhere. Um, and so yeah, the, the consequences of layering AI on top of a setup like that are, are not good because, because like we said, the model is not really going to discriminate of like it's not really going to make a judgment about whether the information that's being given is correct. It's going to assume it is. And then if that's connected to other systems that, that send to employees or send to customers, you're asking for kind of like a, like a, like a, a bad setup.

Yeah.

Yeah.

AI is a pattern recognition machine. And so it's just going off of what, what it has access to and it's guessing what the next appropriate thing is. And, you know, if the input data is not good, obviously you're going to have problems. This is, so I'm, I'm giving this presentation next month at GTM 25. And the argument I'm really trying to leave people with is like, do the boring stuff first. You have to get first-party data in a good spot. And I'm always recommending Momentum to like gather all of this insight from across your customer journey. And then you need to get third-party data in the right place. And my generic recommendation is always Clay. I'm like, look, we built a bunch of this in-house because it was before Clay like exploded into the zeitgeist. But we're, as you know, talking to your team about potentially like converging on Clay to do a bunch of it. But I'm just like, you, these two things, like these two products are like 80% of your AI roadmap, you know? And instead people are like, go ahead.

Oh, well, I was just going to say, you know, the good news on this is like, is like we're, we're trying to do a lot of the actual boring, tedious work for you. So, you know, when you pull data points from Clay, we've done a lot of work in the backend to like actually assess that quality. And we've done a lot of work to assess the quality of the 150-odd data providers in the marketplace. And when we've ranked our waterfalls by that and we've set up the, the commercial agreements with those folks and the sort of like, um, now we're working on actually a lot more like compliance-related stuff, which has become more of a, more of a thing as we've moved a little, a little bit more upmarket. But you know, there is so much beyond even just actually, um, pulling data from somewhere and updating into your CRM, which is admittedly somewhat routine task. What that— with the data source that you're pulling from itself needs to be kind of like cleaned and made accessible and all of this. And so, yeah, so I completely agree with you. The plumbing to do that is, um, is not fun. And like, that's That's what, that's what people pay Clay for. The prior world of this was you'd have 4 or 5 different, often conflicting data sources connected directly to your CRM. And then, and then reps could look at it and pick the employee count that's, you know, most favorable for them. If it's, if they want the account, well, they'll pick the one that's in their territory. If not, they pick the one that's out of their territory. And it's, it's, it's, um, it's a difficult thing. And so, um, and so yeah, the, there's so much like picks and shovels type, type work around data that, um, that is necessary. And then, and then, you know, the good news is once you come out the other side of that, the level of automation of these systems today means that you, you can often just kind of like leave it alone. Um, and, and that's a great, that's a great new thing versus, um, versus kind of the, the prior world, at least that I grew up in from the RevOps side.

Yeah. And is that the domain of RevOps, of a data team? Where do you most frequently see that live within your customers?

So it depends on kind of how the customer views their market. The more volume that exists in the market, I think the more it lives with the data team. So, you know, as an example of that, we have some— a lot of the major AI companies are Qlik customers, and the volumes that they deal with are absolutely insane. Frankly, never seen anything like it. And, um, you know, you almost don't even want to like have a lot of that data live in Salesforce, um, because you need an actual production-grade data warehouse, an ETL setup, data team that is managing some of that, some of that feedback. Um, and so And so the way that we kind of like see that in Clay is we work with the data teams when they have pretty high volumes and also when they have kind of a PLG motion because another type of like large data is product data. So at Clay, for example, we've got people using credits and doing things like this and most of that lives in Snowflake. but the aggregations of those things live in Salesforce. So people can kind of see the, see the work on that. The models that power that, the DBT models and things like that, that actually power the aggregations and the, and the consistent updates from our production database into our warehouse, into Salesforce, all of that is the data team. And you can imagine how there are some data teams that take it further where, you know, they actually want to kind of sync their accounts to their warehouse and then they want to have the enriched data live in their warehouse too. And so those teams are definitely involved with, um, with Clay. And then a lot of our customers, those teams are kind of like producers for the downstream RevOps consumers that take what they have and carve up territories and think about pipeline coverage and things like that. We, we encounter customers that have a smaller volume in their market, which by the way doesn't mean their market is smaller. It might just mean they target the top in the Fortune 100 or something and they have, yeah. 8-figure contracts, um, that usually does live more with ops. And a lot of the problems here are more about, can I build kind of like a, a virtual copy of my customer, um, in my, in my CRM? So can I have, like, when someone changes jobs, do I have that recorded? When an account, um, reaches a new employee miles count milestone, do I have that recorded? When they launch new AI initiatives and things happen in their business, do I kind of have that have that recorded. Oftentimes in those types of companies, we do see more ops and demand gen folks involved with that. Um, partially because, you know, you don't really need a warehouse or like a DBT pipeline to manage that stuff. Um, you can do it all in Clay and in Salesforce. And so, um, and so that would be sort of my, my general, like, like cut on the market. You know, data teams exist where there is like a lot of data to sort through. Um, and for many companies there's still, you know, 10,000+ accounts, but not like millions of accounts.

Yeah. Oh, that's a really interesting framework because, uh, for us, we have a big, really big market, hundreds of thousands of, of target accounts. And so this is fairly exclusively the domain of our data team. They think about acquiring, managing, uh, the data that the the GTM org uses. We— our system of record is Snowflake, not Salesforce.

Yeah.

And we push into Salesforce, but the scoring is built in on top of Snowflake. So this resonates a lot. Um, I want to ask, so where should a GTM live? And maybe before that, like, what are the roles? So I want to be— so I'm like committed to fixing my data foundations. I have a path there. Um, what are the specific roles that you think need to be in an org that is serious about pursuing an AI roadmap, and where do those people live?

Yeah, so you, at a minimum, you need someone thinking about strategy that is aligned with, um, the executives and understands the business very well, and someone thinking about implementation that actually may not understand some of those things but understands the systems that they're dealing with. And classically, you know, you've got your, you've got kind of your RevOps sales ops role on the strategy aligned with executive side, and you've got your GTM engineer that is hands on keyboard doing stuff. I think it is interesting that today the GTM engineer really is more of a like IC, IC role. And the, and the, the best way to utilize GTM engineers is just to have them doing stuff, you know, maybe in Klair, maybe in other tools. All day. Um, I, I, I don't, for example, see a lot of like VPs of TTM engineering, right? So I don't see like these like big org structures that are built around this, whereas you do see, you know, pretty substantial sales ops or rev ops organizations. And that's because they have a lot of internal alignment, business strategy, account coverage, pipeline, you know, issues and things to sort out. And they need they need, you know, really strong context from the CRO and so forth in order to do that. I think when you get down to the GTM engineer, they are kind of like burning down the list of things that are most likely readily automatable, um, or they're burning down the list of data problems and like solving them in interesting ways, but they're really focused on solving them and they're, they're focused on the sort of like building aspect. Um, now in terms of where in the organization that lives, because the GTM engineer has a big impact typically on pipeline generation and rep productivity and so forth. Um, they, they will in the best orgs, in my opinion, straddle sales and marketing. And so if you have a CRO that, um, that owns both sales and marketing, then you ought to have a centralized GTM engineering team within that CRO org that serves both of those functions because, um, direct into the CRO or through RevOps? I, um, oh, through RevOps, sorry, but within the, within the CRO org. I actually have the opinion that if marketing, if there's a CMO and marketing, um, marketing reports to, you know, up to that person, you might consider having, um, uh, GTM engineers live next to marketing ops inside the CMO organization. Organization. And that's because today I would say that, um, you're gonna get the most bang for your buck with GTM engineers when you're working on automating like top-of-funnel activities, when you're working on automating somewhat routine sales tasks. But as you get into organizations where they sell more upmarket and so forth, I think you actually see like fewer routine sales tasks that, that sales reps are doing. But you do still see a lot of routine stuff in top funnel. Um, and then finally you have the consideration around like data and systems. And so this is like a third organizational option would be to have the GTM engineers actually live somewhere in like the CIO or maybe CTO organization. This is a situation where you might have a setup where you have like a business systems team that actually owns Salesforce, um, ZoomInfo, Clay, all the tools. They own the spend and the budget and the implementation. Implementation of those tools. Um, and, and the GTM engineers should probably sit very close to those folks, um, as, as long as they are able to kind of like take requests and so forth. So you, you have some options, but the sort of through line is that it's a centralized, centralized team. And I think the best setup is actually to just funnel basically like the implementation of a go-to-market AI initiatives through the go-to-market engineering team in whatever way that's kind of set up in the organization.

Okay. That makes a lot of sense. So, so it is specific to the business and their market and segmentation, you know, like where SMB versus enterprise.

Yeah. And, and you could hire different types of go-to-market engineers too. So I've actually kind of thought that we should have like full-stack go-to-market engineers and like backend go-to-market engineers, but we don't, we don't have to, we don't have to go down that rabbit hole, but Um, like if you have a very experiment-driven thing, you know, you're in marketing, you're trying to launch new experiments all the time, you might consider hiring more of a like experiment GTM that is going to like quickly hack together, hack together new campaigns and launch them. Whereas, um, you might also have a different set of problems around data quality where you actually want to hire kind of like a deeper system data scientist, basically data scientist type thing who is hands-on keyboard and clay, then they're probably going to live closer to the chief data officer, CIO, CTO, something like that. Um, and so, and so yeah, there's not like an, um, uh, off-the-shelf GTM engineering org design thing, um, that, that I generally tell customers. I generally kind of give them this readout and ask them, you know, what's your, what's your setup today and where are you trying to get to? Yeah.

And you could even have multiple of those roles. You could have the data person and the experimentation top of funnel person in the CMO's team and the person in the RevOps team that's doing the sales automation stuff. So it doesn't necessarily need to be the same person, I guess.

That's right. That's right. I do think it's like, um, it's almost like having like a staff engineer maybe that can kind of jump around different product teams and help out. You could consider the GTM engineer as like one of the most technical people within the go-to-market org that can also, that can also do that. And I think that's a, um, that's a fine model too. When you have that set up, that's where you probably would just have a GTM engineering team that is kind of loaned out. Um, and, um, and I've, I've actually, I've seen that model too. You will need a, a manager for that team, like a head of GTM engineering or something like that.

Yeah.

Uh, and, uh, and you know, that team really ought to be able to push the boundaries and kind of say, hey, this is the stuff that we've done and look at the impact that it's had.

Yeah. So when you think about the jobs to be done, how, how quickly do you go out and find a GTM? GTM, is this something that people should be looking at at like $5 million ARR, $10 million ARR? Is it like now the third role that you hire in the sales org? Like, how do you think about staging?

So if I was starting over, I would build out an organization where I've got, I've got my RevOps slash sales ops role kind of combined. That's thinking about, um, you know, pipeline coverage, some of the strategy things around sales. Then I would have a go-to-market engineer attached to that. Um, like it sits right next to that person doing some of this stuff. Then I would also have an agency that probably running outbound for me and also probably providing some like services level work around some of the data quality stuff that's, that's happening. Um, and so I actually like at Clay, people are often surprised to hear that we use a Clay agency for our outbound. Um, and that's because outbound is this kind of services-oriented work that is, um, that is like always changing. There's always things with inbox health and domain health and things like that. Um, and then there's always kind of like constant, constant iteration. And so, um, and so starting from scratch, I would, Try to have those 3 things kind of attached to my, to my go-to-market engineering, uh, or to my go-to-market organization. Um, and then what I would do is over time I would start to make some decisions about what do I keep in-house, what do I farm out? Uh, maybe I pull more of the experiment-driven work inside from my agency and, and let them just kind of operate existing campaigns that are working. Um, Maybe I move my GTM engineer actually into more of a RevOps role and I farm more of the work out to the agency around some of the systems maintenance. Um, and so those are decisions you can make, but, but I think like you're not talking about an overly costly op structure here when you're, if you just do those 2 or 3 things. Um, and then the benefit you get is, you know, if you're at $3 million, you're at $5 million, the kind of book isn't written on how you're going to grow yet. And so if you need to make pivots, you can kind of like take those two roles and actually morph them into other things and, and create, you know, still retain those employees. And my whole thing is I always think it's sad when go-to-market organizations have low retention because the tribal knowledge in, in go-to-market is sometimes like deeper than the tribal knowledge in like an engineering organization. And so, um, yeah, I would, I would start up with a setup like that. And I think founders should not be afraid to like look external. There's so many third-party agencies that are really good that will just help you skip like several steps and the whole journey of like learning about your go-to-market.

Yeah, that makes a ton of sense. Um, where should people go to hire this, these GTM EEs? Yeah, this I think is one of the hardest things.

So we have, uh, some resources for this now. So we have a job board. Um, yeah, so right now it lives for unknown reasons. Uh, well, I guess it's good reasons. In our, in our Series C announcement. So clay.com/series-c, you'll see a jobs board where you can actually post your job. Um, and I think we also have clay.com/jobboard, um, where you can post your role and that will be surfaced to, uh, to our community of go-to-market engineers. We also now have a talent, um, a talent board. So you can actually submit, um, uh, you like your LinkedIn profile and we'll, uh, Richard of course, um, into our, into our organization. And then we'll do the ma— we'll do some of the matching as well. So we'll surface talent for our customers, and folks that, um, that are looking for GTM engineers can kind of get into that pool. And then we also have a Slack. It's about 20,000, um, 20,000 folks in there. Not all of them GTMers, of course, but actually a good number of them, of them are. And so I think usually between all of those three, people are, are seeming to be able to at least begin interviewing. Um, although I will still say I kind of will make recommendations to folks and people can reach out to me on LinkedIn as well to kind of like get, um, reviews or feedbacks on job postings or to get an initial list of, of candidates. And, you know, I've hiring for Clay, I've interviewed like thousands of great people that for whatever reason, often look location-based, uh, couldn't, couldn't join Clay. And I kind of have them at my disposal to refer to, to organizations too. Um, so, so that's, that's kind of one thing. I would also—

clay.com/job-board. Yeah.

Uh, unless— okay, great. Yeah. So, so you can post your job posting there. And then we, we do have this talent directory, which I don't know if we've exposed. I think we will like send that to people if they ask, but it's not like exposed to the general, the general web.

Okay. Yeah.

Um, and then we have our Slack as well, which actually has its own channel for, for hiring and, and recruiting. So, um, so those are options. And then you can also DM me on LinkedIn and I'll usually try to, try to help.

One more question before we get into quickfire. Um, so we talked about data as the foundation for, for everything. Um, how should folks think about the right use cases to start with? So I've now got like a good data foundation, I've done the enrichment, I've got a plan in place. When— and we've talked about automating some of the low-value tasks, but how should people think about the biggest areas of opportunity? Everybody wants that step change ROI. Like, how should people hunt for that? And what have you seen as maybe the, the rocks to look under?

Yeah, um, I, I think the biggest thing is actually, uh, like account scoring and segmentation. I, I think, I think there's a, there's a, there's a massive problem with probably more than half the time you're going after accounts or talking to accounts which are not qualified, not in market, you're missing out on accounts that are actually like ready to buy or actually like very hot or are smaller than your existing criteria, but for whatever XYZ reason, they're, they're actually, uh, gonna purchase a large, a large contract. Um, it's, it's simply aligning the, the accounts and the folks that are, you know, great fits for the business with like ready and willing reps to talk to them and sell to them, I think is like a real challenge. And, and I, one analogy on this is, um, is you always have these kind of good logos, right? Like, like, uh, you always have these companies, um, and we were chasing Figma for like a long time. They eventually became a customer, but we were chasing them for a long time. And so, you know, when you're in seat as a rep, you're always like, what can I do to break into Figma, what can I do to get into Figma? What can I do to, um, you know, um, research Figma to some, to some greater degree? When in reality, probably the best thing is actually to go ahead and just like let them, let them lie for a while and, um, spend time with the accounts that are actively gonna buy right now. And so I think businesses still have this kind of like matching of demand issue that actually AI can help really resolve. And you can now pull like most of the data that you need in order to, in order to get that information about an account. And, and I think that is like probably one of the biggest opportunities. Do I just have incredible books of business from my reps? Are they real-time updated? Do I have all the signals that I need on my accounts? And are my people talking to like literally the right accounts and contacts? That I think is probably one of the biggest opportunities that folks can go after here. Doing that well is downstream of a lot of the other things we've talked about on this podcast. But the, yeah, I just consistently observe that the right people don't get talked to even if they're ready to buy. And by the way, this still happens at Clay and I I always get super frustrated when I see it. But we've made really good progress in kind of matching our demand and supply. And I think most companies are still kind of in the early innings of this, especially large organizations is where this really, you know, if large organizations are looking for like 1% revenue less in different places, this is probably one of the places.

Yeah, for sure. Okay, let's get into rapid fire. And I'll let you get outta here 'cause you've got US Open tennis to watch, which I don't want to get in the way of. What do you think separates a good CRO from a truly great one?

Systems thinking. Yeah, definitely systems thinking. I think you can be pretty math-oriented in terms of like dashboards and so forth, but if you're not clued into the systems and the flow of leads and deals and and, um, what actually happens in the, in the belly of the beast to make all that work, um, you, you probably are not tuned into some of the things that are going to cause trouble for you and also some of the opportunities that you can go after. So yeah, I think systems thinkers are, are some of the best heroes that I meet, especially today.

Um, what's the most common advice you give to newer leaders outside of AI? Just like, what, what advice do you give to leaders that are taking their first big like VP sales job or, um, like second line role?

Yeah, spend time recruiting. Uh, this is actually something that I haven't done well in my role, uh, and I've, I've really tried to work, work harder on, but, um, you know, recruiting is kind of like a drag in some ways. Um, it's, uh, pretty hard. It's, um, the consequences for failure are immense, especially if you're hiring, you know, first or second line leaders. Um, and it's really hard to systematize. You, you, when you're hiring at scale and you're trying to hire, you know, 50 reps in a quarter, it's like, man, how do I get even 30 good people to fill these seats and, and then maybe churn out 20? So recruiting is super, super tough. There's a lot of art to it. Um, I actually think Varun, one of the co-founders of Clay, is an incredible recruiter. I've learned a lot from him. Um, but yeah, appreciating and diving deep into recruiting, you basically cannot go wrong if you do that well, and you can go extremely wrong if you don't.

Yeah. What's the hardest lesson you've had to learn as you're figuring out how to lead salespeople?

I think it's that, you know, people and people don't just kind of like take your word for it. I think I've tried really hard at Klei to be in the weeds and to lead by example. But even still, I catch flak for just kind of firing off these like things and these policies and not really explaining why or not really demonstrating why we're doing things or sort of like catching people off guard or catching people by surprise. And, you know, folks, even if the reality is that it's, it's kind of a, a shit show as you're scaling a startup, folks kind of want to work in a place where there's stability and there's thoughtfulness and there's rigor. And, and even if you have all those things internally, if you don't kind of like show people that that's happening, or just, or show them the way, then, then they kind of think it's not happening and they start to kind of like mistrust. And so I've, I've kind of had bad moments on that. I've had good moments on that. And it's something that it's all ever present in my mind, especially now that Clay is much larger than it was.

Yeah, that is a good one. Last question. What's the best thing you've read in the last 12 months?

Best thing I've read in the last, last 12 months. There is a book that I love. I actually said this on a previous podcast, but it's still true. It's called Stoner. Um, by, uh, by, by John Williams. Um, it is a fantastic book. It's about this like, um, literature professor in the Midwest who sort of, it goes through his entire life from almost like childhood into death. And, um, and he sort of like, he sort of like never from an external sense has like finds happiness. Like he never gets external validation and people are often like mean to him and stuff like that. But he ultimately does find kind of internal validation in his work. Uh, and I thought it was a good analog for sort of like scaling startups and sales because let's be honest, most of the time you sort of like, especially as a leader, are dealing with escalations on things.

You're eating glass.

Eating glass. And in fact, I just said the phrase eating glass in an email to a customer today, or I think I said chewing glass. Um, and so you must be able to kind of find internal validation in the work that you're doing. And oftentimes the external stuff might come much later or be expressed differently than when you're an IC and your manager is like, hey, great job on that thing. So yeah, so Stoner by John Williams, I think, fantastic book.

And a good tie-in to my last episode with Dr. Michael Gervais about purpose-driven leadership. So that's a good plug and a good place to leave it. Well, Everett, this was awesome, man. I really appreciate it. I think we got to a lot of great answers for folks on how they should think about this journey because it's the thing that everybody is talking about. So appreciate you joining me and we'll have to do it again.

Amazing, Kyle. Yeah, thanks. Thanks so much. And yeah, you can, you can talk to me about this for another several hours. I won't get bored. So appreciate it.

I have a bunch of questions we didn't hit, so I could do the same. Thank you for listening to the Revenue Leadership Podcast. If you enjoyed it, don't forget to subscribe, and you can find a link in the show notes. And be sure to leave a 5-star review, share it with your network, and please join me next Wednesday for another great conversation.