"We have a process for that."
At Level 2, the organization recognizes that the chaos of Level 1 is unsustainable — usually after a painful incident or a key person leaving — and centralizes control. Think of a franchise restaurant: every location follows the same recipe book, but a manager still has to approve every order before it goes to the kitchen.
Characteristics:
- Process: Defined and documented. There is a standard way to deploy, but it is often manual or ticket-based. The process exists in a Confluence page that is 60% accurate and 40% out of date.
- Standardization: "Golden Paths" exist but are enforced via policy documents, not code. You must use the standard CI/CD pipeline, but you might have to copy-paste the YAML yourself from a shared template repository.
- Experience: "Gatekeeper Ops." The Platform team creates standards, but developers still have to wait for the Platform team to provision resources. This is sometimes called Jira Ops — the primary interface between developers and infrastructure is a ticket queue.
- Observability: Centralized logging and basic alerting exist. On-call rotations are formalized.
- Risk: Medium. Consistency improves significantly, but velocity is slow because of the Central Bottleneck — the Platform team.
What failure looks like at Level 2: The Platform team has a backlog of 200 open tickets. Developers wait two weeks for a new database. They start working around the process — creating shadow infrastructure in personal AWS accounts — which reintroduces Level 1 chaos alongside the Level 2 structure.
The Shadow IT Warning: The most dangerous sign that you're stuck at Level 2 is the emergence of shadow infrastructure. When developers bypass the official process because it's too slow, you lose the standardization benefits you worked to achieve. This is the primary forcing function to move toward self-service.
Goal: Move from Gatekeepers to Self-Service. The Platform team should be building systems, not processing tickets.