The business case for development platform standardization

Standardizing, automating and maintaining a software development platform is not free. It requires the investment of many work hours by scarce, highly-skilled specialists who could be doing other complex IT work within your organization. For an investment like this, you need a solid business case. In this article, I will try and make that business case. Let’s dive in.?

Platform engineering is not just a technology shift; it’s also a new way of looking at your whole development organization. And, as you have probably experienced at some point, new ways of doing things tend to trigger resistance. Especially if they cost money to implement.?

When building the business case for platform engineering and presenting it to (financial) management, It’s important to focus on how these initiatives cut down on non-value-generating work for dev teams, reduce complexity and increase focus through reduced cognitive load. Quality of life should be the focus when pitching the change to the dev teams. Thus, our business case has hit its first snag: many of the benefits of proper platform engineering can not be captured in easy metrics like hours and euros. Sure, we can measure developer happiness by monitoring turnover (and every organization should do this!), but many factors influence metrics like these.?

However, even measuring time savings from platform standardization can be tricky. They depend, for example, on the team's DevOps maturity level. Teams with a low maturity may gain 20 hours a week from adopting a standard platform, while more mature teams may not gain any initially since they are replacing one efficient implementation with maybe even the same platform capability.?

Counting and multiplying minutes?

That said, I’ve found plenty of hard evidence proving that software platform standardization is worth every penny you invest. At Rabobank, we’ve structured the development platform in ‘building blocks’ that teams can subscribe to. For each building block, we offer to the teams, we determine the time savings. For one building block, we found that the savings per week, per team were 10 minutes. Assuming 47 weeks of development per year gives us 470 minutes or 7.8 person-hours per team. We know how many teams subscribe to this building block, so we can calculate the total person-hours saved per year by multiplying that by 7.8.?

Using this method, we found that, even at this early stage of development of our system, we were returning, on average, 165 person-hours per year to each of our dev teams. With 150+ dev teams in our organization, this multiplies to almost 25.000 person-hours, the equivalent of 13-14 highly skilled devs building user value full-time.?

These are the only hard numbers we have for now, but I am truly convinced that we can soon improve change capacity by 20%, creating a positive business case for any development organization consisting of 20 dev teams or more.?

However, the best part of it is that the gains scale up with the size of your organization. This means that, with almost no increase in investment, you can get that same 20% capacity increase from 200 teams.?

Cognitive load: the business case behind the business case?

I’ve mentioned this in a previous article, but it bears repeating: an efficient development platform frees up development hours and makes those hours more effective. With ops work disappearing from the workday, developers have more focus, less cognitive load and less knowledge to acquire and share. This frees up even more time and, more importantly, head space for them. I know this is impossible to ever capture in a metric, but my gut feeling is that this is the most significant part of the business case.?

Measuring impact in customer value?

So, what does this all mean on a broader scale? As you know, making software developers more effective and efficient is not about cutting costs. There is simply way too much engineering to be done everywhere to even think of cutting development capacity. So, why do we want to free up feature development time, embed lifecycle management more efficiently, reduce cognitive load and improve developer focus? Right: to create more user value.?

Every minute not spent on upgrades or target architecture migrations can be spent on improving the amount and quality of the features we deliver to customers. And that is, ultimately, where software engineering makes us money, so anything we improve in our internal engineering processes should enhance the experience of the people who use our software.?

Again, this is not something easily captured and isolated in a single KPI, but I know this: no dev ever built a killer feature while trying to find a bug in a deploy script.?