Why This Matters for DevOps and Platform Teams
Platform engineering teams face a unique version of the Innovation Tokens dilemma: they are building internal products (developer platforms, CI/CD pipelines, infrastructure abstractions) where the "customer" is other engineers. And engineers are the most vocal advocates for exciting technology.
A platform team that spends all its tokens on novel infrastructure has nothing left for the actual platform experience. Consider two approaches to building an internal developer platform:
Team A (Token-heavy approach):
- Custom service mesh (1 token)
- Bleeding-edge GitOps controller (1 token)
- Novel infrastructure-as-code tool (1 token)
- Result: Tokens exhausted. Developer portal is a wiki page.
Onboarding takes 3 weeks. Developers are frustrated.
Platform team is permanently in firefighting mode.
Team B (Token-conservative approach):
- Standard Kubernetes with managed control plane (0 tokens)
- ArgoCD for GitOps (0 tokens — mature, well-documented)
- Terraform for IaC (0 tokens — industry standard)
- Spent 1 token on: A custom developer portal with self-service
provisioning tailored to their specific workflow
- Result: Developers can spin up a new service in 10 minutes.
The platform team has capacity to iterate on the experience.
New hires are productive in 2 days.
Team B's platform is more valuable to the organization despite being built on "boring" technology, because it was built on boring technology. The team had cognitive and operational budget left over to focus on what actually matters: the developer experience.
The Platform Tax Multiplier
When a platform team chooses exciting technology, the cost is amplified because it affects every team that uses the platform. If your CI/CD pipeline is built on a novel tool that breaks in unexpected ways, every development team in the company is blocked. If your infrastructure abstraction uses a niche IaC tool, every new hire across the organization has to learn it.
This is the platform tax multiplier: the operational cost of a platform team's technology choices is multiplied by the number of teams that depend on the platform. A one-token choice by the platform team can cost the organization the equivalent of ten tokens in aggregate friction.
Consider the math: if a platform team of 6 engineers adopts a novel tool that costs each of them 2 hours per week in operational overhead, that is 12 engineer-hours per week. But if that tool also costs each of 20 product teams 1 hour per week in friction (slower builds, confusing errors, missing integrations), that is an additional 20 engineer-hours per week. The platform team's one-token choice is actually costing the organization 32 engineer-hours per week — nearly a full engineer's time — in invisible tax.
If you are interviewing for a platform or SRE role and asked "What's your philosophy on adopting new tools for the platform?" a strong answer explicitly acknowledges the multiplier effect: "I'm more conservative about platform technology than product technology, because platform choices affect every team. A tool that costs my team one hour a week costs the organization ten hours a week if ten teams depend on it. I'd rather have a boring, reliable platform that developers trust than an exciting one they have to work around."
Key Point: Platform teams should be the most conservative technology choosers in the organization, not the least. Their job is to absorb complexity so product teams don't have to. If the platform itself is complex, it is failing at its primary mission. The measure of a great platform is not the sophistication of its internals — it is how invisible it is to the teams that use it. Boring platforms that just work are the highest form of platform engineering.