The latest articles on DEV Community by Jordan (@itzdaninja). https://dev.to/itzdaninja https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F2186912%2F13413c2d-2d90-4d1d-9afe-d446f2102044.jpg https://dev.to/itzdaninja en Jordan Wed, 06 May 2026 11:08:29 +0000 https://dev.to/itzdaninja/why-most-internal-developer-platforms-fail-and-what-to-do-about-it-pd7 https://dev.to/itzdaninja/why-most-internal-developer-platforms-fail-and-what-to-do-about-it-pd7 <p>I've spent twenty years building and scaling platforms across financial services technology. In that time I've seen internal developer platforms succeed and I've seen them fail. The technical differences between the successes and the failures are smaller than you'd expect.</p> <p>The organisational differences are enormous.</p> <h2> The adoption problem nobody talks about </h2> <p>Most IDP failures share a common characteristic: the platform team <br> treated adoption as inevitable rather than earned.</p> <p>The assumption goes like this, if we build something genuinely better <br> than what exists, developers will naturally migrate to it. This is <br> rarely true. Developers are busy, sceptical of platform initiatives <br> based on past experience, and rational about where they invest their <br> time.</p> <p>The teams that get adoption right treat the platform as a product with a go-to-market problem. They identify a first team, make that team successful, and let word of mouth do the rest.</p> <h2> The metrics that actually matter </h2> <p>The industry has converged on DORA metrics as the standard for <br> measuring engineering performance. They're useful and worth tracking. <br> But they measure outputs, not platform health.</p> <p>A platform can have strong DORA metrics and still be quietly failing.</p> <p>The metrics I've come to care about most:</p> <p><strong>Time to first deployment for a new team.</strong> Not a team that's been <br> on the platform for two years — a new team starting fresh. If this <br> is measured in days rather than hours, the platform has an onboarding <br> problem that deployment frequency won't reveal.</p> <p><strong>Unplanned dependency rate.</strong> How often do developers go outside the <br> platform to get something done? Every workaround is a product signal.</p> <p><strong>Platform team toil ratio.</strong> What percentage of time is reactive <br> versus proactive? If this isn't improving quarter on quarter, the <br> platform is treading water.</p> <p><strong>Developer NPS.</strong> Uncomfortable to measure. Impossible to argue with.</p> <h2> The documentation trap </h2> <p>Platform teams that rely on documentation to drive adoption have <br> already lost.</p> <p>If developers need to read three Confluence pages to understand how <br> to deploy a service on your platform, the platform has a usability <br> problem. The documentation is papering over the gap between what the <br> platform is and what it should be.</p> <p>When I hear a platform team say "we need better documentation," I now <br> ask a different question: what specifically are developers confused <br> about, and why does the platform not make that thing obvious?</p> <p>The answer to that question is a product improvement. Not a new <br> Confluence page.</p> <h2> Where this comes from </h2> <p>These are some of the themes I explore in depth in <br> <a href="https://platformengineeringguide.com" rel="noopener noreferrer">The Comprehensive Guide to Platform Engineering</a> a 550-page practitioner reference I've just published covering the full platform engineering lifecycle, from Kubernetes and GitOps through to IDPs, AI-native infrastructure, and the organisational change required to make any of it stick.</p> <p>Happy to discuss any of this in the comments, I'm particularly interested in what others are seeing around IDP adoption in practice.</p> platformengineering devops kubernetes sre