Platform Engineering as a Standards Body
I believe there is a subtle but pervasive misconception about the role of Platform Engineering. Leadership often views platform teams as "tooling factories," while engineering colleagues see them as the team that "productizes the infrastructure layer."
While neither view is entirely wrong, they both miss the most critical aspect of the field. I argue that Platform Engineering is better described as an internal standards body. Tooling is merely the vessel through which those standards are delivered.
The Priority Shift: Standards First, Tooling Second
The prime directive of a platform team should be to solicit feedback on environmental friction, establish a standard for best practices, and codify those findings. At that point, building a tool (idly, an IDP or IaC module) is just one possible outcome. Sometimes, the most impactful work a platform team can do is simply publish a policy that shifts the implementation work to other teams while maintaining centralized oversight.
If you don’t have a standard, your tooling is just a faster way to create technical debt.
Consistency Breeds Velocity
Consider the common ambition of adopting an IDP like Backstage. The goal is to track microservices, their repos, and their health. But if every service follows a different naming convention, suffix logic, or repository structure, your "automated" IDP will require constant manual intervention and custom glue code. Velocity isn’t achieved by the IDP; it’s achieved by the naming standard that makes the IDP possible.
Predictability is the prerequisite for automation. And you don’t get predictability without enforced standards.
The Art of the Exception
Even with an exceptional platform, exceptions are inevitable. A rigid "thou shalt" approach is a recipe for shadow IT. Instead, we should view our standards as paved roads, and exceptions as off-roading. Our goal is to make the paved road so smooth that no one wants to leave it, but we must have a framework for when they do:
- Architectural Advisory: Often, teams want to deviate because they aren't aware of a pattern that solves their problem within the standard (e.g., sidecars vs. multiple deployments).
- Standards Evolution: If 20% of teams are requesting the same exception, your standard is likely out of date. Change the standard, and you remove the friction for everyone.
- Unsupported Paths: For the truly unique cases, define what "unsupported" means. It doesn't mean "forbidden," it means the team owning the service assumes the maintenance burden previously handled by the platform.
Platform Engineering succeeds when it creates a environment where the secure, reliable, and compliant way to work is also the easiest. That’s the power of a standard.