Hi, All Sometimes it can be difficult to convince companies of the importance of “platform engineering”. For a year, our team worked hard to develop Internal Developer Platforms, but from the company’s point of view, “What value is it? What indicators can you prove?” When I hear the question called, I worry a lot. It can be explained in words, but in the end it seems to be expressed in quantitative figures. Has anyone ever had the same problem as me? Any advice would be appreciated. 😞

I've found it helpful to articulate capabilities you're trying to provide. A very nice summary of the most prevalent ones can be found here: https://github.com/adobe-platform/Adobe-Workshop-ArgoCon2022/blob/main/IDP-Capabilities.md Then it's not really about "platform engineering" (which perhaps isn't commonly understood), but about providing capabilities to the organization (which are much more tangible)

Hey Henry, I link here some resources that I think can help you out with that: • https://internaldeveloperplatform.org/why-build-an-internal-developer-platform/#:~:text=Internal%20Developer%20Platforms%20(IDPs)%20have,lower%20costs%20and%20maintenance%20overhead. • https://platformengineering.org/blog/five-reasons-why-an-internal-developer-platform-is-worth-it • https://info.container-solutions.com/the-rise-of-the-internal-developer-platform •

We have a blog post on our journey on improving our Deploy Frequency: https://www.aboutwayfair.com/careers/tech-blog/how-wayfair-tech-increased-deploy-frequency-490-in-2-5-years It still relies on buy-in on the value of the [DORA metrics](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance) described in [Accelerate](https://itrevolution.com/product/accelerate/).

My best advice would be to start small, with a single “customer” that you can work together with to build value. Depending on your org, they may well also be the people with budget to make it happen. Talk lots about your progress and shout about the wins. In my role, I get to work with a broad range of organisations and all too often, an infra engineering team decides to build an IDP without involving any development teams in the design, build or long term roadmap. They then act surprised when devs aren’t interested. The key metrics that you can show have been mentioned already. I favour simplicity: time taken for a new employee to submit their first PR, time taken for an experienced employee to make a trivial change in production, and Net Promotor Score. Developer velocity is great, but a healthy respect between Dev and Ops is the ultimate goal for me.

Those are great choices — simple and easy to measure. Also, I recommend measuring these things before you build a platform, so that you have a solid baseline to compare with later. (Obviously, if you’ve already built something it’s hard to go back in time to show how much worse it was back then. I learned that one the hard way; but fortunately the team remembered the history. In a larger company over a longer stretch of time, you might need more concrete documentation…)

One of the manifesto of platform engineering is product driven. Start with customers, define the customers, and let them tell you what are the quantitative figures. For reference, DORA is one measurement, from overall perspective, there are hundreds of measures, you will need to find what benefits you create for the company.

+1 to @Ron Hough’s point on metrics … and you don’t necessarily need an entire observability platform to achieve those day 1 metrics. I’ve literally written stats down on a whiteboard each month that I’ve then been incredibly thankful for in leadership meetings years later! You might not think it’s too important that you’ve got two apps on your platform using a tiny amount of resources with a tiny team, but in 18 months time as you scale to tens-of-thousands of apps and the team is still comparatively small, you’ll be glad to be able to tell that really compelling story. As a company director once coached me on many years ago, “show your working”. Talk about your progress, your success and overcoming failure. The act of communicating progress is as important as the steps forward you take. You have to show change of state, otherwise people assume nothing is moving forward.

Yeah, this seems like a really simple idea, but it’s easy to overlook taking measurements early on. You think, “Yeah, we did X but it’s just a small step and there’s so much more to do…” so you don’t really document it. But those small steps add up. One day, you’re impressed with how much you’ve improved productivity over the past year or two. You want to ask for some more people to work on your team, and when you’re asked to justify the cost you have to resort to handwaving “well… but stuff is so much better now than it was two years ago!“. Having a spreadsheet with dates and hard numbers showing marked improvement over the previous two years would go a long way toward making your case. You can’t assume the progress will just be obvious. It probably will be to the developers, but may well not be to the execs making the spending decisions.

Thanks for the really insightful answers. 🙂 ! Looking at your answers, I got to thinking and thinking a little more myself. I sometimes say “This is what our platform will need!” First of all, we set the development goal and worked on it. However, over time, the components we develop may not be needed right away in our development culture and environment. The Internal Developer Platform is a wonderful culture and idea, but we shouldn’t be mistaken for working from the start looking at the “completed product”. According to what you said, first of all, we will have to consult with the internal development team that needs small components and them so that we can figure out the needs and quantitative figures even if we work manually sometimes. Nothing saddens an engineer more than a component with few users. 😞