The Problem With "You Build It, You Run It"
DevOps gave us a powerful principle: the team that builds software should also be responsible for running it. This was a necessary correction to the old model where developers threw code over the wall to operations and walked away.
But taken to its logical extreme, "you build it, you run it" creates a different problem. Every team becomes responsible for their own CI/CD pipelines, their own monitoring setup, their own deployment workflows, their own infrastructure configuration. The result is not empowerment. It is fragmentation.
Teams end up spending 30-40% of their time on platform concerns instead of product work. They build bespoke solutions for problems that have already been solved by the team two floors up. And when something breaks in production, the debugging starts with figuring out which of the twelve different monitoring setups might have the relevant data.
What Platform Engineering Actually Means
Platform engineering is the practice of building and maintaining an internal developer platform: a curated set of tools, workflows, and self-service capabilities that abstract away infrastructure complexity and let product teams focus on delivering features.
This is different from DevOps in a few important ways.
It is a product discipline. The internal developer platform has users (the engineering teams), and it should be treated like a product. That means user research, feedback loops, documentation, and iterative improvement. The platform team is not a service desk. They are building a product that makes other teams more effective.
It provides paved roads, not guardrails. The goal is not to restrict what teams can do. It is to make the right thing the easy thing. If deploying a new service through the platform takes five minutes and deploying it manually takes two days, teams will choose the platform. You do not need to mandate it.
It centralizes the undifferentiated work. Observability setup, secret management, certificate rotation, deployment pipelines, environment provisioning. These are all necessary but undifferentiated. When every team solves them independently, the organization pays the cost of that duplication in engineering hours, operational inconsistency, and security gaps.
What a Platform Team Looks Like
A platform team is typically small (3-6 engineers) and operates with a product mindset. They maintain:
- A deployment pipeline that teams can adopt with minimal configuration
- Environment provisioning that lets teams spin up staging and production environments through a self-service interface
- An observability stack with sensible defaults and the ability to extend
- A service catalog that tracks what is running, who owns it, and how it connects
- Documentation that is accurate, current, and written for the people who actually use the platform
The team measures success not by the number of features they ship, but by the velocity and reliability of the teams that use their platform. Deployment frequency goes up. Lead time goes down. Time spent on operational toil decreases.
Common Mistakes
Over-engineering the platform before understanding the users
The most common failure mode is building a sophisticated platform that nobody asked for. Start by understanding what your engineering teams actually struggle with. Instrument the development workflow. Talk to the people who are deploying code. The first version of the platform should solve the three most painful problems, not provide a comprehensive solution to every possible scenario.
Treating the platform as mandatory
Mandating platform adoption creates resentment and workarounds. If the platform is good, teams will adopt it because it makes their lives easier. If teams are avoiding the platform, that is feedback about the platform, not about the teams.
Staffing the platform team with junior engineers
Platform engineering requires deep technical expertise across infrastructure, networking, security, and developer tooling. The engineers on this team need to understand the problems they are solving at a fundamental level, not just configure tools. Senior engineers who have operated production systems are the right fit.
The Organizational Shift
The real change that platform engineering represents is not technical. It is organizational. It acknowledges that some engineering problems are better solved once, well, by a dedicated team, rather than solved repeatedly, inconsistently, by every team in the organization.
This does not mean product teams lose ownership of their services. They still build them, deploy them, and operate them. But they do so on a foundation that handles the undifferentiated complexity, freeing them to focus on the work that actually differentiates the business.
The organizations that get this right see measurable improvements: faster onboarding for new engineers, higher deployment frequency, fewer production incidents caused by configuration drift, and engineering teams that spend more time on product work and less time fighting their tools.