Episode 39: Dave Mangot of Mangoteque on 
How To Leverage DevOps to Deliver a Competitive Product

Episode Transcript

Shiv: All right, David, welcome to the show. How's it going?

Dave: Nice to be here, Shiv. Thanks for having me.

Shiv: Yeah, excited to have you on. And this is a bit of a different one. I read your book and a big fan of a lot of the things that you had to say on DevOps and shipping product. And so excited for the audience to learn from you and your background. So why don't we start there? Walk us through how you got here and what your experiences.

Dave: Sure, I moved to Silicon Valley in the late 90s and hilariously had no idea that there was this dot com boom thing going on. I was just here to go to graduate school and whatever and people found out I knew about computers and they offered me a job and then another job and another job and ultimately I wound up being an architect in infrastructure engineering for Salesforce. So, got to work on enterprise software at extremely large scales and high transaction rates and high amounts of security and compliance and all that other fun stuff. Went on to run a global site reliability engineering organization for SolarWinds, which is basically the area of the business that was all the cloud company acquisitions. So all their SaaS stuff, but you know, Salesforce, early in SaaS, SolarWinds, all the SaaS acquisitions that they did. I ran an engineering organization inside each of those companies. And during that time, SolarWinds got bought by Thoma Bravo and Silver Lake, which was my first real introduction to private equity and wound up developing relationships, especially inside Thoma Bravo and after I left SolarWinds, I started working with portfolio companies from different private equity firms. And I really loved it. And like you kind of probably read in the beginning of the book, the thing I like about private equity, you know, in particular and SaaS is that everyone's really serious. And I don't mean serious like in a stodgy, awful way, but serious like we want to get results. We have an investment thesis that's really clear. We know what our constraints are. There's going to be constraints around time. There's going to be constraints around money. Almost always, they want to increase value. So certainly things that got a company to where they are at that point, not necessarily the things that are going to carry them to the next level. And I'm feeling like you're probably going to say it's the same thing with marketing. The things that got them there aren't going to take them to the next level. And so I love it because I get to work with these companies on taking them to the next level and helping them do it themselves. So I'm a solo. I don't bring in dozens of people and put them on your payroll or anything like that. It's just me. But I help people get the most out of the teams that they have. And we know from the research, so when you're alluding to DevOps, the high performers are twice as likely to meet or exceed their organization's performance goals. So whether that's revenue, customer satisfaction, customer acquisition, whatever those things happen to be, those are the results. So that's what I'm there for.

Shiv: That's awesome. And it's funny because the business that you have built here is very similar to our business, but on the DevOps side. So it's interesting to meet like a counterpart from a different function. But talk a little bit more about this idea of shipping product and how it's critical to value creation. I think that's kind of where you start your book. And just from my experience, you know, in a different life when I was the CMO of Wild Apricot, slowly my role expanded into leading product initiatives and eventually leading the product team and working with engineers to lead strategic initiatives. And we got acquired by private equity and I ended up leading the product organization of four different companies at the same time and along with the marketing hat. But we don't talk about that as much because what we do is the marketing work. But as I went on that journey, I learned that, you know, we talk about marketing and sales and growth often as separate from product. And in the early stages, people talk about product market fit. But as you grow as a business, that product element is just so critical to achieving growth objectives and growth targets. And how you accomplish that is actually by shipping product and having great processes and listening to customers and then delivering what you've promised and having something that people can actually use. So, just talk about that because that's kind of where you started your book and just from a technical perspective, how you see that.

Dave: Yeah. So, the book is called DevOps Patterns for Private Equity. And, for me, DevOps is about shipping with speed and quality. And so, you know, I ultimately look at this or I explained to a lot of people, this is kind of like money ball. You want to have more at-bats, right? And you want them to be quality at-bats. So those are your speed and your quality going up and striking out all that useful as I know from watching too much baseball recently. Anyways, so, but you know, the interesting thing about getting good at delivering software, which is ultimately what we're trying to do here, is it allows you to take advantage of market opportunities that maybe you wouldn't be able to take advantage of otherwise. So this also means, you know, giving customers the things that they want. And so some of the examples I give in the book is like, you know, I worked on a CDN content delivery network for cable and wireless in the early 2000s. And one of the customers we had was a bunch of the major movie studios were getting together and they were trying to figure out how to do streaming movies. Streaming movies, right? Right. You know, it's 2024. We're all like streaming movies. Of course, everybody's streaming movies. What's the big deal? But like, back then there were no real streaming movies. It was a wreck. You had all this super proprietary software and all these other things. And the movie studios were trying to do this in the early 2000s. And ultimately Netflix at the time had been shipping those red envelopes, but Netflix ultimately came to dominate streaming movies. Well, how?

Why does it make any sense, right? I mean, the movie studios, they're not short of cash. They have lots of money. They probably hired the best consultants that they could that told them, you know, we're going to write all this software. We're going to ship it once a year. You know, this is how we do things. This is this is how the world works. And Netflix doesn't do that. And Netflix is good at delivering software. And Netflix, you know, ultimately came to win this, this battle, even though they came to the battle years late, you know, and then they moved to the cloud. And that's a whole famous DevOps story and things like that. But Amazon, they were a bookstore. Does anyone think of Amazon as a bookstore anymore? Google was a search engine. I remember when, you know, Google was still hosted at Stanford. Does anyone think of Google as simply a search engine and that's all they do anymore? Like. It's not, you know, and those companies are good at delivering software. And so when you can deliver with speed and quality, you get more at-bats. And so if I go into a portfolio company and they tell me, you know, we do quarterly releases. I'm like, okay. So you have four times a year to get it, to have the opportunity to get it right, to achieve that, you know, product market fit isn't so much of a thing with private equity anymore. We are, have that. But you know, what are the things that the customers want? What are the things that we have to do to keep the software running? Like all those things. If I release four times a year, I get four at-bats. If I release software once a week or once a day, now we're talking 50 at-bats, 100 at-bats, things like that. And that is really just it's asymmetrical warfare at that point. It's not a fair fight because I get 50 chances to really make my customers happy and you get four. And it turns out that we've also learned from the DevOps movement that releasing four times a year is way less safe than releasing 50 times a year. And you and I can get into why that is.

Shiv: So you opened a lot of threads there. I want to make sure we get to all of them. So the idea of releasing more and continuous delivery versus once in a while delivering something. Yeah, that's like a popular term and everybody understands that. I guess, is your point that the more you deliver product and ship product, you're more likely to discover the right areas that your product can actually drive growth from and find more users or deliver more value to them?

Dave: Yeah, I mean, I would, you know, you ran a product organization, so you probably can tell me the answer to this question, but I would imagine that everything that we release to our customers is a hypothesis. It's a hypothesis about this is what they want. This is what they need. And often we release things and our customers give us feedback and say, this is great. If this could do this other thing it would be super valuable for us. We would never be able to run our business without it. Once we had that, you know, and being able to, what are you going to do about that kind of feedback? Right. We, we do a lot in product. We do a lot of like reaching out to the customer ahead of time, you know, and try to find out what they need. But, you know, there's that whole thing of, you know, Henry Ford, we would have built them a faster mechanical horse or something like that. Like, you know, all that research is really important but ultimately we need to release things that are super valuable to our customers and we need to respond to, you know, changes in the market. You know, everybody now wants to jump on the AI bandwagon, which is great. Don't get me wrong. I have an LLM running here locally on my machine that I use when I need it for stuff. But like, how do you take advantage of that? If your product roadmap says that we can release the next new thing in March of 2025. Okay, but your competition is gonna release the AI thing next month. What are you gonna do about that?

Shiv: And so how do you bridge that gap? And I guess also I'm mindful of the fact that even though it's 2024, there's a big chunk of the software market that is legacy or on-prem and isn't ready for this type of operational infrastructure to deploy software at a faster rate. And so how do you bridge that gap if you're company’s like that? And then obviously, companies that are more multi-tenant and they're able to do that, like how do you look at those? Because I think those are almost two different problems.

Dave: Yeah, you know, I'm a big fan of W. Edwards Deming, who was the statistician who helped turn around Japan after World War Two. And he has a great quote, which is “Survival isn't mandatory.” You know, for the companies that are more legacy and things like that, you got to come up to speed. You know, that's it. If you, survival is not mandatory, there is no guarantee that all these, you know, I talked to lots of companies that are like, we're going too slow. These startups are coming after us. They're eating into our market space. What, you know, what do we do? I'm like, you got to go faster. And you know, the great thing or the nice thing, whatever you want to call it is we know how to do this. It's not something that has to be invented from whole cloth. Like we know the things that help you go faster. We know things like automated testing helps you go faster. I can't tell you how many companies I go into and they're like, well, you know, we write the software, then it goes to the QA people for a few weeks and then it comes. Okay, but that, you know, in lean we call those are handoffs, right? And there's a lot of waste in the system, but you know, you, you take weeks to do testing where your competitors take hours. That's just not a fair fight again. And we know how to do it. And, you know, I've worked with plenty of private equity investors who were willing to make that investment and say, we need to get this company going. And we're willing to, you know, bring in people to help write automated tests and whether that's, you know, valuable or not as a whole other discussion. But, you know, we need to catch up. And a lot of these people are moving to the cloud, which, you know, there's all these arguments about cloud and is it expensive and that's it. That's really not what it's about. The cloud is about agility. It is about like, I want to be able to spin up a representative test environment and know whether this stuff really works or whether I'm guessing. And like, I know as somebody who is, if I'm running a business, I don't want guessing. I want answers. I want someone to say like, look, we tested it and it works instead of, well, is it going to work when we give it to the customers? I don't know, maybe. I get around a business like that. And so like, there's definitely ways of getting these companies to go faster. And we're not gonna flip a switch and they're not gonna go faster overnight. Obviously there's, you know, this is complicated and this is how I help companies, you know, navigate these waters. Like, you know, it's complicated, but that's okay. So what? It's hard, big deal. We're gonna do it.

Shiv: What would you say are the stages between very immature or not immature, but like on-prem or legacy, these handful of releases a year versus this continuous delivery and then everything in between, like what are those stages of evolution that companies need to get through and how can they move through that faster?

Dave: Well, faster is again, like some of these things are gonna take the amount of time they're gonna take. But generally like what I see often, and this isn't always, because some companies do things that I think are a little weird, but that's okay. I think they're cool if it fits in with their objectives and their timeframes and all those other things. But generally, there's on-premise software, which is you know, like you said, legacy, things like that. It's very difficult to maintain because you don't control the environments where this stuff is running. If you, let's say, wanted a new database for some new feature, how do you get a new database on your customer's environment? I got to ask their IT people for more equipment, my God. It's just such a, it's kind of a great nightmare. So, that's, you know, that on-premise is kind of where you're starting. A lot of companies I see move to what I call the hosted phase, which is basically we take a lot of this on-premise stuff and they just dump it into the cloud. Like, which, you know, doesn't sound super awesome, but you know, now I'm running, let's say I had a thousand customers. Now I'm running a thousand instances of my software, but I'm running it, I'm running it in the cloud. I'm running it, you know, with all the things that the cloud has to offer. And like you and I just talked about a few minutes ago, that's flexibility. And flexibility is just a huge advantage when I want to go fast. Flexibility is like just unlocks all kinds of things. And at that point, when they're in the cloud in this hosted stage, what we're trying to do is, this is another Deming kind of concept, is reduce variation. Right. So you, you know, you mentioned like, you know, the Holy grail is sort of this, you know, multi-tenant, we release all the time kinds of things. Well, that's really hard to do when everything is a beautiful artisanal custom snowflake. I can't, it's hard to get efficiencies, right? You had Vinny from a JMI equity on the podcast and he was saying like, when you want to scale, you need efficiency, right? You don't just need capacity. And so, you know, the cloud has in theory unlimited capacity, which is fine, whatever. That's not what you need. You need efficiency. So we reduce variation. We start figuring out what are the custom things. What can we turn into a configuration variable? How can we combine databases so that each customer has their own data in there, but we know the differences. And over time, we keep iterating and iterating until we get to that multi-tenant SaaS sort of place, which, you know, why does all private equity love to turn on-premise software into multi-tenant SaaS? Because our margins are incredible in multi-tenant SaaS. The incremental cost of adding a customer is nothing. The incremental cost of adding in-hosted environment is I have to spin up all this new infrastructure for each one of these clients. And that doesn't mean I can't make money there, but make a heck of a lot more money if my margin is really large because the incremental costs are low.

Shiv: How long should this process take? And even multi-tenant, they're not always at the most sophisticated level at all times, but just to set expectations, right? Because even we get this question on the marketing side where people want to ramp up pipeline and demand gen and revenue, but there's all this foundational work that needs to be done before you can actually get to the revenue generation phase and everybody wants it in the next few weeks or the next couple of months. And there's this, I have to go through an education phase to say, no, we need to invest and you need to be comfortable with knowing this is going to take three months on the lower end and probably six months on the larger side as we try to figure this out. And you have to be willing to invest that time and money to be able to do that because one way or another, you're going to have to make that investment. So I imagine this is very similar to that, but just help us understand, like, what does that look like in each of these phases getting to that level of sophistication.

Dave: So you and I both are doing consulting stuff. So I'll give you the very consulting answer, which is it depends. But that being said, it depends really on a few things. It depends on the biggest thing is the culture of your organization. So how willing are people to adopt some of these principles? Sometimes I go into companies and the engineers are like, oh my God, I have been talking about doing this since I got here and no one's paid any attention. And now you're saying it and then, you know, the company's like, well, maybe we should pay attention. And, you know, those turn out great. Sometimes I go in and they're like, you don't understand, Dave. We have real problems here. We have to deal with security and compliance. Okay, yes, I'm sure you're the first company to deal with security and compliance. But, you know, we have to do everything by hand in the data center. We have to custom, artisanally-craft everything. Like, okay, so where we're gonna start here is that you don't actually have to do that. But, you know, I have worked with, you know, big financial, you know, FinTech clients that, you know, they, the question is like, that you asked is sort of how long does it take? And like, we got their first product from, you know, let's say data center and cloud and, let's say six months. But then, you know, they didn't have one product. They had more product. They had, you know, and it took them four, four and a half years to get all the different products in because like what makes sense, we started with the easier stuff and they moved on to the harder stuff. And as they got into the harder stuff, they had already built a lot of this capacity, a lot of the, you know, a lot of the, let’s call it tips and tricks or whatever you want to call it so that when they got to their really intractable problems the things that had and this is you know you read my book so this was the first quote on the first page on the first line of the first anything was “Make the hard things easy so you can work on harder things.” And so they had worked on things that had been hard before and no things are now easy and then they were able to work on harder things and you know ultimately they you know fully cloud, fully everything, huge successful IPO, like all kinds of stuff. But yeah, it can take a while.

Shiv: Yeah, I think that message is important because in a lot of cases, I like to think a lot about how markets have evolved and a lot of SaaS companies that you see today that are 10 million, 50 million, 100 million started often 20 years ago and they grew with the market and now they have all of this legacy stuff in place and that's normal and natural for any business to have gone through so many evolutionary stages, but with that comes this form of technical debt that you kind of have to fix and remove. It's like a type of liability on the balance sheet that's kind of weighing you down, right? So if you don't do that, then over time it just keeps growing. And at the rate at which technology is accelerating, your technical debt, if you don't address it, I would say increases exponentially by the year because you're just leaving it there and not removing it from that balance sheet.

Dave: Yeah, I love that, what you said. I think there's a couple of things that are really important there. One is, you know, no one should feel bad about the fact that they, you know, were around for a long time and now they're going slow. And that's why you're here. That's why you got an investment from private equity is like you built something valuable and people are recognizing that. And that's why they want to make an investment in you. And that's. That's a good thing. That's something you should be proud of. Like it's, you know, yeah, if you were a little startup that started last month, you would have much more modern development practices. So what? Big deal. That's not, you know, that's definitely not something to feel bad about. And then the technical debt thing I love because everybody talks about it. Like it's this, gosh, we have all this technical data. Technical debt is, you know, is basically, I made the appropriate choices at the time for the situation that I was in. Who would run a business making the appropriate choices for the place that they're gonna be 10 years from now? That's insane. You don't know what's gonna happen in 10 years. I work with a company that, we can talk about it, but they wanted to do a three-year product roadmap in two years. And I was like, you don't know what's going to happen in three years. You don't know what's going to happen next year. Like the, you know, if you, the money ball thing, if you can deliver with speed and quality often, you can respond to whatever happens. But like the way that you guys plan this out, like every single thing that you want to do has to go perfect for the next two years. I was like, what, what do you think the statistical probability is that every single thing is going to go perfect? It's a joke, like forget it. And so. There's nothing wrong with technical debt, like in terms of like, you know, people made the right choices at the right time. It's very, very rare that I bump into anybody where I'm just like, what were you thinking? It just doesn't happen. 

But, you know, Ward Cunningham, one of the signatories of the Agile Manifesto, was the guy who came up with this term technical debt. And the thing that he was concerned with was a little, you know, kind of what you're talking about, drag on the organization. And like, if you don't pay down this technical debt to use that, you know, that phraseology, like, then you get more and more drag. And that starts to slow you down. And if the whole thing that we're, you and I have been talking about is delivering with speed and quality, well, I'm not going to have speed if I keep getting dragged down. And so that's when we make those investments because we want to be able to go fast again and we want to be able to compete. That's what this is about, right?

Shiv: I literally wrote down ‘Agile Manifesto’ like five seconds before you said it, as that was going to be my next question. So that's pretty cool. So yeah, the question I had on that is the Agile Manifesto is about culture, right? It's about how you think about how you organize yourselves to ship product. And it's almost like a philosophical difference between a waterfall method or what have you. So, inside these companies, from what I've experienced, and I'm just curious for your take, is there's just like resistance to changing culture. And that's one of the biggest things that's holding these companies back from changing how they operate. And so talk about the people side of that, because I feel like that's really what needs to change.

Dave: Yeah, survival is not mandatory. Deming. But you know, I think the fun thing about the Agile Manifesto, and I loved how you brought up waterfall, is waterfall was just what we were just talking about. Waterfall assumes that I have knowledge of what's going to happen in the future that I can predict. You know. Trust me, I've worked, you know, early in my career, especially at companies that ran by waterfall. And they're like, we're going to do this and then this is going to happen. And then this is going to line up. And then, you know, we had the Gantt charts and the things and whatever. And it turns out that, you know, let's say it's January and we said, you know, we're going to do six months of development. And, you know, on August 1st, we're going to hand it to QA. How often do you think we actually handed it to QA on August 1st? Never, it never happened. Like it's a joke, like it's so funny. And like that's what the Agile Manifesto is about. And this idea of culture, right, is they didn't pick the name Agile out of the sky. Like Agile means Agile, like actually being Agile and being able to respond. And so if I get new information, I adjust, right? I don't get new information and say, no, look, the Gantt chart says this. So this is what we're going to do. I have new information. Why would I do that? I'm just throwing money in the garbage. So getting people to come along and realize that this isn't, first of all, agile doesn't mean no planning. That's ridiculous. Whoever got that idea into their heads, that's not what it's about at all, is that. In Agile, we plan very carefully around closer time horizons and we plan more loosely about further out time horizons. And I'm going to just go out on a limb here. I'll bet you do the same thing in marketing. You don't plan what the marketing message is going to be two years from now, but since you work with product, you know, like, this is the direction that the product is heading. And in two years from now, these are the kinds of things we're going to be talking about in our marketing materials. Do you develop all the PDFs today for two years from now? No, of course not. And like, why do people in software have the use to at least have this notion that like, well, I'm going to decide exactly what's going to happen in the future. Like you don't know, it doesn't matter. And that's, it's a waste of time. And so with Agile, we really concentrate on the things that we're going to deliver, let's say in the next few months. And the things that are further out, it's not like we don't think about them. Of course we do, but we don't spend a lot of time drilling into the specifics of those things because it's nonsense. And so people have to get comfortable with being uncomfortable a bit, but the culture change ultimately, it's like, there's this great expression I love, “If you show someone a class picture, the first person they look for is themselves.” And so, you know, to get people to come along, you have to explain to them why this is good for them. Right. And I, you know, back in the day, let's I work, you know. 

When I was at Salesforce, I had a junior engineer come up to me. I was an architect. So, you know, very high up on the technical ladder. And he was like, I'm going to, you know, learn this programming language. And I was like, why? Like no one's going to do stuff with that anymore. no, no. You know, and I say, before you do anything, go out and look for what jobs are available in the, you know, in the marketplace for people who know that language. And, you know, he went back and he's like, yeah, there's like some publishing company in the middle of Pennsylvania, nowhere and farm country that's looking for people that know how to do this, but everybody else is looking for this other skill. And I'm like, yeah, maybe you should be looking, you know, learning that other skill. And so it's a little bit of skating to where the puck is going, but a lot of us, we already know where the puck is going. The puck is going to cloud. The puck is going to, like you said, continuous delivery, all these things. And so it's, it's really like, Hey, what kind of job do you want to have? And people really, they come around because they see it's in their best interest, which hilariously, is in the company's best interest, which is also in the investor's best interest. So if I can make people's lives better, I'm going to give them a better life, then everybody wins. And so like I said, this in the book, like it's a win, win, win job, which I don't even know that many of these out there. Like it's, it's, it's a blessing in a way.

Shiv: Right. How do you balance and I'm hearing you talking, I'm like, all of these things make total sense, but inside of a business, you have all these competing priorities and that's the reality of product teams in general and every team really, but in product's case, you have these operational improvements and then infrastructural or architectural improvements. And then you actually still have to ship features and product and roadmap requests from customers or sales has certain feedback and certain things that you think might close more deals or capture a new part of the market. So how do you balance this transition to becoming more mature and sophisticated as an organization with those ongoing and pressing needs that actually move the needle on things like revenue and retention?

Dave: Yeah, I think there's two sides of it. One of the things I talk about, I ask people, what do you want to spend your engineering tokens on? What does that mean? And I'm like, you only have a limited number of tokens, right? We can't do everything. That would be great. Unlimited resources, unlimited time. We can do anything. But nobody has that. Certainly, companies I've ever worked with have unlimited resources and unlimited time. So it means we have to get very clear about what we're going to do. And this, you know, gets into these idea of prioritization and things like that. And CEOs that I work with love this because like people get real focused on the things that we have to do. And, you know, I talked to the engineers and they're like, well, what should I be working on? I'm like, what's the most important thing to the business? And they're like, what? I'm like, work on the things that are most important to the business. I'm like, if your boss comes to you and, you know, you're not delivering enough stuff maybe or whatever. And they're like, well, what are you working on? You say, I'm working on the things that are most important to the business. What are they going to say to you? Don't do that. Like, no way. They're going to say, carry on. And then, you know, so like that's kind of one half of it. 

The other half of it is a lot of people who are like, we can't do this. We can't do that. They're, they're thinking about it in terms of what they're doing right now. And like, there are no teams that I work with that, you know, by the end of the engagement can deliver just as much stuff as they did before. Like, no way. They're way past that. They're delivering way more things. And so, there's, you know, there is an ability to balance those things out. And so, you know, the things that people, and this is what agile is good for in a lot of ways, the things that people get upset about isn't so much if I'm in product and, you know, you tell me you're gonna deliver, I say I want this on August 1st and then, and you know, or you say you want this on August 1st and I say, shiv, how about we give it to you on August 15th? You're like, well, that's not really what I want, but are you gonna give it to me on August 15th? And you say, absolutely. If you deliver on August 15th, like most people will accept that. The things that people get really upset about is that you say, I'm going to, you know, you say I want it on August 1st and I go, sure, Shiv, no problem, August 1st. And then August 1st comes around and you're like, where is it? And I'm like, how about the 7th? And then they're like, okay, fine. And then on the seventh, it's not there. And then the 21st you deliver it. It's all this like, you know, uncertainty on short time horizons that are the things that make people really upset. 

And so when we can get our capabilities down, we can make the hard things easy so we can work on harder things, then being able to deliver on a lot of things with consistency, you know, speed and quality again, isn't as hard to do because I know what my capacity is. I know what are the things that we can do. I know that if, you know, I go to you and say Shiv, if we can get this thing working or whatever, I'll be able to give you three times as much stuff. You might be like, you know what, do it because I want three times as much stuff. Whereas like if I'm just keep coming to you with excuses after excuses and you don't believe a word I have to say about anything, no, you're going to be like, no, give it to me on the thing. That's what I want it. And so all this idea of like maintenance patching, I think is some of the stuff you're alluding to whatever security, you know, all those things we can do but we can only do them if we have a system in place that allows us to reliably deliver the things that we say we're going to deliver. And then, you know, then our, your job as the product guy or your job, you know, you're talking about marketing, not really on this podcast, right? Your job with the marketing person becomes a lot easier to deal with. 

And so one of the stories I told in the book, right, was about working with a marketing department. What we used to do is we used to deliver product and then we would, you know, tell the marketing department, Hey, we delivered this thing. And then they would be like, okay, great. Can you give us all the collateral, right? The blog posts, the things that we want to put on Twitter, the things like that. And so like the product to be out in the marketplace, but nobody knew about it because marketing now we're starting to collect all their stuff. And we're like, Hey, you know what? Let's reimagine this. Let's look at this differently. Like, we know when we're going to release this. We know what's going to be inside this feature. It's not, we're not guessing. We're not going to discover what that is on the day it goes out into production. We know that ahead of time. So, you know, we worked with them say like, well, when would you need this? When would you need that? So by the time that thing was turned on in production, everything was ready. The blog posts are ready to go. The tweets are ready to go. It became like a non-event. Like everybody set up their stuff in whatever HubSpot, I don't know, you know what the tools are. So then it all automatically just went and everything just happened. And instead of being this like thing everybody has to make a big deal about, and we have to give up our Saturday. It just became, releasing software is a non-event. We just do it.

Shiv: What about, and that's a great answer, what about bigger initiatives? And I bring this up even with this idea of this, you're talking about monolith systems that have multiple modules intertwined. And that's an example of just breaking that up is a big initiative and takes time, right? And some cases like these monoliths are so huge that it could be more than a year that you're talking about to run through that. And then there's other initiatives, like if we're launching a new product or a new capability, like let's say you're launching a payments platform for a software that doesn't have it or launching an upmarket product that requires a whole new set of functionality. How do you bring this philosophy to that where you kind of need to get to a new state first and ship that? Or even then do you see this philosophy of continuous delivery applying?

Dave: B. So think about what we talked about with Agile, this idea that we understand what's going to happen on a short time horizon, or a shorter time horizon, let's say. And the things that are going to happen out in the future, we understand, but we're a lot less clear about. If I have this big monolith or whatever that I want to break apart, I don't go about doing that by sending everybody in, you know, they're going to spend a year and a half and then boom, there's a huge explosion. Now I have 15 microservices. Like it just doesn't work that way. Right. What we do is there's a lot of software engineering techniques for this, but like one example is what's called the strangler pattern. So like we sort of break off a piece, right. And we start talking to that piece through a different interface, like an API application programming interface, right? And that thing will still talk to the stuff behind, but now we're used to talking to that thing. And then over time we can break off that functionality from the big monolith. And nobody really knows. Nobody knows the difference. Like to everybody, they're like, well, we're still talking to the same API. What's happening behind that? Nobody knows it's irrelevant. The only team that knows what's really happening behind the scenes there is the team who's developing that API. And we can strangle off pieces from the monolith over time and worry about those pieces so that we're not, we don't have to wait the year or whatever it takes to get the benefits. We get benefits right from the beginning and we keep accumulating those benefits to use the term that you were talking about earlier. We keep paying down that tech debt and the more we break these, you know, we pay this stuff down, the faster we get to go. And that allows us to, to really, you know, break these things apart, but in a way that makes sense. And we don't, we don't, we're not trying to boil the ocean. We're trying to make incremental improvements over time.

Shiv: I think that's a great answer. And actually, I would love to keep talking about running up on time, but as an ending message, I think just for the audience, as they think about these types of projects, there is a natural inclination that everybody has to build something to completion before it's taken to market. And I think just as a philosophy of piecemealing it and having that continuous feedback loop is a great message. But if the audience wants to learn more, what's the best place they can go to learn more about you or your book?

Dave: So certainly, Mangoteque  dot com, I write every month about, you know, you can sign up for a mailing list there. I write every month about these kinds of topics, about the things I see inside portfolio companies. and for me, like, I think, you know, I work a lot with CTOs. That's, you know, mostly the people I work with, but I also work with investors, right? Because I think, you know, number one, when I know what your investment thesis is, that helps me a lot to shape things. But number two, like this is alpha, right? This is the thing that can differentiate your firm from the other firms. If Toyota was really good at finance, which all PE folks are good at finance, but you know, pretty good at marketing, whatever, but didn't know anything about cars, how good would they be, right? And understanding this stuff about how software is made, what are the timeframes, what are we talking about when we're talking about breaking up a monolith? I think that stuff is really important. So I write about those things. Definitely, you know, check out my book, DevOps Patterns for Private Equity. It is not hard to find. It's everywhere that anyone sells any books anywhere. And yeah, and just, you know, really hope that people take this idea to heart about money ball. Like you really want more at-bats. You want to have more chances to get this right and beat the competition. And so that's kind of any company, but it's really with this three to five year investment thesis, I think it's really key for private equity.

Shiv: That's awesome. And we'll be sure to include all of that in the show notes. And with that said, Dave, thanks for coming on and sharing your wisdom. I think a ton of companies and firms and investors can learn a lot from it when they think about the technology side of their businesses and how to create value there. So I appreciate you doing this.

Dave: Thanks, Shiv.