Article originally posted on InfoQ. Visit InfoQ

For the last two decades, I have built Internal Developer Platforms (IDPs) at companies like Apple, IBM, and Atlassian. One recurring question I see from practitioners in the platform engineering community is how to make a case for building an IDP for management. How can you create the urgency to build an IDP now and not in the next two quarters or two years? Here are some approaches I wish I had known about when starting my career.

First, you need to understand what your top management cares about. What are their current priorities? What is top of mind?  Here are a few options to ask and think about:

• They want to drive digital transformation across the engineering organization, modernize the stack and roll out the shiny new tech they read about on “cio.com”.
• They want to build new, faster revenue streams to create business value.
• They are concerned about mitigating security risks that damage the company’s reputation.
• They are optimizing for operational efficiency, managing spending, or even cutting costs, e.g., cloud costs.
• They are working to retain and attract the best talent in the market. 

Whatever the main focus is, make sure you understand it and align your platform initiative to management priorities. Build a business case that reflects the cost of waiting to build an IDP, but do it the smart way. As Galo Navarro explained, “We need this platform engineering initiative now; otherwise, we are doomed,” this is not a great approach when reaching out to management. They hear doomsday stories at least 20 times a day. Here are some arguments that will be effective with management:

Accelerate digital transformation

Imagine a large-scale enterprise tries to move to a cloud-native setup, but the transition is unsuccessful because they still need to have legacy systems to support it. For example, Kubernetes adoption works well for small teams starting new projects, but things become incredibly complex at scale. Despite organizations’ expectations, Kubernetes is not the solution to all engineering challenges. 

Some organizations underestimate the additional cognitive load Kubernetes adoption puts on developers, which leads to lower developer productivity. Some even think Kubernetes is a platform, but as Manuel Pais pointed out, it is only the foundation. In a case like this, you could argue: “We should build an IDP to provide abstraction layers on top of Kubernetes and will mitigate the risk of our digital transformation failing.”

Build new and faster revenue streams

Many engineers don’t think about business metrics, but they’re important to incorporate into your argument for your IDP. One of the most important metrics is Time to Market (TTM), which defines the time between developing a new product or feature, entering the market, and generating revenue. The longer your TTM, the greater your investment in each new product and feature requires. 

If shortening TTM is one of your top management’s goals, you could create a case that defines this: “Building an IDP could shorten our TTM by up to 40% by increasing developer productivity. With an IDP, developers can self-serve all the tech and tools they need, reducing time wasted waiting on Ops. IDPs also make it easier to make architectural changes on applications, which you need for rapid iterations. The result is a boost in productivity for developers and operations, enabling us to react faster to a competitive landscape.”

Mitigate security risks

Security and data breaches like those that recently impacted Uber and Slack have increased management’s awareness of security issues. While engineers focus on technical problems that cause risk, management will be more concerned with the damage to brand reputation and loss of market share that results from breaches. If security risks are a top priority for management, you could build a case like this: “An IDP will help us mitigate security risks and their consequences. A well-designed IDP enforces security best practices by driving standardization and detects security vulnerabilities automatically if security tools are integrated smartly.”

Optimize for operational efficiency

Almost every developer tool aims to optimize for operational efficiency, so if this is the case you want to make; you need to add some meat to the bone. If your management is worried about unnecessary outages or downtime due to manual, half-scripted workflows, your IDP story should highlight increased reliability as a result of building a platform. Developers want fewer outages because it means fewer late-night calls and interruptions. The business wants fewer outages because it translates to better customer retention, and high availability is a strong selling point.

If high cloud costs are an issue, you could argue that an IDP makes it easier to manage your setup more efficiently. Small changes, like the ability to detect and pause unused environments, can bring down costs. Large enterprises might also benefit from cloud vendor-neutral platforms, enabling them to easily switch between different cloud vendors. In general, identify the most significant inefficiencies in your organization – developer workflows, key person dependencies, ops bottlenecks, etc. – and tailor your argument accordingly.

Attract and retain top talent

IDPs also help engineering organizations attract and retain top talent by improving the developer experience. High cognitive load causes DevOps burnout and high turnover. According to the recent Gartner report “A Software Engineering Leader’s Guide to Improving Developer Experience” (behind paywall), investing heavily in better developer experience is the best way to safeguard developers’ creative work and the key to their productivity. This results in happier engineers and helps your organization innovate faster.

Calculate an ROI for your Internal Developer Platform

If you ask for bigger budgets for building your IDP, you’ll need to come up with an ROI calculation. In my experience, organizations that don’t have an IDP need one FTE (full-time equivalent) in charge of operations per every 5-7 person development team. Think about how quickly this compounds across organizations with dozens (or hundreds) of teams.

Platform metrics

In addition to coming up with an ROI calculation, you should also consider the metrics you expect to improve once the platform is built. I recommend onboarding one lighthouse team first. Then benchmark some of their metrics against other teams that haven’t been onboarded to the platform. This will give you a good sense of how the new IDP fits the developers’ needs and to be able to measure productivity gains.

The first metrics that will come to your mind will be the classic DORA metrics like lead time, deployment frequency, change failure rate, and MTTR. You will also want a dashboard on top of your platform where you can observe these metrics constantly. Though it can be more difficult, you should track time freed up for ops or reduced developer waiting times.

The platform should also meet specific metrics like SLOs (service level objectives) based on SLAs (service level agreements). As Chris Ford and Cristóbal García García pointed out, your platform needs to be a reliable product. Otherwise, developers won’t trust it, push back, and find ways not to use it or work around it. For this reason, the platform team should agree on ambitious SLOs before building the IDP and always keep reliability as a top priority.

Once the platform is rolled out across the entire engineering organization, consider platform adoption metrics. These will tell you if the product (the platform) fits the needs and if you are on the right track regarding onboarding, training, and evangelizing the platform to developers the right way. Key metrics would be the following:

• Market share or the percentage of developers using your platform. If your IDP is optional, there will always be alternatives. For example, developers can access the underlying technologies directly and ignore the IDP.
• Net Promoter Score (NPS) or the extent to which users recommend the platform to their peers.
• Onboarding time for new developers. An IDP should accelerate the onboarding of new developers because they no longer need to learn the underlying technology. If your onboarding time does not go down; there is something wrong. Either your IDP is crap, or your new developers aren’t using it. 

In the end, you will need to tie these metrics back to the storyline you initially drafted for your top management (faster TTM, more innovation, operational efficiency, and retaining talent). In addition to defining and tracking quantitative metrics, you should always continue doing qualitative research. Constantly run interviews with your customers and the developers. Michael Galloway shared some great examples here.

Building an IDP means investing in creativity and innovation

Investing in creativity and innovation has never been more urgent than now. Your management is aware of the potential financial crisis coming next year. Companies that invest in shorter innovation cycles and faster TTM will always meet customer demands and have an edge over the competition. It’s up to you to demonstrate how an IDP will get your organization there: by reducing cognitive load on developers, enabling them to self-serve what they need to run their apps and services, driving standardization by design, and improving the developer experience.

This piece will help you emphasize the urgency of building an IDP to your management. If your management says “yes” and approves your budget (I’m keeping my fingers crossed for you on both counts), the journey doesn’t end there. Be careful to mitigate the most common fallacies in platform engineering, and start by building the house, not the front door. To put it in plain words: think about the architectural design of your Internal Developer Platform before you start building, and always remember to prioritize your Developer Experience for your Developer Community.