The platform team role — the shared capability

The platform team is the middle layer between the infrastructure team and the application team. The platform team consumes the contract the infrastructure team produces and exposes a delivery capability to the application team. The capability is a product with internal customers: the application teams. The platform team publishes paved roads and golden paths, and the application teams choose to use them. The platform team is not a bottleneck for application changes; the platform team is the reason application changes are safe to ship.

The middle layer

The platform team’s position in the operating model is defined by what it consumes and what it produces. It consumes the infrastructure team’s contract and produces a delivery capability the application team uses without having to know the substrate.

flowchart LR
    subgraph INFRA["Infrastructure team"]
        CON["Contract:\nIAM role, subnet, image"]
    end
    subgraph PLAT["Platform team"]
        CI["CI workflows\n(reusable)"]
        TPL["Service templates"]
        GO["GitOps controller"]
        POL["Policies: signed commits,\nvuln gates, drift check"]
        OBS["Observability defaults"]
    end
    subgraph APP["Application teams"]
        S1["Service: api"]
        S2["Service: worker"]
        S3["Service: cron"]
    end
    INFRA -->|"contract v1.x"| PLAT
    PLAT -->|"paved road"| APP
    APP -->|"opens PR"| PLAT
    PLAT -->|"CI signs, deploys"| APP

The platform team’s products are not the application manifests. The platform team’s products are the reusable artefacts the application team consumes: a reusable CI workflow, a service template, a default observability stack, a default policy bundle.

The platform as a product

The platform team treats its output as a product. The product has internal customers (the application teams), a release cadence (the platform repo’s release branches), a versioning scheme (semver), and a deprecation policy (the platform team announces a deprecation window before retiring a version). The product is not a bespoke service the platform team delivers per request; the product is a paved road the application team opts into.

A paved road has three properties:

1. It is the default. A new service in the organisation starts from the platform template. The CI workflow, the manifest shape, the observability labels, and the policy gates are all populated from the template; the application team does not have to invent them.
2. It is opt-out, not opt-in. A team that needs to deviate from the paved road can; the deviation is a pull request against the template, not a request to the platform team.
3. It is maintained. The platform team owns the template’s lifecycle: the bug fixes, the security patches, the version bumps, the deprecations. The application team consumes a maintained product, not a snapshot.

The product framing matters because it changes how the platform team measures success. A bespoke-service platform team measures success by tickets closed. A product platform team measures success by adoption: how many services run on the paved road, how many pull requests per week open against the template, how many deviations are merged.

What the platform team does not do

The platform team’s boundaries are explicit. The platform team does not:

• Write application manifests. The application team owns the manifest; the platform team owns the template the manifest is generated from.
• Approve application changes. The platform team owns the CI workflow that builds, signs, and scans the application; the application team owns the reviewer chain for application logic.
• Run the application’s on-call rotation. The application team owns the service’s availability; the platform team owns the delivery pipeline’s availability.
• Maintain the cloud account. The infrastructure team owns the cloud account; the platform team consumes the contract.

The boundaries are the audit chain. A platform team that crosses them is a platform team that has absorbed either the infrastructure team’s work or the application team’s work; either absorption is a failure mode.

The bottleneck failure mode

The platform team that has not adopted the product framing becomes a bottleneck. The signal is queue length: the platform team’s ticket queue grows; the application team’s time-to-first-deploy grows; the platform team starts to decline work.

The fix is structural: publish the paved road, make the template the default, measure adoption, and route deviations through pull requests against the template instead of tickets against the platform team. The platform team’s job is to make the application team self-sufficient on the paved road, not to be in the critical path of every application change.

Production discipline

1. Publish the paved road. A reusable CI workflow, a service template, a default observability stack, a policy bundle. All versioned.
2. Make the paved road the default. A new service starts from the template; the deviation is a PR.
3. Measure adoption, not tickets. Track how many services run on the paved road and how many deviations are merged.
4. Separate the on-call rotation from the application rotation. The platform rotation owns the pipeline; the application rotation owns the service.

Cross-course references

• This course, Part CVII (ProductionArch) covers the seven components the platform team’s products implement.
• This course, Part CXI (KubernetesPipeline) covers the GitOps controller the platform team operates.
• Linux for Production Sysadmins - Part XXXIV (ConfigMgmt) covers the paved-road pattern at the configuration level.

Quiz