Self-service lets development teams obtain resources and perform supported operations directly, without waiting for another team to handle each request. In an engineering platform, that means teams can access tools, provision infrastructure, deploy applications, and operate software while security and organizational requirements are handled behind the experience. Self-service does not mean doing all the work yourself; it means the work behind a request is integrated into the product rather than handed back to the developer as a queue of manual steps. section 1.1 section 2.1
Design the service interface first. Give each capability an API, then build portals, command-line tools, or other interfaces on top. Whether a capability is built or purchased, its integrations must support the intended experience: a tool that cannot fit the platform’s authentication and authorization model may require a custom API. A portal alone is not self-service if requests still depend on manual provisioning or coordination. section 1.3.3 section 6.2.2 section 3.1.4
Make the experience work across the whole task, not just at the request screen:
- Let authorized users onboard a team through a single command or web form, and let leads add or remove members without a ticket. Give members the appropriate access from the time they join. section 3.4.1
- Authorize around teams. Keep customer identity separate from cloud infrastructure identity, and propagate team membership to tools that cannot consume it directly. section 4.3.3 section 7.3.1
- Include operations: developers need direct ways to create dashboards, set monitors, trigger alerts, and view results—not only to deploy. section 7.1.2
- Measure whether the capability removes friction. Compare ticket-based delays with orientation time and automation completion time; track onboarding, first production deployment, and adoption. section 3.2.2 section 3.4.1
Deploying a new service
A developer uses an internal developer platform portal to configure and deploy a microservice without involving the operations team. Templates and policies apply standard configurations; automation handles build, testing, and deployment. That portal is one possible self-service interface. An engineering platform has a broader remit, spanning the tools and capabilities needed throughout software delivery and operation. section 10.6.1
Treat each capability as an evolving product feature. Start with a specific delay or dependency, deliver a usable path through it, and check whether developers adopt it and complete the task faster. A self-serve feature that emits no usage data cannot show whether it worked; a platform team left responsible for legacy manual requests may never gain time to improve it. section 1.3.3 section 3.1.4 section 3.2.2
