In my last article, I wrote about some of my experiences in developing and presenting a compelling Return on Investment. I’ve had many people reach out to share their own stories. A common problem is that leadership agree with the principles of implementing an Internal Developer Platform (IDP), but claim there is not budget allocation to make it happen. In this article then, I’ll give you five ways of demonstrating cost-savings related to IDPs to open access to budgets that you perhaps haven’t thought of.
OPEX is the Devil
Most organisations strive to minimise their operational expenditure (OPEX) - the things they need to pay for every month - ranging from staffing costs, facilities, software licenses, and much more. You finance team will generally have “one-off” CAPEX funding available for any project that can demonstrate a year-on-year reduction in OPEX.
You can target this funding by demonstrating that you are able to reduce public cloud expenditure, or extend the lifespan of your private data centres. Running data centres (either bought or rented) is an expensive business, and even a 5-10% reduction can yield some significant savings.
In both scenarios, you will want to gather evidence that when developers use your platform, they are more efficient in their use of compute and storage. This can typically be demonstrated by less duplication of commonly required tools, right-sizing of virtual machines or containers, and greater efficiency through economies of scale.
It’s Good To Be Green
Let me guess, your platform has been incredibly successful, but some of the hardware you started out on is now getting a bit old and should ideally be replaced. Unfortunately, new servers don’t come cheap and reductions in the departmental “tech debt” budget means that you’re being asked to “sweat your assets” - even if that means you’re running an increased risk of failure, falling out of vendor support, or missing out on new capabilities and features.
Getting tech debt money to buy new servers is hard work, but there’s a better way.
I’m so happy to see more companies take their environmental impact more seriously and invest in ways to make their organisations more sustainable and deliver value to the community. According to the CBI, two-thirds of investors take these Environmental, Social and Governance (ESG) factors into account when investing in a company.
As a result, most organisations now have a dedicated ESG function, responsible for measuring a business's impact on society, the environment, and showing how transparent and accountable it is. They will have an annual budget to fund initiatives that can help the business be more sustainable.
Data centres represent somewhat of a problem for ESG departments, as it takes a lot of electricity to power a warehouse full of servers, as well as the energy required to keep them cool. Thanks to Moore’s Law, we find that modern hardware often provides much more “bang for buck”, or more precisely, compute cycles per watt of energy.
When building a story around replacing servers, focus the conversation on the overall reduction in CO2. I’ve found it can be incredibly powerful if you can represent the figure in terms that someone can visualise - e.g. flights around the world, bath tubs of hot water, etc. Sure, new servers cost a lot of money, but they can drastically improve the energy footprint of an organising - helping the environment, reducing OPEX in power/cooling, and extending the lifespan of the data centre.
One final tip, if you’re worried about what to do with your old hardware, most large vendors have really great recycling programs where unwanted hardware is recycled or donated to charity organisations.
Time is Money
When you are running an Internal Developer Platform, it is vital that you understand the needs of your users. One big mistake I often see though is that product managers will only talk about features and functions, rather than the bigger picture of what the users’ application does and where it fits into the business.
Understanding the types of applications running on your platform can be incredibly powerful. Not only does it enable you to bring stories to life through real-world examples, it enables you to estimate the likely revenue impact if that application were to be unavailable. That’s useful not only for your engineers to appreciate the importance of their work, but also as a tool when considering funding.
By looking at the revenue flowing through the various applications running on your platform, you can estimate an approximate cost per hour of downtime. Therefore, if you can show that your platform is well positioned to reduce downtime or the time taken to recover from a failure, then it’s trivial to put a dollar amount on that benefit. I’ve successfully used this technique a number of times to demonstrate a sizeable ROI for a common monitoring tool, as well as broader adoption of a golden path / supply chain approach to development.
“Our People Are Our Most Valuable Resource”
All organisations will gleefully tell you that their people are their most valuable resource - and it’s true - but that might not be evident when you look at the assault course most need to crawl through to get even the simplest of IT change made!
Internal Developer Platforms are a great way to improve developer productivity, as well as developer satisfaction. We all come to work each day to be impactful, and as a developer, if it takes weeks or months of toil to get things into production then that’s not going to make you feel very warm inside.
Happy developer write better code, faster. That’s great for everyone:
By giving developers self-service access to testing tools, we can catch problems earlier in the development process, where they are cheaper to fix.
Happy developers are more likely to stay with the company longer, adding to the knowledge pool, helping junior developers, and reducing the significant costs and wasting of time in hiring and training new staff.
Internal Developer Platforms promote sharing of a common toolset, reducing the number of tools in the estate. This reduces potential licensing costs, build/maintenance effort, and the risk of security exploits. Most importantly, it is a key enabler for a flexible workforce that able to shared knowledge, work across different teams, and form a more cohesive and coherent approach to problem solving.
By enabling developers to write quality code faster, we reduce both the cost and lead-time required to deliver projects. The business can deliver more features; it can start generative revenue faster; and it is more able to respond to and take advantage of market changes.
Developers that are able to deliver production features safely are more motivated to be creative and innovative - a vital component of a positive culture.
Never Let a Crisis Go to Waste
Getting money to build new features where the benefits are evident is one thing, but raising funding to improve code quality, performance, scalability, reliability, or security can be a very different challenge.
In highly regulated environments, the mere prospect of a crisis often propels action. The critical factor lies in your ability to articulate the impact of a potential threat in a way that captivates the interest of those holding the purse strings. The more precise you can be about the nature of this risk, the better.
Critically, you should be able to put a monetary value on the impact to the business. The annual Data Breach Report produced by IBM is one of the most useful resources I’ve found, not only to show the risks associated with security vulnerabilities, but also as a framework to think about how activities can be equated to dollars.
In other environments, it’s sadly often easier to secure funding for improvements when it’s too late. It might feel like ambulance chasing, but you should take the opportunity to promote improvement plans off the back of any incidents that your business is facing. It sometimes takes a crisis to get the full, undivided attention of leadership.
“close scrutiny will show that most 'crisis situations' are opportunities to either advance, or stay where you are.” - Maxwell Maltz
When we face production incidents, it’s natural for us to feel a little defensive. When your platform is responsible for a major production incident that is impacting the businesses ability to operate, there’s a broad range of emotions from the shame of making a mistake, confusion as to what went wrong, anxiety from the pressure to fix it quickly, frustration withe complexity of the problem, anger if you perceive unfair criticism, self-doubt as your initial recovery attempts fail, fear of repercussions, and of course, protectiveness of your team and the platform you’ve created together.
That complex array of emotions can make you feel defensive, which is often counter-productive to ensuring you get the support necessary to avoid the same problem happening again - be that funding, prioritisation or additional staff. A seasoned manager will talk less about what caused the problem, and already preparing a statement on what is needed in the future to stop it happening again.
Summary
Whether you like it or not, building a successful platform is about more building some cool technology or having happy users. If you want to continue to develop and grow your platform, you will inevitably need a continuous stream of funding.
In this article, I’ve highlighted just some of the ways you can make the case for investment - but I’d encourage you to think about what works in your business. One of the best things you can do is invite someone in your Finance department to sit down and have a reciprocal learning session: you teach them more about cloud and technology, they teach you about how budgets and finance work.