Do I need platform engineering?

- [Instructor] I've spoken generally about the promise and benefits of platform engineering, but how can you know if it's right for your company? Here's a simple way to answer the question, do you need a developer platform? This may seem like an oversimplification, but at the end of the day, it really does come down to that. You can break it down a little further by digging into the features of a developer platform. Do we need self-service? Is our platform ecosystem complex enough yet to benefit from Golden Paths? These are the right questions to get to the heart of the question, do I need platform engineering? We can also use a few metrics that correlate with the need for platform engineering, the size of your organization, and the complexity of your platform ecosystem. It stands to reason that the larger and more complex your organization, the more likely you will benefit from an IDP and a dedicated platform engineering team. There are no fixed numbers for these metrics, but we can approximate. Any developer organization with 75 to 100 developers or more is likely to benefit from an IDP, even if that organization has a relatively simple platform ecosystem for software delivery. The infrastructure self-service and Golden Path features should improve key delivery metrics. Of course, the larger an organization gets, the more component platforms it's likely to use. Very large organizations that have grown organically over time often have a broad, highly heterogeneous platform ecosystem. This may be the single strongest case for a platform engineering team and IDP. Ecosystem complexity has an outsized impact on delivery metrics and developer burnout. So it's clear that very small organizations with simple ecosystems are on the low end, and large organizations with complex ecosystems are on the high end. What about the middle? In those cases, growth trajectory is a good metric to use. If you're working in a fast growing organization that's adding new component platforms, you should consider planning for a platform engineering team. Keep in mind that org size and platform complexity are indirect indicators of the most important metrics of all, software delivery. Platform engineering is a means to an end, and that end is high delivery velocity with low rates of deployment failure and high production stability and reliability. The goal of platform engineering is to improve the classic DevOps metrics, lead time for changes, change failure rate, and mean time to recovery. So the first question is, are you measuring these metrics? If not, start there. If these metrics are all in an acceptable range, you may not yet need a developer platform. The next question is, are you really measuring these metrics? I don't mean to be cheeky here, I've done many DevOps workshops. One of the common challenges I've seen is that measuring these metrics accurately can be tricky. Measuring change lead time is especially difficult, it's very easy to miss steps when workshopping the process. I've seen teams initially report lead time in hours, then realize through discussion that it's actually days when you add up all the critical path testing and validation steps. Take care to measure honestly and accurately and you'll be in a much better position to make improvements. Automating the measurements of metrics, such as lead time, can be very helpful. Many open source and commercial CI/CD tools offer timestamping features that can be used to correlate changes with deployment times. These data can be used to track changes from a task on a backlog all the way to a production deployment. So ask yourself and your peers honestly, do we need platform engineering? Using these metrics and questions, you can be confident in your answer. If the answer's yes, you'll have the data to support your argument to colleagues and leadership.