What Nobody Tells You About Platform Engineering
The platform engineering conversation has been dominated by tooling since the beginning. Kubernetes adoption. Internal developer portals. Golden path templates. Feature flag systems. Self-service infrastructure catalogs. The assumption underneath all of it is that the problem is fundamentally technical: developers don't have good enough tooling, so we build better tooling, and velocity follows. …
- Most internal platforms fail because they centralize complexity instead of removing it, the tools are different but the cognitive load is the same.
- Platform entropy is the default trajectory: every reasonable addition without a reduction strategy produces a platform nobody fully understands.
- Kubernetes complexity is often organizational complexity that found infrastructure as its expression. Fix the org coordination, and the infrastructure often simplifies.
- Abstraction debt accumulates at every layer boundary where failure is opaque. Design for transparent failure before you design the happy path.
- The operational simplicity moat is built by treating surface area as a scarce resource, every capability earns its overhead or gets removed.
The Tooling Trap: Why Platform Teams Keep Solving the Wrong Problem
Here's what the tooling trap looks like in practice. A platform team diagnoses that developers are spending too much time on infrastructure. The solution is obvious: build better infrastructure abstractions. Wrap Kubernetes in an internal deployment service. Add a self-service portal. Build golden path templates so developers don't have to write YAML by hand. The platform ships. Adoption is mandated. Six months later, developers are spending more time on infrastructure than before, now it's the
Platform Entropy: Why Every Internal Platform Tends Toward Sprawl
Platform entropy is what I call the accumulation of technical surface area that happens when platform teams respond to each reasonable request without a coherent reduction strategy. Each addition makes local sense. The sum becomes operationally incoherent. The pattern is predictable. A team needs a feature flag system, added. Another team needs a secret injection mechanism, added. A third team needs a custom deployment strategy that the golden path doesn't support, added as an escape hatch. Thr
Kubernetes Complexity Is Often Organizational Complexity in Disguise
The most counterintuitive thing I've learned about platform engineering is how directly infrastructure complexity maps to organizational complexity. Conway's Law runs in both directions. Here's a specific example. A platform team at a mid-scale company has seventeen Kubernetes namespaces, each with their own RBAC configuration, network policies, and resource quotas. The RBAC drift across namespaces is significant, roles that were created for specific engineers who have since left, permissions s
Frequently asked questions
- How do you know if your platform is centralizing complexity instead of removing it?
- The clearest signal is support ticket volume. If developers regularly need help from the platform team to debug failures, to handle edge cases, or to understand why the golden path doesn't work for them, the platform has centralized complexity it hasn't removed. A platform that removes complexity has low support ticket volume not because developer…
- Is platform entropy inevitable? Can it actually be avoided?
- It's the default trajectory. Whether it's avoided depends on whether the platform team has an explicit reduction strategy running in parallel with additions. In practice, this means that for every new capability, the team asks: what does this replace, and when will we remove what it replaces? The teams that avoid runaway entropy run periodic audit…
- How do you design abstractions that fail transparently?
- Start with failure scenarios before you design the happy path. For every abstraction you're building, write the three most likely failure scenarios and ask: will a developer who has never seen the internals be able to understand what happened from the error message alone? If the answer is no, the error message is part of the design work, not an af…
- Platform engineering has been described as 'DevOps done right.' Is that accurate?
- It's accurate in the sense that both disciplines are trying to solve the same underlying problem: the cognitive overhead and coordination cost of operating complex software systems. Where platform engineering is different is in its explicit acknowledgment that not every team should own the full operational stack. DevOps said: break down the wall b…
- How do you make the case for platform engineering investment to leadership when velocity is hard to measure?
- Don't try to measure velocity directly, it's a lagging, noisy indicator. Measure the inputs to velocity that the platform directly controls. Onboarding time for new services: how long from 'we decided to build a new service' to 'it's running in production'? Deployment confidence: what percentage of production deployments require manual interventio…