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

Episode Date: August 13, 2025

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.

Hi, I'm Eric Dots. 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 data. episode, we want to give a huge thanks to our presenting sponsor, Rutter Sack. They give us the equipment and time to do this show week in, week out, and provide you the valuable

content. Rutter Sack 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 real time. You can learn more at RutterSack.com. Welcome back to the Datasack 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 enjoyed. This is from Josh Hansen. He does data at Clay, which is a more. 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 DBT 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. 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. 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 some plenty of other cool workflows, I think. But in my mind, I put it in that low code like 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. this tool, it, you know, enables them somewhere to DBT. So 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 like 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. 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 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. 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 sign 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 Sierra, you've got your 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 sass companies i think maybe it it could be different in more standard companies but there's eventually just going to 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, like, more advanced scripting that I'm not aware of. But 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 mean, 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 as a mouse, you're not interested. That's what you're 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. 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 live in a 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

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 future is very muddy still at this point. You know, it's, we're not, are they going to take, or all these NPCs are 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. 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 youngens 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 One Drive 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 dog. anymore. Yeah. 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. Yep, yep. So 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 one drive. 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 like 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 so going to send you a spreadsheet with it's not on yeah 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 iteration you know it's just you sending it to send and what is multiple iterations of something. Inevitably, you get a, oh, I asked you to make this change, but I don't like it and 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.

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 is going to be messed up. I haven't been very successful trying to roll back like a, Excel documents to a certain time of day. 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, well, 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. 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, Ruttersack. 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 rudder stack 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 longest running production instance of Rudder Stack at six years in 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. I got another one for us. Let's see, this one, simplicity, when's in 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 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 him in, was hard-coded everywhere, and nothing worked. And it was like, oh, but it's just sequel. 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 it'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 COC. 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 hardcoded a bunch of things.

We don't have any like version control. We used, you know, the tools we had without considering any, you know, anything that might be the right tool for the job. Like that, 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'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 chunked 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 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 it was a friction that was born out of kind of you know for like a better term like ignorance like they didn't know that

there was a better way or that to them it felt like it was going to be harder because they weren't looking at the total cost over time right so so i think that's one thing that gets people it's kind of 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. When I write here, people and they're like, well, I 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, nope, that's just a no. But if you're trying to stitch 12 SaaS 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 what you need from a SaaS platform or what tools are going to work best

or things like that. And trying something on your own, even if it's just like exploring, POC can help you understand oh this is what I actually need out of it yep so and people get themselves tied up in knots because they're like oh no we got to go buy it 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 energy

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 it's 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 let's call it an ERP it's not actually an ERP but it's kind of close to an ERP and that it like 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.

companies are going to just expand scope with what they can do. I think the requirements part and 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 is 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.m. 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 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 white list 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, like, people can't, and, you know, people don't generally have an intuitive sense for that. Yeah.

And they also don't tend to have an intuitive sense for, like, let's say you had a ticketing system, you could get to that information and it 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. 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 in 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. 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, 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, 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 favor if you couldn't replace all of what this system theoretically working perfectly yeah yes yes that'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 that's 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 like all 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 is 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. Yeah. 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 exactly what you need. So then when the sales pitch comes out, you can 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.

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 negotiations to the table where you're like, I really just want to buy these like two things or three things versus spending up in some kind of unvaluted 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 company 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 it. I don't really want to hear about it anymore. 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.

And 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 got 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. Flantier is on track for a projected annual revenue just above $4 billion. Outperforming Databricks and Snowflake, which both have more customers and twice as many employees. Plantier has no ecosystem, no open standards, posture, no developer community,

and almost zero visibility among the team's 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, and then high-head count in a big ecosystem look good until someone with fewer people, less noise, and tighter focus eats your lunch. Cernical 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 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 yeah 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 a hundred percent right all the time you can do that if you're not it's not going to work yep all right so for those you don't know who planter is there how should I describe one let's call the analytics company or intelligence company so Just to give you an idea, I mean, it's a very different strategy, market, et cetera.

The forward deployed engineer thing, I feel like that's 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 U.S. 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. 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. They're like 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.

Like, you can do it. But like, everyone has its tradeoff. 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, wedding doesn't require popularity. We're 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 increases 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 his, like the last, I don't know, let's call it 10 years, probably more VC-backed SaaS companies don't want a ton of forward-deployed engineers. It's 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 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 won 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.

We've 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 the combination of like, oh, we're going to deploy a bunch of like for deployed, engineers armed with AI to like solution things with no like good product oversight or architecture or framework or anything or like built or yeah 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 it going to feel really good but like as that that gets to scale and as you say, oh, we want to make this more of a product, like that's going to be rocked. Once you 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 nearly what you want it to be, that's going to be part of your problem.

Yeah. Yeah. I would agree with the like AI solves real problems over winning Hacker News threads, but that's a whole longer. Yeah. 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-end. 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, Planteer 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,

there'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, for whatever the reason is,

like in the commercial space, government's different, but in the commercial space, it's like, 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. 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, 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 in 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 the, where you're saying calls it like a dirty word, it's to 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 end is you know it's trickier you have to use there to like that's the piece

where i think the dirty part is like come on like why don't you have APIs why don't you have like reasonable interfaces to get data in and out like that 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, the 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, if 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. Do 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.