DevOps for the Skeptical VP: Building Your Business Case in 30 Minutes

Hey, folks. Let me ask you something. When was the last time you sat in a meeting where your VP or CEO asked, "But what's the ROI on DevO- DevOps? " And someone actually gave them a straight answer? Yeah, that's what I thought.

Of course, here's the bit that nobody really wants to say out loud. Most DevOps pitches fail because they sound like re- religious conversions, not business proposals. We talk about culture transformation and breaking down silos like we're running a corporate, corporate wellness retreat, not trying to convince someone to spend six figures they don't really have to on something that they don't fully understand. And when you're a company of 100 or 200 people, every dollar matters. Every hour counts.

You can't afford to get this wrong. So today, we're fixing that. Welcome to Engineering Evolved, where business meets innovation and technology drives transformation. Each episode, your host, Tom Barber, explores the challenges and opportunities facing the organizations in the middle, the forgotten ground, where startup rules no longer apply and enterprise playbooks are far too large. From scaling systems and leading teams to aligning engineering with business goals, this is where practical insight meets real-world experience.

Engineering Evolved, guiding today's leaders through the evolution of engineering. This is Engineering Evolved, where we talk about building better engineering teams in small to midsize companies, the real way, not the enterprise consultant way. My name is Tom Barber, your host, and this is episode eight, which is DevOps for the Skeptical VP. Today, we're gonna try and build something you can actually use, not just theory and fluff, but a real business case that will get your DevOps initiative funded even when you have... When you're working with a tight budget and a small team.

And we're gonna try and do this in 30 minutes. So here's what you're walking away with today. ROI calculations that will work for companies with 10 engineers or 100. Risk mitigation arguments that make sense when every engineer wears multiple hats. MVP design principles that let you fail fast and prove value without betting the company.

And objection handling for every "But what about" question you're gonna get. So before we dive in, let me tell you who this episode is for. Are you an engineering manager at a company with 15 developers trying to convince leadership that manual deployments are killing your velocity? This might be for you. Are you a CTO at a 200-person company who knows DevOps works, but you're stuck explaining to a CTO-- CEO who came from sales and doesn't understand why we can't just hire more developers?

This is definitely for you. And if you're that skeptical VP or CEO, yes, I know you're listening. Stick around because I'm going to show you exactly what questions you should be asking and what answers should make you write the check. So let's get into it. First, let's talk about why most DevOps business cases crash and burn before they even ready reach the executive suite.

So mistake number one is the technology-first pitch. Talked about this in a previous episode as well. You walk into the room and start talking about Kubernetes, CI/CD pipelines, and infrastructure as code. Congratulations. You just lost everybody who makes the budget decisions.

Here's what's happening in their heads. "This sounds expensive and complicated. What problem are we solving again? " 'Cause of course, if you think about it, when was the last time someone got a budget approved by talking about how cool a technology is? Probably never.

Mistake number two is like the vague value proposition. So, "DevOps will make us more agile. We'll accelerate innovation. It's about our digital transformation journey. " I would advise you to stop because these buzz, these are buzzwords, not business outcomes.

Because what does agile mean in dollars? What does accelerated innovation do to our Q4 revenue? If you can't connect your proposal to numbers on a P&L statement, you're not ready to pitch. Mistake number three is the big bang approach. "We need to re-platform everything, retrain everybody, and rebuild our entire deployment infrastructure.

It takes 18 months and $500K. " In a small company, that's terrifying 'cause you know what happens next? Nothing. Because when you only have 30 engineers, you can't afford to pull three of them off product work for six months on a bet that might or may not pay off. And honestly, that VP is right to be scared.

So what does work? And the answer is that, you know, I want you to... And I want you to remember this because of its foundation of everything we're gonna build today. The business case that works is the one that proves value before demanding trust. And that's it.

That's, that's the whole game. You're not asking for permission to transform the company. You're asking for a small bet that can prove out in 90 days. Can you think of a project right now, maybe one that's been stalled for six months, where DevOps principles could cut the deployment time in half? Hold that thought because we're gonna come back to it.

So- Why hire when you can partner? Concept Cloud's leading engineers build your startup's prototype without the overhead. Launch faster. Conceptcloud. com.

Let's try and talk some real numbers, the kind that makes CFOs lean forward in their chairs. Uh, you've got the three-pillar ROI model. Pillar one is cost avoidance, and this is your defensive play. What are you not spending if DevOps works? Let me give you an example that's real for a midsize company.

You've got maybe 20 engineers. How many hours did they spend last quarter manually deploying code, fighting with environments, and fixing broken deployments? Let's be conservative and say it's 100 hours in total. What's the fully loaded cost of engineers? $80 per hour.

That's $8,000 per quarter or $32,000 per year. Now let's add opportunity cost. What could they have built with those 100 hours instead? What features didn't ship because you were fighting deployment fires? Cost avoidance alone won't get you funded.

You know why? Because it sounds like you're trying to do the same thing cheaper. In a small company, leadership is used to things being inefficient. They're used to be scrappy. But here's what they're not used to, leaving money on the table.

Pillar number two is revenue acceleration. And this is where it gets more interesting, and it's where small companies have a huge advantage over big ones if you can move fast. Ask yourself, how many customer requests are sitting in your backlog right now that you can't get to because deployment is too slow and risky? How many times has a customer said, "If I just had feature X, we'd upgrade our plan"? Real example from 150-person SaaS company I talked to is they had a Fortune 500 prospect ready to sign a 200 grand annual contract, which was gonna be their biggest deal ever, but the prospect needed one specific integration.

The company's deployment process was so broken that it would take four months to ship. And so the prospect went with a competitor who could deliver in six weeks. 200 grand lost because they couldn't ship fast enough. And in smaller companies, every deal matters. Every feature can be a game changer.

If you can cut your time to market from months to weeks or weeks to days, what does that do to your sales velocity? Of course, that's not theoretical. That's real money where it's just walking out the door whilst you're stuck in deployment hell. Pillar number three is risk reduction, and now we're talking about the stuff that can literally kill a small company. How many production incidents did you have last quarter?

In one small company, one bad incident can cost you your biggest customer. One day of downtime can trend on Twitter and destroy your reputation before you can even write the postmortem. So let's put some numbers on this. Say you're a B2B SaaS company doing 3 million in ARR. One P1 incident that takes down your service for six hours during business hours, what's that cost?

Lost revenue from customers who can't use your product. Let's call it $1,500. Engineering time to fix $20, uh, 20 hours at $80 an hour, so $1,600. Support time dealing with angry customers, 10 hours, 500 bucks. The customer who churns because they've lost trust in your service, which might be, I don't know, a $15,000 annual contract value.

So one incident can cost you, like, $18,000, and that's, that's a conservative estimate. Now, how many of those incidents could have been presented-- prevented with automated testing, proper staging environments, and the ability to roll back bad deployments in 30 seconds instead of scrambling for two hours? So here's a question for you. What would happen if your main competitor had a production outage tomorrow and you didn't? In a small market, reputation is everything.

That one incident might be the difference between winning and losing your next three deals. Let's talk about MVPs, the minimum viable products, and we're not building a product, we're building proof. Here's what you're proposing. Give me one application, two engineers focused on it and 90 days, and we'll prove the concept, measure the results, and decide if we scale. Not three engineers, not the whole team, just two people, one application and focused effort.

And this is where most pitches get clever and trial-- try to boil the ocean. Don't. Pick the easiest win and demonstrate real business value. So how do you choose that MVP? Try asking yourself these three questions.

What's our most painful deployment process right now? Maybe that-- it's that customer-facing application that requires someone to stay late every Friday for deployments. Maybe it's that API that goes down every time you deploy. Maybe it's that manual process that requires five different people to coordinate, and it still breaks half the time. Whatever it is, just pick something where the pain is visible, measurable, and costing you real money or sleep.

Which engineer or small team is ready to move fast? In a small company, you can't afford dead weight on an experiment, so pick your best engineer who's frustrated with the status quo or your senior engineer who's been begging for better tools. You need someone who can figure things out independently because you don't have the luxury of hand-holding. And then number three is what metric can we move in 90 days that leadership will care about? Not deployment frequency.

That's engineer speak. We can deploy customer fixes in 10 minutes instead of waiting three days, and now you're talking a business language. So before you start, you need agreement on what success looks like. Not vague agreement. Be specific and write it down.

Signed off agreement. So here's a template for you. So success criteria. Try deploy time, customer impacting bugs, time to fix critical bugs, engineering happiness. You can measure all of those.

Investment required. How about engineering time or tools and platforms, training or total amount of investment required? Decision points. 30 days progress check. 60 days preliminary results.

90 days go/no-go decision. And here's the key. You need explicit permission to fail fast. And what does that mean? It means that if at day 30 or day 60 the data shows that this isn't working, then you just stop.

You put those engineers back to product work. You keep on going on because-- You don't keep going on because of the sunk costs. You don't pivot to a different approach that wasn't the original agreement. You stop, you analyze, you learn, and you decide what to do next Think about it from a CEO perspective. You're not asking them to bet the company.

You're not asking to pull half the engineering team off product for six months. You're asking for two people 90 days and 75 grand. If it fails, they go back to what they were doing. If it works, you've just made the entire engineering team two or three times more productive. Most importantly, you're giving them the one, one thing small company leaders love, and that's the ability to make a reversible decision.

At 30 days, they can pull the plug. At 60 days, they can adjust. At 90 days, they have data to make that decision. Can-- So can you see how different this is from, like, "Give me 500 grand and trust me for 18 months"? The same minds that worked on the last Mars rover now work on yours.

Concept to Cloud builds startup MVPs that perform. concepttocloud. com. In the first 30 days... Let me tell you what should happen in those first 30 days.

Week one, infrastructure and tooling setup. Just, it's not even coding. Just get the pipeline built. Week two and three, first automated deployment of the simplest component. Not in production yet.

Just prove the pipeline works. Week four, production deployment with rollback capability. Real traffic, real monitoring, real results. And so by day 30, you should be able to walk into a room and say, "We deployed three times this month with zero incidents. Previously, we deployed once and had two incidents, and so here's the data.

" And that's your 30-day checkpoint, and if you can't say that, you need to figure out why before day 60. All right. So you buil- built your buil- business case, you've got your MVP defined, and you're ready to pitch. Here's now what's gonna happen. You're gonna get objections, and so let's try and handle those.

Objection number one: "We don't have time for this. We're drowning in feature requests already. " And this is the objection you will get in small companies, 'cause I've heard it enough times. And of course, it is true. You are drowning, 'cause everyone's wearing all the hats.

The wrong answer to this objection is, "But DevOps will save time in the long run. " The correct answer if someone says this is, "You're right, which is exactly why we're starting with the most time-consuming deployment. Right now, every time you deploy that customer API, someone loses four hours on a Friday night. In 30 days, that'll be 20 minutes any day of the week. So those four hours come back to the team immediately.

And when we scale this, we're talking about giving back the team 10 to 15 hours per week. That's like hiring another engineering... another engineer without the recruiting cost. " So you see the difference. You're not arguing.

You're agreeing and showing them how this is how you get more time. Objection number two: "This sounds expensive. We're bootstrapped and watching every dollar," which of course is the reality of small companies. Cash is always tight, and every dollar counts. The wrong answer to this is, "Well, transformation always costs money.

" The correct answer would be, "Let's look at what we're spending now. We spent $32,000 in engineering hours on manual deployments last year. We lost a $200,000 deal because we couldn't deliver fast enough. We had three production in- incidents that cost us a total of 50 grand in lost time and churned customer. Our proposal costs $75,000 to potentially eliminate all three of those problems, and we can stop in 30 days if it's not working.

What's the expensive option? " So you make the status quo expensive because that's when you actually-- because when you actually calculate it, it is expensive. You just haven't actually been tracking it. Objection number three is like, "What about in security? " And the wrong answer is, "Well, DevOps is secure.

" The correct answer would be something along the lines of, "Great question. In fact, automated deployments with infrastructure as code give us better security than manual processes. Every change is logged, version controlled, and can be audited. We can roll back in seconds instead of hours. Security isn't an obstacle.

It's an advantage. " And I could go on. There are a whole list of different objections, but it's about coming back and having the right play that makes it feel, makes the senior leadership feel empowered and like they're gonna save money and stress and sort their things out in the long run. So here's a question. Like, what objection are you most worried about hearing?

Take a second to think about it. Now, what's the data-driven answer you could give? If you can't think of one, and that's your homework before you pitch. So moving on, I would like to talk about metrics because here's the thing, you can't manage what you don't measure, and you definitely can't prove ROI without numbers. So there's four key metrics, which are the DORA metrics.

DORA the explorer. And if you've been in DevOps conversations, you've probably heard of the DORA metrics. Four simple measures that tell you everything about your delivery performance. Deployment frequency. How often are you pushing code to production?

If you're an elite team, multiple times a day. Good teams, once a day to once a week. Average teams, once a week to once a month. Low performance, less than once a month. Where are you now?

Where do you wanna be? That's your North Star. Lead time changes. From time from code commit to code running in production. If it's elite, it's less than one hour.

If it's good, one day to one week. If it's average, one week to one month. If it's low, it's more than one month. If your lead time is measured in weeks or months, you're hemorrhaging opportunity cost. Change failure rate.

What percentage of deployments cause a failure? If it's elite, maybe it's naught to 15%. If it's good, it's sixteen to thirty percent. If it's average or low, it's thirty-one to forty-five percent or higher. Every failed deployment is a learning opportunity because you're failing more than you're succeeding.

Something's fundamentally broken. Mean time to recovery. When something breaks, how fast can you fix it? If you're elite, less than one hour. If it's good, it's probably less than a day.

If it's average or low, it's probably more than a day. And that's your risk mitigation metric. The faster you can recover, the less damage you take. So start measuring today. Before you even start your DevOps initiative, measure these four things.

Get your baseline because in ninety days you're gonna measure again, and the difference is your proof. And here's the lovely part of all of this, is you don't need fancy tools to start. A spreadsheet works. Just literally chuck it in an Excel spreadsheet. Track every deployment, note the time, note if it failed, note how long it took to fix, and that's it.

If you can commit to doing that for the next ninety days, you'll have the ammunition you need to scale this across your entire organization. So let's say you pitch this and you get approval. What happens after you get approval? Because this is where a lot of initiatives stumble. You got approval.

You've got ninety days. So now what? And here's the most important thing. You need to build the checkpoints where you're allowed, expected even, to kill the project if it's not working. Thirty-day checkpoint.

This is your reality check. Are you on track? 'Cause be honest, if you're not, this is where you make the call. Do we adjust or do we stop? The worst thing you can do is hide the problems at thirty days and hope they fix themselves by day sixty because they often won't.

Day sixty, you should have preliminary results now. Not final results, but, you know, directional indicators. Is deployment frequency improving? Is change rate going down? If the answer is no and you can't explain why, this is your second exit ramp and you need to use it.

Ninety-day decision. This is it. It's a go or no-go decision to either scale or stop. And of course, this is critical because the decision should be obvious from the data. If the metrics improved, scale it.

If they didn't, stop and figure out why before you try again. So success should look like deployment times dropped from four hours to twenty minutes, zero deployment-related incidents, customer-facing bugs cut in half. Those two engineers are happier and more productive. Oh, and you shipped extra, three extra features because they weren't fighting deployment fires. And you say, "Well, we proved it works with one application, so here's the plan to scale to three more applications over next quarter.

" Same two engineers leading it, training others as they go. Same metrics, same checkpoints, same disciplined approach, but now we know how it works. That's how you turn a pilot into a program in a small company. You don't hire a DevOps team. You make your existing team more effective.

Yeah, yeah, just finishing off and then we're done. All right, we've covered a lot today, so let's wrap this one up. You now have everything you need to build a business case that will get funded, even in a small company with li- limited budget. The ROI framework, cost avoidance, revenue acceleration, risk reduction with numbers that matter for midni- mid-sized companies. The MVP approach, ninety days, two engineers, one application, clear success criteria.

Objection handling for every question you'll face, including, "Aren't we too small for this? " And the metrics that prove value without requiring enterprise-grade infrastructure. But here's what I want you to remember most. You're not asking for permission to transform the company. You're asking for permission to prove value with a small reversible bet.

And so there's a huge difference. So here's some more homework for you. Pick one application. Pick your best two engineers who are frustrated with the status quo. Write down your current state metrics, even if it's just Friday night deployments take four hours and we all hate them.

And then define what your ninety-day success criteria in business terms, not tech terms. And schedule thirty minutes with your CEO or VP next week. Don't overthink it. Don't make it perfect. Just make it real because the cost of doing nothing isn't zero.

It's compounding every single day. And hey, if you do it and it works, send me a message. I'd love to hear about it. If it doesn't work, send me a message too and we can figure out what went wrong together. Until next time, this is Engineering Evolved.

Stop talking about DevOps transformation and start proving it works two engineers at a time. Bye for now. Thanks for listening to Engineering Evolved with Tom Barber, where ideas meet innovation and leadership drives change. If you enjoyed today's episode, please leave a rating and review wherever you listen. It helps more leaders discover the show and keeps the evolution moving forward.

From idea to investor demo in weeks, not months. Concept to Cloud, world-class engineers accelerating startup success. Concept2Cloud. com.