The Naming Change That Hid a Strategic Question
The platform engineering movement produced a shift in terminology across the enterprise technology industry. Teams that were previously called DevOps teams began to be called platform teams. The name change reflected something real: the emergence of a distinct discipline focused on building internal developer platforms that provide self-service capabilities to application development teams, rather than embedding DevOps practices within those teams.
But in many organisations, the naming change was applied to existing teams without changing the teams’ mandate, operating model, or product orientation. The DevOps team became the platform team on the org chart and in the job titles, but continued doing what DevOps teams do: embedding with development squads, helping teams adopt CI/CD practices, managing pipeline tooling, and providing operational support. The team had a new name and the same job.
The strategic question that this naming change obscures is significant. DevOps teams and platform teams are different organisational constructs solving different problems. Conflating them produces a team that does neither job well and an organisation that does not realise it is missing one of the two capabilities.
What DevOps Teams Actually Do
DevOps teams in the original sense solve an adoption problem. When an organisation is at an early stage of DevOps maturity, development teams need help adopting CI/CD practices, automating testing and deployment, and breaking down the silos between development and operations. The DevOps team embeds in this context, working alongside development teams to build capability that the development teams will eventually own.
The DevOps model has a natural lifecycle. As development teams mature, the DevOps embedding model becomes less necessary. Development teams that have built their own CI/CD capability and automated their deployments do not need embedded DevOps support in the same way. At this point, the question is what happens to the DevOps team. Some organisations dissolve it as the capability it was building is now distributed across the development teams. Others evolve it into something different.
Platform engineering is what the evolution looks like when it is done deliberately. But the evolution requires a deliberate choice, not a renaming.
What Platform Teams Actually Do
Platform teams solve a different problem: scale. When an organisation has many development teams, each building and managing their own CI/CD pipelines, their own testing infrastructure, their own deployment tooling, and their own observability setup, the result is significant duplicated effort and significant quality variation. Each team’s pipeline is slightly different. Each team’s observability is set up differently. Each team’s security practices are slightly inconsistent. The organisation cannot move all teams to new standards efficiently because there is no standard to move to.
The platform team builds the standardised capabilities that all development teams use, as a product. The internal developer platform provides self-service access to the compute, deployment, observability, and security capabilities that development teams need, with a consistent interface and a consistent standard of quality. Development teams use the platform rather than building their own infrastructure; the platform team invests in making the platform good enough that development teams prefer using it to building their own.
The platform team’s relationship with its customers is product-oriented, not service-oriented. It has a roadmap driven by the needs of its internal customers. It measures its success by the adoption of its platform and the productivity impact on the development teams that use it. It manages a product backlog and makes product decisions about feature prioritisation. It does user research with development teams to understand the friction points that the platform should address.
This is qualitatively different from what a DevOps team does. A DevOps team measures its success by the practices it has helped development teams adopt. A platform team measures its success by the adoption and productivity impact of the product it has built.
The Organisation Design Consequence
The distinction between DevOps teams and platform teams has a direct consequence for organisation design, and it is the reason that the conflation is a strategic error rather than just a terminological one.
A DevOps team is positioned relative to the development teams it serves. Its funding model is typically shared across the development teams it supports. Its headcount is sized relative to the number of development teams and the intensity of their adoption support needs. Its performance is assessed on the adoption of DevOps practices across the teams it serves.
A platform team is positioned as a product team. It has a product owner. It has a clear platform product that it owns and develops. Its funding model is based on the platform investment required to serve the development team population that uses it. Its performance is assessed on platform adoption, platform quality, and the productivity impact on the development teams that use it.
The organisation that has a DevOps team when it needs a platform team, or a platform team when it needs DevOps adoption support, will get a result that does not match the investment.
The Capability Assessment That Clarifies the Requirement
The right question for technology leaders is not “do we have a platform team?” but “what problem are we trying to solve, and does our organisational construct match the solution to that problem?”
The organisation that has development teams at low DevOps maturity and needs to build CI/CD capability across those teams needs DevOps adoption capability, probably delivered by a small embedded team or a centre of excellence that develops the practices and builds team capability to own them.
The organisation that has development teams with reasonable DevOps maturity but significant duplication of infrastructure and inconsistent quality across teams needs a platform product, delivered by a platform team with genuine product management discipline.
The organisation that has both needs may need both for a period, with a deliberate plan for the DevOps adoption capability to decrease as platform adoption makes it less necessary.
The platform engineering investment produces the best return in organisations that have the product management discipline and the platform-as-product orientation that the model requires. The return is also contingent on development teams that are willing to use the platform rather than build their own infrastructure, which requires the platform to be good enough that the preference is genuine rather than mandated.
The label on the team matters less than whether the team’s mandate, funding, and success metrics match the problem the organisation needs solved.