The Developer Experience Problem
Developers spend 30-40% of their time on infrastructure: provisioning environments, configuring CI/CD, debugging deployments. Platform engineering centralises this work into an internal platform that provides golden paths for common tasks.
The cognitive load on developers is the hidden cost of microservices. Each service needs a pipeline, monitoring, logging, secrets management, and security scanning. Without a platform, every team reinvents these capabilities. We have seen teams spend two weeks setting up a new service when it should take two hours.
Mindset Shift: The platform engineering team treats the developer as the customer. Their product is the internal developer platform (IDP), and their success metric is developer productivity. Traditional operations teams optimise for stability; platform teams optimise for developer velocity.
Context Matters: Platform engineering is appropriate when developer productivity is a bottleneck; traditional operations is appropriate when stability is the primary concern. We have seen organisations struggle because they applied platform engineering in stability-critical environments, or traditional operations in innovation-critical environments.
What an IDP Provides
- Self-service environments: Developers provision staging, test, and preview environments without tickets. The platform provides templates that create environments with correct networking, security, and monitoring. Developers get a URL in minutes, not days.
- Standardised pipelines: Pre-built CI/CD templates that enforce security scanning, testing, and deployment practices. Teams select from approved templates that include security gates, quality checks, and deployment strategies.
- Observability stack: Pre-configured logging, metrics, and tracing for every deployed service. Services are automatically instrumented when deployed through the platform. Developers get dashboards, alerts, and tracing without any configuration.
- Service catalogues: Discoverability for internal APIs, documentation, and ownership. The Backstage service catalogue (from Spotify) has become the de facto standard, providing a single pane of glass for all internal services.
The Golden Path: The paved road for the most common developer tasks: creating a service, deploying to production, adding monitoring, rotating secrets. Developers can still go off-road when needed, but the golden path provides defaults that are secure, scalable, and consistent. The platform team maintains the golden path; developers consume it.
Environment Provisioning: The highest-impact capability. We have seen deployment times drop from two weeks to two hours. The platform uses Infrastructure as Code (Terraform, Pulumi, or CDK) to define environments as templates. Developers select a template from a portal, specify parameters, and the platform provisions VPC, subnets, security groups, Kubernetes namespace, CI/CD pipeline, monitoring dashboards, and logging. The entire process takes 10-15 minutes.
Building the Platform
Start with a platform team of 3-5 engineers. Identify the top 3 developer pain points. Build self-service solutions for those first. Measure developer satisfaction and time saved. Expand based on demand, not speculation.
Product Management for Platforms: The platform team should have a product manager, not just engineers. The product manager defines the roadmap, prioritises features, and measures outcomes. The team should use the same agile practices as product teams: sprints, retrospectives, user research, and metrics dashboards. The platform is a product; treat it like one.
Recommended Build Order: Start with environment provisioning (highest impact, lowest risk). Then add pipeline templates, observability, and service catalogue. Each addition builds on the previous, creating compounding value.
Organisational Structure: The platform team should be separate from traditional operations but aligned with it. The platform team builds self-service capabilities; operations handles the infrastructure the platform runs on. Both report to the same engineering leadership. We have seen organisations fail when the platform team is buried inside operations and loses the product mindset, or when completely separate and loses infrastructure expertise.
Our Recommendation
Treat the platform as a product. It has users (developers), features, and a roadmap. Gather feedback continuously. The goal is not to build the perfect platform but to solve real problems incrementally.
The internal developer platform is not a destination; it is a capability that evolves with organisational needs. Start small, measure impact, and expand based on developer demand. The organisations that succeed treat platform engineering as a product discipline, not an infrastructure project.
Key Principle: Invest in the platform team. Hire product-minded engineers who understand developer workflows. Measure developer productivity, not infrastructure cost. And remember: the best platform is the one developers choose to use, not the one they are forced to use.
