TCP #121: Accountability Without Authority Is How Platform Teams Fail
When platform is judged on reliability, cost, and compliance without approval rights over infrastructure, failure is structural, not personal.
The most common dysfunction I see in platform engineering is not technical.
It is organizational.
The platform team is accountable for reliability, cost, and compliance readiness. Simultaneously, app teams provision their own infrastructure, configure their own environments, and make their own architecture choices. The platform has no approval rights over those decisions.
When something breaks, the platform team explains the incident. When the AWS bill is too high, the platform team presents the cost review. When the auditor finds a misconfigured S3 bucket provisioned by an app team, the platform team answers for it.
This is not a people problem. It is a structural mismatch: accountability without authority.
The Business Cost of Structural Mismatch
Structural mismatch in platform engineering manifests in three ways, all of which are costly.
Reliability incidents you cannot prevent
App teams deploy changes outside the platform’s change management process. Those changes introduce instability. Platform is on call for the fallout. The platform team cannot stop the root cause; they can only respond to it after the fact.
Cloud cost variance you cannot explain
App teams create resources without tagging standards. The platform team reports total cloud spend to the CTO, but they cannot attribute it to teams, products, or tenants with confidence. Cost reviews become estimates. Budget conversations become defensive.
Audit findings you cannot remediate
A control requires that all S3 buckets be encrypted. An app team creates a bucket without it. The auditor finds it. The platform team owns the control. But they did not own the bucket.
Each of these is a variation of the same root problem. The platform owns the outcome without owning the inputs.
How Smart Teams End Up Here
This structure does not happen by accident. It usually develops through a reasonable sequence of decisions.
The company starts small. Developers provision their own infrastructure. It works. Ownership is clear because ownership is total: each team owns everything they build.
A platform team forms. Its first mandate is to centralize shared services: CI/CD, networking, and account management. It takes those over. But app teams keep their existing infrastructure provisioning rights. Nobody wants to slow them down.
The platform team grows. It takes on reliability objectives. It takes on a compliance scope. It takes on cost accountability. Each expansion is reasonable in isolation.
What nobody updates is the boundary. App teams still have full autonomy over their own infrastructure. The platform now has accountability for the consequences of that autonomy.
By the time this becomes visible, it is embedded. The platform team is measured against outcomes they cannot fully control. Their performance review includes metrics that depend on decisions they have no input into.
The Operating Principle That Resolves This
Accountability must match authority. This is not an organizational theory. It is an operating principle that can be implemented in weeks.
The practical form: platform teams should have approval rights over any infrastructure decision that touches their accountability scope.
That means:
If the platform owns the cloud cost review, the platform approves compute and storage provisioning above the defined thresholds
If the platform owns the compliance posture, the platform reviews and approves infrastructure changes that affect controls in scope
If the platform owns the reliability objective, the platform sets the change management policy that governs deployments to production
This does not require the platform to do all the work. App teams still build. They still deploy. The platform provides the standards, the guardrails, and, in defined cases, the approval gate.
The goal is not control. The goal is alignment between who owns the risk and who influences the decisions that create it.
What Improves When You Get This Right
When accountability matches authority, three things stabilize quickly.
Incidents become attributable. When platform standards govern the infrastructure, post-incident reviews identify gaps in the standard, not just in the team that missed it. The root cause analysis becomes systemic. The fix improves the platform, not just the individual response.
Cost reviews become credible. When the platform controls tagging policy and provisioning standards, attribution improves. You can present AWS spend by team, by product, or by tenant. The CFO gets a useful number. The CTO can make decisions from it.
Audit prep becomes predictable. When the platform owns the change classification model and the approval gates, control coverage is tracked continuously. Evidence collection becomes operational rather than reactive.
The platform team stops being the team that explains what went wrong. It becomes the team that designed the system that prevented it.
On Wednesday, paid subscribers get the full operating model for implementing this: the approval decision tree, the change classification model, and the sensitive-change checklist I would use to define which infrastructure decisions need platform review, which can be self-service, and which must be blocked.
That’s it for today!
Did you enjoy this newsletter issue?
Share with your friends, colleagues, and your favorite social media platform.
Until next week — Amrut
Get in touch
You can find me on LinkedIn or X.
If you would like to request a topic to read, please feel free to contact me directly via LinkedIn or X.