Writing a Platform Engineering Team Charter That Holds Up

Almost every large engineering organization now has a platform engineering team. Few have a charter that anyone reads after the kickoff. Gartner projects that 80% of large software engineering organizations will have established platform engineering teams by 2026, up from roughly 45% in 2022. The teams are real and the budgets are approved. The founding document, when one exists, is usually a slide titled "mission and vision" that lists the tools the team will build and the values it will hold. That document is the wrong artifact, and it is wrong in a way that costs the team its credibility about eighteen months in.

We have written and rewritten enough of these charters to know what the slide leaves out. A mission statement tells everyone what the team aspires to. It does not tell a frustrated product engineer who decides a database migration, who pays for the platform, what the team will refuse to do, or what happens when the platform stops earning its keep. Those are the questions that surface under pressure, and a charter that cannot answer them is decoration.

Why most charters die quietly

The typical platform charter fails in three ways, and none of them are about ambition.

The first failure is the aspiration list. The charter promises developer productivity, golden paths, reduced cognitive load, and self-service everything. Every line is a goal. Not one line is a boundary. When two product groups both want the platform to support their incompatible deployment topologies, the charter offers no way to say no, so the team says yes to both and dilutes itself into a thin wrapper that delights nobody.

The second failure is the technology manifest. The charter names the stack: Backstage for the portal, Argo for delivery, a specific service mesh, a specific secrets manager. Within a year one of those choices is wrong, the team migrates, and the charter now describes a platform that no longer exists. A charter pinned to tools has the shelf life of the tools, which in this domain is short.

The third failure is the missing reader. Nobody outside the platform team can tell, from the charter, what they are owed or what they owe in return. Consuming teams treat the platform as a free service with infinite scope. The platform team treats every request as a mandate. The charter never set the terms of the relationship, so the relationship is renegotiated, painfully, in every planning cycle.

The counter-take we offer is simple. A platform engineering charter is not a mission statement. It is a contract. Its job is to bound a relationship between a team that builds shared capability and the teams that depend on it, and the most valuable sections of that contract are the ones that say what the platform will not do and who decides what. Aspiration is cheap and everyone already shares it. Boundaries are expensive, which is exactly why they belong in the founding document rather than in a hallway argument two quarters from now.

A charter is a contract, not a manifesto

Treat the charter the way you would treat a service agreement with an external vendor, because functionally that is what it is. The platform team is a supplier. The product teams are customers who, as the DORA State of DevOps research keeps demonstrating, will route around any supplier that slows them down; elite performers move from commit to production in under one hour, and they will not accept a platform that adds a day. A good contract is short, specific, and mostly concerned with edges: where one party's responsibility ends and the other's begins.

We keep the charter to roughly three pages. It answers six questions, in order, and it answers them in outcomes rather than tools.

• Mandate. What problem does this team own that no other team owns? State it as a single sentence a skip-level can repeat. "We own the paved road from commit to production for backend services" is a mandate. "We enable developer excellence" is not.
• Scope and non-scope. The capabilities the team will build, and an explicit list of the things it will not. The second list matters more.
• Decision rights. For each class of decision, who decides unilaterally, who is consulted, and who is merely informed.
• The reciprocal agreement. What the platform owes consumers, and what consumers owe the platform in return.
• Funding and staffing. Where the money comes from and how many people the mandate requires.
• Review and sunset triggers. The conditions under which the charter is reopened, and the conditions under which the team is wound down.

The discipline here is to write in commitments, not adjectives. Every line should be something a third party could later judge true or false.

Decision rights are the part everyone skips

The section that separates a working charter from a poster is decision rights. Most charters imply that the platform team decides platform things and product teams decide product things, which collapses the moment a decision sits on the boundary. Who chooses the default Kubernetes version every service inherits? Who decides that a team may opt out of the paved road? Who approves a breaking change to a shared interface that 40 teams depend on?

We make these explicit with a simple responsibility map borrowed from the responsible, accountable, consulted, informed model, usually written out as RACI on first use so nobody has to guess. For each recurring decision class the charter names exactly one accountable owner. The platform team decides the internal architecture of the platform unilaterally; it does not get to decide a product team's release cadence. A product team decides whether to adopt a new golden path; it does not get to fork the platform's shared base image and expect support. The interesting cases are the shared ones, and the charter earns its keep by pre-resolving them. A breaking change to a shared contract, for instance, is a decision the platform team is accountable for, but only after a fixed consultation window and a published deprecation schedule.

Without this section, every boundary decision becomes an escalation, and escalations are slow and political. With it, most decisions resolve at the level where the context lives, which is the entire point of having a platform in the first place.

The agreement runs both ways

Here is the asymmetry that quietly kills platform teams. Charters describe, at length, what the platform owes its users: uptime, support response, a paved road that works. They say nothing about what users owe the platform. So the platform commits to a 99.9% control-plane availability target and a fifteen-minute self-service provisioning experience, and in exchange it receives a stream of one-off requests, shadow infrastructure built around it, and services that never register their ownership metadata.

A charter that works is reciprocal. The platform commits to specific service levels, a published roadmap, and a stable set of interfaces with a real deprecation policy. In return, consuming teams commit to using the golden path for new services unless they file a logged exception, to not standing up competing shared infrastructure without review, and to keeping their service catalog entries current. This is not bureaucracy. It is the same bargain any internal platform depends on, made legible. The Cloud Native Computing Foundation's platform engineering maturity model frames adoption as something a platform earns rather than mandates, and a reciprocal charter is how you write that principle down before the first dispute rather than after it.

The exception process deserves its own line. A platform with no escape hatch breeds shadow tooling; a platform where the escape hatch is the path of least resistance never reaches critical mass. The charter should make exceptions available, logged, and time-boxed, so that opting out is possible but visible and accountable.

What the charter must leave out

The strongest charters we have helped write are notable for what they exclude. They do not enumerate technologies, because the stack is an implementation detail that will change. They do not claim to own developer happiness, because that is unmeasurable and unfalsifiable. They do not promise to support every language and framework in the organization, because a platform that supports everything is a platform that is excellent at nothing.

A useful test: if a sentence in the charter would still be true at a different company with a different stack, it probably belongs. If it names a vendor or a tool, it probably belongs in an architecture decision record instead, where it can be revised without reopening the team's mandate. We keep a standing non-goals list at the top of the charter precisely because it is the section people most want to erode. Every quarter someone proposes that the platform also own data pipelines, or internal documentation, or the incident process. Sometimes that is right, but it is a charter change, made deliberately, not scope that accretes because saying yes was easier in the moment.

Metrics that tell you the charter is working

A charter you cannot measure against is a wish. We instrument four signals, and we put their definitions in the charter so they cannot be redefined when they turn uncomfortable.

• Voluntary adoption. The share of new services that chose the paved road when a logged exception was readily available. Above 70% means the platform is winning on merit; a high number propped up by mandate is winning on policy, and policy erodes.
• Time to first production deploy. Median time from a new engineer's first commit to their first production deploy through the platform. This is the honest measure of developer experience, and the first paved road should reach production around month four of the team's life.
• Exception rate and age. How many teams have opted out, and how long their exceptions have been open. A growing pile of stale exceptions is a charter that no longer matches reality.
• Boundary escalations. How often a decision the charter should have resolved ends up escalated anyway. A rising count means the decision-rights section is incomplete.

These are leading indicators of whether the contract still describes the world. When they drift, you reopen the charter rather than blaming the team.

Where to start

A platform team without a real charter is not doomed, but it is negotiating its existence from scratch every planning cycle. If you are standing up or resetting a team, work in this order.

1. Write the mandate as one sentence, and pressure-test it by asking which adjacent team it takes work away from. If the answer is "none," the mandate is too vague.
2. Draft the non-goals list before the goals list. Name at least five things the platform will not own in its first year.
3. Build the decision-rights map for the ten decisions most likely to land on the boundary, and assign each exactly one accountable owner.
4. Write the reciprocal commitments as paired obligations, so every promise the platform makes has a matching obligation on consuming teams.
5. Set the service levels and the four metrics above with explicit definitions, and publish the baseline you are starting from so improvement is provable.
6. Define the review cadence and the sunset trigger, so the charter is a living contract with a built-in expiry rather than a founding myth nobody revisits.