A short while ago, I wrote up how to approach doing ROI cases for DevOps. The catch, of course, was that doing ROI for DevOps is often the wrong “question.” That said, we all live in the real world, so you need to tell the finance people, let alone your management chain, something if they’re asking you to justify a decision.
To follow-up on the piece, I called up my old friend Ed Goodwin, a programmer friend who went and got an MBA and entered a whole new career in finance. I asked him to walk me through how you’d think about doing the ROI for something like DevOps and, more broadly, how to work with finance people who are curious about new IT processes like DevOps and cloud native. He gives some excellent, pragmatic advice. As always, it helps to just talk with people—even if they’re from finance.
PLAY EPISODE
SHOW NOTES
- Subscribe to the feed
- Feedback: podcast@pivotal.io
- Links referred to in the show:
- Ed and I’s previous podcast, now moribund, Back of the Envelope
- Find Ed on Twitter or at the Houston R user’s group
TRANSCRIPT
Coté:
Hey, it’s been a long time since we recorded anything.
Ed Goodwin:
Yes, it has actually. It’s been two years now, I think? Something like that?
Coté:
Yeah. I think oddly enough the last time we recorded, we were talking about federation related stuff about VMware and stuff like that. 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, for I think about several episodes, I would say, “Ed, I don’t understand how money works. Can you explain it to me?” Then you would say …
Ed Goodwin:
Then I would say, “Coté, nobody understands how money works, but here’s how everybody theorizes. “
Coté:
Exactly.
Ed Goodwin:
Yeah.
Coté:
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 address and shore up one of the questions I get asked a lot, which is, what’s with this DevOps and this cloud, and all this wacky new way of doing stuff, what’s the ROI for it?
I was actually talking with someone about this this morning. I think when you get asked an ROI question, it’s what I call like a Rorschach question. 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. Specifically, when you get down to something like switching over to doing Agile software development or DevOps all this process stuff, I have to resist the urge to be that old, what do they call it? The bastard operator from hell or whatever? There’s always the answer, “That question is invalid.”
Ed Goodwin:
They gray-bearded UNIX guy with the pizza stains on his Star Trek shirt?
Coté:
Exactly. I feel like that’s the real answer for like return on investment questions when it comes to process and culture. It’s not the helpful answer.
Ed Goodwin:
Yeah.
Coté:
So, I come to you, Ed.
Ed Goodwin:
Yeah.
Coté:
How does money work?
Ed Goodwin:
Okay, so I’ll start off with a question to you because I want to make sure we’re baselined correctly, and I’m not a tech person anymore. I follow enough to talk about it, but what are we defining as DevOps in this particular case? I realize that’s a fuzzy thing.
Coté:
Sure.
Ed Goodwin:
Speaking to the person who hears that term thrown around, and I hear things like Chef and Puppet and Crowbar and whatever. That’s the extent my knowledge.
Coté:
We’ll have a pretty simple definition, and that is, what is not DevOps? Let’s start with that? Traditionally, in companies that are working on custom software, they have teams of developers, and they have teams of operations people. The developers, they get some requirements from somewhere. They leap to conclusions, that guy in Office Space.
They write this software, and then the software’s ready to be delivered or deployed or whatever. 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. They monitor it. 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 give it to the operations people to install the upgrade.
This all works fine and dandy. You might have a service desk in the middle, but over the recent years, when you’re delivering most of your software over the internet, whether you’re a traditional vendor or a non-tech company. 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. There’s this expectation that not only should that work, like your software should be up and scalable, but you might want to be able to deploy changes to it every week or multiple times a day.
Wealthfront is a good example here where it’s interesting. You go to their webpage and right on their webpage they go, we deploy software every day. 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.
Tactically, it’s become valuable for companies to be able to deploy their software as frequently as possible, weekly, if not daily. If you move to that kind of thing, the old way of having separate groups doesn’t really work out so well. 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 support this, you have to understand the application a lot more.
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. We put them all on the same team, so that they all have responsibility for the product, if you will. It’s a shift in how the organization is laid out, and how you plan out the projects.
Ed Goodwin:
Okay, so when you’re making the shift, where does the ROI question come in? Why are we paying to send you to these conferences to learn this stuff? Or is it why are we getting this software to help you do this stuff? Or why are we …
Coté:
Exactly.
Ed Goodwin:
All those?
Coté:
Yeah. This is what I meant by it’s a Rorschach kind of question. The way someone answers those questions determines why they’re asking you about ROI. The first way that I think people are answering this question is they’re using ROI in maybe an incorrect way.
Ed Goodwin:
Let’s face facts. In 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 their box and do their job to make sure that they looked at this. If they’re anybody else, it’s typically a, convince me I’m not going to get fired if this whole thing goes wrong.
Coté:
Exactly. The more cheerful way I’d put that is I need proof that this works.
Ed Goodwin:
Yes. That’s right.
Coté:
And that it works without runaway costs. That it works in an affordable manner. It could be affordable or profitable, depending on the vantage point that you have, but it’s not going to be a money pit essentially.
Ed Goodwin:
Right. Return on investment, just in a nutshell is how much am I getting back in relation to what I put in? Typically, it’s measured on some time frame, annual basis typically. If I invest a million dollars, and I get $250,000 back annually, that’s a 25% ROI. Very simple math. The question becomes how do you define what you put in, and what you got out?
In the case of DevOps, to your point, if we’re talking about a cultural change, there’s a number of things going in there, so the ROI calculation gets really … You can make it as complex or as simple as you want to make it. Really, that’s seems to be more of an operational change, and so how would you measure improvement? I’d measure it in number of deliveries. Are we delivering every day? It used to take us three months to do a cycle, and now we’re doing it every day. The cycles are incrementally faster. You could probably try to analyze number of features added, but I would argue from a software development standpoint that’s fuzzy.
To your point, it’s just a cultural shift. The reality is the ROI from my vantage point looking at it from a corporate perspective, the ROI shouldn’t be measured on how I get the product to market. In other words, I’m taking costs out the product delivery. It should be measured on what’s my return on investment on the project?
If I’m using DevOps to put together Facebook’s social media platform, their website, 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. If you try to make it really granular, you start conflating things on the product side that are seeping into the delivery side. What you’re talking about in DevOps is actually marrying those two together, so it’s a continuous cycle where if you’re talking about an Agile methodology, sales and marketing 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. If I can do that faster, I can create this continuous feedback loop.
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 an irrelevant question.
Coté:
Right. “Wrong question.”
Ed Goodwin:
Yeah. It absolutely is. There’s a lot of this stuff, especially when you’re talking about any sort of capital investment, where you’re talking about laying out a chunk of money today to get some sort of return on in the future. When you start talking about that stuff, there’s a timeline there. In other words, I’m shelling out a bunch of costs today.
Let’s just take Apple and the iPhone. When they were developing the iPhone, you could see their capital expenditures ticking up and their R&D expenses ticking up as they were developing this thing, but it wasn’t until they actually released it to the public they started getting one dollar of sales back on the deal.
Coté:
Right. That highlights one thing when I was writing up a piece on this that’s troubling about wrapping ROI around a process or cultural change. It’s like you said, it’s over some period of time. 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. One of the harder ones is what’s the boundary of time you’re going to judge?
Ed Goodwin:
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 ridiculous. It doesn’t make any sense. I would argue with DevOps, here’s where I’ll put on the finance hat, if what you’re telling me is correct in the sense that this is a lot of path toward integration, theoretically, I would imagine you’re stripping out costs as fast as you’re putting them on. 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 or four months. In the process of doing that, I should be requiring less help desk tickets get created so my overtime for my support staff should be going down. If I’m virtualizing the servers, I’ll be using less server space and hard drive space, and therefore that should compress down. I should be able to point to cost being stripped out on the back end and say this is maybe not 100% directly related to this process, but it’s at least correlated with it.
Coté:
What’s your commentary on how the finance person thinks about the idea of saving money? Like you’re saying, in the sense of we have less downtime. Whenever we’re down, that costs us X amount of dollars a minute. If we have less downtime, therefore the ROI is this.
Ed Goodwin:
Number one, I’ll caveat this by saying there are good finance people and there are bad finance people. It depends on what organization you’re in, and what your organization is calibrated to. I’ve seen a lot of people, and this is where I think the developers and the ops guys interacting with the finance team, what that relationship looks like. As engineering people, as people dealing with code, you tend to value precision. You tend to value the ability to … Like I 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 little to no feedback.
Coté:
Right. The only feedback you get is the occasional joy of a clever pivot table.
Ed Goodwin:
No. I’m not even talking about that. I’m talking, okay, so let’s say we’re dealing with high level strategy. Let’s contrast it. As a developer, you go through. You check out some code from the source control. You go through and 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. This is just constantly going on. You’re constantly getting feedback. Is the code working, or is it not working?
Then you do your unit tests, your scaffolding, you check it back in, and it goes into the release branch. Then you guys do, if you’re in a continuous environment later that day, you do your automated release, and you look. Has anything blown up? No. Have all the unit tests come back positive? Yes. Is the user still checking into the application and checking in and signing out when they want to? Yes. Great. I did a great job. I know this works.
On the finance side, you go in. You get to your point, you sit there and you put together your reports, and you gather your data. The data is always fuzzy. This comes out of one system here. We’re not booking the accrual for this until we get this piece of data from the other system, and then we do this estimate. We lay it on top, and that’s what our final top line number looks like, or that’s what this account expense item looks like for the entire company or whatever.
Then you say, we’re spending way too much on travel and entertainment. 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 oversee and authorize travel and entertainment expenditures over $5,000 or $10,000, whatever it is.
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. 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 processes have had any effect. Then I’ve got to wait another, call it, 60 to 90 days to see if that’s a trend or if that’s actually a blip on the radar.
I’ve worked like mad. I’ve put in this structure. I’ve emphasized all these things and put the right people in place, whatever. Most of that is not even truly a finance person’s call. It’s just making recommendations and seeing if they get followed. Then I’ve got to wait three months to figure out if what I did was actually correct or not. That’s what I’m talking about the lack of continuous feedback.
Coté:
Yeah, your feedback loop is mega long.
Ed Goodwin:
Yeah.
Coté:
In comparison to development.
Ed Goodwin:
In comparison to development, that’s exactly right. The point of all that is when you’re dealing with 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? If I’m looking at this DevOps thing, and trying to figure out if my ROI is actually working. Once again, I wouldn’t try to couch DevOps in terms of ROI. I’d want to couch it in terms of, 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.
I’d want to look at, really honestly I’d want to look at my development expense. 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, theoretically I want to smash those together into one cost center. I want to say combined what is that whole expenditure look like? Is that going smaller or larger relative to what revenue’s doing?
Coté:
Right. If I can summarize to this point because the thing that the old gray beard, annoying sys admin does is tells you what you should be doing. He just tells you you’re wrong and then moves on with his life.
Ed Goodwin:
Right. Sorry, just to interrupt, but getting back to the original reason for that whole digression is as the engineers, they want to come in and say, if I tell you I’m going to get you $1.75 in savings per development cycle, is that enough? Or should it be $1.85, or should it be $1.95? What I’m saying is let’s just say if it’s around $2, we’ll call it a day. Fine. I think that’s the conversation where it breaks down a little bit. The developers don’t understand. I don’t need the precision. I just need the direction.
The finance guys are saying people come to me with all this rigmarole about we’re improving this, we’re improving that, yet my general admin expenses keep going up month over month, so I’m not seeing it.
Coté:
Right. That gets to the next phase, which is … You popped in my head an interesting way of looking at it. When you’re talking with the finance people, to them, it’s all like a black box essentially. You can do whatever you want inside the black box, and the only outputs that they know about are what’s the cost, and how much is it making me? Essentially.
Ed Goodwin:
Yeah. Exactly.
Coté:
Then therefore, if you want to change around the process that you do in the black box, and you go to the finance people, and you’re like, “I need a million dollars.” Why do you need a million dollars? It’s because I’m going to DevOps, and that’s going to cost me a million dollars in hiring staff, or maybe getting licenses, or time where we’re not making money. Maybe that’s a little fuzzier.
Then maybe it’s sort of like all you can really, the only things you can converse between those two parties is, this is either going to lower our costs, by switching over to this, or it’s going to somehow make it so that we make more money. Which could sort of be the same thing, but it’s going to lower costs.
Ed Goodwin:
They’re not the same thing.
Coté:
What I mean to say is, for example, by speeding up, you might lower costs of sitting around and doing nothing. Because you can speed up, you can do more output essentially. It’s a silly distinction.
Ed Goodwin:
To the finance person, when I walk around, you guys are all surfing the web and answering question on StackOverflow anyway. You don’t need to be sped up.
Coté:
Right. Exactly.
Ed Goodwin:
That’s the part where it is important to frame it. The other thing I would say is instead of coming in and saying, “I need to spend a million dollars,” you should be coming in and say, “I need $10,000 for this site license, and we’re going to try this out, and we’re going to do this, and roll it in.” You just over time roll it in. If you just try to say we’re going to spend a big pot of money, and at the end of this, we’re going to have something, those are always. One is not agile, and number two, that’s always a part of failure.
Coté:
Right. It seems like the point you want to get to is process change. I like the way you were putting it in the beginning. You don’t really talk about how the process is better or worse. You just focus on the end result that you’re get, revenue-wise. Saying, if we switch over to doing it this way, we’re going to end up with more revenue, or more savings.
Ed Goodwin:
Yes.
Coté:
If someone’s asking you to do the ROI for DevOps, someone’s asking you to do the ROI for the wrong thing.
Ed Goodwin:
They are. The other thing …
Coté:
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 were doing it in this new way essentially.
Ed Goodwin:
That’s exactly right. The other thing I would really make the case on is this, is that there is a certain amount of, call it, well, it is called maintenance CapEx, the capital expenditures that are just to maintain the status quo and maintenance expenses as well. If I’ve got 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 not just to work on new features, not to work on the next version. Just to support the current version.
You’ve got desktop support. You’ve got technical support or whatever on the back end, and 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. You can’t just say we’re not going to incur any more development costs. You’ve got to release upgrades to the current version. You’ve got all this other stuff.
To sit there and say we’re going to carve out expenditures, you can’t drop that down to zero. There’s an embedded cost to just having a product. That’s the thing you’ve got to make the case on. What I think the case really to be made there is we’re lowering the ongoing costs of this stuff.
Coté:
Yeah, that’s good. That’s like a new handle to focus on.
Ed Goodwin:
Yeah.
Coté:
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.
Ed Goodwin:
Yes.
Coté:
We can operate.
Ed Goodwin:
What you really focus on is the time frame to go from here to there, and what the metric is we’re going to measure it on. Here’s the other difficult part about this, especially in the circles that you’re running in with this. I always laugh at the other podcast you do with all of our other buddies when you start talking about this is a static company. It’s slow growing. It’s this, that, or whatever, and they’re growing at like 10% a year.
Coté:
Exactly.
Ed Goodwin:
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 anemic. That’s like, Microsoft. They’re dead. They’re only growing at 10% a year.
Coté:
Right. You might as well be selling aluminum if you’re at that rate in the tech world.
Ed Goodwin:
Yeah, but the reality is, if you’re selling aluminum, you’re growing at 1.5%, 2% a year. That’s the difference. When you start talking about compounding, you’re talking about exponentially different numbers. That’s the thing that makes this very difficult. If I’m a company that’s growing revenue at 25%, 30% a year because I’ve got some hot product, and I don’t do DevOps, my SG&A, my general and admin expenses, are going to be growing even if I’m just standing still. They’re going to be growing probably somewhat in line with that revenue growth.
If I do DevOps, they might be growing at a much slower. Let’s say in a non-DevOps world, you’re growing the top line at 30%. You’re growing revenue at 30%. You’re growing SG&A at, call it, 15%. That’s for most companies is a killer situation to be in. You’re just generating every year massive amounts of cash, more and more than you were generating the year before, and you can use that to fund other stuff.
If I do DevOps, let’s say I only knock that down, or let’s say I knock it out of the park, and I knock that down to 10% a year. I go from generating revenue at 30%, and SG&A is only growing at 10% versus the 15% it was growing before. The fact of the matter is when the finance guy is looking at it, he’s going, and “I’m not seeing any costs coming out.” Of course you’re not seeing any costs coming out because SG&A is still growing because the company’s still growing. Yet there’s a massive product that’s still growing, and we’re still supporting it, but we’re supporting it more efficiently than we would otherwise.
Coté:
Yeah, that makes sense. Once again, it gets back to the argument that you need to make is … Tell me what you think, or you’ve seen has been successful in cases like this. This process works. In my mind, what that means is you have to point to other examples of that process having worked with people.
Ed Goodwin:
Right, but from my understanding it’s very in the high flying, high dollar tech companies. I assume companies like Facebook and Amazon are using DevOps quite successfully, but maybe I don’t know that a company like IBM necessarily is using DevOps successfully. Maybe they are, and I just don’t know. It becomes very easy to say that works for them because they’re in a special category.
For us, if I’m a Frisbee manufacturer, do I really need DevOps? IT’s just not part of my core competency. It’s not something that I truly care about. Why do I need this? My response to that would be the Mark Andreessen response is, every company needs IT. It’s now become an integral part of everything, so if you’re going to have IT at all, you’re probably going to have something like this.
Coté:
What are analogs of other processes or best practices that become enshrined as, you should do things that way? The situation is, that’s fine for Merlin problem. That’s great for all those unicorns or whatever, but we can’t do that, so it doesn’t apply to use. Yet there are other practices, like you probably shouldn’t have free beer at your company. That’s just not a sound policy.
There are accepted things that are unquestioned that are process and culture-wise. How do those things become so?
Ed Goodwin:
That’s the difficult part. Sometimes they become so just because of inertia. Sometimes, as we like to laugh about, the management consultants in the ivory tower coin a phrase and put together a PowerPoint presentation, and they take over the world. On the manufacturing side, you have the Six Sigma, the GE Six Sigma stuff. Lean manufacturing, and the Toyota just-in-time systems and stuff.
Coté:
Oh, yeah. Those are good analogs.
Ed Goodwin:
Yeah. Those are cases where what you point to is the increase in the operating margin of the company. We were operating at a 15% operating margin, and now we’re at an 18% operating margin. It’s because we’ve taken out all this waste. DevOps, I think, would be the same kind of thing which is over time 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, it will have gone down dramatically.
Once again, you still have to have a good strategy. In other words, my favorite idiot example is I can have a business where I sell $10 bills for $5. I will generate so many sales it will make your head spin.
Coté:
Right.
Ed Goodwin:
At the end of the day, it’s a stupid business model. 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. You want to balance that, but I think at the end of the day, DevOps is about the operational metrics. It’s not about a return of investment off of a conference, or a return on investment of a software license.
Coté:
In an intellectual gun-to-head situation, where you have to decide between two things, do you think generally it’s best to focus on reducing costs, eliminating waste, to put it another way? Is that always win, if you position things that way?
Ed Goodwin:
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, that’s probably the wrong thing to say, a good chunk of CEOs came through sales. They’re customer facing, and their strategies are always customer facing. The things they worry about are customer facing.
Most CFOs tend to be more operational. They tend to be more cost focused just because, once again, corporate inertia and historical context of what the CFO role has morphed to be over time more strategic than it has been in the past. In the past, it very much used to be an accounting function. What are our numbers? How do they roll?
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.
Coté:
Which is to say your stereotypical, your archetype of the CEO there, they’ll be focused on growth?
Ed Goodwin:
Yes.
Coté:
They want to get more and more new sales and new money.
Ed Goodwin:
Right.
Coté:
Whereas the CFO is focused on what we’d call the bottom line, that is reducing the costs of things.
Ed Goodwin:
Right. I would say from a pitch standpoint, you’re trying to get buy-in, the focus for DevOps for pitching to the CFO would be time to delivery, time to market. Then for the CFO, it would be essentially cost per release cycle.
Coté:
Right, just like a lead pitch. What we’re doing, there’s a lot of waste in the system, and we’re removing that waste. That waste might be operational. It might be literal licenses or costs that we have, but somewhat in this archetypical CFO example, they understand the value of removing waste and tend to value that.
Ed Goodwin:
Yeah. The other thing I would say to that is at the end of the day, most companies have a corporate budget. At the beginning of the year, beginning of the quarter, beginning of the month or whatever, you say, I’m going to spend X amount of dollars. If I’m in charge of the ops budget, and to where I want to spend my dollars and everything, what I would focus on is I’ve got the option to spend it on this thing, or this thing. This thing is more optimal because it will lower my release time. It will do this. It will do that.
The thing that people don’t pay enough attention to, I think, is the actual validation of the fact that it’s working or not. As I like to say, 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 DevOps. I need people with coding experience now. I used to only just need sys admins.
That’s all well and good, but you’ve also got a team of sys admins over here, and if you’re telling me that these guys are coming in, and they’re going to make this whole thing leaner, than why am I not seeing any of these guys leaving to some other position? Or moving to some other department? Or moving to some other company? I know that’s kind of a scary thing to address sometimes, but the reality is you don’t just get to add costs and not take costs out somewhere.
Coté:
Right. That’s another issue in the circles that I run in, as you say. The split between the new way of doing stuff and the old way of doing stuff, and whatever team or whatever person is sitting on top of both of those silos of excitement. Like there are finite resources of time, money, and priorities, and all their usual corporate planning stuff. 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. Which is a totally different thing than ROI.
It’s that strategic question of like how much should I be spending on the new way of doing stuff, but maintaining the old way of doing things, or what?
Ed Goodwin:
You want to know beyond the ROI question because I think the core launching point of this conversation was, how do I make my finance people happy? I can tell you from my experience how you make most of the finance people I run with happy. You tell them what’s going to happen before it happens. If you do that well, you’re probably okay. If you do that poorly, you’re not okay.
What I mean by that is, okay, I’m going to spend this pocket of money of DevOps stuff. I’m retooling my team to be more DevOps oriented. I’m going to run an incremental higher amount of expenses over, we’ll call it, the next three or four months while we do this transformation. 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.
We had a team of five people that were running this. You will see over the next year that run down to three people. We had this much we were paying in licensing expenses. We’re going to pay some percentage of that less, starting in six months because we will have rolled off the old system onto the new system.
If you’re off, let’s say you said this was 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.” Here’s why I’m not concerned about it.
Or you come in at month three, and you say, “Hey, I thought this was going to happen in months six. It’s not happening at all. We need to kill this thing. We need to stop it, and we need to stop the bleeding.” This whole thing was a mistake, and here’s what we learned, and here’s how we’re going to fix it. 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.” Then six months later, it’s like, “Where’s my savings?” We’re still doing DevOps!
Coté:
It’s going to be awesome!
Ed Goodwin:
Right. Once again, the world is fuzzy, and the world is messy, and things don’t work out the way you planned 100% of the time. I think everyone realizes that. If you’re honest with yourself, and then you turn around and be honest with everybody else, 9 times out of 10, that’s going to take you where you need to go.
Coté:
Yeah. I don’t know if it’s ironic, but it’s delightfully ironic that the origin of doing Agile or lean or DevOps are often like the future is very unpredictable, so we need to have small batches to study and triangulate and get more information. Typically, you think of the finance people as not that, but in fact, at least in the happy version of the world, the finance people are just like, “I just want to make sure you’re being responsible, and we’re talking.” Right?
Ed Goodwin:
Right.
Coté:
There’s not crazy stuff happening that we hear about way too late.
Ed Goodwin:
Exactly.
Coté:
Then we course correct, and we get a chance to like work on stuff, which matches well with the original intentions.
Ed Goodwin:
Yeah. I worked on a project a while back that was a six-month project that we were doing implementation of stuff or whatever, and we had some consultants coming in. We were tracking well ahead of budget all along the way. Let’s just say it was month three, and I came in, and I sat down who was in charge of spending the money. I said, “Look, we have been tracking ahead of schedule, and ahead of budget, all the way along here. I’m going to tell you. This month, you’re going to see us racking up a bunch of hours, and we’re going to start slipping above of budget expenditures on this deal. We’re going to look like we’re not making progress. We are at a point in time on this project where at the implementation that it’s reaching this inflection point. After we get through the next three weeks, all we’re going to be doing is validation. What’s you’re going to see is the consultant hours are going to drop way off because I don’t need them anymore. It’s just going to be us cranking on making sure all the data’s coming through correctly.
You’re going to look at the project tracking mechanisms we put in place, and you’re going to see that we’re spending a lot more than you think we should be. This is why. I’m just giving you a heads-up. Everything is fine. If it’s not fine, I’ll let you know.
Honestly, we did exactly what I said, and everybody was fine. It’s a function of giving everybody advanced warning. It’s a function of you really trying to really understand what drives the DevOps, it’s not that I was doing DevOps, but would drive that conversion. What would that conversion look like? I would push back on, not that I want to side with finance with everything here, but I would push back on the ops teams that are like, “How do I sell this? How do I do this?”
Part of it might be, I’m just speaking to archetypes here, you might not truly understand what this process should look like. You don’t understand it well enough to simplify it for someone who’s not coming from this world. If that’s the case, you might want to dig a little deeper and say, how do I really and truly make sure I have a handle on this?
Coté:
Yeah. That makes sense. I think that’s a good place to leave off, unless you have something else to throw out there.
Ed Goodwin:
No, I don’t. I’m not sure we answered the original question. How do I calculate ROI?
Coté:
I know, but I thankfully, I started off saying there is no answer because it’s a bad question.
Ed Goodwin:
There you go. We come back around.
Coté:
I think what’s helpful, whenever there’s a situation where there’s, it’ a bad question with no answers, then the proper pedantic thing to do, and that word means the wrong thing nowadays, but the helpful thing to do is to say, here’s how you should think about that. Here’s how to solve the original problem that prompted you to ask this question, and follow down that path.
I think to you point, so if the question is, how do I make my finance people happy? The answer is, you should talk to them.
Ed Goodwin:
Yeah. You should have conversations about what this is really going to mean. 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.
Coté:
Right.
Ed Goodwin:
I was on tab to spend X, and I’m going to spend X plus 1 this year, but I’m going to drop it down to X minus 2 next year, and the year after that, X minus 3. If you deliver on all those thing, you wake up one day, and find out you have a high functioning DevOps system in place, and it’s all hunky-dory, and all your problems are solved.
Coté:
That’s right. If someone was interested in more Ed, where should they go to look that up?
Ed Goodwin:
Oh, jeez. I’m so not a social media person anymore. I have a Twitter account. I have an Instagram account, and post to them once every six months. I guess Twitter is the best place to hit me up. That’s @EGoodwinTX. Yeah, I guess I’ll respond to that. Honestly, the best way to hit me up, I run the Houston R Users Group, and that Meetup site, there’s a huge amount of messaging that goes back and forth prior to the Meetups. I get a lot of R technical questions thrown my way and stuff. That’s actually a good place to do that. I wish I could tell you what the address on that was. Let me see. It’s Meetup.com/HoustonR, and that’s it.
Coté:
HoustonR.
Ed Goodwin:
HoustonR. Without an e.
Coté:
That’s right.
Ed Goodwin:
If anyone wants to come to the Meetups, I’m pretty much at every one, every month. We meet at STARTHouston mostly the first Tuesday every month. We typically have really good topics like machine learning and time series analysis and whatever.
Coté:
Exactly. Making sense of that crazy language. Perfect.
Ed Goodwin:
Yeah. The joy of that is I’m not a developer anymore. I don’t have to answer why it’s programmatically a mess of a language. I just get to have fun with it.
Coté:
Exactly. Great. As always, this has been the Pivotal Conversations podcast. You can check out the show notes. I’ll put some links to the R user group Ed was talking about, and his famous Twitter account. Very high traffic.
Ed Goodwin:
Yeah. I have two followers, and I think you and …
Coté:
That’s right. You can find all that stuff at Pivotal.io/podcast or podcasts, depending on plurality, your position thereof. With that, we’ll see everybody next time. Bye-bye.
About the Author
