Nobody Uses the Platform Nobody Fought For

Editor’s note:The internal platform debate is one of the most consequential arguments in software engineering, and it almost never gets documented honestly. Eleanor Vance found the engineers willing to describe what the argument actually looks like.

The argument started, as these arguments usually do, over a deployment pipeline. One team wanted to deploy on their own schedule using their own tooling. The platform team had spent fourteen months building a standardized deployment system that handled rollouts, canaries, and rollbacks with a consistent interface across every service in the company. The product team did not want to use it.

"They said our pipeline was too opinionated," says the platform engineer who was in the room for that conversation. "I said: yes, it is. That is the entire point."

This is the argument that plays out, in some form, at almost every company that has decided to build an internal developer platform. It is usually framed as a technical dispute: different services have different requirements, the platform makes too many assumptions, the abstraction leaks in practice. These complaints are sometimes valid. But underneath them is usually something else: a disagreement about who gets to make decisions about how software is built.

Internal developer platforms are, at their core, an argument. They encode decisions about what good looks like: how services should be deployed, how configuration should be managed, how observability should work, what the contract between a service and the infrastructure beneath it should be. Building a platform is an act of institutional opinion-making. The politics are not incidental to the work. They are the work.

The most effective platform teams understand this and build accordingly. They invest in adoption the way product teams invest in users: with research, with feedback loops, with the humility to change things that are not working. They document not just how to use the platform but why specific decisions were made, so that the engineers using it understand the reasoning and can engage with it rather than just resenting it.

"The teams that fight us hardest are usually the teams that care most about quality," says Priya Mehta, who leads platform engineering at a logistics company. "They have a strong opinion about how things should work. So do we. The argument is productive if we both show up for it."

The teams that never fight back, the ones that smile and say yes and then build their own deployment scripts in a private repo, those are the ones that worry her. Passive non-adoption is harder to address than principled disagreement, because you cannot iterate on a problem you cannot see.

The platform engineer from the opening disagreement eventually sat down with the product team's tech lead and spent two days working through their specific deployment requirements. Some of those requirements led to real improvements in the platform. Others turned out to be artifacts of a previous workflow that the team had not consciously chosen to keep. One was a genuine constraint that the platform could not accommodate and probably never would.

"We gave them an escape hatch for that specific case," she says. "One escape hatch, documented, with a review process. Not a fork of the platform. An escape hatch." The product team is now one of the platform's most consistent users. The deployment pipeline they fought about serves forty-seven services. The argument, she says, made it better.

A platform nobody uses is a cost center with documentation. A platform people fight over is infrastructure.