Talking DevOps ROI with the finance department

Episode 3 · 2015-09-08 · 42:20 · SRT · archive.org · all Tanzu Talk

Well, hey, it's been a long time since we recorded anything. Yes, it has, actually. It's been two years now, I think, something like that. Yeah, I think oddly enough, like the last time we recorded, we were talking about Federation-related stuff about VMware and stuff like that. But I'll have to go back and look. But we used to have a podcast called Back of the Envelope. As I jokingly like to say, it was the podcast where every episode, where I think about, for several episodes, I would say, Ed, I don't understand how money works. Can you explain it to me? And then I would say, Coté, nobody understands how money works. But here's what everybody theorizes. Exactly, exactly. And so relevant to that, I've been puttering around with figuring out ROI and return on investment and things like that recently. And I published a piece recently about trying to sort of address and shore up one of the questions I get asked a lot, which is like, so with this DevOps and this cloud and all this wacky new way of doing software, what's the ROI for it? And I was actually talking with someone about this this morning. Like, I think when you get asked an ROI question, it's what I call like a kind of a Rorschach question. Like, it usually says a lot more about the asker than the actual thing they're asking about. There's all sorts of different things they tend to want when they're asking about it. But specifically, when you get down to something like switching over to doing like agile software development or DevOps or all this process stuff, it's almost, I have to resist the urge to be that old, what do they call them? The bastard operator from hell or whatever? Like, you know, there's always the answer. That question is invalid. The gray-bearded eunuchs guy with the pizza stains on a Star Trek shirt? Exactly. And I feel like that's the real answer for sort of like return on investment questions when it comes to like process and culture. But it's not the helpful answer. Yeah. And so I come to you, Ed.

You're going to be for, yeah. How does money work? Okay. So I'll start off with a question to you because I want to make sure we're kind of baselining correctly. And I'm not a tech person anymore. So I follow enough to talk about it. But so what are we defining as DevOps in this particular case? And I realize that's kind of a fuzzy thing. Oh, sure. So, you know, I'm speaking as a person who just hears that term kind of thrown around and I hear things like chef and puppet and crowbar and whatever. Right. So we'll have a pretty simple definition. And that is, so what is not DevOps? Let's start with that. So traditionally, in companies that are working on custom software, they have teams of developers and they have teams of operations people. And the developers, they get some requirements from somewhere, the leap to conclusions, Matt guy in office space. And they write this software and then the software is ready to be delivered or deployed or whatever. And they give it to the operations people who figure out how to get it up and running on servers. And they make sure that it stays up and running and they monitor it. And if things break, the operations people try to figure out what to do. And then at some point, the developers write a new version of the software and they kind of give it to the operations people to install the upgrade. And this all kind of works fine and dandy. And you might have a service desk in the middle. But over the past, you know, recent years, when you're delivering most of your software over the Internet, whether you're a traditional vendor or a non-tech company, like you could be an online banking application, or you might be a health insurance company where someone files a claim to your web app or whatever. Or you might have a mobile app. And there's this expectation that not only should that work, like your software should be up and scalable, but that you might want to be able to deploy changes to it every week or multiple times a day. Like Wealthfront is a good example here where it's interesting. You go to their web page and right on their web page,

they're like, we deploy software every day. And like, it's not their business to be a tech company. They're a, I don't know what you would call them. They're an investment service, essentially. And so tactically, it's become valuable for companies to be able to deploy their software as frequently as possible, weekly if not daily. And so if you move to that kind of thing, the old way of having separate groups doesn't really work out so well. Because when you're moving that fast, you need to take a lot of operational consideration into how your applications are run. And conversely, if you're the ops people who need to deploy and to support this, you have to have, you have to understand the application a lot more. So the notion of DevOps is that we combine these two teams together more, along with a bunch of tools that we might have and some training. And we put them all on the same team so that they all kind of have responsibility for the product, if you will. And so it's a shift in how the organization is laid out and kind of how you plan out the projects. Okay, so when you're making this shift, where does the ROI question come in? In the, why are we paying to send you to these conferences to learn this stuff? Or is it, why are we getting the software in to help you do this stuff? Or why are we... Exactly. And then this... Is it all those? Yeah, yeah. This is what I meant by like, it's a Rorschach kind of question, right? Where the way that someone answers those questions is like determines why they're asking you about ROI. Yeah. And so the first way that I think people are answering this question is they're using ROI in maybe an incorrect way. I mean, you tell me... Well, let's face facts. Yeah. 99% of the time when someone up the corporate chain asks you an ROI question, if they're a finance person, they're probably just trying to check off the box and do their job to make sure the parent that they looked at this, right? Yeah. If they're anybody else, it's typically a convince me I'm not going to get fired

if this whole thing goes wrong. Exactly. Right. And the more cheerful way I would put that is I need proof that this works. Yes. That's right. And that it works without runaway costs, right? That it works in an affordable manner. Right. It could be affordable or profitable depending on the vantage point that you have, but that it's not going to be a money pit. Right. So, I mean, return on investment, just in a nutshell, is how much am I getting back in relation to what I put in, right? And typically, it's kind of measured on, you know, some timeframe, right? So annual basis, typically. So if I invest a million dollars and I get, you know, $250,000 back annually, that's a 25% ROI, right? I mean, it's very, very simple math, right? So the question becomes, how do you define what you put in and what you got out? Because, you know, in the case of DevOps, to your point, if we're talking about a cultural change, there's a number of things kind of going in there. And so the ROI calculation gets really kind of, you can make it as complex or as simple as you want to make it. Really, that speaks to me of more of an operational change. And so how would you measure improvement? I'd measure it in number of deliveries, right? Are we delivering every day? Or we used to take us three months to do a cycle and now it's taken us, we're doing it every day. So the cycles are incrementally faster. And, you know, you could probably try to analyze number of features added, but I would argue from a software development standpoint, that's kind of fuzzy, right? You know, but to your point, it's just a cultural shift. And the reality is the ROI, from my vantage point, kind of looking at it from a corporate perspective, the ROI shouldn't be measured on how I get the product to market. Like in other words, I'm taking costs out of the product delivery. It should be measured on what's my return on investment on the project, right? So if I'm using DevOps to put together Facebook's, you know, social media platform,

their website, right? I'm not going to try and calculate an ROI on the DevOps pieces of the continuous integration of delivery. I'm going to measure the ROI on the website, the whole website. And, you know, because if you try to make it really granular, you start conflating things on, you know, the product side that are kind of seeping into the delivery side. And then what you're talking about with DevOps is actually marrying those two together, right? So it's kind of a continuous cycle where, you know, if you're talking about an agile methodology, so sales and marketing or the developers are coming up with a nifty feature, it's getting rolled into the site. That's causing more users to come onto the platform, which is driving advertising revenue. And if I can do that faster, I kind of create this continuous feedback loop. So picking out the pieces that were delivered by the faster continuous integration versus the pieces that are delivered by the developer having the idea versus the pieces that were the sales and marketing guy going out and selling the ads, it's really kind of an irrelevant question. You know? Right. Wrong question. Well, yeah, it absolutely is. And it's also, you know, there's a lot of this stuff, especially when you're talking about any sort of capital investment, right, where you're talking about making, you know, laying out a chunk of money today to get some sort of return on in the future, right? When you start talking about that stuff, there's a time lag there, right? So there's a time, in other words, I'm shelling out a bunch of costs today, so let's just take let's take Apple and the iPhone, right? When they were developing the iPhone, you could see their capital expenditures was kind of ticking up and their R&D expenses kind of ticking up as they were developing this thing, but it wasn't until they actually released it to the public, they started getting $1 of sales back on the deal, you know? Right. Yeah, and that highlights one thing when I was kind of writing up a piece on this that's troubling about wrapping ROI around a process or cultural change is like you said, it's over some

period of time, right? Right. And picking that period of, I guess to fast forward to the end, all the variables, there's not that many of them that you input into an ROI calculation are hard to figure out in a process change, right? Right. And one of the harder ones is what's the boundary of time that you're going to judge? Exactly. And so, you know, so if you're going to be doing some sort of transformative corporate culture change to move this thing, you're saying it's going to take us two to three years to do this, measuring the ROI over the course of the first year is kind of ridiculous. Like, it just doesn't make any sense, right? Now, I would argue with DevOps, here's where I'll put on the finance hat and say, if what you're telling me is correct in the sense that this is a lot of, you know, kind of a path to more of an integration, theoretically, I would imagine you're stripping out costs as fast as you're putting them on. And so, it should be relatively net neutral. In other words, if I'm going to build a continuous integration platform, I would imagine you could build out a good scaffolding for that and call it three to four months, right? Yeah. And in the process of doing that, I should be requiring less, you know, help desk tickets get created, so my overtime for my support staff should be going down. I'll be, you know, if I'm virtualizing the servers, I'll be using less server space and hard drive space, so therefore, that should compress down. I should be able to kind of point to costs being stripped out on the back end and say, this is, you know, maybe not 100% directly related to this process, but it's at least correlated with it. And so, like, what's your commentary on, like, how the finance person thinks about the idea of saving money? Like you're saying, like, in the sense of we have less downtime and whenever we're down, that costs us X amount of dollars a minute. So, if we have less downtime, therefore, the ROI is this. Well, I think,

you know, number one, I'll caveat this by saying there are good finance people and there are bad finance people, right? So, you know, it kind of depends on what organization you're in and what your, you know, what your organization is kind of calibrated to. You know, I've seen a lot of people and this is where I think that the developers and the ops guys interacting with the finance team, what that relationship kind of looks like as engineering people and as, you know, people dealing with code, you tend to value precision and you tend to value the ability to, you know, as I can say, the biggest thing I miss from my days as a developer coming into finance is the fact that I used to get instant feedback and now I get no, I get little to no feedback. Right, right. The only feedback you get is the occasional joy of a clever pivot table. No, it's not even, I'm not going to talk about that. I'm talking about, okay, so let's say we're dealing with high level strategy, right? Let's contrast it. So as a developer, you go through, you check out some code from the source control, you go through, you make your modifications, you implement your feature, you do some unit tests, your unit tests come back positive and that's all happening on a half hour to an hour basis, right? This is just constantly going on and you're constantly getting this feedback. Is the code working? Is it not working? Right? So then you do your unit test and you have your scaffolding and you check it back in and it goes into the, you know, to the release branch and then you guys do, if you're in a continuous integration environment, later that day, you do your automated release and you look and has anything blown up? No. Have all the unit tests come back positive? Yes. Is the user still checking into the application and checking out when they're signing out when they want to? Yes. Great. I did a great job. I know this worked, right? On the finance side, you go in and you get to your point, you sit there and you put together your reports and you gather your data and the data is always fuzzy because it's like, okay, well, this comes out of one system here and we're not, you know, booking the accrual for this until we get this piece of data from this other system and then we do this estimate and we lay it on top and that's what our final top line number looks like

or that's what this account, you know, expense item looks like for this, for the entire company or whatever. Then you say, well, we're spending way too much on travel and entertainment. So we're going to implement a new report to track travel and entertainment. We're going to implement a new policy to manage travel and entertainment. We're going to move this person over to directly oversee and authorize travel and entertainment expenditures over $5,000, $10,000, whatever it is. Okay. So we've done all that. That takes three weeks to do, put in place, whatever, if you're working at a really high-performing, super agile company, right? And how many of those are really out there? Then I have to wait for not the next monthly results, but the monthly results after that to even see if that process has had any effect. And then I've got to wait another call at 60 to 90 days to see if that's a trend or if that's actually a just blip on the radar. So I've worked like mad. I've put in this place, I've put in this structure, I've emphasized all these things and put the right people in place or whatever. Most of that's not even really truly the finance person's call. It's just making recommendations and seeing if they get followed. And then I've got to wait three months to figure out if what I did was actually correct or not. And that's what I'm talking about, the lack of continuous feedback. Your feedback loop is mega long in comparison to development. In comparison to development, that's exactly right. So the point of all that is when you're dealing with this stuff at the finance side, you're looking for directionally right. Am I moving in the right direction or am I moving in the wrong direction? So if I'm looking at this DevOps thing and trying to figure out if my ROI is actually well, first of all, once again, I wouldn't try and couch DevOps in terms of ROI. I'd want to couch it in terms of, look, I see this many metrics in terms of builds and cycles. These are our feature releases. And I want to look at it in terms of development and operation heads.

How many heads it's taking me to deliver that stuff? And I'd want to look at, really honestly, I'd want to look at my development expense. What's the developer, what's the cost center of development and operations look like? And if you're telling me that these two are now integrated and they're talking to each other, I theoretically kind of want to smash those together into one cost center and I want to say combined, what does that whole expenditure look like? And is that going, you know, larger or smaller relative to what revenue is doing? Right. So if I can summarize to this point, right? Because the thing that the old gray beard annoying sysadmin never does is tells you what you should be doing. He just tells you you're wrong and then moves on with his life. Right. And then so, sorry, I just interrupted, but the original kind of reason for that whole digression is as the engineers, they want to come in and say, well, if I tell you I'm going to get you $1.75 in savings per, you know, I don't know, per development cycle, is that enough or should it be $1.85 or should it be $1.95? And what I'm saying is, you know what, let's just say if it's around $2, we'll call it a day and we're fine. And I think that's the conversation where it kind of breaks down a little bit because it's like, I don't, you know, the developers don't understand, I don't need the precision, I just need the direction. And the finance guys are saying, you know, these people come to me with all this rigmarole about we're improving this and we're improving that and yet my, you know, general admin expenses keep going up month over month and so I'm not seeing it. Right, right. No, and so that gets to the next sort of like phase which is, and I think you popped in my head an interesting way of looking at it. Like, so when you're talking with the finance people, to them, it's all like a black box essentially, right? Yeah. And you can do whatever you want inside the black box and the only outputs that they really know about are sort of like what's the cost and how much is it making me essentially,

right? Exactly. And then so therefore if you want to change around the process that you do in the black box, right? And you go back, you go to the finance people and you're like, I need a million dollars and they're like, why do you need a million dollars? Right? And it's kind of like, well, because I'm going to do DevOps and that's going to cost me a million dollars in like hiring staff or maybe getting licenses or, or time where we're not making money maybe that's a little fuzzier, but like, you know, and, and, and then so maybe it's, it's sort of like all you can really, the, the only sort of things you can converse between those two parties is this is either going to lower our costs, right? Yes. By switching over to this or it's going to somehow make it so that we make more money, right? Which, which could sort of kind of be the same thing, but it's sort of going to lower costs. So then, so they're not the same thing. Well, what I mean to say is, for example, you might, you might lower, by speeding up, you might lower the cost of like sitting around and doing nothing. And then because you can speed up, you can do more output essentially. I mean, it's, it's a silly distinction, but. No, but, but to the, the finance person, it's like, well, but when I walk around, you guys are all surfing the web and answering questions on Stack Overflow anyway. So you don't need to be sped up. But, you know, exactly. So, you know, that's the part where it is, I think it is important to kind of frame it. And the other thing I would say is, instead of coming in and saying, I need to spend a million dollars, which you should be coming in and saying, I need $10,000 for this site license and we're going to try this out and we're going to do this and I'll kind of roll it and you kind of just over time kind of roll it in, right? If you try to just kind of say, we're going to spend a big pot of money and at the end of this we're going to have something, I mean, those are always, I mean, number one, it's not agile, right? And number two, that's what's always going to prone to failure. Right, right. No, and so it seems like the point you want to get to with process change is, and I like the way you were putting it at the beginning, is you don't really talk about how the process is better or worse

or whatever. You just focus on the end result that you're going to get sort of revenue-wise and like saying, if we switch over to doing it this way, we're going to end up with more revenue or more savings, right? Yes, yeah. And so it's almost like if someone's asking you to do the ROI for DevOps, someone's asking you to do the ROI for the wrong thing, right? They are. And the other thing too- And instead, you might need, there's some other argument that you need to make with them that doing what you're currently doing is worse than if you're doing it in this new way. That's exactly right. And so the other thing I think I would, you know, really kind of make the case on is this, is that there is a certain amount of, call it, you know, what it is called maintenance capex, right? Like the capital expenditures that are just to kind of maintain the status quo, right? Like if, you know, and maintenance expenses as well. So if I've got, you know, a team of three developers working on a product and we release that product into the wild, I still need to have developers on hand even though the product is already out in the market and the reason why and not just to work on new features, not to work on the next version, just to support the current version. I mean, you've got desktop support or you've got technical support or whatever on the back end and, you know, depending on the product level they're going to have a certain level of complexity and it might not be as high as the core development team but you can't just say we're not going to incur any more development cost because you've got to release upgrades to the current version and you've got all this other stuff, right? So to sit there and say we're going to carve out expenditures, you know, you can't drop that down to zero. There's an embedded cost associated with just having a product. Yeah. And that's the thing that you've got to kind of make the case on and so what I think the case really made there is we're lowering the ongoing costs of this stuff. Oh yeah, that's good. Now that's like a new handle to focus on is that the future,

we'll just make it very simple, the future maintenance costs that will result from operating in this way will be less than other ways. Yes. And what you really focus on that is the time frame to go from here to there and what the metric is we're going to measure it on and maybe, you know, because here's the other difficult part about this, especially in the circles that, you know, you're kind of running in with this is your tip when you talk about, I mean, I always kind of laugh at the other podcasts you do with all of our other buddies when you start talking about, you know, this is a static company, it's slow growing, it's this, that, whatever, and they're growing at like 10% a year. Okay. Exactly. Most companies in the world do not grow at 10% a year. Most companies would kill for 10% a year growth, but in the tech world that's like anemic. It's like Microsoft, I mean, they're dead. They're only growing at 10% a year. Right. You know, you might as well be selling aluminum if you're at that rate in the tech world. Well, yeah, but the reality is if you're selling aluminum you're growing at one and a half, 2% a year, right? I mean, so that's the difference and when you start talking about compounding, you're talking about exponentially different numbers and so that's the thing that I kind of, you know, that makes this very difficult is if I'm a company that's growing revenue at 25, 30% a year because I've got some hot product and I'm, you know, and I don't do DevOps, my, you know, SG&A, my general admin expenses are going to be growing even if I'm just kind of standing still, they're going to be growing probably, you know, somewhat in line with that revenue growth, right? And if I do DevOps, they might be growing at a much slower, so let's say, so let's say in a non-DevOps world you're growing the top line at 30%, you're growing revenue at 30% and you're growing SG&A at call it 15%, all right? That's, for most companies is a killer situation to be in because you're just generating every year massive and massive amounts of cash more and more than you were generating the year before and you can use that to fund other stuff. Okay, if I do DevOps, let's say I only

knock that down to, or let's say I knock it out of the park and I knock that down to 10% a year, so I go from generating revenue at 30% and SG&A has only grown at 10%, right? Versus the 15% it was growing at before. The fact of the matter is when the finance guy is looking at it, he's like, I'm not seeing any costs coming out. Well, of course you're not seeing any costs coming out because SG&A is still growing and you have this massive product that's still growing and we're still supporting it, but we're supporting it more efficiently than we would otherwise. Yeah, no, no, that makes sense and that's, that's, that's, you know, once again gets back to the argument that you need to make is, well, I don't know, I mean, I mean, tell me what you think or have seen has been successful in cases like this is that this, this process works and, and here, and in my mind what that means is you have to point to other examples of that process having worked with people. Right, but from my understanding the trouble is, is that it's very, you know, in the high flying, high, you know, dollar tech company. So, you know, I assume companies like Facebook and Amazon are using DevOps quite successfully, but, you know, maybe, I don't know that a company like IBM necessarily is using DevOps successfully or maybe they are and I just don't know, but, you know, it becomes very easy to say, well, that works for them because they're different. They're in a special category, right? But for us, I mean, if I, you know, if I'm, I'm a Frisbee manufacturer, do I really need DevOps? I mean, it's just not part of my, IT's not part of my core competency. It's not something I really truly care about. Why do I need this? And my response to that would be, you know, kind of the Marc Andreessen response is, every company needs IT. It's now become an integral part of everything, you know? And so, if you're going to have IT at all, you probably need to have something like this. So, so what are, what are like analogs of other processes or best practices that sort of like become enshrined as like,

you should do things that way, right? Like, because the situation is like, it's, it's the typical that's fine for Merlin problem, right? Right, right, right. Like, you know, that's great for all those unicorns or whatever, but, but we can't do that. So it doesn't apply to us. And yet there are other practices like you probably shouldn't have free beer at your company. That's just not a sound policy. You know, there's sort of like accepted things that are unquestioned that are processing culture wise. And how do those things become so? That's the difficult part, right? So they, they, sometimes they become so just because of inertia, right? And, and sometimes they, you know, as we like to laugh about the management consultants, the ivory tower coined a phrase and put together a PowerPoint presentation and they take over the world. So I think another, I mean, like on the manufacturing side, you have the, you know, the six sigma, the GE six sigma stuff and like lean manufacturing and the Toyota just in time systems and stuff. Oh yeah, those are good analogs. Yeah. And so the, you know, but those are cases where you can, what you point to is the increase in the operating margin of the company. So we were operating at a, you know, 15% operating margin and now we're at an 18% operating margin is because we're taking out all this, you know, all this waste. Right. And so DevOps, I think would be the same kind of thing, which is, okay, over time, if I look at, you know, if I look at what our development costs are to deliver a release, they've gone down dramatically. If I look at the time to deliver a release, those have gone down dramatically. Now that, you know, once again, you have to still have a good strategy. Like in other words, I, my, my, my favorite kind of idiot example is I can have a business where I sell, you know, $10 bills for five bucks and I will generate so much sales. It'll make your head. But at the end of the day, it's the stupid business model, right? So if, if I have a development strategy

that's putting in place features that nobody cares about, I don't really care what my cost to deliver is. Right. You know, and so you always kind of got to balance that. But I think at the end of the day, you've got to point to the DevOps is about the operational metrics. It's not about a return on investment in off of a conference or a return on investment off of a software license. And so, I mean, in a sort of like intellectually gun to head situation where you have to like decide between two things that you don't want to like, do you think generally like it's best to focus on reducing costs, eliminating waste, to put it another way? Like, is that, does that sort of always win if you position things that way? it depends on the company culture, it depends on a lot of things. I would say this, I would say most executive management teams really respond to sales because most, I don't want to say that, that's probably a wrong thing to say, a good chunk of CEOs came through sales. They're customer facing. Right. It's all about, and their strategies are always customer facing. The things they worry about are customer facing. Most CFOs I think probably tend to be more operational. They tend to be more cost focused just because of once again, kind of corporate inertia and historical context of what the CFO role has kind of morphed over time to be more strategic than it has been in the past, but in the past it used to be very much an accounting function. What are our numbers? How do they kind of roll? So I would say coming in and getting approval, to do something, you're focusing on cost is probably a good thing. If you're trying to do whole cultural changes, focusing on sales is probably the better way to go. Right. Which is to say your what do you call it? Stereotypical, your archetype of the CEO there. Yes. They'll be focused on growth. They want to get more and more new sales and new

money coming right. Whereas the CFO is very focused on what we would call the bottom line that is reducing the cost of things. Right. And so I would say from a pitch standpoint, trying to get buy-in, the focus for DevOps for pitching to the CFO would be time to delivery, time to market. Right. And then for the CFO, it would be kind of essentially cost per release cycle. Right. Just a lean pitch. What we're doing is there's a lot of waste in the system and we're removing that waste. that waste may be operational, it might be literal licenses or costs that we have, but someone in this archetypical CFO example, they understand the value of removing waste and tend to value that. Yeah. Yeah. And, you know, so the other thing I would say to that is at the end of the day, most companies have a corporate budget, right? I mean, and so at the beginning of the year, beginning of the quarter or beginning of the month or whatever, you kind of say, I'm going to spend roughly X amount of dollars, right? And so if I'm kind of in charge of the ops budget and kind of to where I'm going to spend my dollars and everything, what I would focus on is, look, I've got the options to spend it on this thing or this thing, and this thing is more optimal because it will lower my release time, it will do this, it will do that, you know? And the thing a lot people don't really pay enough attention to, I think, is the actual validation of the fact that it's working or not. You know, and as I like to say, you know, it's fine if you, you know, it's fine if you want to sit there and tell me I've got to spend more to hire this person who's an ops person with development experience because we're going to DevOps and I need people with coding experience now and I used to just only need sysadmins, right? Well, that's all well and

good but you've also got a team of sysadmins over here so if you're not going to, if you're telling me that these guys are coming in and they're going to make this whole thing leaner then why am I not seeing any of these guys moving into some other position or moving to some other department or moving to some other company? Like that's, and I know that it's kind of a, I don't know, a scary thing to have to address sometimes but the reality is you don't just get to add costs and not take costs out somewhere. Right, right, right. Right. So. Yeah, and that's another issue in the circles I run in as you say is the split between the new way of doing stuff and the old way of doing stuff. Yeah. And how as whoever, whatever team or whatever person is sitting on top of both of those silos of excitement, right? Yeah. Like there are finite resources of time, money, and priorities and all your usual corporate planning stuff and sort of like how you allocate those finite resources over those two things and think about the opportunity lost or gained by focusing on the new stuff or optimizing the old stuff or vice versa. Right. Which is a totally different thing than ROI. Yeah. But it's that strategic question of like how much should I be spending on the new way of doing stuff but yet maintaining the old way of doing things or what? So you want to know the beyond the ROI question because I think the core launching point for this conversation was okay so how do I make my finance people happy? Right. And I can tell you from my experience how you make you know the most of the finance people I kind of run with happy. You tell them what's going to happen before it happens. And if you do that well you're probably okay. And if you do that poorly you're not okay. And what I mean by that is okay I'm going to spend this pocket of money on DevOps stuff and I'm

retooling my team to be more DevOps oriented and I'm going to run an incremental higher amount of expenses over call it the next three or four months while we do this transformation and then the costs will drop off because we're not doing the training we're not putting in the software licenses we're not doing this and we're stripping out stuff. So we had a team of five people that were running this. You will see over the next year that run down to three people you we had this much we were paying in licensing expenses. We're not going to pay we're going to pay some sub percentage of that less starting in six months because we'll have rolled off the old system onto the new system. Right. And if and if you're off like let's say you said it's going to happen in six months and you get to month three and you realize it's going to happen in month seven you come to them in month three and you say hey it's not going to happen in month six it's going to happen in month seven and here's why and here's why I'm not concerned about it. Okay. Or you come in in month three and you say hey I thought this was going to happen in a month six. It's not happening at all. We need to kill this thing. Right. We need to stop it and we need to stop the bleeding and this whole thing was was a mistake and we here's what we learned and here's how we're going to fix it. Right. If you're having those conversations and you're giving them enough lead time to react you're probably going to get a lot farther than just we're doing DevOps and I need a million dollars and then six months later it's like well where's my savings while we're still doing DevOps. It's going to be awesome. Yeah. I mean and I and once again the world is fuzzy and the world is messy and and things don't work out the way you planned 100% of the time and I think everyone realizes that but if you're honest with yourself and then you turn around and be honest with everybody else nine times out of ten that's going to take you where you need to go. Yeah. No I think I think that's the I mean it's I don't know if it's ironic but it but it's delightfully ironic in that the the origin of doing like agile or lean or DevOps or all this stuff is often like the future is very unpredictable so we need to have small batches to study and

triangulate and get more information and then it's like a comforting and then typically you think of the finance people as not that right but but in fact at least in the you know in in in in the happy version of the world like the finance people are just like hey I just want to make sure you're being responsible and we're talking right right like that there's not like crazy stuff happening that that we hear about way too late and that was correct and we get a chance to like work on stuff which matches well with the original intentions. Yeah and so you know I worked on a project a while back that was you know a six month project that we were doing this implementation and some stuff or whatever and we had consultants coming in and about you know we were tracking well ahead of budget all along the way and then and let's just say let's just say it was month three I came in and I was sat down with the person I was the person was kind of in charge of spending the money and I said hey look we have been tracking ahead of schedule and had a budget all along the way here I'm going to tell you right now this month you're going to start seeing us racking up a bunch of hours and we're going to start slipping back below you know above our budget expenditures on this deal and we're going to start racking up more hours and it's going to look like we're not making progress we are at a point in time on this project where at the implementation it's kind of reaching its inflection point and after we get through call it the next three weeks all we're going to be doing is validation and so what you're going to see is the consultant hours are going to drop way off because I don't need them anymore and it's just going to be us cranking on making sure all the data is coming through correctly you know but you're going to look at the project tracking you know mechanisms we put in place and you're going to see that we're we're spending a lot more than you think we should be and this is why so I'm just giving you a heads up everything's fine if it's not fine I'll let you know and you know honestly we did exactly what I said and everybody was fine you know it but it's it's a function of giving everybody advance warning and the function of you trying to really understand what drives the the

DevOps I mean not that I was doing DevOps but it would drive that conversion and what should that conversion look like and I would push back on you know not that I want to side with finance on everything here but I would push back on the ops teams that are kind of like well how do I how do I sell this how do I do this part of it might be I'm just you know speaking to archetypes here you might not truly understand what this process should look like and so you're having trouble explaining you don't understand it well enough to simplify it for someone who's not coming from this world right and if that's the case you might want to dig a little deeper and say how do I really truly make sure I have a handle on this yeah now that makes sense well I think that's a good place to leave off unless you have anything else you wanted to throw out there no I don't I I'm not sure we actually answered the original question which is how do I calculate ROI but thankfully I started off saying there is no answer because it's a bad question so we come back around but but but I think I think I think I think I think what's helpful right like like whenever whenever there's a situation where there's it's it's a bad question with no answer then then the the the the proper pedantic thing to do and I mean that that word means the wrong thing nowadays but the helpful thing to do is to say here's how you should think about that and here's how to here's how to solve the original problem that prompted you to ask this question and you know go along that path and I think I think you know to your point right like so so if the question is how do I make my finance people happy the answer is you should talk to them yeah and I think you yeah and I think you should have conversations about what what this really is going to mean and if you can't you know you don't have to worry so much about quantifying down to the penny but you should in rough terms be able to talk about I'm going to be able to deliver this much more with the same amount of money right you know and I was on on tab to spend you know x and I'm going to spend x plus one this year but I'm going to drop it down to x minus two next year and then you're up to that x minus three you know and if you deliver on all those things then

you might wake up one day and find out you have a very high functioning DevOps you know system in place and it's all hunky dory and all your problems are solved that's right so so if someone wanted to was interested in more ed where should they go to look that up oh geez I am such not a social media person anymore I have a Twitter account I have an Instagram account and I posted them once every six months you know I guess Twitter is the best place to hit me up so that's at a goodwin tx and then yeah I guess I'll respond to that honestly the best way to hit me up so I run the Houston our users group and that meetup site there's a huge amount of messaging that goes back and forth prior to the prior to the meetups I get a lot of kind of like our technical questions thrown my way and stuff so that's actually a really good place to do that and I wish I could tell you what the address on that is let me see it's meetup.com slash Houston are that's it so yeah dinner Houston or without without an e and yeah and if anybody wants to come to the meetups I'm pretty much every single one every month we meet at Stark Houston mostly the first Tuesday of every month and we typically have really good topics on like machine learning and time series analysis and whatever so exactly making sense of that crazy language perfect yeah yeah so the joy of that is is it's I'm not a developer anymore I don't have to answer why the it's programmatically kind of a mess of a language and yeah I just get to have fun with it so exactly well great well as always this has been the Pivotal conversations podcast you can you can check out the show notes I'll put some links to the our user group Ed was talking about and his famous Twitter account very high traffic yeah I think I've got like two followers and I think you and that's right

and and you can you can find all that stuff at pivotal.io slash podcast or podcast depending on your plurality your position thereof and with that we'll see everyone next time bye bye bye

Tanzu Talk · 🍕 Get more pizza.