← Back to principles
Platform
Enable Self Service and Independent Use
Statement
Enable Self Service and Independent Use
What this means in practice
Platform capabilities are provided so teams can provision, deploy, configure, and use them end to end without waiting for or relying on the platform team. Self-service interfaces, clear documentation, and sensible defaults empower teams to move independently whilst remaining within guardrails that ensure safety and compliance.
Why this matters
Self-service reduces dependency on the platform team and eliminates bottlenecks that slow delivery. When teams must raise tickets or wait for platform engineers to perform routine tasks, flow is disrupted, the platform team becomes a constraint, and both sides are frustrated. Independent use scales platform value across the organisation without scaling the platform team linearly.
Practices that meet this principle
Teams can provision infrastructure, environments, and platform services through self-service tooling
Documentation and onboarding guides enable teams to adopt platform capabilities without direct support
Guardrails and policy-as-code enforce compliance without requiring manual review for standard requests
Platform APIs and interfaces are well-documented, versioned, and stable
Feedback loops exist so teams can report issues and request improvements to self-service capabilities
Validation
A project meets this principle when:
Teams can provision and configure platform services without raising tickets or waiting for the platform team
Self-service tooling is documented and accessible to all delivery teams
OR:
The platform team is not a bottleneck for routine provisioning or configuration tasks
Scoring Guide
Score −1 — Disagreement / Rejected: The team acknowledges this principle is applicable but has explicitly decided not to follow it for this product. A rationale and decision record exist explaining why enabling self-service and independent use is not adopted.
Score 0 — Not doing: Teams cannot provision or configure platform services independently. All requests go through tickets or direct platform team involvement. No self-service tooling or documentation exists.
Score 1 — Planned: The team has committed work to enable self-service and independent use. An owner and target date exist for introducing self-service tooling, documentation, and guardrails. The plan is tracked.
Score 2 — Adopted for new work: Self-service tooling is available and documented for all new platform capabilities. Teams can provision, deploy, and configure new services end to end without platform team involvement. Guardrails and policy-as-code enforce compliance for standard requests without manual review. Any exceptions are explicit and reviewed.
Score 3 — Enforced for new work + migration plan: Self-service and independent use are systematically enforced for all new work through process or tooling (e.g. automated provisioning, policy-as-code gates). A tracked migration plan exists to extend self-service capabilities to legacy platform services.
Score 4 — Fully adhered: Self-service is comprehensive across all platform capabilities including legacy. Documentation and onboarding guides enable adoption without direct support. Platform APIs are well-documented, versioned, and stable. Feedback loops are in place for teams to report issues and request improvements. The platform team is never a bottleneck for routine tasks. Remaining gaps are minimal, known, and time-bound.