Platform engineering was supposed to be the answer to the chaos that shift-left and DevOps introduced. We asked developers to own more of the pipeline, from testing to security to maintenance, and then we acted surprised when the cognitive load became crushing. John Keates's article, "Rightsizing Platform Engineering," names the real problem: it's not about building more platform, it's about building the *right* platform for your specific engineering culture. That distinction matters because most teams are either drowning in duplication or suffocating under an internal product that tries to do everything and satisfies no one.
The core tension is one we see play out constantly in practice. On one hand, you have teams that embraced DevOps fully, only to realize that every squad is reinventing the wheel for CI/CD, security scanning, and environment provisioning. On the other hand, you have organizations that over-correct by building a golden path so rigid it becomes a straightjacket. The answer, as Keates argues, is rightsizing: a platform that reduces cognitive load without stripping away the flexibility that makes engineering work engaging. This isn't a technical decision as much as a cultural one. You can't buy this off the shelf, and you can't mandate it from the top down. It requires listening to the people who actually use the platform daily, and that's where most initiatives fail.
This connects directly to a broader theme we've been tracking: the human side of AI and automation. For instance, when we looked at Unlock ChatGPT for Work: A Practical Guide to Getting Started, the takeaway was that AI tools only deliver value when they slot into existing workflows without demanding a complete overhaul. The same logic applies to platform engineering. If your internal developer platform requires a training bootcamp to use, you've simply moved the cognitive load from the code to the platform itself. Similarly, our piece on Bridging Retrieval and Action: A New Approach to AI Tasks highlighted how connecting different systems explicitly reduces friction. That's exactly what a well-rightsized platform should do: connect the pieces your team already uses, rather than forcing them into a new, monolithic environment.
What we appreciate about Keates's framing is that he doesn't pretend there's a universal metric for success. You can't measure "cultural match" with a dashboard, but you can measure it by asking whether your engineers feel empowered or constrained. If your platform team is spending more time policing usage than enabling innovation, that's a signal. If your developers are still duplicating security checks because the platform's built-in ones don't fit their use case, that's a problem. The practical takeaway here is almost uncomfortable in its simplicity: start by auditing where the cognitive load actually lives in your organization, and then build only the platform components that directly reduce that load. Everything else is just infrastructure theater. The open question we're left with, and the one worth watching, is whether platform teams will have the humility to treat their internal users as customers with choices, or whether they'll keep building cathedrals in the desert.