Standard : Internal platforms provide self-service capabilities that enable teams to deliver safely and efficiently
Purpose and Strategic Importance
When delivery teams must raise tickets, wait on other teams, or navigate undocumented processes to provision environments, deploy services, or access shared capabilities, their flow is interrupted and their autonomy is constrained. Internal Developer Platforms (IDPs) solve this by building paved roads — curated, opinionated golden paths that make the right way the easy way. Teams can self-serve what they need, when they need it, without creating dependencies on centralised operations or platform teams. The platform encodes organisational best practices into tooling, so safe and efficient delivery becomes the default rather than something that requires expertise or permission.
Aligned to our "Engineering Excellence First" policy, this standard recognises that platform teams must treat their platform as a product — with a roadmap, user research, versioned APIs, and a commitment to reducing cognitive load for the teams they serve. A great internal platform abstracts complexity without hiding it entirely, offers clear platform contracts, and measures its own success through the delivery performance and satisfaction of the product teams using it. Platforms that are poorly designed or poorly maintained become obstacles rather than accelerators; this standard defines what good looks like at each level of organisational maturity.
Strategic Impact
- Eliminates ticket-driven dependencies that interrupt team flow and delay delivery by hours or days
- Encodes security, compliance, and operational best practices into self-service tooling, making safe delivery the default
- Reduces cognitive load on product teams by abstracting platform complexity behind well-designed interfaces
- Accelerates onboarding of new teams and engineers by providing well-lit paths to productive delivery
Risks of Not Having This Standard
- Delivery teams block on platform or operations teams for environment provisioning, creating systemic delivery bottlenecks
- Each team builds its own bespoke deployment and infrastructure tooling, increasing inconsistency and duplication of effort
- Security and compliance controls are applied inconsistently when teams work around absent or inadequate platform capabilities
- High cognitive load on engineers managing their own infrastructure and tooling reduces focus on customer-facing product work
- Platform knowledge is siloed in specialist teams, creating fragility and slowing the onboarding of new team members
CMMI Maturity Model
Level 1 – Initial
| Category |
Description |
| People & Culture |
Teams rely entirely on central operations teams for infrastructure and deployment needs. |
| Process & Governance |
All platform requests are handled via tickets with no defined SLAs or self-service options. |
| Technology & Tools |
No internal platform exists; each team uses ad hoc scripts and manual processes independently. |
| Measurement & Metrics |
Platform team toil, wait times, and delivery team satisfaction are not measured or visible. |
Level 2 – Managed
| Category |
Description |
| People & Culture |
Platform team begins identifying common patterns and pain points across delivery teams. |
| Process & Governance |
Some shared scripts and templates are documented, but adoption is inconsistent and unofficial. |
| Technology & Tools |
A basic shared tooling catalogue or wiki is created to document common platform capabilities. |
| Measurement & Metrics |
Ticket volume and resolution times are tracked; recurring requests begin to surface platform opportunities. |
Level 3 – Defined
| Category |
Description |
| People & Culture |
A dedicated platform team adopts a product mindset and treats delivery teams as internal customers. |
| Process & Governance |
Golden paths are documented, promoted, and supported with clear platform contracts and versioning. |
| Technology & Tools |
An Internal Developer Platform (IDP) provides self-service environment provisioning and deployment capabilities. |
| Measurement & Metrics |
Platform adoption rates, self-service task completion rates, and delivery team satisfaction are tracked. |
Level 4 – Quantitatively Managed
| Category |
Description |
| People & Culture |
Delivery teams actively contribute improvements to the platform via well-defined contribution models. |
| Process & Governance |
Platform capabilities are released iteratively based on user research and measured delivery impact. |
| Technology & Tools |
The IDP integrates with CI/CD, secrets management, observability, and security scanning as a unified experience. |
| Measurement & Metrics |
Cognitive load reduction and DORA metrics improvement are used to quantify platform investment value. |
Level 5 – Optimising
| Category |
Description |
| People & Culture |
Platform engineering is a respected, strategically funded discipline with clear organisational mandate. |
| Process & Governance |
Platform roadmap is driven by continuous feedback loops, delivery telemetry, and emerging capability needs. |
| Technology & Tools |
The platform dynamically adapts to team needs, offering composable building blocks rather than rigid workflows. |
| Measurement & Metrics |
Platform effectiveness is benchmarked externally; the organisation is recognised for developer experience excellence. |
Key Measures
- Self-service task completion rate: percentage of platform tasks completed without raising a ticket or seeking help
- Platform adoption rate: percentage of delivery teams using golden paths for core delivery workflows
- Time to provision a new service or environment via the platform self-service interface
- Cognitive load index: developer survey score measuring perceived complexity of delivery tooling
- Platform-related delivery delays: number of delivery team blockers attributable to missing or broken platform capabilities
- Net Promoter Score (NPS) or equivalent satisfaction score from delivery teams for internal platform tooling