Making the Case for an Investment in Modernizing Your Legacy Codebase

Navigating the tricky terrain of securing your board’s buy-in starts with landing quick wins and learning to speak their language.

It’s April 1, and you’re approaching the midpoint of a six-hour quarterly review. The vice president of marketing is explaining to the board that with a $100,000 investment in Facebook advertising, she can reduce the cost of customer acquisition from $10 to $9, while the lifetime value remains the same. And this isn’t just an educated guess. The strategy she’s proposing is based on a three-month pilot program her team rolled out at the beginning of Q1. They have no reason to believe it can’t be scaled. They’ve run the numbers. It’s a virtual slam dunk.

The men and women seated around the table look at each other briefly. They know what each other is thinking without saying a word. Value holds steady while costs go down? That’s the kind of simple arithmetic that makes them happy. They nod their approval, and the VP of marketing turns the meeting over to you — so you can ask for $2.5 million to invest in a continuous delivery pipeline that they have neither the vocabulary nor the patience to understand. Oh, and you can’t guarantee it will yield returns in the next six months.

Getting a pit in your stomach just imagining that scenario? Then you’re probably like most CTOs responsible for selling a board on the importance of investing in tools that will improve their development team’s ability to build and ship software. It’s not an easy task, but believe it or not, it is possible to minimize the stress by learning to speak the board’s language and logging quick wins that will help you gain their trust.

Striving for Simplicity

The reasons for our hypothetical marketing pitch’s success were its simplicity and chances of success, two things that typically can’t be conveyed when lobbying for an investment in technology. The argument for an improved continuous delivery pipeline might go something like this:

“If I spend more money on software engineering, our time to release is going to decrease. And if our time to release decreases, our ability to respond to customers’ demands increases. And if our ability to respond customers’ demands increase, we are able to ship features faster than our competition. And if we can do that, we will make more money.”

Which doesn’t exactly make for an easy-to-follow three-slide presentation — especially if it comes in the post-lunch portion of the meeting, when your audience’s eyelids are already bound to be getting heavy.

Then there’s the matter of the likelihood that this investment will actually bear the fruit that you believe it will. You may have a fair amount of confidence in your hypothesis, but that’s all it is to the board: a hypothesis. Testing continuous delivery isn’t the same as testing a new marketing campaign; the cost of proving that something works in technology is equal to the cost of doing it at scale. In other words, the only way to prove that implementing test automation can eliminate 80 percent of what human testers are doing is to go through the process of implementing it.

The classic dilemma faced by any engineering lead who wants to automate goes something like this: You have a weekly one-hour build, for a total of 52 hours of build time in a year. Automating that build will take three weeks, or 120 hours’ worth of time. That means it will take more than two years to see a return on your time investment, which, on its surface is a hard sell. What the average executive may not realize is that there’s much more to it.

It should go without saying, but if you’re only running a build once a week, you do not have an opportunity to ship before that, which means you can not deliver improvements as quickly as those improvement are being completed in the code by the engineering team. In other words, there’s an opportunity cost to not automating that can be easy to overlook.

Compounding the problem is the fact that you’re batching up an entire week’s worth of work into a build and validate stage. Any failure discovered in there could be built on top of a week’s worth of work, which means you may need to undo a week’s worth of work to resolve that failure.

By automating the build and setting it to run with every change, those failures are can be identified and resolved much more quickly. And so, while it may seem counterintuitive to those board members you’re pitching to automate a process that, on paper, may not show a return for years, in reality you’ll be solving a whole host of issues that are harder to quantify. Which is why the average high-performing tech organization doesn’t think twice about automating whenever and wherever they can.

Quick Wins = Investment

As Chris Lynch, a tech leader in the public sector told us recently, in order to build credibility and secure buy-in from a board, sometimes you just have to show that you can do a thing. Not something that requires a $2 million investment, but something you can do with the engineering team already and you progress toward an outcome that allows you to generate a larger investment.

For starters, you’ll likely need a way to differentiate yourself from your peers in the IT department. Too often, boards will lump software development in with IT and assign blame to all parties for a failure that might not have even been yours, making the task of asking for a potentially large investment even more challenging. Weren’t you guys the ones who dropped the ball on the rollout of that expensive new phone system, they may be thinking. And you want us to write you another seven-figure check?

But beyond that, even with some math to help demonstrate the validity of an investment in your continuous delivery pipeline, you’re going to be asking that board to take a leap of faith. You’re presenting a hypothesis that can’t be proven until you embark on the project. You can document how much your team is spending on this perceived problem now, but you can’t say exactly how much you’ll save by implementing your solution.

So those quick wins you’ve been wracking up along the way will make it that much easier to say, “I hypothesize there’s a 50 percent cost savings opportunity here. And what I’m asking you to do is to agree with me that this is a valid thing to be investing in and to give me enough resources to get started and to show progress. And then at the next quarterly meeting, I am going to demonstrate to you how much progress was made, and you can choose whether or not continued investment is important or not.”

You won’t be asking for a blank check. You’ll be asking for a little trust now, with the acceptance that you’ll be held accountable later.

Want to ship software faster to production? With its weeklong Navigator program, sodo will bring technical subject matter experts to you to help you identify your team’s skills and set goals for a software delivery transformation. https://l.shipondayone.com/nav.html