The Data Stack Show - Re-Air: Data Tools, Templates, and the Trouble with “Easy” Solutions with the Cynical Data Guy

Episode Date: March 11, 2026

This episode is a re-air of one of our most popular conversations, featuring insights worth revisiting. This week on The Data Stack Show, John and Matt bring you another edition of the Cynical Data Guy. John and Matt dive into the evolution of customer data infrastructure, the growing influence of low-code tools like Clay, and the blurred lines around the “engineer” title in modern data roles. They also discuss the trade-offs between SaaS adoption and building custom solutions, the pitfalls of enterprise software buying, and the realities of platform lock-in—using Palantir’s unique business model as a case study. Key takeaways include the importance of simplicity and scalability in data engineering, the need for clear requirements when evaluating tools, and a healthy skepticism toward sales pitches and “art of the possible” features. Don’t miss this month’s Cynical Data Guy.  Highlights from this week’s conversation include: Reacting to the Rise of the GTM Engineer (1:11) Is "Engineer" the Right Term? (4:49) Low-Code Tools, AI, and Future Workflows (7:14) Simplicity in Data Engineering (14:38) The Pitfalls of "Simple" Solutions (15:18) Choosing SaaS vs. Building In-House (18:26) Business Process Abstraction and SaaS Adoption (21:31) Enterprise Software: Art of the Possible vs. Practicality (24:31) Sales Advice: Focus on Customer Needs (27:11) Forward Deployed Engineers and Delivery Models (29:05) Platform Lock-In: When Is It a Dirty Word? (36:41) Legacy Systems and the Reality of Lock-In (39:53) Final Thoughts and Takeaways (40:55) The Data Stack Show is a weekly podcast powered by RudderStack, customer data infrastructure that enables you to deliver real-time customer event data everywhere it’s needed to power smarter decisions and better customer experiences. Each week, we’ll talk to data engineers, analysts, and data scientists about their experience around building and maintaining data infrastructure, delivering data and data products, and driving better outcomes across their businesses with data. RudderStack helps businesses make the most out of their customer data while ensuring data privacy and security. To learn more about RudderStack visit rudderstack.com. Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.

Hey, everyone. Before we dive in, we wanted to take a moment to thank you for listening and being part of our community. Today, we're revisiting one of our most popular episodes in the archives, a conversation full of insights worth hearing again. We hope you enjoy it and remember you can stay up to date with the latest content and subscribe to the show at datastack show. Hi, I'm Eric Dodds. And I'm John Wessel. Welcome to The Datastack Show. The Datastack Show is a podcast where we talk about the technical, business, and human challenges involved in data work. Join our casual conversations with innovators and data professionals to learn about new data technologies and how data teams are run at top companies. Before we dig into today's episode, we want to give a huge thanks to our presenting sponsor, RudderSack.

They give us the equipment and time to do this show week in, week out, and provide you the valuable content. RudderSack provides customer data infrastructure and is used by the world's most innovative companies to collect, transform, and deliver their event data wherever it's needed, all in RutterSack. real time. You can learn more at rudder sack.com. Welcome back to the Datastack show. We're here for our monthly installment of the cynical data guy. Matt, welcome back to the show. Yep, I'm back. All right, we've got a few LinkedIn posts to react to. Matt, I'm excited to get your reactions to some of these. Got some juicy ones. So I will jump in with the first one right here. And let's see. So this one, this one I really enjoy. This is from Josh Hansen. He does data at Clay,

which is a marketing automation company. So I'll read it. As a data nerd, the rise of the GTM engineer championed by Clay feels a lot like the emergence of an analytics engineer ushered in by DPT Labs. In both cases, a tool arrived at the perfect time and perfectly solved the problem teams were facing. Data people rallied around DBT and it quickly became a core part of the modern data stack. It's now nearly ubiquitous. Now, RevOps, marketing ops and sales ops are seeing something similar. The GTM engineer powered by Clay is becoming the go-to-solution for the complexity and fragmentation and modern go-to-market workflows. And then today's fundraising news is a testament You know, Clay raised $100 million at $3.1 billion evaluation with a link to an announcement.

So I know you're not a marketing guru, nor am I. I'm curious to your reaction to the analogy here. But I have worked in a marketing department before. That is true. That is true. I've actually worked in two marketing departments and quickly moved out of both of them. Yeah. Yeah, what do you think?

I mean, one of the things I kind of wonder is like with DBT, you know, when he talks about what's going to be, it's like the emergence of the analytics engineer. Well, we're now talking about if that's going to disappear again and just be absorbed. Yeah. It's the same thing going to happen with this GTM engineer. Like it's a luxury for a moment. And then people go, wait, why are we paying someone to just do this? So this is going to show probably my ignorance of clay because I'm not a clay expert. I've seen the product maybe twice logged in a couple times. So not an expert in it. But from what I've seen, it looks like it's primarily kind of a low-code tool where you can enrich data, take data from multiple places. So if you have a leads list, you wanted to enrich your leads list, it can do that. And plenty of other cool workflows, I think. But in my mind, I put it in that low-code business user data tool category. So, Clay, if you listen to this, somebody from Clay, I love to have you on the show to set us straight. But so that's the bucket I put it in.

And I think the analogy, I get what he's saying and that we're talking about, we've got this analyst persona. We built this like tool that felt native and like, yes, as an analyst, like, this is great. This is how I want to work. And then I think the analogy here is like, oh, like we've targeted this other group. You know, we've got this tool. It, you know, enables them somewhere to DBT. So I see that on one level.

On another level, because we're talking about data, and this is the data stack show, there is kind of a reaction of like, well, what about the data team? Because this is essentially in one of those, not that it can't complement like a data strategy on a data stack, but it's also essentially one of those tools that is, let's call it maybe augmenting for failures in the data stack.

Yeah. Where like ideally you'd have flows and all this stuff gets enriched automatically and you've got pipelines and then it all magically shows up in the places it needs to be. if you had to fully kind of implement a data stack. So I actually see, I don't think this is completely fair. I do think it could complement a pretty well built out stack,

but I think practically it's actually typically covering for gaps. Yeah, so that makes me wonder, first of all, should engineer be in quotes? Like, you know, if we're talking that kind of low-code thing. The other one is, I mean, I don't have extensive experience in this type of space, but I do know that if you're dealing with a lot of, lot of marketing stuff. Like, yeah, you're covering for gaps.

You're covering for gaps because the products are all terrible when it comes to data. You know what I mean? So it's like trying to get stuff out of any of these platforms is a nightmare. None of it works well. None of it was because it was never designed. It was all designed for marketing people to try to like them in their little walled garden and stuff like that. So maybe it's needed because every, you know,

because you're dealing with 12 different SaaS companies that, all organizing their data properly. Yeah, and I do think that's a big component of the success here is you've got Clay, and then you've got four different solutions for data enrichment that you use because one's better at this, one's better at this, one's better at this, and then you've got, you know, you've got your CRM, you've got your, you know, tool like an outreach or, you know, you've got all these different like sales and marketing related tools. And I think Clay does have an interesting spot there.

but I also just think conceptually, but the engineer part, I guess, it's like, well, is this person actually an engineer? Because there's this, like, I think there's this future where, and this is probably biased to SaaS companies. I think maybe it could be different in more standard companies, but there's eventually just going to be a, continue to be a standard level of technology usage ability that I think most people will have. And I tend to at least reserve engineer for somebody that would be doing more than just using a low-code tool, which maybe Clay has some more advanced scripting that I'm not aware of. So I don't know. I'm not sure about the engineer part. DBT is a lot more of a technical tool from what I've seen than Clay.

Yeah, I think we've seen a little bit of the downgrading of the term engineer over the last decade or two in general. Yeah. So I think this is, I agree with you. If we're talking a low-code tool, like, you're not, we're not engineering at that point, guys. I don't know. That's not what we're doing here. If all you're using is a mouse, you're not interested. That's not using as a mouse.

Well, but I do think it's interesting because I assume the tools like Clay will continue to exist and they'll continue to integrate AI stuff into them where it's like, you just tell it what you want it to do, like connect these two things. and you're not even like primarily pointing and clicking, you're just kind of like reviewing the workflow or, you know. Then we'll call it vibe engineering. Vibe. What is vibe low coding? We need a term for that because it's not, you're not, I mean, you're engineering kind of, but not really. You're like vibe configuring or something, I don't know.

You're like low vibing. So maybe in hybbing. Live. Perfect. Yeah. So yeah, that, yeah, anyways, I thought it was interesting. And I mean, the other thing that, the other thing for the space is the AI MCP server stuff, is if all of the things that Clay connects today all come out with MCP servers, like, does that reduce the value of like the low code clay thing?

Because essentially you can like more easily, you could, that could potentially open the door to more easily interact with some of these APIs that are not very easy to interact with. Yeah, I think that world is still very, that feature is a very, That future is very muddy still at this point. You know, it's, we're not, are they going to take, or all of these NPCs is going to take over, or is it going to be, you know, some other thing?

We just don't know at this point. So it's one of those, I think it's one of those hard things where it's like, well, what am I supposed to build? I don't know, make a choice and kind of go with it, I guess. Right. All right. You got one for us. Yeah, so this one's a little lighter.

This is from John Cook, who says Microsoft is basically forcing me to use OneDrive and have everything auto saved to the cloud. You youngans will never know the pleasure of figuring out which downloaded version of an Excel file has the latest updates. Or I will point out which email has the latest one in it. So, yeah, I think that's one of those. I will tell this story. When OneDrive first came out with the auto save and they were starting to push the like,

you know, oh, don't attach in an email. Just share it. and we'll show it like it's an email attachment. I thought it was great until I actually sent it to someone and nobody had any idea what they were doing with it, first of all. The second problem was, that's great at this idea of like you're going to collaborate except for the fact that then when someone goes in

and completely changes everything in yours because they don't realize it's a shared document anymore. So that's one of those disadvantages that I saw because I was like, oh, this will be really great. Oh, wait, no, attach everything. Don't do that. Yeah, I remember when it first came out too, and this is probably still true, but especially when it first came out, nobody could get permissions right the first time, so you never

had access to whatever somebody tried to share with you. That was the best one. That was the best one when they would email it, and yet no one could actually open it. Yeah, yeah. So that, I think that is easier slash better now. But the second point that you just brought up, to me is like the classic accounting. use of Excel of like very important that this is a locked in time, place, space that the numbers never change. It's the end of the month, whatever. And that still does not jive very well with

this like OneDrive. Like we have versions of each thing. Like most of the accountants I've met still hate that. It will like specifically, they may save it to One Drive, maybe, but they'll specifically have it saved in whatever folder locked in to whatever date and like if they're really savvy you might get like a read only view of it but like they're probably just still gonna send you a spreadsheet with a

that's not on one drive so well and I mean you still go through the same thing especially if you're collaborating on something and you're going through multiple iterations even if it's just you sending it to someone is multiple iterations of something right inevitably you get a oh I asked you to make

this change but I don't like it want to go back to the other version. And now you're like, okay, crap, okay, let's go through here. That's the versions. What time was it that I did this? No, I don't want to revert. I want to download it separately and then open it and then try to figure out what was in there.

So you're kind of trading one off for the other in a lot of ways. Yeah. Well, and here's the other thing. And I admit I haven't tested this in a while. Google's the best with this. But I haven't seen in the Microsoft product suite or some of the other product suite, that they really have a good complete version history.

Like if I try to roll something back, like, it's always like, I feel like it's either like collapsing changes so I can't like quite tell where I want to roll it back to or I'm like, or something,

something is going to be best up. I haven't been very successful trying to roll back like Excel documents to a certain. Especially in those early days. I feel like they were a little bit like working with Power BI in the early days where it was like, this is going to be great.

Oh, wait, what? That did do what I wanted it to do. Yeah. Yeah, I expect it's better now, but I definitely had some, like, I need to like revert this back to yesterday or a couple of days ago, and it did not go as planned. So hopefully that's better. So that's one.

If you use this now and you know that it's either better or it still has problems, let us know because I haven't used Office in like three or four years at this point. Yeah. Not, don't really miss it. Other than charts, it's the one thing I posted on that recently. Nothing works as well as Excel when you want to create a really specific chart for presentations. Because you can literally change every individual element independent. That's great.

Other than that, don't really miss it. We're going to take a quick break from the episode to talk about our sponsor, Rudder Stack. Now, I could say a bunch of nice things as if I found a fancy new tool. But John has been implementing Rudder Stack for over half a decade. John, you work with customer event data every day and you know how hard it can be to make sure that data is clean and then to stream it everywhere it needs to go. Yeah, Eric, as you know, customer data can get messy. And if you've ever seen a tag manager, you know how messy it can get. So Rudderstack has really been one of my team's secret weapons.

We can collect and standardized data from anywhere, web, mobile, even server side, and then send it to our downstream tools. Now, rumor has it that you have implemented the last. longest running production instance of Rudder Stack at six years and going. Yes, I can confirm that. And one of the reasons we picked Rudder Stack was that it does not store the data and we can live stream data to our downstream tools. One of the things about the implementation that has been so common over all the years and with so many rudder stack customers is that it wasn't a wholesale replacement of your stack. It fit right into your existing tool set. Yeah, and even with technical tools, Eric, things like Kafka or PubSub, but you don't have to have all that complicated

customer data infrastructure. Well, if you need to stream clean customer data to your entire stack, including your data infrastructure tools, head over to rudderstack.com to learn more. All right. Again, another one for us. Let's see. This one, simplicity, wins, and data engineering. My simple rules, three rules. Number one, build data pipelines that are simple and efficient. I rarely use more than Python and SQL to solve 80% of the problems I see every day. Number two, choose SaaS instead of building from scratch. Dramatic gasp, managing your own infrastructure can be exhausting. Number three, you want simple solutions that can grow.

They provide clear answers to business problems and tackle real questions without slowing you down. Master the art of simple data engineering. Yes, so simple. Build, build very simple things. Also, make sure they can grow for you. Huh? Like, probably most of the worst data engineering infrastructure I've worked with was because people just tried to build, like, simple, quote, unquote, for the moment.

And it completely locked them in, was hard-coded everywhere. Right. Nothing worked. And it was like, oh, but it's just SQL. Yeah, it's terrible sequel that can never be adjusted easily and can't grow. So, yeah. simple but in contradiction with each other and intention. Yeah, I think I know what he's getting at here and there's a level of sophistication and experience that brings about simpler solutions

that are also still good and scalable. Just because you have done it a lot of times and you understand it deeply and you can simplify because you understand it deeply. I think I get that angle of it for sure. But the flip side to what you're saying, I think is a lot of people are saying, Oh, I want simple. We just did it simple. We just did a DOC. We did a rough drill, like whatever you want to call it,

which all of those are good. But essentially some of those can creep into production, which effectively means there's no plan. We hard-coded a bunch of things. We don't have any like version control. We used, you know, the tools we had without considering anything that might be the right tool for the job. Like that version of simple.

I do like can definitely get you in trouble. Well, and also to go with that, I think that as you get better and you, you're going to get, acquire more knowledge and expertise in this, your idea of simple is still going to look complex to a new person in a lot of ways. Like you've jumped a lot of stuff down because I mean like, I even back when I was like an analyst,

I got into the point where like I had a set template for every analyst project I did. Right? And I'm like, it's really simple and it straightforward and it keeps it going. Then I, you know, one company later, I'm managing people and I'm like, you know, you just got to keep it simple like this. And then I looked at it and they were like, oh, because they were just right and just, you know, just yolo in it every time. And so the idea of having to deal with any structure in it was not a simple solution. It was this massive friction to them. Right.

I mean, it was a friction that was born out of kind of, you know, for lack a better term, like ignorance. Like, they didn't know that there was a better way. Or to them, it felt like it was going to be harder because they weren't looking at the total cost over time. Right. So I think that's one thing that gets people, it's kind of a curse of knowledge in a certain way where it's like, this is simple. Just do, just keep it simple. And it's like, you have a better understanding of what simple is in a long-term picture than these people do. I think the other thing that we have in here is the use SaaS,

which I would agree, whenever I hear people in there are like, well, why use that? We can just build ourselves. Like, I don't want to be, I don't want to maintain my own servers.

No, thanks. Nope, that's just a no. But if you're trying to stitch 12 SaaS things, platforms together or tools, life can hurt a lot. Yeah. And also the fact that,

I think the hard part was saying, like, go with SaaS instead is there's a lot of situations, especially if you're going into new stuff you want to do. You don't actually know, like, what you need from a SaaS platform or what tool is going to work best or things like that. And trying something on your own, even if it's just like Exploration POC, can help you understand, oh, this is what I actually need out of it. Yep. and people get themselves tied up in knots because they're like,

oh, no, we got to go buy it and we got to go figure it out and all that stuff. And it's like, well, but you don't really know what you want. So it's going to be real hard for you to make a good purchasing decision. Yeah, I'm actually experiencing this right now of, especially when you're introduced to a tool and a category you weren't aware of, it is really challenging to do requirements for that. Because it's like, and to like sort through sales pitches and like,

how is this valuable? How is this not? So I'm actually experiencing that right now where, you know, really great sales pitch. This tool like does big laundry list of things. Like it's, you know,

it's going to be a really great tool. And yet the, it's actually really, and this is close, Well, let's call it an ERP. It's not actually an ERP, but it's kind of close to an ERP, and that it just does so many different things. But because of that, and especially like analogous tools that we're seeing that are,

you know, doing more and more, which I think we'll see, I think we'll see more tools try to expand their scope, especially with AI. If coding is potentially going to get cheaper or at least faster for a lot of companies, they're going to just expand scope with what they can do. I think the requirements part in the business application, part gets even harder because you potentially, A, end up with more features that you're not actually going to use and B, applying it to the business as really hard work because you have to untangle all the existing business processes and like help the, and back to your template

example, help the business users see what this template, aka SaaS solution, because that's a lot of what SaaS solutions are analogous to a template, right? They're trying to automate something. and you can get the same reactions I think that you got like, oh, hey, this template, it really helps. It makes things faster and better. I think you get that all the time with SaaS solutions of like,

hey, like, just do this. Like, all you have to do is map the file here and, you know, these, you know, line up these columns and do this and do that. I think you can get similar reactions from people just like you, just like the reactions you got with your, you know, templates for reports.

Yeah, and I also think you're always at the risk with the SaaS stuff, especially if it's going to replace an existing thing of like, yeah, we really love it, but make it exactly like the old process that we had. Yeah, right. And you're like, okay, so now we're paying how much more money to replicate something that didn't work very well to begin with? Yeah.

So that special snowflake problem is very real. Right. And then one other nuance, too, is that I find that people are typically, unless they've had intentional focus effort. to think this way. People are typically fairly bad at taking their, what they do every day and abstracting out on like buckets. Like, oh, like, I'm, like, let's just use a help desk analogy. You know, I whitelist domains, I respond to Wi-Fi connectivity issues and like two or three other like bucket of things. Like people are generally not good at that, like, actually having an

intuitive sense for like that abstraction level. or in analytics, like, oh, like, I, you know, I spend about half my time, like, on, you know, modifying dashboards and 25% on ad hoc, like, people can't, and, you know, people don't generally have an intuitive sense for that. Yeah. And they also don't have an intuitive sense for, like, let's say you had a ticketing system. You could get to that information that was categorized well, which not many people do, to be honest, but so you did. Then, like, how do I take that and say, okay, we've got client reports, we've got 40 clients. I'm going to combine these 10 reports into this one or standard report and these 20 into these two standard reports. All of that work is, in my mind, some of the most challenging data work. Right. Way more so than the engineering because of the business context, the technical context, and just the general, like, you're holding a lot of things together to be able to do that, a magical combination effort.

And then you've got to go sell it to get buy-in because it's slightly different than it used to be. So that's really hard work. work. And then you'll deal with, because I've seen this multiple times, well, that doesn't solve this one thing. And you're like, yeah, it's like, okay, guys. I mean, I remember having this discussion where it was like, we were trying to replace one process with another.

And granted, it, there was like one aspect that the old system would do better. It wasn't this one was terrible, but the other one was better. And it was like, well, we can't do that. And I'm like, guys, on a scale of one to a hundred, our current is like a 10. And you're getting on me for all this stuff, this other thing can't do, which our current process doesn't handle. And you're all upset about this one thing. And it's like, this is like a 33. Like, we're like three times better than where we were.

So like, there's this idea of like, well, but if you can't perfectly replace it, or my other favorite, if you couldn't replace all of what this system theoretically working perfectly. Yeah. Yes. And it's like, but it's not doing that. I don't care that in theory it should be able to do that. It doesn't. We don't. Yeah, I feel like that's the art of the possible is the trap of enterprise software.

Because all enterprise software, especially the high dollar stuff, rarely has like limitations on it. Even let's just like BI tools. The kind of enterprise offerings in BI is like, oh yeah, you need to make a 3D chart or like a, bullet chart overlaid onto a pie chart or just like crazy things. You're like, why would you want to do that? And people get, oh, like, we could see where maybe we could use this. Or like, we're going to get to this. And you just have this like big spread of art of the possible.

And you're paying for the art of the possible and you're paying for the things you're actually using it for. And for some companies, that spread is large. Like you could say you had a million dollar bill. The art of the possible part of the bill, like could be over half of it. And you're actually practically using the other half. Yeah. And that even goes back to the whole, like, how do you go buy the right thing?

And it's like, one of the things you got to watch out for in any of these pitches is they're going to pitch you on a whole bunch of stuff that they're trying to convince you as important that most likely you don't actually care about or need in your current situation. I mean, I used to deal with that when I was, you know, like the senior director level where it was like, you know, we'd be trying to buy something. And it would be like, every one of them would bring up this thing that I'm. like, I don't care about. Right. Oh, we can, it was something like, you know, be things where it was like, oh, you can do like a model registry. And I'm like, don't need that right now.

Don't care. Well, and it's a really, it's a really effective negotiating tool as well. If you're going into one of these conversations and you have a really clear idea of like exactly what you need. So then when the like sales pitch comes out, it's all you can like literally strike like, I'm going to strike these five things like really cool that you're cool like tools able to do that. like never going to use it. Doesn't impact my buying decision, not looking to pay for that. Now, of course, like, you know, they're on one level, a lot of these companies charge what

they're going to charge. But I think that does bring some negotiation to the table where like, I really just want to buy these like two things or three things versus ending up in some kind of convoluted enterprise package where, you know, there's 14 things that like you kind of in your mind, like, yeah, maybe we'll use that one day. that's nice to have that practically like nobody's either ever going to put the time into implementing it or you actually don't need it. Yeah. And it's like even if you're not going to get like from a negotiating standpoint, even if I don't get anything off from it, what I really wish, which was a constant problem I would have is you would have a, you'd have a company and they would, and they'd have their standard pitch to you. And you would get to the end, you'd be like, okay, one, three and five. That's what I care about. Two, four and six through ten, I'm never going to use. I'm never going to buy. buy it. I don't really want to hear about it anymore.

Right. Okay, cool. All right. So can we go see a demo? Yeah, we can see a demo. Let me tell you about two, seven, eight, nine, and ten. It's like, you literally spent 40 minutes of our hour talking about things. I told you last meeting. I am never going to buy and I'm not making this purchase decision. Right. Right. Yeah. So there's some free sales advice. When I tell you, when I tell you, I don't want this. Don't keep trying to sell me. on it. Yeah. All right. I think we had time for one more here. Yeah. I think we exhausted that one. All right. I'll read it. Last one. Matthew Mullins. Hey, this was a great one. Really enjoyed it. So, Matthew says, wild. Plantier is on track for projected annual revenue just above $4 billion.

outperforming Databricks and Snowflake, which both have more customers and twice as many employees. PlentyR has no ecosystem, no open standards, posture, no developer community, and almost zero visibility among the teams building on top of modern stacks. So he says some uncomfortable takeaways. Winning doesn't require popularity, just results. Forward deployed engineers is a great delivery model, which traces back to the topic we just talked about. AI that solves real problems is greater than infrastructure that wins hacker news threads. Platform lock-in isn't always a dirty word, especially if the platform works.

Then high-head count and a big ecosystem look good until someone with fewer people, less noise, and tighter focus eats your lunch. Circle data guys. I think one big thing about that, because I would agree with a lot of that stuff, is, you know, like, to have a real strategy means you have to be different from everyone else. but that also means you could be wrong and people are scared of being wrong. And so they kind of play the same game, so to speak, right? And trying to win over the same people in the kind of community. And it's like, yeah, if you don't care about popularity, you can win.

Only if you win. Like, that's the big key. You have to win, you know? Yep. It's kind of like the person who wants to be like, I don't want to deal with any of these politics or bureaucracy. And it's like, cool, are you going to be like 100% right all the time? You can do that.

If you're not, it's not going to work. Yep. All right. So for those of you don't know who planter is, there. How should I describe one? Let's call them an analytics company or intelligence company. So just to give you an idea, I mean, it's a very different strategy, market, etc. The forward deployed engineer thing, I feel like that's a.

a new term. It's essentially like they do a lot of consulting. And they have all of their own like proprietary tools that aren't, you know, they don't have all this, you know, marketing budget deployed to like show off all their tools. It's all proprietary. So here's like some notable clients, ready? They, according to Wikipedia, they have contracts with 12 groups in the US government, including the CIA, DHS, NSA, FBI, CDC, and the Marine Court. And then they also have some large contracts it looks like with Pfizer, Airbus, NHS, and a few others. Yeah. So this is a drastically different strategy than product-led growth, let's say.

Right. And it's, and like you have certain advantages and tradeoffs with that. Because like I worked for a company that primarily did like kind of B to G stuff. And it's once you get in there, if you're in there, you can own it. But you also deal with stuff like selling and then not getting paid for a year. I remember, like there's one place I heard of, their accounts receivable was always like 55%. You know, like you have to be able to deal with that.

It's also hard to get in initially. Like that's like all this stuff has to be bid out. You have to win it. It's a whole long process. I mean, the place I worked at, you know, we had sales cycles that were measured in years, not months. So it's one of those things. is like you can do it, but like everyone has its trade-off and you got to be able to do it.

I mean, I think they also took advantage of the fact of with all the defense contracts they have, they did it at a time when people were getting very negative about working for defense companies. So they took a reputation hit kind of externally for that. Sure. Yeah. Okay. So his takeaways, waiting doesn't require popularity. Just results. Okay. I agree with that. The forward deployed engineer, I think is a really interesting one. Back to the like selling to the enterprise features people don't use.

I do think there's a remedy here of like, hey, we're going to sell you on. You only care about three things, Matt, to say you're the customer. Yeah. You should care about these five things based on customers like you. And by the way, we can have an engineer help you implement those things. There is an implementation cost of X, Y, or Z. But, you know, we expect the average ROI across our customer base would be X, you know, over this time period. I do think we're going to see more of that again.

I feel like the private-led growth and self-service and all that stuff is that still makes sense sometimes, but I think we're going to see more of this, more engineers and more people involved in this implementation layer. And that's kind of a dirty word. Yeah, go ahead. I think consolidation is going to cause more of that too, just because you're going to move towards bigger platforms instead of point solutions.

Yeah, which, I think here's this complexity. Yeah. And you have to do more of kind of the handholding and the selling at that point for a lot of those things. I think the risk you sometimes get with is, like, I mean, I've worked at places where, like, they had a consulting arm, right? And one of the things you ran into was the people who were in charge of selling that would sell stuff that was like, wait a minute, how much did you get for that?

Like, we got $50,000. Okay. That's going to take three sprints. That costs $180,000. Good job, guys. And they don't care because they get their commission off of the $50,000, not minus $130,000 that they just caused. So you have to kind of keep those in check.

Well, yeah. I mean, that's a problem. But maybe a bigger problem is, and I think this is why has like the last, I don't know, let's call it 10 years, probably more VC-backed SaaS companies don't want to un-a-fored. deploy engineers is like it is easy to use the forward deployed engineers to cover up product

problems. So part of the strategy to like make sure you're developing a really good product is to throttle the forward deploy engineer piece. So we're not like covering up gaps or product problems with people. So it'll be interesting. I do think there's going to be more of these engineers but we should I think everybody should be concerned about how it may impact product quality. Well, I think also you run the risk of kind of one-offing everything, too. So rather than getting to the point where you're developing, like, robust features that are usable by a large group, you've just kind of one-off it every time. And then that becomes like the de facto model of how you do it rather than figuring out,

like, okay, no, how do we make this into a reusable thing? Because then eventually you get to the point where either the engineers or the people who run that part are like, we don't need that. got it handled. And now you've got this like, that's what we do type thing. And you're trying to take that away from us. This is our expertise. And it's like, no, we need to be a part of the product.

Yeah. Yeah, that's a great point. Well, the other, I think the scariest thing is, is the combination of like, oh, we're going to deploy a bunch of like four deployed engineers armed with AI to like solution things with no like good product oversight or architecture or framework or anything. or like, or visibility. I think that

like on the surface is going to on the surface may actually feel really good and they're like, wow, like look at the speed we're moving at. We're solving real problems. We've got happy customers. Like I think you could, I think some of that is going to feel really good.

But like as that gets to scale and as you say, oh, we want to make this more of a product. Like that's going to be rough. Once you do that. realize it doesn't have the same scaling power. And then once you're going to get more money or to sell and you realize that your multiplier is not merely what you want it to be, that's going to be part of your problem.

Yeah. I would agree with the like AI solves real problems over winning Hacker News threads, but that's a whole longer insulated bubble issue right there. Yeah. Well, my last comment on it, platform lock-in. isn't always a dirty word, especially if the platform works. I think sort of, I think it depends. If you're picking an ERP, regardless of the ERP, you're locked in to some level, right?

If you're picking some core business technology, you're, like, there isn't currently a way to do that without some pretty severe lock-in. Right. So, but if you're picking something that doesn't need to be. locked in and essentially it's locked in because the vendor like set it up that way. That's where I would say like I think you need a justification

and you know Plantaire happens to be a $4 billion company with all these government contracts, probably not going anywhere. But I really get concerned for companies that do high lock-in with a centralized system that's like kind of a core ERP or operational system. It's like a startup.

That to me is kind of scary. And that's happening. That's happening right now. Yeah. And that's one that I feel like, you know, because one of the things that you always used to deal with was the startup would be the, well, I essentially need a discount because I'm taking a chance on you. Like there needed to be allocations because of the fact that I don't know if you're going to be here in three years. Right. And so when you try to be like, well, we're going to really lock you in for whatever the reason is, like in the commercial space, government's different.

But in the commercial space, it's like, yeah, that's. Yeah, it's going to be a hard sell. It's also, I think, on the, because there are some people who are like, I just want one system, I wanted to work, I'm willing to go with whoever's the best. But they don't properly calculate this isn't a once forever decision. This may be a once for the next five to 10 years decision. And you've got to account for the fact that, yes, we're picking this right now. We have these reasons, but it will incur these costs down the road.

and nobody wants to do that and it becomes, well, that's going to cost too much. It's like, well, yes, but we knew that would be the case when we made this decision. Well, and there's just certain, again, back to where I started with this conversation, there are just certain things by the very nature. I don't care if you adopt an open source thing. Like, it is going to be locked in by the nature of the product. Right. And while maybe you're not locked in via a contract, like you're essentially locked,

via the labor that it would take to move off of it. So there's two versions of it, right? There's one that's like locked in via contract, locked in via like the sheer amount of effort to move off of it. And then maybe the third is like the kind of where I think where you're saying calls it like a dirty word. It's the lock in of like this is essentially, you're unnecessarily locked in where the data,

you know, getting data out of the platform is nearly impossible. Getting data in is, you know, is trickier. you have to use their tool. That's the piece where I think the dirty part is like, come on. Why don't you have APIs? Why don't you have reasonable interfaces to get data in and out? That's the lock-in that I think a lot of people especially hate. Yeah, I think when we talk about a dirty word,

it's kind of that like from a finance perspective almost of like you picked a solution for the next six months that has no flexibility and you killed all of our ability to option anything else in the future because we have to use all their stuff now. Yep, yeah. So I think that's the big one. But yeah, but I mean, like, to give an example to what you're saying, there are banks that, like, I have a friend who worked at a bank, and they paid a guy like a quarter to a half a million dollars a year

to be on call because they had their whole system was in Cobalt, their transaction system. Yep. And they were locked into it. There's no cost to it. Except for the fact that when it starts duplicating transaction, you need someone in there who can fix it fast. Yeah, sure.

So, like, you're still locked in doing that, you know. You pick up something and you're like, well, we're only going to make stuff with Python and with this. Like, eventually you're going to write enough code that it's going to be a pain to move off of it. Yeah, for sure. All right. Thanks for being on the show, Matt. I think we're at time. You have any parting wisdom for everybody this week?

No, I think it's all out there. Don't try to sell me when I told you I'm not about buying. There's that one. You know, that is a good one. I think that's a great one. All right. Thanks, everybody. Thanks for listening. Stay cynical. The Datastack show is brought to you by Rudderstack.

Learn more at rudderstack.com.