Five Things a New Platform Team Should Stop Doing in the First Six Months

Forming a platform team is a good decision. The ops team is overwhelmed, every deployment requires coordination, and product engineers are spending time on infrastructure problems instead of product problems. The case for a dedicated platform team is straightforward.

Running it like an ops team with a different name is not a good decision. It is the failure mode that causes platform teams to burn out their best engineers and reproduce the exact bottleneck they were created to solve. The pattern sets in the first six months. These are the five things to stop before they calcify into habits.

1. Running tickets for product teams

If product teams open tickets to get infrastructure resources, environment access, secret provisioning, or deployment approvals, the platform team has reproduced the ops bottleneck with better branding. The ticket queue grows with the engineering organization. The platform team processes tickets. Product teams wait. Nothing fundamental changed.

The platform team's job is to eliminate the ticket, not to respond to it. Every recurring ticket is a product requirement: there is a self-service capability that does not exist yet. A recurring request to provision a new database should become a self-service workflow that takes three minutes. A recurring request for environment access should become an identity-tied provisioning step in the onboarding process.

Stopping the ticket model requires intentional effort because the ticket model is comfortable. Tickets are visible, manageable, and close-able. The self-service investment requires building something instead of responding to something. The platform team has to protect time for the building, or the tickets will fill it.

2. Owning production deployments

The platform team owns the deployment tooling. Product teams run their own deployments. When these ownership lines blur — when the platform team becomes the final step in a product team's deployment process, the approvers or the button-pushers — two things happen that should not happen.

First, the platform team becomes the rate-limiting step for every product team's release process. A platform team of four engineers cannot scale to be the deployment gate for seven product teams without creating a queue. The queue is a bottleneck. The bottleneck is the failure.

Second, product teams do not develop operational maturity. The best signal that a deployment process is poorly designed is a product team that cannot run it without platform involvement. When the platform team absorbs that operational complexity rather than eliminating it, the product teams never learn to own their production systems. The on-call burden stays centralized. Platform engineers cover incidents caused by product team code. Burnout follows.

The platform team makes deployment reliable, observable, and self-service enough that product teams can run it safely. Then product teams run it.

3. Building what's interesting instead of what's needed

Platform engineers find infrastructure problems interesting. This is one of the things that makes them good at the work. It is also a source of misalignment between what the platform team builds and what the product organization needs.

The temptation is to build Kubernetes operators, custom deployment controllers, and internal tooling platforms when the product organization's actual pain is that the local development environment takes three days to set up, or that the test suite is unreliable enough that engineers run it three times before trusting a green result.

The fix is discovery. Talk to the product teams who are your internal customers. Ask them where they lose time. Ask what they have to ask you for that they wish they could do themselves. Ask what they find slow, unreliable, or confusing about the current platform. The answers will mostly not be interesting infrastructure problems. They will be documentation gaps, flaky tests, and undocumented processes. Build those first.

The interesting infrastructure problems are worth solving eventually. The product organization's friction is worth solving first because the product organization is the platform team's customer. Customers define priority.

4. Setting SLOs without SLIs

Most platform teams agree on reliability targets in abstract terms — "the deployment pipeline should be reliable," "the CI environment should be available during business hours." These are SLOs stated as aspirations. Almost none of the teams that state them have instrumented the service level indicators that would make the targets measurable.

Without SLIs, you cannot tell whether you are meeting your SLOs. You cannot tell when you started missing them. You cannot tell whether the improvement work you did last quarter had the expected effect. You have opinions about reliability rather than measurements.

SLIs for platform teams are not difficult to define. Pipeline success rate: what percentage of CI runs complete without infrastructure-caused failures. Deployment lead time: median time from pipeline trigger to production deployment complete. Environment availability: what percentage of time the development environment responds to standard operations. These are instrumentable in most CI/CD and observability stacks.

The work is not in the definition. It is in the instrumentation. The instrumentation is worth doing because it turns reliability conversations from opinions into data — and because platform teams without data about their own reliability are in a poor position to advise product teams on SLO design.

5. Treating adoption as someone else's problem

A platform capability with 20% adoption is not a platform. It is a side project. The other 80% of the engineering organization is solving the same problems a different way, creating inconsistency, accumulating divergence, and avoiding the cognitive load reduction the platform was supposed to provide.

Low adoption is usually attributed to developer culture or individual preference. Platform engineers say the product teams just do not want to change their workflows. This framing misidentifies the problem. If the golden path had genuinely lower friction than the alternative, product engineers would use it. When they do not, it is because the golden path has friction — documentation gaps, missing features, reliability issues, or a learning curve that was never addressed.

The platform team is responsible for adoption because the platform team owns the product. A product that people do not use has not solved the problem it was built to solve. The platform team's job includes making the golden path the path of least resistance, finding out why it is not, and fixing the friction. If developers are not using the deployment pipeline, the platform team needs to know whether it is because of missing capability, reliability problems, poor documentation, or something else — and then address the actual cause.

Adoption metrics belong on the platform team's dashboard alongside availability and lead time. When adoption is low, that is a product signal, not a culture signal.

---

Platform engineering works when the platform team operates with product discipline. Internal customers, a maintained backlog, SLOs with instrumented SLIs, and adoption as a first-class metric. Not ops with new branding.

The golden path concept — the single, maintained path that handles common cases and reduces the most common friction — is covered in the golden path glossary entry. The SLO/SLI/SLA definitions that underpin the measurement work are in the SLO SLI SLA glossary entry. If you want a structured view of where a new or struggling platform team stands across these dimensions, the Foundations Assessment produces a prioritized findings report.