Patrick Spychalski is the co-founder of The Kiln, a leading GTM engineering agency and one of only six Clay Elite Studios, their highest partnership tier. They recently got acquired by 2X.
Before The Kiln, Patrick helped Clay stand up its early social, events and partnership motions, back when Clay had just invented the term “GTM engineer”.
In this episode, we talk about the state of GTM engineering 3 years in, whether Claude Code is eating Clay’s lunch, when a startup should hire its first GTM engineer, and more.
Listen on: YouTube, Apple Podcast & Spotify
We discuss:
Clay vs Claude Code
Patrick’s top Clay / Claude workflows and agents: what he would keep if he had to delete everything else
The newest tools Patrick is currently experimenting with
When to hire your first GTM engineer and what makes a good one
Into whom should GTM engineering should report into?
Why Patrick sold The Kiln to 2X
Show Notes:
Connect with Patrick:
Patrick Spychalski’s LinkedIn: https://www.linkedin.com/in/patrickspychalski/
The Kiln: https://thekiln.com/
2X: https://2x.com/
Connect with Finn:
Finn’s LinkedIn: https://www.linkedin.com/in/finnthormeier/
Thormeier.co - Founder Brand & LinkedIn advisory: https://thormeier.co/
Mentioned in the episode:
Clay: https://www.clay.com/
Claude Code: https://claude.com/product/claude-code
n8n: https://n8n.io/
Modal: https://modal.com/
Eric Nowoslawski (Growth Engine X): https://coldoutbound.com/
Deepline: https://deepline.com/
BlitzAPI: https://www.blitz-api.ai/
Tom Wentworth (incident.io) episode: https://www.founderbrand.org/p/the-most-ai-pilled-cmo-in-tech-shares
Full Transcript:
Finn Thormeier: All right. My guest today is Patrick Spychalski. He is the co-founder of The Kiln. The Kiln is one of the leading GTM engineering agencies and clay partners. They recently got acquired by 2X. He also previously helped clay stand up their early social events and partnership motions. I wanted to have him on because I don’t think there’s many people who are deeper in the whole Thank you for coming on the podcast.
Patrick Spychalski: I appreciate you having me. Glad to be here.
Finn Thormeier: How would you describe the, I mean, you’ve been there since basically the, let’s say the dawn of GTM engineering when kind of Clay coined that term, which I guess has been like three-ish years, something like that. How would you describe the state of GTM engineering as of July, 2026?
Patrick Spychalski: Yeah. Yeah, I think it’s at an interesting stage right now where it’s evolved to the point where many people, I’d say even a majority in some spaces of people in marketing and sales have heard about it. They know what a GTM engineer is. It’s becoming a lot more in the vogue, a lot more prominent. Even a year ago, I would say it wasn’t a super popular job role. And now most companies, especially tech companies, are prioritizing it as kind of a core role to hire for. It’s also in an interesting state where the tool stack, I think, is shifting a little bit. Clay initially came up with the term GTM engineering. That was kind of their invention. And I’d still say they’re really core to the work that GTM engineers do. But for a while, I would say that it was really one of the only tools that people were using for a GTM engineer, at least the primary one. It’s now evolving to the point where the Claude Codes of the world, obviously N8N has come out probably into the vogue maybe a year ago or so. It’s getting to the point where the tool stack’s changing pretty significantly. And also, it’s starting to come out with sub-niches of the role where initially, let’s say the broad GTM engineer role is what everybody’s looking to hire for, but now they’re realizing that GTM engineers mean something different for every company. There’s different priorities associated with every business. Sometimes I talk to a company and their main priority is outbound, so they need a GTM engineer who’s got a lot of experience with outbound tooling and the tool stack connected to it. Really want more of like a data engineer, like someone who can go into a data warehouse and sequence all the information to something like Salesforce and create these bi-directional syncs. And so I think they’re coming to realize that, you know, different GTM engineers have different skill sets and need to be hired accordingly. So yeah, it’s at a very interesting stage right now.
Finn Thormeier: How would you describe what’s the leading edge of GTM engineering right now? I mean, I feel like three years ago, just having a clay account and having any workflow in there, that’s like the leading edge. Where are we now?
Patrick Spychalski: Yeah, so I would say like all of the most talented cutting edge UTM engineers I know are building a lot of really interesting infrastructure within Cloud Code. So I think a lot of the really talented ones that I’ve worked with have realized that, you know, you can recreate a lot of the workflows you would build in no code tools in tools like Cloud Code and save yourself a lot of money depending on what the workflow is. But they also realize that these things should not be completely agentic. So for example, if you have an enrichment workflow, the whole thing shouldn’t just be an agent going and finding information and putting it in a document. It’s a big waste of money. You’re using a ton of tokens to do that, and it’ll end up costing you actually more than a tool like Clay would. Clay, I think, is a really good combination of the agentic and the deterministic. So they have to actually rebuild the scaffolding that kind of supports a tool like Clay as well. I would say GTM engineers at a lot of startups I know are starting to try to create their own workflow interfaces and agents. This is a lot more difficult for enterprise companies because of security and compliance reasons. It’s pretty complicated to spin up your own agent and then connect it to Salesforce without there being any problems. But for companies, especially in the Seed and Series A range, I’ve seen a lot of GTMes create their own workflow scaffolding and cloud code and almost become their own host for the workflows that they’re building.
Finn Thormeier: What does switching or replicating things that maybe previously you did in Clay instead in Cloud Code, what does that unlock except maybe some cost benefits?
Patrick Spychalski: I would say the majority of it is cost benefit. There’s a little bit of added positives. I’d say one thing Clay isn’t very good at so far, and I’m sure they’ll improve this, is the relativity component. Let’s say you source Yeah. You can think when you’re using Excel or Google Sheets, you can reference another cell in a table. Clay can’t really reference another cell. So it’s really tough to do that relativity. And that surfaces in a lot of workflows. So things like that, I think, are nice to build yourself or build in something. So there is some unlocked benefit, but for the most part, I think it’s just that place changed their pricing recently. It’s a lot more enterprise forward. They’re really trying to target these bigger companies. And for people who are at Series A or C companies with pretty tight budgets, they were having a lot of trouble justifying the cost, especially to probably the founders or co-founders or CEOs. And so it’s just easier to build it, something like Cloud Code. And again, we’re not really seeing that shift on enterprise. I think enterprise companies will stick with Clay for quite a while, just due to the security constraints and the fact that it’s like a real tool you can procure.
Finn Thormeier: I mean, what is your take on Cloud Code eating Clay’s lunch?
Patrick Spychalski: I think it’s a lot more complicated a problem than people say it is. I see all these posts being like, Cloud Code is going to completely destroy Clay. Clay is dead. Clay is dead. And I really just don’t agree with that. I think Clay has built a really good platform for, and I kind of mentioned this a second ago, but combining the agentic and deterministic aspects of enrichment to create a really cost-effective platform, even with them up They still create a pretty cheap way to run enrichment, build workflows, and safely connect them to platforms. And I really think the safety part is important to hammer on because, like, if you create a Claude agent that connects to your Salesforce, there’s really no guarantee it doesn’t just, like, destroy all the data, wipe it out, not use a sandbox. There’s a million things that can go wrong. Clay really is, One of the safer ways to update your CRM or send messages through a sequencing tool or update a data warehouse because you’re able to visualize all of the outputs before sending it over. You’re not letting an agent just run crazy. It’s just a direct integration with data inputs and outputs. Yeah, I don’t see any large businesses moving over to strictly cloud code anytime soon. I still think Clay is probably their go-to, but I can totally see the justification for startups. One other thing I’ll add quickly is that I think there are some use cases There are cases that are great to be replaced with Cloud Code, and then there’s others that aren’t. So a great example of one that I’ve seen a lot of people effectively replace with Cloud Code is enrichment of lead lists. And so if you have a list of 1,000 contacts that you’re planning to reach out You just want to find their LinkedIn and their email and their phone number. You can just plug that list into Cloud Code, use a tool like an API like DeepLine or something or Blitz API and just run the whole thing and enrich the whole list and send outreach. And I’m seeing that being done really well. People like Eric Nowoslowski, who runs a really successful outbound agency, has essentially just built this huge Incredible automated system that does all of the enrichment and outbound message writing for all, all within kind of this like cloud code built infrastructure. And I think that’s a really good use case, but a bad one would be something like CRM enrichment or even like inbound lead aggregation, anything that connects to like core systems that you really care about.
Finn Thormeier: And besides, so when I asked you kind of what’s the leading edge, you kind of went, you know, a lot of people are moving to cloud code besides the infrastructure. In terms of use cases, so let’s say a very straightforward workflow you might build is you have a website de-anonymization tool, you identify people who visit your website, and then you maybe enrich them, you qualify them, and then you send them some sort of sequence. If that’s the kind of vanilla simple thing, what’s like a recent workflow or agent or clay table that you saw that blew your mind that the smartest people are doing?
Patrick Spychalski: Yeah. So I think you very accurately described the more like, let’s say basic vanilla clay tables. It’s really centered around outbound. A lot of those, like it’s just sourcing lists, doing enrichment and sending out like an automated message. Like that’s what clay was initially made for. People would use it for, for the most part. I’d say as we’re working with more enterprise companies, what we’re seeing is like a lot of these businesses don’t want to get rid of reps. And I think that’s actually the correct decision in many cases, like sales reps still have massive value for reasons we can talk about in a second. But so instead of getting rid of those reps, They’re building these kind of co-pilots that just help enable the work that they do and make them work more efficiently. So, for example, being able to create an agent or like a clawed skill that you can plug into an org and reps can use to source lead lists or run enrichment or draft messaging. You know, because like every rep right now, I’m sure whether... If they’re willing to admit it or not, they’re using a ChatGPT or a Claw to do a lot of their work. It’s helping them source lead lists and find people’s emails and then write messages. And that’s a good thing.
Finn Thormeier: Researching accounts.
Patrick Spychalski: Exactly. Researching accounts. I think it’s a good thing. I truly think that is like a massive value add and it’s gonna make them more efficient, but there’s no standardized way to do that in an org. So people are writing different messaging. They don’t know which tools to use for enrichment. There’s no like structured way to go about these things. And so I’m seeing a lot of, Enterprise.org shift to how can we create these kind of like dynamic clawed plugins that have a variety of skills underneath them that reps can access and use to make themselves more efficient. And there’s so many things that you can do. They could be after a call updating the HubSpot record with all the calls Call notes and information that you found. You could have like a pre-call prep workflow where they can call a thing. It’ll prepare them for all the calls they have coming up for that day. It can be researching accounts and contacts to see which ones are qualified and which ones aren’t. It could be drafting messaging. So there’s a bunch of things that reps can do using just one cloud plugin. And I kind of see that’s where things are going, especially for these rep-enabled workflows.
Finn Thormeier: Yeah, maybe for people listening, I recently interviewed Tom Wentworth, the CMO at Incident.io, and he showed me their cloud setup and they have an applied AI team for the go-to-market team and they’ve built a lot of these cloud skills. I mean, Fable 5 recently got unbanned. I don’t know if you’ve had a chance to play around with it much. Do you see it having any Is there a big impact on any go-to-market processes where you see it being a real game changer?
Patrick Spychalski: Yeah, it’s an interesting question because I feel like the more I think about it, there is a ceiling to the model quality necessary to perform certain tasks. You don’t need Fable 5 to do most of the things we do in go-to-market, Yeah. Yeah. Yeah. Yeah. Yeah. Outbound is inherently a competitive thing. You have to stand out from the other people sending outbound. So you have to have some sort of alpha or some sort of nuance. So I would assume these models can have some improved way of running outbound where it can write better messaging or more nuanced messaging or just have better tonality that resonates with people in that messaging. But I don’t know how much better it’s going to make it. I still think having a human touch to outbound messaging, having somebody write at least like the examples or the scaffolding that surrounds messaging is super important because otherwise it’s just going to sound like every other AI generated outbound message. So yeah, I don’t know. I don’t think it’s going to impact it a ton. It’s a crazy model. Don’t get it twisted. Like it’s an insane thing to use. Like when I’m building stuff for myself, it just can build it so much more efficiently and it can ID it so much better. But for a lot of the good market workflows we’re building for big companies, it doesn’t seem to have that big of an impact.
Finn Thormeier: So you see it more as like the model that maybe builds your, I don’t know, internal tools that you might use in GoToMarket, but the actual day-to-day execution of enrich this account, research this person, you don’t need that for it. Which model writes the best outbound messaging?
Patrick Spychalski: That’s a good question. I’ve always thought, like, you know, I know there’s a lot of debate around this. I’ve always thought anthropics models write the best outbound messaging. And the way we generally work is we don’t write each message one by one for prospects. We’ll usually write some sort of template and then have kind of variables within that template. And so I usually try to use like the highest Opus model. It’s also obviously quite good. I think it’s meant mostly for creative writing. And I would imagine, I haven’t actually used it for this yet, but I’d imagine Fable’s incredible for it because we try to just have this template be really like sound and succinct and well-written. But yeah, I honestly, We use it as a thought partner for writing copy. We’ll have an output of template. We’ll usually make edits to that template. For so long, even when we started the agency, we had copywriters writing copy for our clients for way longer than you would imagine we would because we think it’s really important to have that human nuance.
Finn Thormeier: For the bigger, it sounds like you guys are working with bigger companies now, for those bigger companies and enterprises, how important right now is to them kind of cost management around the GTM use cases when it comes to picking the right model and maybe using some of those open source models for certain tasks?
Patrick Spychalski: Yeah, so you said, sorry, just to recap, because you said cost management, right?
Finn Thormeier: Yeah.
Patrick Spychalski: Yeah, I think it depends on the business. There’s some enterprise companies we work with that are these fast-growing AI startups. They don’t care. They could care less. They’re like, whatever we got to spend to make the output good, it’s fine. But then there’s other businesses, of course, that have a lot more cost sensitivity, and they’re telling us, figure out what the best model is. If we can use API keys for any of these Clay workflows, we want to use them. We want to be really cost-effective. But it’s interesting, like when we first started as an agency, we were working mostly with startups. So we would just talk to these like series A, series B businesses. And they were all obviously, as you can imagine, super cost sensitive. They had raised a round. They want to make sure the round lasts them a while. So they were always telling us like, you know, we need to figure out what API keys to use. We need to figure out what tech to procure. Like focus heavily on cost. But then there have been some clients we’ve worked with recently on the enterprise stage where like, we’ll propose to them like, hey, if you buy this API key, it’ll save you like $5,000 a month on compute costs. And they’re like, Don’t care. We don’t even feel like going through procurement. The procurement for that is going to take so long. Just spend it. It’s worth the speed. We don’t want to have to get through procurement. It’s worth the speed of using the thing we already have. It’s interesting to see.
Finn Thormeier: I see a lot of LinkedIn posts where people talk about their personal cloud setup and they have this super complex thing. They have all the connectors and the MD files with context about them and the super... Complicated, complex, you know, context layer and all of that. I’m just curious, what do you see actually has a big impact on maybe the output that, you know, your cloud or your cloud co-worker cloud code has versus what is just, you know, people creating LinkedIn posts to get, you know?
Patrick Spychalski: Yeah, I think, you know, a good rule of thumb is probably, like, get, like, somebody, like, get the system you see somebody posting on LinkedIn and, like, decrease the complexity by probably 30 to 40%, and that’s probably the right thing to do, you know, like, even I’m also guilty. I remember back when Clay was really on the up and up, I would be posting these absurd workflows. And they’d have some practical value, but you could probably get 90% of the value by decreasing the complexity by 50%. So I was just trying to put the absolute maximum. And I think that kind of applies to a lot of cloud workflows as well. And I think a lot of those interesting things you see on LinkedIn are coming from practitioners that are working at startups or working for themselves. And so they They can create these really complicated things because they know the mapping in their head. So they know exactly how it works. And they have these MD files that kind of just like navigate their own brain mapping of how they should do work. This becomes a lot more difficult when you’re working with big companies. Like, you know, we try to make things as simple as possible. So another, just going back to the kind of the clawed plugin example, like if you’re building a clawed plugin, we’re hoping that like you only have two or three MCP is connected to a given skill. For example, if you’re running an enrichment skill, we want to find one data provider, maybe two, that can cover everything for the enrichment, because we don’t want to find Five or six. We don’t want to have like email waterfalls with like cats. It’s just a lot. Like that’d be so much complexity and so much procurement. So like, for example, like if we found a, like, I think deep lines are great, like, you know, kind of up and coming API that plugs into cloud code and they have waterfalls built in. So like it’s one API for all the waterfalls. They’re like, okay, great. So we’ll use deep line for the enrichment for this component. We try to keep things simple. We try to have one or two APIs to plug into our skills.
Finn Thormeier: For your personal setup, anything that you changed or connected or set up that you feel like actually had a meaningful lift?
Patrick Spychalski: I would say, besides the enrichment providers that I mentioned before, there isn’t anything, I’d say, insane or cutting edge about the skills that we’re building. I think we build them well. I think we have pretty strict rules for how they should work, how they should connect to systems, and that’s usually the main nuance. I don’t have any LinkedIn posts prepared anytime soon that’s like, here are the 15 MCPs that I use every day. It really is just need-based, and most of it can just be used. For example, we have a workflow internally that every time we get off a call, it’ll update the HubSpot record for that company with all the new information. What stage the deal is at, it’ll change the deal stage, it’ll update the notes, it’ll change the next steps, and it’ll do all the updating for us after the call. And it’s really helpful, but it just requires a HubSpot MCP. Crazy about it. Maybe some enrichment if we need it.
Finn Thormeier: If you had to turn off or delete every single agent, cloud, code, routine, clay table you have running and you could only keep three, which three do you keep?
Patrick Spychalski: That’s a great question. I think the first one, and this is maybe unique to us, but I’m sure some people have like kind of adjacent workflows that they use. So we create statements of work at The Kiln when we’re building engagements with prospects. Like when we propose, When we build an engagement to a prospect, we build this really in-depth statement of work about the work that we’re going to do for the prospector slash client. Let’s say, for example, we’re getting on a call with Anthropic and they want to do work with us. We’ll build out this really detailed statement of work and send it to them. We have a really well-made agent that builds the majority of the statement of work. Otherwise, it would take us so long to type all of this out. And it frankly does a better job of summarizing all the calls and emails we had and sequencing that to engagement than we could manually. And I used to have to write these manually. I used to do it myself before the models were good enough. And it took me So that’s great. That’s the first one. The second one probably is the kind of dynamic HubSpot updating skill that we have. Pretty much when anything changes with the prospect, it will now update our HubSpot. And we’re continuously building this out to make it better. But in short, like prospect sends us an email saying something about an engagement. It’ll update the HubSpot record. We have a call with the prospect to update the HubSpot record. We’ll send an email to them, whatever. Something happens, it’ll all update in the record. And that’s so nice because like most sales reps don’t want to spend time updating things manually and they’re And there’s some things that just can’t be captured in a CRM update clay table. Like a clay table doing CRM enrichment mostly is covering like firm graphics and like third party stuff, but first party like new information using an agent to do that is great. So that probably would be the second one is this like kind of dynamic HubSpot updating agent. And the third one, I’ve really appreciated our like pre-meeting prep docs being created by skills now. I don’t know. I’m sure most salespeople can relate to this and probably founders as well. But my calendar is like ridiculous. Like I have like eight hours of calls. I probably have an average of like six to eight hours of calls a day. And it’s like a lot. And many of these I don’t have time to prepare for. Like I’m not like going to sit there and look through like, okay, what did I say this was for? And what’s the background? And having a document that just gets sent to me and I can open it for 30 seconds before a call and read through it every day. Such a value add. And I’m sure it’s a value add for most salespeople who have back-to-backs all day. So those would be the three that I think have been the most valuable for me.
Finn Thormeier: Do you have like a dream agent or workflow that we’re not quite there yet to be able to do that thing, but you would love for it to exist?
Patrick Spychalski: Yeah, I think so. So all the stuff that I mentioned, I feel like is pretty... Like top of funnel. It’s generating proposals and updating HubSpot. I would love an agent that can truly Deal with the annoying logistics of a deal, which is like following up with prospects with like a well-written message saying like, hey, I wanted to follow up on this. By the way, here’s an extra piece of value add that we came up with recently. And then like if they ask us questions about procurement, being able to go into our company’s docs, like look at the procurement information and like truly like a more like agnostic AE bot would be really nice. I don’t think it’s really there and I don’t trust it. I mean, prospects... They’re valuable. I don’t want an agent even slightly messing up the wording of one of my emails, even if the content is correct. I think sales is such an art. It feels such a dance, and you have to make sure that every
Finn Thormeier: How do you think about balancing basically automation with human in the loop? Let’s say for the sales outbound prospecting thing, is this like a pure ACV question where for very high ACVs you just have more human and for very low ACV you do more automation?
Patrick Spychalski: Yeah, I actually say that’s a pretty good way of describing it. Like I’m sure there’s exceptions, right? Like where it’s important to have humans in the loop for certain industries maybe where the people aren’t as susceptible to like emails, maybe you have to cold call them, right? So you have to like cold call these large lists of people in certain industries. But for the most part, I would argue that Uh, the majority of it is ACV based. So when we work with clients who have these big whale accounts that they’re going after, you know, million dollar plus ACVs, we’re like, we’re just going to create systems that can build assets for you better, but like you should be prospecting these accounts. Like we’ll build the slide deck for you. We’ll build the PDF for you. We’ll, we’ll even draft a message that you should probably edit a little bit to make sure it’s perfect. But, um, Yeah, it’s mostly ACV based. I mean, when you’re talking to a company that’s reaching out to whatever, a hundred thousand prospects a month, what are you going to do? Like, there’s not much you can do. You got to kind of automate the message.
Finn Thormeier: So like, should every company have a GTM engineer?
Patrick Spychalski: Um, it’s a good question. I mean, in B2B specifically, I think it’s valuable to have one, but not every company should have one. I mean, especially if you’re early stage. Um, I think, um, A fallacy I see a lot of early stage founders or operators fall into is trying And I don’t even really like using this word because I think it’s a buzzword, but trying to operationalize everything in the beginning, trying to create systems and methods of attack and really try to build infrastructure before you have PMF or you’re still doing founder-led sales. In the beginning, I really think it’s a lot of just brute force and you should probably just accept that maybe your CRM data isn’t perfect, but somebody in your org has it in their brain as to what a prospect is doing and how things are going. So I think there’s a certain stage by which you should probably hire a GTM engineer. And that’s, I think, when your sales team’s becoming more developed. Like maybe, you know, founder-led sales is over. You have like three or four AEs. I think that’s when it starts adding real value. We started working. There’s a company, Modal, we worked with a while ago. And they’re a larger company now because they’re doing super well. So congrats to them. But when they first started working with us, they had like four AEs. And I felt that it was a really good time to hire us because it was like they are now starting to build the infrastructure that these AEs are working in. They kind of have to have systems. And it probably benefits them to have systems. And there’s so many leads coming in now that they have to do something about it. So it felt like a proper time to hire one.
Finn Thormeier: What do you say to the haters who say a GTM engineer is just a RevOps person?
Patrick Spychalski: Yeah, we get that one a lot. And I’d say in a way it’s kind of right. It probably should fall under RevOps if you’re hiring one. It probably should be somebody that RevOps hires. But I think the average RevOps person that you talk to doesn’t know how to use half the tools that GTM engineers use. So it’s really just a tool difference. Like, you know, if you’re a RevOps person and you learn how to use Clay and ClogCode and N8N and connect those to your existing systems, I think you’re pretty much like, yeah. I think RevOps maybe should be given a little more credit than that. A lot of stuff RevOps does is pretty creative and drives direct revenue. I think it’s just a tool difference. Maybe one day it’ll just get usurped into the same thing.
Finn Thormeier: So if we take that company that you mentioned, they have three to four AEs, which I assume that means probably they’re 50 people, maybe they’re around Series A. Would you say that that GTM engineer should report to the head of sales or the head of marketing or someone else?
Patrick Spychalski: It’s a great question, you know, because obviously they never have rev ops people at companies that big, or at least they rarely do. Like, it’s usually just a head of marketing, head of sales. In our case, it’s usually, and this is not the best answer, but it’s usually the person whose workflows the GTM engineer is working on the most. So, like, sometimes both. But a GTM engineer should be pretty... I’d say autonomous in their work. They shouldn’t be getting ordered around. I think especially at the Series A stage, they should not be getting ordered around by heads of sales and heads of marketing. They should be figuring out things to build and maybe even reporting to the co-founder maybe once a month and just saying, this is the stuff I’m building. It doesn’t seem good. It’s adding value. And you should be talking to the head of sales and head of marketing a lot, but I don’t know if they should be ordering you around because sometimes a GTME, especially a strategic one, knows better on what tools to procure and how to build systems than a head of sales or head of marketing.
Finn Thormeier: And then for the bigger companies that you’re working with, do you, let’s say you have a head of GTM Engineering, where do you think is their ideal spot to report into at that stage?
Patrick Spychalski: That’s a good question too. I’d be curious, I’d have to ask some of the people, because I mean, there are definitely heads of GTM Engineering at more mature tech companies. I know I think Cursor has a head of GTM Engineering. Cursor Anthropic probably has their own variant of that. So they have them. I would, like, hesitantly say that they should probably report into either, like, into, like, the head of RevOps, if the head of RevOps, if the RevOps store is pretty big, maybe into the head of RevOps, or into the head of Ops, actually, like, if they have a good head of Ops. The problem is, reporting to head of marketing or head of sales is a big issue, because, like, Marketing and sales notoriously clash. And so like, if you report to any of them, they’re going to just prioritize their work over the others. And they’re also probably going to, there’s always the blame game of like marketing, sending us bad leads and sales is saying that, and then marketing saying, well, sales just is just bad at closing and we’re actually sending them good leads. And so there’s always like this kind of conflict between the two. And so I don’t think you should report to either. It should probably be to somebody who’s optimizing for efficiency or well-built systems. Um, And so it’s, it’s almost like somebody either separate from them or above them. I mean, obviously like if you can get them to report to the CEO, then it’d be great too, but you know, CEO is busy. Um, but it should be somebody who like, isn’t in the middle of that battle, I think.
Finn Thormeier: Yeah. I think you guys even help place GTM engineers now with companies. What, how would you describe the, the hiring profile of the right kind of person to be a GTM engineer?
Patrick Spychalski: Yeah, I’d say it’s probably one of our most in demand services, just because everyone’s trying to hire a GTM engineer, and they’re really hard to hire for two, I think, core reasons. The first is that There’s not a massive talent pool for it. It’s pretty tough to find a really talented one. And if you want to hire one, they’re really expensive. So talent pool is pretty low, especially at the price you’re probably wanting to pay for one. And then the second is that, as kind of mentioned before, there are so many different kinds of GTM engineers. There’s ones that handle more RevOps-based work, marketing-based work, sales-based work. And so there’s no perfect profile for one, which is why we offer the service. I mean, the first thing I asked myself when we were thinking about offering this is like, Why would we do this when we need to hire GTM engineers? We’re cannibalizing our own business if we’re doing this. And then the more I thought about it, the more I was like, Like there’s a certain kind of GTM engineer that should be placed at some companies. And a lot of those are not people that work for us. And so we’re very picky about the clients we bring on. They have to be hiring a GTME that isn’t the sort of one we would hire because otherwise it’s completely a conflict of interest. Like, you know, whatever. If like, I don’t know, like Google tried to hire us to hire a GTM engineer and it was just a person who would work well for us, I’m probably going to prioritize us. And I don’t want to do that. So we have to find something to use. He’s looking for more of a specialized one. I think our people are really great all around GTMEs, but we try to find people that are hiring. We really need one for RevOps, or we really need one for sales. And the profile is usually someone who has a very hacky kind of personality a lot of the time. GTM Engineering, they don’t have a lot of... You know, well-known courses for it. It’s not something you learn in school. It’s not something you go to class for at college. So it has to be kind of a self-starter role right now. You have to kind of seek it out or have to have found out about it and decided to make the career pivot. So there’s a lot of real self-starters in GTME. The ones that we found are really great are ones that started in a technical role. They’re specifically good for rev ops based GTME roles. So people who were software engineers or forward deployed engineers and decided to become a GTME because it’s so natural for them to learn this stuff like clay is easy when you’re when you’ve learned code, like not a hard thing to learn. So, and then for more like sales-based GTM engineers, like AEs, especially like enterprise AEs who worked at a company that sells a technical thing seem to be really good. So like, you know, like I’m sure like a Databricks AE would be really good at being a GTME because they understand all the technical nuances of like a Databricks product and they have to understand that stuff and they know how to sell. So they know the plight of a sales team or a salesperson. So they tend to be really good. And then someone from MarOps who decided to become a GTME is really good, too, for marketing-based go-to-market engineering work. So somebody who worked in MarOps knows all the tool stack and then decided, I want to learn clay and cloud code and N8N seems to be quite good. So different profiles for different types of roles.
Finn Thormeier: I mean, it obviously depends on the kind of use case that you want to apply there, but it sounds like, I mean, there’s GTM and engineer, in GTM engineer, and it sounds like almost you want to lean more towards an engineering person who then learns GTM rather than a GTM person who now needs to learn systems thinking and that sort of thing.
Patrick Spychalski: Yeah, I think depending on the use case, like again, if you’re running an outbound motion and you’re hiring a GTME that’s doing outbound, Like it could be better to find an AE or an SDR who became a GTME because they understand outbound, right? But for any sort of like rev ops, like for CRM enrichment or any sort of like rev ops based work, I really find the engineers are better at figuring that stuff out because they understand systems thinking already. And for complex systems like that, it tends to work out better. So that’s why I say like there’s no one profile. I think it depends on what you’re trying to hire them for.
Finn Thormeier: I don’t know how to frame this question, but where do you think the kind of alpha or mode is? I think there’s some level of what’s happening is that GTM engineering is a buzzword. Companies just want to do it because they heard it and they’re like, we’ve got to do it, but they don’t maybe fully understand it. Where’s the alpha here? Is it just having one? I don’t know if that question makes sense to you.
Patrick Spychalski: No, I think I kind of get the idea. I think there’s an inherent issue with just deciding to hire a GTM engineer for the sake of it. That’s not, I don’t think, a good idea. And there are so many companies that I’ve spoken to and often ones that we tend to disqualify that are just like, we need AI, GTM engineers, AI, we need to hire this AI person. And usually that’s just coming from the higher ups, like whatever the board of the CEO being like, we need AI and that’s going to solve our problems. Sometimes there’s a big strategy gap. Sometimes your reps aren’t writing that great messaging or they’re not calling the right people. There can be a lot of real Creative strategy gaps in a go-to-market system that won’t be solved by a GTM engineer. When you hire a GTM engineer, you’re not hiring an AI wizard that can solve all your problems. You’re hiring somebody that can build systems to accelerate things you’re already doing well. We never work with a company. If a company comes to us and they’re like, hey, we want to build a scaled outbound motion. We want to get the messages our SDRs are writing. We want to automate that creation of the messaging. We want to send them at high volumes. It would be foolish to take that on if the messages suck and they’re not getting responses. Zero times 100 is still zero. Why would we scale that messaging? We would never take a client like that on. I think often there’s this gap problem where they just think AI will solve our problems and they likely won’t. You should probably just think a little bit more.
Finn Thormeier: Yeah. And I’m curious to get your take on this. I’ve talked about this with Tom Wentworth and he’s very deep in the whole Clay and Claude Code. His take is basically that right now it gives them an edge just because they’re deeper in it and more advanced in it than most of their competitors. They’re automating things that they’re not yet automating. They’re saving their AEs times in places where their competitors are not. Part of that is just because these tools have gotten easier. But they’re still kind of complex. But very soon this will be commoditized and it will be very easy to build any workflow and you just write one prompt and it will build you whatever you want to have. And so everyone will have access to these skills or agents or workflows or whatever it is. And then the real differentiator will be Brand or taste or whatever people say. What’s your take on that in general? Will this idea that you can build a very cool cloud code setup and clay table all be commoditized and everyone will be using the same setup and then it still just comes down to who has the better product and who has more taste?
Patrick Spychalski: Yeah, I think that’s partially correct, but I would say my overall take on this is as follows, which is that tech will always be commoditized to some extent. Whatever’s cutting edge will eventually be caught up to. The Founder Brand. I think Tom is correct in the sense that it’s a massive advantage right now for them to be doing this stuff over their competitors if their competitors aren’t doing it. And frankly, this is why we often target kind of boring industries to do our work with because if we implement it for them, it will be a massive competitive advantage for a pretty long time. I’m sure everybody’s talked to those companies that are just absolutely archaic. They haven’t moved past a certain tool in 25 years. Beating them, if you’re one of their competitors, is pretty easy if you have the right tech. But to your point, eventually it’ll get caught up and it’ll eventually get commoditized. And then in commoditized spaces, for example, SaaS is getting really commoditized with all of this. All the SaaS companies have the same tool stack at this point. They have clay, they have cloud code, and they’re all doing pretty similar stuff, depending on the SaaS, I guess, but for most B2B SaaS businesses. Then the main competitive edge is creativity. And Clay kind of had this concept marketed for a while with like GTM Alpha and the GTM Alpha is truly like your own creativity to create these like really valuable plays. And I still think that that tends to be true. You can’t have agents do this stuff for you. Like I think there is this like, I don’t know how to explain it, but like human ingenuity and intuition that can really create Outbound plays that agents never could. And so I think that’s where the real creativity lies. Like if one company is sending a pretty boilerplate outbound message just saying like, hey, I saw you raised a round recently. Here’s our offer. That’s a classic. Another company is sending this beautifully done, AI-generated, branded PDF, doing an audit of the company’s existing systems based on information that they enrich. The other will obviously win every time, and I think some variant of that is always important to keep on top of mind.
Finn Thormeier: Are there any new tools that you’re playing around right now that you’re experimenting with or that will be inside of the LinkedIn posts in six months?
Patrick Spychalski: Yeah, it’s a great question. I mean, I think I’ve always had pretty like unidimensional LinkedIn posts every time I put them up. Like in the sense that I’ve never said that there’s 50 tools you should use. Like I’ve only really ever talked about Let’s say three heavily, which is Clay, N8N, and Cloud Code. And that’s because every time I’ve used one of those three tools, it’s felt like a real paradigm shift and worth talking about. It’s not just some new data provider that’s going to give you alpha for a week. I really think that the infrastructure problems are the ones I like solved. And I really do see the future being... Like plugins to the like cloud codes and codexes and Gemini’s of the world. I still think that those plugins are going to be what’s super valuable. And right now there’s not really one that I think solves every problem. I think, you know, I’m sure Clay at some point will develop their own kind of like MCP that plugs into cloud code so you can build workflows through it. There’s again, like the deep lines and blitz APIs of the world that give you enrichment data, but there’s not like, Uh, not one great like scaffolding layer. I think that plugs in the cloud code yet. That’s really been built. So until that gets built, I have nothing new. I mean, I’ve been talking a lot about cloud code and different APIs that plug into it, but nothing like super fundamental besides the actual tech behind cloud itself.
Finn Thormeier: Now last, a selfish question, uh, as an agency owner, what, uh, can you recommend selling your agency and what tips do you have to sell your agency?
Patrick Spychalski: Yeah, it’s, I mean, I think selling your agency really has to be kind of a, like, personal decision. I actually think, like, you know, obviously there’s a lot of financial decisions that are, like, sub-decisions of the overall decision, but the question should really be, like, Fundamentally, how do you want to live your life for the next few years? What do you prioritize? And how do you see the vision of your company being materialized down the line? So for us, there was a lot of questions. The first question was, You know, like where, where do we think we could take this if we built it ourself and does it kind of align with our own goals of what the company should be? And so for us, our goal was like, let’s work with all the biggest companies in the world on doing GTM engineering and just stay at the cutting edge. I frankly never had like, at least since we started the business, a dream to hire like 500 people and have this mega agency myself. Like that doesn’t appeal to me.
Finn Thormeier: I don’t think anyone dreams of that. That sounds like the worst.
Patrick Spychalski: Maybe, but you know, the problem for me, at least, was that, like, I think we have such talented people on our team. I think, like, I get fired up when I talk to the people on our team every day because I just think they’re so good, and I frankly think they’re all better GTM engineers than me, which was my goal when I started the agency. I wanted everybody on our team to be better than me, and I think that’s truly there. And when you hire, when you have 500 people at an agency, it’s really hard to achieve that same level of quality. I mean, it’s pretty much, it’s nearly impossible because, you know, like you have to have like 500 people that you’re paying like salaries to them that they could easily go find better salaries elsewhere. So like, yeah, there’s like the competitive, like, uh, like. Who do I work with? There’s so much bureaucracy and really talented people don’t want to work in bureaucracy. They want to be free. They want to be able to do whatever they want. They want to be able to have side projects. And so you just can’t have a really well-built agency with the same density of talent I think we have. And so I came to that realization and I was like, Okay, well, like, what do I really want then? Like, and it’s probably to work with the biggest companies in the world and keep working with these really smart people and keep doing cutting edge work. That’s what excites me. Like, I think for everybody on our team, building really cutting edge stuff is what excites us. And like being at the front line of GTM engineering, I think is like a legacy we’re all trying to achieve. And so when I came to that realization, And then 2X approached us. I pretty much said, as long as you let us keep our core group, continue slowly hiring and building the agency and working with really cool, exciting companies and give us the resources to do that, it felt like an enticing opportunity, which was just like, you give us a bunch of money to grow the thing and do the things that we wanted to do. Because we were bootstrapped. When we had a marketing initiative that cost $50,000, I was like, man, I could either buy a Toyota Tacoma or I could do this marketing initiative. It’s kind of a tough one. I do really like the Toyota Tacoma. I probably won’t do the marketing thing, but when you have real budgets from a larger company that’s pushing you to do a thing, it feels a lot more powerful. We now have this larger entity backing us and allowing us to grow more. Um, at the way we want to grow and hire really talented people. And that, and so that was kind of like the lifestyle decision we decided on is like, I don’t want to be a CEO of a 500 person agency. I want to run a small core group of people that are really good at what they do. Um, and as long as I can get a decent exit outcome from it, then like, it’s, it seems like a pretty good, uh, pretty good deal. And then, and then hopefully it’s a good deal to two X. Cause you know, as long as we keep growing this thing and adding value and adding enterprise value, then hopefully they get their good end of the deal. And it ends up being hopefully like a deal for, for, for both of us and ends up working out.
Finn Thormeier: So besides that, meaning to keep staying at the leading edge, work with the biggest companies, anything else that’s kind of next for the kiln?
Patrick Spychalski: I’m unsure. I mean, our recruiting offer has been growing a good amount, so we’re pretty pumped about that. But I think... We’ve always tried to stay pretty core to our offering because I think it’s something we do really well and it’s something we’re known for. And so I’ve always been really afraid to stray away from that. Our offering is just, we’re going to give you some really talented people to build really cool projects for you. And we feel we have the best collective GTM engineering talent in the world. So we’re giving you that as essentially a service and you get to pay us monthly for it, which is a pretty good deal. Yeah. We always have people on our team who are building SaaS products internally and building cool tools and cloud code plugins. I mean, the stuff our team has built, if it ever was productized, I’m sure somebody would make a lot of money from it. But I tend to let the team develop that themselves. If they want to use it as their own product, they can roll it out. And we use it internally and we roll it out to our clients all the time. So I’ve always been really afraid to like,
Finn Thormeier: All right. This was awesome. If people want to check you out or want to check out The Kiln or 2x, all of the links will be in the show notes below. Patrick, thank you for joining.
Patrick Spychalski: I appreciate you having me. Appreciate it, Finn.
