S2E5 | Data, Orchestration & Activation Layers in GTM with Tariq Minhas & Spencer Tahil

All right guys, welcome back. We are on Behind the Growth Podcast and today we have yet another Growth Alliance partner and his name is Tariq. He runs Cargo and I'm pretty psyched to have him on the podcast finally because we do a lot of awesome work together. But Tariq, I'll let you introduce yourself and Cargo, kind of where we're going to kick off the conversation.

Sure. Thank you, Spencer Tahil, for having me. We've been having a lot of jamming sessions and some client work that we've done together over the last few months. So very happy to speak about all that on your podcast today. What is Cargo? I mean, we're a workflow administration tool. A lot of people refer to us as if Clay and Enattain had a baby, that would be Cargo. If that doesn't make sense yet, hopefully by the end of this conversation it would.

Olaf? Yeah, I was actually just talking to Marcos from another company, another agency in the go-to-market and rev-op space, and he was saying, you know, where are you going? You're making a switch to like a different direction. Like you're not going to be competing with us anymore. That's like kind of good. And I said to him, I was like, yeah, because I'm pretty bullish on Cargo. And he's like, What is that? And that's how I described it. I said like, well, I imagine that for mid-market you're using Clay, N8N, and Supabase. Well, why would you not just put everything under one house and just use Cargo? That's kind of how I've been pitching it. And for me, it makes sense. Yeah, I'm wondering if that's like not a canonical representation of what you do.

It's funny because I've been having very similar conversations with Claygencies over the last few months, and this is not something I would have anticipated maybe 2 years ago, but it seems that something interesting is happening in the GTM engineering world as a process of which people are coming to conclusions about the tools that are the most popular, traditionally speaking, and we're looking for some new paradigm and then some of that conversation involves us. So yeah, that resonates a lot.

For anybody that's listening, Tariq and I actually work a lot very closely together. So it's very interesting that last week we had Frank on from Salesforge as well. And we were talking about, it's like, why this? Why now? And I would love to have your reasoning to like, why Cargo? Why now? Why did you build it? What are we doing? Because I have my own thoughts as a user, as a power user, but maybe you've seen different things in some of the different accounts that you're deploying.

Yeah. Let me give you a short version and then, you know, you feel free to unpack it as you see fit. We at Cargo have always had this view that the go-to-market world inevitably resembles more and more the engineering world. That is to say, a lot of the trends or practices that we've seen in, you know, software engineering over the last, let's say, 2 decades, we're starting to see now in the last 2 years in the GTM world. There's something special happening where there's a new segment of the population that is now getting their hands dirty with engineering work related to GTM. They're more and more confident about tackling more challenges across the revenue funnel. But as the complexity and volume of that work increases, they face realities and constraints that require them to change their paradigms and toolsets. So this is something we bet on when we built Cargo about 3 years ago. And now we are starting to see that, uh, that narrative take shape. And obviously a lot of this is due to the traditional players, so Clay being one of them, N8N being another. You've mentioned Supabase, right? Putting a Firebase equivalent database into the hands of ordinary people very easily. So clearly something is unlocking in the GTM engineering world. And we feel like, you know, we're right in the middle of that conversation.

I think it's interesting because the seat that I sit in, I mean, like how we got involved on the first time was with a client project, um, where I was tasked to deduplicate and reassociate I would say, what was it, like 450,000 contacts inside of a HubSpot environment. And there were multiple companies and we were trying to merge multiple Clay tables. So a lot of like CSV files that we had to export. I think it ended up being, I think like 2 or 3 million record entities at the end of the day. I just couldn't do it. Like I couldn't do it sanely in one place. So I think I had approached you and was like, hey Tariq, can we use Kartra for this? And we ended up building a really awesome flow inside of CARGO. And every time I show that to somebody in the bootcamp, they're like, what, what is this? This, you could do this for revenue operations now? I think it's the way that it's set up, moving, going back to your thought of like engineering, I definitely think like, I hate this title, go-to-market engineer, because a lot of people are saying that they're quote engineers. You need a degree to say you're an engineer, right? But you need to know that you're testing a hypothesis, that you have a specific process, that there's like there's a specific scenario that you're trying to figure out if it's validated or not, then you need to go back and iterate on it. I think a lot of people that are in this space, this like go-to-market space, just kind of work linearly. Like they just say like, we have this template, it's going to work again, rather than, I mean, sometimes it will, not all of one thing will fit into another thing. There's nothing such thing as like one size fits all, maybe a t-shirt, but not like when it comes to like tech stack.

It's interesting about the persona, right? So that's really the center of all of this. If you take the parallel from the academic world, there's always been this debate between physicists and engineers as to who really does science, right? And then there's a whole food chain to it. So there's engineers, there's technicians, and so on and so forth. I think at some point we're going to start having those distinctions also more clearly in the GTM space. It's not very far away.

I hope so. I mean, I think there's a lot of kind of like broken implementations that happen right now. I think I'm seeing it less and less when I come across people that either want to work together or they're they're in a bootcamp, they want to learn more about a specific tool. They're saying like, oh, can we use Cloud Code to do this? You know, Cloud Code is just going like kind of wild right now. But I definitely see people are getting a lot more creative, but I definitely think that the more creative people are by nature, the less organized they might be. And I think you have these two or three different subsets of people that are calling themselves go-to-market engineers. You have people that are coming from sales, you have people that are coming from technical, and then you have marketers. That are interested in money. Most, you know, like everybody tries to, you know, follow the gold rush, right? I am seeing a lot of like broken implementations when it comes to this go-to-market world. Not to point fingers, but a lot of them will use Clay. It feels like an experimental— it feels like a sandbox server when I'm building something in Clay. If I want to like set up like 20 campaigns or 20 A/B tests, I'll do it in Clay. If I want something that's going to run reliably, I'll probably just use Cargo.

At this point, I think none of that should be very shocking in the grand scheme of things, right? Again, going back to the engineering world, there was a time when there wasn't GitHub or you didn't have Docker or Datadog and so on. There's a reason why these tools came up because there were enough people out there who were creating, let's say, more difficulties than what they were solving with their engineering. And then we had to build tools at the stack space and rituals and practices and teams. To make sure we avoided those outcomes. I think this discipline is still very nascent, and so we're at the phase where people are still enjoying entering into this space and being able to, you know, create things with their hands, which is great. Very soon we'll start to see some more standardization, some more normalization of what is acceptable, what are the good practices, and around that, the tool space will also evolve. I was speaking to someone who sells GTM infrastructure, right? So around emails, I can't name them, but if you look at the way they go to market today versus how they used to do it before, it resembles very, very similarly what people in the dev tool space are doing, right? Inevitably, these two worlds do converge. And so this implementation reliability documentation problem, now we start to see it because we've had this explosion of K agencies. People from across the world who found livelihoods building and shipping playbooks, et cetera, to clients, and they need to run in production. And when they run in production, we realized that the technical debt that is created and how to manage that better going forward. So there's a lot I can say about why this technical debt happens. And, you know, it's partly a persona problem. It's partly a tooling problem, but I think for the most part, it's a paradigm problem. We just haven't evolved collectively to that point. If you look at implementations done by people who are coming from actual engineering backgrounds, you can see the difference in the way they ship stuff versus people who've never been in that space, right? And obviously there's good and bad examples on both sides of that persona, but eventually you'll see those two converge.

I think it's, uh, I think it's exactly what you said is, uh, you have different implementation strategies and I think you're seeing more of them come to light. At least, you know, when I'm talking to other agency owners, you know, like they're, they're private closed-door conversations that happen. Like, oh, what are you using? Like, what is, what is the best API to use? And, and I was just just having a conversation with Marcos. I was like, there are, and he said, well, why would you, why would you kind of like pay a little bit more? What makes sense? Like, why, how can you solve what we're trying to do in Clay with Cloud Code or with Cargo? You know, people need to be able to see their data. And I kind of countered and I said, like, why do you need to be able to see it if you're orchestrating it? And it like begs a good question. It's like, are we going into the age of just orchestrating data. Once it's in production, you don't really see it unless you're an engineer or if you're a salesperson, you don't really see it unless it's inside of Salesforce. So that's interesting to me because I'm seeing that across the board. It's like people don't actually want to look behind the scenes unless they're the ones that's doing it, doing the one, the ones that are doing implementation. I can go in our cargo account. I know how it works and how every node works. But, you know, nowadays I'm building half of the time. Jonathan's building the other half of the time, right? I think the order of operations is changing. At least on my side, I'm seeing a lot more people becoming enabled with new tools. Cloud Code is a really big example of this. Like, anybody can pick up Cloud Code, they can insert a JSON, you know, go into to have it build in production inside of n8n. But a lot of people are missing like the strategy or the enablement play. Where does that data actually come up in their stack? Does it come up in Salesforce? Does it come up in HubSpot? So I don't know, it's just like very interesting to open the conversation on, I guess.

Yeah, actually, you raise a very interesting point. So one definite difference that does exist between these two worlds is data in GTM is a very difficult reality. It's very fragmented and is owned by different players. Some of it is yours, first party. A lot of it is third party. It's very pricey. Price is a very strong constraint in the GTM world. And so as a result, you have very little ownership and very little maneuverability. With data, but 90% of the quality of your output is to do with those data decisions, right? This is not as pertinent in the engineering world. And so this is a unique challenge that we have to face. Just as in the engineering world, you have a lot of plumbing, so you don't have to reinvent the wheel every time you need to create an app or a button or some sort of user experience. There's a lot more plumbing in the GTM world that's easy to overlook, but eventually, even if you have your agents building your workflows and looking after them and making sure there's no errors and making sure your reps are fully enabled, You'll need that plumbing to make the system work. The second thing is QA culture, right? Again, data is fragmented, outcomes are fragmented. They're hard to document because sometimes you don't agree on what the right outcome should be, right? Maybe for sales it's different, for marketing it's different. So that QA culture is also missing. And so perhaps that's the— those are the two big things in the order of operations that will evolve.

I can't name who we're working with, but, you know, like over the weekend you guys shipped a security update, like just for us, which also I haven't had a chance to say thank you. So thank you for doing that, you guys. Has like killed it. It's, it's, uh, you know, for instance, like upmarket, a lot of people want full control of their data and they're not going to run hundreds of thousands of rows from HubSpot or Salesforce through a random GPT key. It's just not going to happen. For instance, I definitely think this QA culture is missing in a lot of like creative marketing. It's missing a lot of like marketing strategy because quite frankly, it's not their responsibility to worry about data security, right? To them, all they care about is marketing contact. Did they subscribe? Yes or no? And then that's their marketing, that's their security, right? Like HubSpot will block you. I think going, you know, penetrating the mid-market with like new tools, but are all-in-one tools that are easy to pick up is great. The vast majority of users are going to be in the mid-market or they're going to be consumers. Klay's a great example of this, but I think as soon as you start going into like production level, reliability becomes key, don't have time to sit on a clay table and QA it every 8 minutes to see if a row breaks or if it doesn't fire. And I just don't feel that way when I use Cargo. It just doesn't happen. I get an alert. Yeah, I think we can, we can take this conversation a few other ways. Where would you like to go with it?

I think something that, so we have a partnership channel. So we, we work with people like Spencer Tahil all across the world, right? More and more so. And this targets both sort of mid market companies that eventually are the end users or early stage ones. With mid-market, you have two key patterns that I see. One, the kind of personnel they're going to trust to build what they need is very different, right? It's usually someone with experience. As we said, there's no degree needed to be a GTM engineer, but those key things across the funnel that you need to think about, including, for example, security, is something you're going to pick up with experience. And so that this goes a long way in the quality of the outcome. Secondly, I think a lot of people would like to have better metrics or let's say beacons to know when their stack is in trouble or when an implementation has failed. And from there, the conversation starts with someone like Spencer Tahil to say, okay, how do we fix it? I think probably the GTM engineering world can, can benefit from some education on those two points.

Do you think it's a miseducation issue or do you think it's an undereducation issue? In the, in our industry?

I think it's largely an undereducation issue. It's a miseducation issue to the extent that because we're so focused on adding the next generation of GTM engineers to the world, we overlook the fact of what happens after you've finished your run and you've created enriched data and sent it to a CRM or elsewhere, or you've sent that email. What happens afterwards? What is the human organization that is consuming it, right? What is the— how to work backwards from the ideal interface or experience that the rep has to have from the data that's you've shipped them. I think all that stuff we still undermine, and that's a miseducation because we send people out into the world thinking all you need to do is run a few columns or nodes and the job is done.

If only it were that simple and we could charge hundreds of thousands of dollars to just click a button on a few tables and run a few columns. That would be great.

I mean, so far a few hundred million dollars have been created using just that, but—

I know, but it's crazy.

The market quickly catches up, right? This data lives in the real world. It's pricey. There's real people at the end of it and there's real dollars to be spent buying tools that are marketed like this. So clearly, you know, the market catches up. Not that it's not very slow.

I asked this question. I don't remember who I asked this question to. It must have been a different data partner. I asked them, it was something along the lines of like, you work with, you know, like I'm one of your partners, but like you work with other partners, other companies, right? What if all of your data that you're selling right now becomes absolutely free or everybody can pay for it? Imagine everybody in the market has access to the same exact data, same exact quality, same exact quantity. Where, who are the people that are going to win? What do they have over the rest?

People who can sidestep the data and find something else to create value with, right? It's a, it's a constantly dynamic equilibrium. It's never going to be static.

It's, uh, it's really interesting because they had said creativity and I had said strategy and realistically now it's just about creating enabled people. It's not about, you know, like the headcount, like this phrase, it's like scale without a headcount. It's like. Well, to do that, you need systems and you need people to design those systems. You need people to understand what is not going to get in the way of other people. So anyways, I digress on this, on this whole point.

I mean, I think, and I've seen this happen because we accompany a lot of our partners when, you know, they're trying to close clients selling cargo. Often the fear is, hey, if I'm hiring Spencer Tahil for X months to build me my GTM implementation, whatever that may be, how do I ensure that when he walks away, this thing keeps running? And actually shows an ROI on what we've invested. How do you solve that? I call it the Jenga problem. You've built this stack of Jenga and, you know, as soon as Spencer leaves, we'll touch one brick and everything will fall apart. How do you as an agency solve that perception problem?

I mean, there are different pillars, right? So we can make the analogy of a Jenga tower. Like there are different levels of complexity, but at the end of the day, the tower has to stand by itself. At the end of the day, the person that, you know, that is running the company needs to be able to have the manpower and the knowledge and the technical ability to be able to run a system, or the system just needs to be so kickass that it can run by itself with less oversight. There are two different methodologies. You build a system and then you monitor the system, which is usually the agency model in the go-to-market engineering space. This is predominantly what I'm moving away from, actually, because I would rather just build a system, train you how to use it, and then make you less dependent on somebody. You know, you don't really need to spend money on me. So a good consultant works their way out of a job, right? And then there's the model that I'm moving towards, which is this: time. There's, there's only 3 levers in the business. You have money in, money out, and a time in between. So let's just say the example of this, you have 6 sales reps or 10 sales reps or, you know, 10 people in your sales organization. And let's just say your all-in cost for 1 SDR is like $60,000 a year plus benefits. Let's just scale that to have a full sales team. All in all, 10 people on sales, $60,000 apiece, plus benefits, insurance, everything like this. It's more than $1 million, $600,000 plus benefits, insurance, whatever, about $1 million, give or take, right? In $1 million worth of spending on your sales organization, you have just the leverage of human capital, meaning human labor, the people that are doing calls, people are using a CRM, you have other tech, dev and stuff like this. With a system, what you're able to do is you're able to save them around 2 to 3 hours a day, maybe even more, hopefully. So let's just say out of an 8-hour workday across your whole team, if we can save on meeting prep time, we can save on data consolidation time, we can save on the SDRs on doing research for upcoming discovery calls, or we can empower them inside of Salesforce. Let's just give or take, we save them 2.5 hours a day, 30, 1/3 of their, of their day, like this, just via proactive automation. The end of the year, what is your cost? What is your cost on that time saved, right? What is the benefit of not having it? It's 1/3 of a million dollars. So that becomes the leverage point, right? So if I'm going to go into a sales org and I'm going to say, I'm going to build you a system that in 12 months' time, you're going to— in 3 or 4 or even 6 months' time, you're going to have leverage and you're going to have empowered reps with more information and you're going to have it in a third of the amount of time. So net-net, you save this amount of money, save $333,000 a year, and you pay me less than that, right? Whatever the multiple is going to be. Whether it's going to be 50, 100, whatever, but I get it done for you in 3 to 6 months. Now, net-net, you've just been empowered, you're empowering your team with systems and you're saving that amount of time in the long run because now the system belongs to you, you have your own proprietary data. So I think when it comes to working with different clients and like talking agency approach, there's only really two models. There's the dependent model, which companies are paying other go-to-market engineers right now to be able to sit on their systems, QA it, everything like this. These are, these are teams that don't have the time to do the execution or the enablement. And then you have the teams that have the manpower, they have the revenue operations specialist, they have the CRM designer or the developer, right? They have a Salesforce team. What— why do they need to keep paying me as an agency? They don't. So why should I not just build the system for them fractionally? And I think like this is the model. That we're going to see bridging the gap. We're going to see the gap expand. We're not going to bridge the gap. We're going to see the gap expanding because a lot of people are just going to stay on execution. They're not going to be hearing of Cargo yet because it's just maybe it's not on their radar. They're going to use Supabase. Oh, and it's unfortunate because you're going to see that gap get wider and wider and wider between the top and the strategy and enablement versus just execution. So I think— I don't know if I answered your question well, but the conversation usually comes up with how much are you looking to have your team being empowered versus how much are you willing to delegate for the next 6 months? And that's usually the question that I usually ask people is like, are you guys ready to delegate all of these tasks or do you want to own these and you want to have support? And I think that usually delegates the working engagement.

Absolutely. I think there's a good recipe there for how to build your engagements with your clients. And I think the best people that I've seen in the business, they do 2 things to close this loop. Number 1, they make sure that there's easily accessible quantified reporting on the impact you've had. So if it's sales productivity, if it's data reliability, whatever. And secondly, they build a very good alerting system so that when things go wrong or when they're not hitting their targets, the team has a way of knowing that's happening.

I think it's important to also add in here, there's usually only like 3 parts that I'm like looking at. And I think we were talking about this over Slack. It's like you've got like data and then you've got manipulation and orchestration, and then you have activation. And I think in that order you have the data layer and then you have the orchestration layer and then you have the activation layer. And in my book, I justify your strategy throughout all three of those. But data is— data is everywhere. It's about what you do with it. What is the insight? You know, everybody has access to the same data, whatever. Big whoop. What is the action that you can take or how are you going to orchestrate it to get an insight or an action? Nowadays, people run the same playbook. They're just going like, oh, we have like Apollo data, we got to put it through Clay. We're going to use BuiltWith to figure out what tech stack they're using. We're going to run it through another one to see if whatever they're running ads. Customize the playbook, send it down a LinkedIn request, and like, that's your flow. But there's so much extra data that can be out there. What is your creativity? So why did— I know that in Cargo, it's designed at the data layer and the orchestration layer a little bit different setup than Clay. You want to walk through that?

Yeah, I mean, this is a deliberate design decision, which seems trivial at first, but then as you build more production-grade scalable things, you realize the power that's unlocked when you separate data from orchestration to activation, right? The flip side is, and this is the case for, let's say, easy-to-use tools like Clay, where this is all packaged into one sheet, right? And that's great because that allows 95% of the market to use it very easily without having to do a lot of training. When you separate these, of course, the training is higher. It's like between the difference between an automatic car and a manual car, but it gives you a lot more leverage on each of them. So the data part, you have a lot more leverage on which data you're using, how you're governing what gets enrolled and what doesn't, how you're keeping observability, you know, the impact you've created with that data. Then the orchestration being separate means that you can do a lot more heavy lifting as you would in an engineering context without having to worry about the constraints of the tool. You can literally write JavaScript if you wanted to inside the tool. Most people don't, but you can. And then the last part, the activation part, right? So that's where actual people involved. So accounts are being assigned. Assigned, contacts are being assigned, people's daily capacities for how many accounts they should have is being managed and things like that. So you, we give a lot more power to our users on each of those verticals, which requires a bit more ramp up than you would with a simpler tool. But then for people looking for sophistication, that's a godsend.

I think, I mean, this has almost turned into an ad for Kartra, but I'm a very big like pencil pusher when it comes to like tools I like really love, but we were building something And I think you've seen it inside our account. We were building multimodal agents that are doing like multiple sub-agent flows inside a workflow with the same, like one host standing trigger with an RSS feed. And then from there treating all contacts or all companies the same. It's very malleable in the way that we could work. I just, I would have to do that in an AI. That's an automation tool. I don't think a lot of the marketing teams are ready to start coding. They're not ready for the technical adaptation of what their job could be. But then again, like AI is just a tool. So that's what I told you is like, I can build in Clay, I can build in Carter, I can build in NN. To me, it doesn't matter. It's just matching the right tool to the job.

Yeah. And often it shows up in different ways for different people, right? So maybe you care a lot about error handling, right? You want to have a very good handle on those errors. Every time that you have, let's say discrepancies in what you expected the outcome, you work backwards from there in the historical runs that you've made. And you want to make a query on the types of errors you've had, what fixes you've made on them, report that somewhere. So you've documented the version changes and then push that back. So just because you can do that, now this can become your preference for using one tool or the other, right? We hear a lot of different opinions on why this separation of these three verticals has benefited people. And it's usually from people doing either very sophisticated things or very high volume things. So agencies being very much represented in that for the latter category.

Yeah, I think there's a lot of like I think there's a lot of questions that a lot of marketers have to ask themselves now. It's like, you know, what are the use cases that you want to manipulate data for? What are the production-grade capabilities on your team right now? Do you even have like a no-code workflow builder tool? If not, then what are we considering? What are the constraints of manipulating data? Do we have to abide by HIPAA? Do we have to abide by, you know, GDPR, you know, data handling or anything like this? And then that's just not even diving into like security with moving around like PII and European Union or so on and so forth. So I think, I think now we're seeing a really big overlap between like tech, legal, and marketing. It's interesting, but it's all coming back to go-to-market and like enablement. I just call it like modern go-to-market engineering sales enablement. I think it's a better title, in my opinion.

Absolutely. I think so if you take an anecdote of, so this workflow that you've mentioned, so the, the contact association screener, as we call it. We first came up with this for a client who is one of our early clients. He's an engineer by background. And so this person, I mean, if you look at the flow, it's not very complicated, right? If you're good at scripting and managing data, maybe you could have written this in-house, but really the complex part of this workflow is that it's something that has to run at very high volume regularly every 2-3 weeks. And the outcome of this workflow is that reps are going to think differently about the accounts they're handling because of the contacts that they're exposed to. Right. And so. The observability advantage of doing it that in an abstracted tool was the reason why that company, which has the resources, enough resources to, to engineer that in-house, decided to do that in, in, in Cargo, right? And so when you came along and you did the same, you can just build that for your client and sort of go away until you receive an alert that something is going wrong and go back and fix it. So I feel like a lot of that requires those three verticals to be separated, which is not an obvious reality in all the toolsets out there.

I think, I definitely think there's a future to be had in data manipulation and orchestrate, like, and more or less, I'm like, this word is like orchestration. It's orchestration and enablement. I don't think it's just like data and activation. I think we're, at least from my side of the market, I'm seeing a lot of like teams not want to send automated outbound emails for some reason. Like they don't want to. And for good reason, like most of it's spam, not going to lie, or send that LinkedIn message. I do think that we're seeing a lot more like pushes on like context layers, like queryable context layers rather than just like tool-based approaches or like tool reliability. I spun up another instance of Cargo for this. We were, we were trying to not lock them into specific data vendors, but adopting a new tool where adopting a new tool takes time. You might as well just do it all in one. I would hate to bounce between like Supabase and N8N and stuff like this. So I just do it all in one place. I think that the future, and I would love your opinion on this, I think the future of our industry depends not on the tools themselves and not on the data, but I definitely think it's whoever's not the fastest, but whoever can do it the most securely and the most consistently with creativity.

I absolutely agree. So context really is king. I think in the last few months, we've seen our colleagues in the space having a field day with building context layers, for example. You know, getting Claude to query your, some Markdown files that have maybe your transcripts, all the semantic data that you've accumulated about your business and using that to automate a lot of the actions that you would waste time on normally. And I think that's a great step forward. I think the next hurdle in this process is how do you manage large amounts of sort of tabular data that is coming from your systems of record, right? So your CRM data, maybe your email activity data. All of those, maybe your product uses data, all of those high-volume sort of product databases. How do you make an efficient way of querying that data, pulling it out, retrieving it, mixing it with the right semantic data and giving you this complete context that's needed? I think this is still the missing piece in this sort of context layer. And once we really crack it, I think then we're at the advent of that new sales rep interface, because then you've given the rep the ability to write a prompt. And get back all the intelligence they need to make intelligent outreach.

What we've been building for our clients is something similar, but it's still very custom. I can't say like every single tool that we're using, but where reps live, for instance, is going to be one of two places. It's going to be inside of the CRM or it's going to be inside of Slack. Outside of that, they have no interest in doing anything other than calling or, you know, going to events and stuff like this, right? What we're doing now for instance, is calling our agents via Slack interface. So we give the agent access to a channel and then every single time something gets posted in that channel, whether a user's going to, you know, a user will type in, show me everything about this account, then this will fire basically, and it'll fire into a context layer and the context layer will then go query Cargo Agents and it will query the vector database and it will query HubSpot MCP XYZ XYZ. This is what I love it for because then the user, like himself or herself, like they don't actually have to leave their process that they're already like, they don't have the platform switch, they don't have to context switch and they have everything threaded back. I don't think it's worth our time to train new people, or at least for SalesBase. I don't think that it's worth your time to train your people on a completely different tool that might become obsolete. And I don't know, like 5 or 6 years' time, right? Now they have to go learn Outreach. Now they have to go learn Apollo. Now they have to go learn, like, how to use Clay. I don't— I think that's stupid. I think you should just not disrupt the workflow that's already there. You should integrate into that workflow with more capabilities. And depending on what the information or the context that you need called back, you design your system around that. If it's, if it's context-aware and it knows which MCP to call and what content and, you know, what data to get from where, then it's a perfect system. I've yet to build a perfect system, but I have built, you know, the context-aware systems that are able to pull the right data from everywhere, right?

I think you're absolutely onto something there. We see in the companies we interact with, some of them are our clients, who are very good at making one, a reliable, clean, unified data layer, and then layering on top that semantic context layer. They have a much easier time attacking that last mile, which is making that interface for their reps. So they don't have to be tool dependent, including the CRM, but they can just query the right data at the right time and get what they want, right? Because in the end, that could be a very easy no-code implementation if the data foundations and the semantic context foundations behind are done properly. Unfortunately, most teams have not done that. Even very good logos out there have the problem of just not having good layers behind it. I think that's, that's a big opportunity for the agency world as well to attack that first mile so that companies can easily do the last mile for building interfaces. And maybe those interfaces will always be custom to those companies. Maybe there'll be a tool out there that will build the perfect interface. So we can move on from the, the sales forces and the outreaches and all these traditional tools to a better interface that resembles sales reps better.

Yeah. I think there's just a game of what information do you want and when do you want it and how often do you want it? It's like, I always tell these people, like, whenever I'm doing my discovery or these companies, I'm saying like, what data— when we're talking about like revenue operations, like manipulating people and company and entity data record data, I always say to them, I was like, what data changes? Why does it change? When does it change? And who does the information go to and how? If you can answer that question around data every single time consistently, then you should be able to build a system around it. It's like, for instance, what data changes? This custom field where, I don't know, the HQ of a conglomerate or umbrella firm, why does it change? Or, you know, like what, what changes? When does it change? Every 6 months to a year? Okay. Create a cron job that runs every 6 months or every June, every December, every whatever. Wait for 6 months. Why, why does it change? Because it's, we need to understand where the company headquarters is for either like invoicing or, you know, just for attribution or whatever assignment into the reps or whatever. Who gets assigned the data or the context when it comes back? It's AE from the United States. Okay, great. How does it get delivered? Via Slack message, or maybe it just updates the Salesforce instance. I think if you can build a system, if you can think about problems in this sort of systematic way, doesn't matter if you use Clay, Cargo, N8N, it's a systems thinking. I'm not seeing a lot of this in the market. I'm not seeing a lot of this on LinkedIn. Because people, people don't want to share their shit.

Also, I think the science is not yet developed, right? So we know some people who are doing this well, but it's still far from being a science and it's also far from being a priority. If I add one more point to that, the best people leave behind a system which is very easy to reconcile. So the revenue leaders in that client organization, when they're asked a question about the data, but a trend, they can easily answer it from the data that they have at hand. So The tooling is done in a way that, you know, is conducive to that. Thinking backwards from there is a very difficult architectural reality that most people have not.

I'm not saying I have.

Neither, neither. It's difficult.

As I said, it's difficult. I think like all businesses with the same problem. Well, not all businesses and not all the same problem, but I think a lot of businesses have very similar problems. That's a better statement. And most of them come from visualization, seeing the data. Or seeing information and then data quality themselves. Where is it? How is it stored? Everything like this and the connectedness of that data, whether that's going to be market intelligence or third-party data that you're talking about versus owned, like first-party data, which is like people that have subscribed to your newsletter. Hey, great people that are inside of your CRM. What is the connection? And I think like we're just getting by right now where a lot of people understand, oh my God, I can take that signal or I can take that funding round. I can take all that information, I can plug it in Salesforce and I get them on my radar. I think That's the GTM movement where it's— you're connecting third-party data to first-party data, but now you've given all that engineering power to the marketers and the salespeople and they're like, oh my God, got to build a system, put everything in the same thing, and now it's disorganized and great. How are you going to dedupe all of that? So then it comes down to data quality, right? Where all of your buying, like buying committee— why is this buying committee in this company not the same as the buying committee in the same category in the vertical in this company? Everything is custom. So you can't use templates. Well, you can't, you can use like recipes, but it's not always going to work.

And you know, what's interesting is agents are intervening earlier and earlier on in that revenue stack, right? So whereas before we would have them doing mostly last mile stuff, so maybe compose a message or classify reply, et cetera. Now they're intervening much more earlier in that process. And if you can't explain simple data interactions, good luck explaining why an agent really upstream in the cycle decided X or Y that led to a monumental impact. Further downstream, right? So the more we involve agents into all of this, the more important it becomes to have that handle.

What do you think is something— what is a hot take that you have in our industry right now?

So this is very topical, but I think GTM engineers, particularly people, you know, who sell services, advisory services, we're very prone to sort of fad GTM ways of thinking, meaning that there's something out there today and, you know, a few people pick it up and then everyone has to pick it up to join the club. And, you know, 6 months later it's going to be something else and so on. And we've seen the cycles, right? At one point it used to be certain signals and everyone thought that was genius to be tracking a certain signal or not. Now it's a commodity and so on. I think with ContextOS and Claude, you can easily believe that the real depth of the opportunity lies in how you can engineer GTM systems. And I think there is, there is a point to that. I think the bigger point in my opinion is what it really transforms. If you give that context to us, to the sales rep, this is 90% of the opportunity out there. So it will marginally change some things for GTM engineers. I think they will still need a lot of plumbing. Ways that they will manifest their engineering behaviors will probably improve given this, but really the revolution will be in how the sales reps do their job. And I think we haven't yet gotten to that point of the discourse.

Interesting. It's very hot. It's very like right on the nose of what we were just talking about offline. Um, okay. I think, yeah, I won't, I won't disagree with you. I think people are focusing their energy and their marketing and like go-to-market engineering agencies are focusing their energy where it shouldn't. I mean, great. Keep bumping up that mountain, but I don't think they see the big picture. They don't see the enablement part, like where does that SDR, that AE go to look up data? Are they opening up their own instance of GPT on their, you know, on their browser and saying, hey, show me everything about this. But the question is, why should they have to do that in the first place? Why are you not proactively, agenticly solving their needs? Where's the disconnect between what the AE needs versus the SDR needs versus what marketing needs, you know, and works well for me because I solve that problem. But I think a lot of people fail to diagnose the problem and it, you to do your work properly, you have to put that agent way up in the qualification phase or the research phase. So, you know, just my two cents.

I think it's also very natural, right? So for most of us, these are new capabilities that are very exciting. And so first we need to play with them, understand what the constraints are, what the possibilities are, just for our own sort of limited selves, even just the way we operate our daily lives or businesses and so on. And from there you can maybe draw the parallels to how a sales rep does their job and think in the enablement space. So it makes sense that most of the buzz is, you know, around the GTME using that technology. And I think very quickly it's going to become an enablement topic because the best people are onto this and they're already building that for sales teams.

It'll be interesting to see where this goes in the next 6 months. It'd be very— because, you know, like today we have ClaudeBot with zero security parameters in place. And, you know, yesterday we had ClaudeCode. And now that's the hot topic now. I guess 2 years ago we got Clay, right? What is going to be next? Is it just like type into Cargo, build my whole go-to-market motion and look at my OS playbooks and everything is going to get pre-built based on custom parameters? You know, maybe. I hope so. Makes my job easy. But I think it comes down to what data does this have access to? What gets provisioned? What is the strategy in place? What are the general outcomes? Yeah. I like the industry. It's fun. It's always a new thing to do.

I think it's a very interesting time for tool providers like ourselves to think about this. If you think that the medium of interaction with your computer or data out there is going to be context/prompt-based and systems you're going to build are going to be working backwards from there, then maybe what we serve more than the interface that we provide is more the sort of the libraries and the frameworks that we've built. To manage plumbing in GTM so that we can render that in an open way to people building for the contextless world, right? So just like in the coding world, you have libraries that dozens of people are maintaining for each of them over many years. Perhaps this is the future of GTM tools to some extent. So let's see. I'm always afraid with these things in 6 months, I might have to eat my words, but I think there's definitely something interesting here. So, you know, I'm just putting out there my half-baked thoughts and let's see if they mature into something interesting.

We're going to do it. Another rhyme, but you're like, somebody's going to clip this in like 6 months back. I told you, I told you. Anyways, we've been chatting for quite a while. What's one piece of advice that you'd give to any go-to-market engineering and/or revenue operations team today, knowing what you know now?

I always remember, I think it's a Steve Jobs quote which says, if you want to build value in the world, work backwards from the experience of the end user. This might sound cliché, but I feel like it's not as well integrated. In the GTM mindset. People often forget in the excitement of the tools and the frameworks that we have, that at the end of the day, it's the experience of the end user, which is the sales rep in most cases, or if it's an automated bot, maybe the recipient of whatever outreach you're making, that you have to work backwards from. The moment we do that, the moment we become more like experience or product designers for our GTM, you certainly become better GTM people. And I'm not saying I'm one of them, per se, but the people who I really admire are usually mastering this capability.

Where can people find you, Tariq, online?

I'm pretty reactive on LinkedIn. I post from time to time. If you're someone like Spencer, basically, we have a Slack connect, so which we're very happy and reactive on. So ping me on LinkedIn, reach out to me via email, it's tariq@cargoadvisory. Let's get connected on Slack.

Guys, by the way, they're very good partners. I'd highly recommend. Very, very quick to respond and build new things. I recommend, like, again, I don't have enough good things to say here. So, um, Tariq, thank you for coming on. Maybe next time we get Arroyo or Max on too, but it's been a pleasure.

Absolutely, always a pleasure working with you, Spencer. Thank you for having me.