Peter Eniayewu
Request CV
All writing

Platform engineering: building internal developer platforms that pay for themselves

Damilare Peter EniayewuTalk6 min readPlatform engineering, Developer experience, Leadership

My talk at Poolot for product managers, engineers and people operations: what an internal developer platform is, the ROI case leadership will accept, the five planes of a platform that works, how to staff and phase it, and the metrics that prove it.

From my talk at Poolot, a technology and learning platform, on 17 April 2025. The room was product managers, engineers and people operations, so the argument is as much about money and retention as it is about infrastructure. The figures are the rough numbers and targets I used in the talk, not results from one company.

Modern software delivery asks developers to manage cloud infrastructure, CI/CD pipelines, IAM roles, observability, security compliance and secrets, on top of writing business logic. Most companies never put a number on what that costs them. This talk was an attempt to.

The hidden tax on every engineer

Every engineering organization has heard these three sentences: “How do I set up my local environment?”, “Incident at 2 a.m.: who owns this service?” and “We can't ship, staging is broken.” Each one has a price.

  • 2–3 days for each new hire just to get a working environment, and 2–3 weeks on average to a first meaningful pull request when there's no service catalog and no runbook.
  • 40% of engineering time spent on undifferentiated toil, with every team reinventing the same CI/CD pipeline.
  • $120K+ fully loaded cost per senior engineer per year, which is what that toil is really spending.
  • 3–5x the cost of responding to an incident compared with preventing it. Blocked engineers are lost velocity.

An IDP is not a tool. It's a product your engineers use every day.

An internal developer platform abstracts infrastructure complexity so engineers can self-serve what they need, from environments and pipelines to deployments and observability, without a ticket.
  • Self-service infrastructure: developers provision environments, databases and services without ops tickets.
  • Golden paths: paved workflows for build, test, deploy and monitor, so nobody reinvents them.
  • Unified observability: logs, traces, metrics and ownership in one place.
  • A service catalog: living documentation of who owns what, how it runs and where it fails.

Put simply, an IDP is a unified layer of reusable self-service workflows, abstraction layers and golden paths.

Your platform team is a product team, with internal customers

  • From reactive, answering tickets, to proactive, shipping platform features.
  • From infrastructure as a cost center to the platform as a product with a return.
  • From engineers waiting on ops for resources to engineers self-serving in minutes.
  • From no SLA, roadmap or metrics to OKRs, a roadmap and adoption metrics.
  • From knowledge siloed in one team to golden paths that scale it across the organization.

The ROI case leadership will accept

Each audience in the room cares about a different number:

  • Developers care about time. Cutting infrastructure provisioning from three days to ten minutes saves roughly 5–10 hours per engineer per week.
  • Product managers care about time to market and reliability. Shorter deployment cycles, zero-downtime releases and a lower mean time to resolution.
  • People operations care about onboarding and retention. Onboarding can drop from four weeks to two days, and attrition caused by operational friction falls with it.

Then the arithmetic. If a 50-person engineering team saves four hours per developer per week through self-service, that is about 10,000 engineering hours a year. At a fully loaded $80 an hour, that is $800,000 a year of reclaimed capacity, against a platform team that costs roughly $300,000 to $400,000.

The IDP doesn't reduce headcount. It makes the team you already have more effective: same headcount, same salaries, about a quarter more time on product features.

The five planes of a platform that works

From the bottom up:

  • Compute and storage: cloud, Kubernetes or bare metal. This usually exists already.
  • Infrastructure abstraction: Terraform modules, CDK constructs and self-service provisioning.
  • Application configuration: secrets management, feature flags and environment promotion.
  • Workflows and automation: CI/CD pipelines, GitOps, drift detection and policy as code.
  • The developer portal: Backstage or a custom UI for the service catalog, docs and runbooks.

Golden paths: the single most leveraged investment

A golden path is the opinionated, supported way to do a thing. Not the only way; the recommended way the platform team maintains. For a new service it looks like this:

  • Scaffold the service from a CLI or portal template.
  • Config and secrets are injected automatically from Vault.
  • The CI pipeline arrives pre-wired for build and test.
  • One command deploys to staging through a GitOps flow.
  • Dashboards are created automatically, so observability is live from the first deploy.
  • The service is registered in the catalog with its owner set.

The result: a new microservice, fully wired, observable and in the catalog in under 30 minutes, with zero ops tickets.

Staffing it without starting over

Loosely following the Spotify and Thoughtworks models, the platform team grows with the organization:

  • 10–30 engineers: one engineer, part time and embedded. A golden path for CI/CD and a service catalog, nothing more.
  • 30–80 engineers: a dedicated squad of 2–3. The full golden path, self-service infrastructure and a portal.
  • 80–200 engineers: a platform tribe of 4–8, run as a product with a PM and engineering managers across several teams.
  • 200+ engineers: a platform organization of 10–30, with dedicated security, developer experience and SRE.

The first hire matters most: a platform engineer who thinks like a product engineer. Not an ops engineer who optimizes infrastructure, but one who ships developer experience.

You don't build the whole IDP on day one

  • Months 1–3, foundation. One standard CI/CD template, a Terraform or CDK module library, shared secrets management and a basic service catalog; a spreadsheet is fine. Aim for deployment time down 40%.
  • Months 3–6, self-service infrastructure. Environments on demand for feature branches, unified logs and traces, a defined golden path for new services, and a first version of Backstage or a custom portal. Aim for onboarding time down 70%.
  • Months 6–12, platform as a product. Full self-service for databases, queues and storage, policy as code for security guardrails, cost visibility per team and service, a developer NPS above 8 and adoption above 80%. Aim for toil down 60% and incidents down 50%.

Measuring it: DORA, developer experience and the business

  • DORA metrics: deployment frequency, lead time for changes, change failure rate and mean time to restore.
  • Developer experience: a developer NPS of 8 or more, surveyed quarterly; time from a new hire's first day to their first meaningful PR; platform adoption, as the share of teams on the golden path; and the volume of ops tickets coming from engineering teams.
  • What leadership actually cares about: more features per sprint (the target I gave was +35%), lower incident cost (−60%), faster onboarding (−80%) and lower retention risk.

Five ways IDP initiatives fail

  • Building the portal before the platform. Build the infrastructure abstraction first. Without the layers beneath it, a portal is a dashboard to nothing.
  • No product mindset. Treating the platform as an infrastructure project. Assign a PM, or an engineer with PM skills, run user research and prioritize by adoption blockers rather than by what the team finds interesting.
  • Forcing adoption before the experience is good. Golden paths have to be genuinely better, not just mandated. Engineers route around bad tools; win them over first.
  • No dedicated team. Everyone doing it with 20% of their time means 0% commitment. One dedicated engineer outperforms five part-timers.
  • No metrics. Baseline your DORA metrics and developer NPS before you start. You need the “before” to prove the “after”.

What you can do starting next week

  • Product managers: add developer NPS to the quarterly survey, ask your engineering manager how much time went to toil this sprint, champion one platform item on the roadmap, and keep asking whether engineers have a golden path for this.
  • Engineers: document your local environment setup (that's backlog item one), automate one repeated manual step this week, open a PR adding your service to a shared catalog, and volunteer to run a platform day with your team.
  • People operations: add tooling satisfaction to the engineering pulse survey, review the platform engineer job description against product-thinking criteria, identify the internal platform advocates you need to keep, and track time to first PR as an onboarding KPI.

Three things to remember

  • An IDP is a product. Staff it and measure it like one.
  • Start small. One golden path can pay for itself in 90 days.
  • Developer happiness is a business metric, not a perk.
The best developer platforms are invisible. Engineers just ship. That's what paying for itself looks like.

I've led product, engineering and security for regulated payment platforms. If your team is working through the same problems, I'd like to hear about it.

Email meRequest my CV