At UshaOm, I built an engineering team from scratch to 27 people. For the first 15 engineers, we didn't need a platform team. Everyone knew the Magento codebase, everyone could deploy, everyone understood the infrastructure. Then we crossed some invisible threshold. Suddenly engineers were spending more time asking "how do I deploy this" and "where do the configs go" than building features. New hires took weeks to ship their first change. Not because the code was hard, but because the deployment process lived in three people's heads.
That was when I understood the platform team question. It's not about company size. It's about the ratio of time spent shipping features versus time spent fighting infrastructure.
What Is a Platform?
An internal developer platform (IDP) is a curated set of tools, workflows, and services that let product teams deploy and operate software without needing to be infrastructure experts.
Here's what that actually means in practice: your platform team builds self-service capabilities so a product engineer can, at 2 AM with no infrastructure knowledge, deploy a fix to production. The platform provides guardrails (this code can't access that database, this service can't breach these resource limits), visibility (you can see your service's behavior in production), and controls (rollback, gradual rollout, alerting).
A platform is not Kubernetes. Kubernetes is a tool your platform might use. A platform is not "we have Terraform repos." That's infrastructure as code, which is great, but platforms are bigger than that.
Good platforms are invisible. Engineers don't think about them. They have an idea, write the code, run one command, and it's in production with monitoring, logging, and alerting. They don't think "how do I deploy this?" They think "this is deployed."
Bad platforms are the opposite. Hours reading wiki pages, asking in Slack, jumping through approval processes. At Salesken, before we standardized our deployment pipeline, we had four different ways to deploy across eight services. Each one had its own quirks. One required a manual database migration step that was documented in a Google Doc that three people knew existed. That's not a platform. That's an oral tradition with a Google Doc as a talisman.
The Golden Path
The single best concept in platform engineering is the golden path. It's the boring, well-paved road to doing the common thing. For 90% of your services, there's a standard way to do it. That should be the easiest way.
The golden path means: a standard way to write services (usually a template repository or starter project), a standard way to deploy them (one command to the platform), and a standard way to operate them (built-in dashboards and alerting).
This doesn't mean everyone uses the golden path. It means the golden path is so easy that not using it requires justification. If 95% of your services are Node.js, the golden path is Node.js. If someone wants Rust, that's fine, but they're choosing a harder path for a specific reason.
The golden path is also how you avoid platform bloat. You don't support 15 programming languages, 10 deployment strategies, and custom infrastructure for every team. You support one thing well. Want to deviate? You can. But you're choosing to.
Key Capabilities of a Mature Platform
Self-service environments. Engineers request an environment and it's provisioned automatically. No waiting for ops, no manual configuration. This alone eliminates a massive category of "why isn't this working" bugs. At Salesken, before we automated environment provisioning, setting up a new staging environment took a developer two days and involved filing three Jira tickets. After automation, it was one command and five minutes.
Deployment pipelines. Code push triggers automated steps: test, build, deploy. Standardized but customizable. Teams don't write their own CI/CD logic; they configure the provided pipeline. Your platform team maintains the pipeline. Product teams use it.
Observability baked in. Every service automatically gets logging, metrics, and tracing. Engineers don't set it up. They write code, and the platform captures what's happening. Most platform teams skip this, treating it as a separate concern. Don't. If observability isn't automatic, half your services will have none, and you'll discover this during an incident at 3 AM.
Secrets management. How do services access databases, APIs, and each other? Through managed secrets. The platform provides a secure path that's easier than storing credentials in code. Because if you make the secure path harder than the insecure path, engineers will take the insecure path. Every time.
Service discovery and networking. Services register on deploy, the platform handles discovery, load balancing, and retries. This is infrastructure that product engineers shouldn't think about.
Common Platform Mistakes
Building a platform nobody uses. This happens when the platform team doesn't talk to product teams about what actually blocks them. They build "best practices" infrastructure that solves problems nobody has. Then they're surprised when teams run their own deployments in ways that terrify ops. Talk to your users. Ask what three things would save them the most time. Build those first.
I've made a version of this mistake. At Salesken, our platform team spent a quarter building an advanced canary deployment system. It was technically impressive. Exactly two services used it. What engineers actually wanted was faster CI. We should have asked before building.
Over-investing before you need it. I've watched companies with 10 engineers invest in platform infrastructure designed for 100. Wasted effort. You don't need Kubernetes, a service mesh, and a custom developer portal when five people can just SSH into the same server. Start simple. Scale the platform as the company scales. At UshaOm with 27 engineers, our "platform" was a shared deployment script and a well-documented wiki page. It worked. Not elegant, but it worked.
Building bureaucracy instead of a platform. If using the platform requires more approvals than not using it, you've built the wrong thing. The platform should be faster and easier than the alternative. If it's not, it won't be adopted. Engineers are pragmatic. They'll route around obstacles.
Forgetting that platforms are products. Platforms need a PM. That PM works with platform engineers to understand what product teams need, prioritize what to build, and decide what to deprecate. Without a PM, the platform team builds what they find technically interesting, not what engineers actually need. In Bengaluru's engineering culture, I've seen this pattern a lot: brilliant infrastructure engineers who build impressive systems that nobody asked for. The PM function is what keeps the platform aligned with reality.
The Platform PM Role
Many platform teams don't have a PM. This is a mistake.
A platform PM works with product teams, understands their pain, and translates that into platform investments. A platform PM also says no: "We're not supporting that, here's why." A platform PM thinks about adoption: "If we build this, will teams use it? How do we make migration painless?"
This is a different skill than managing user-facing features, but it's the same mindset: understand users, solve their problems, measure adoption.
Connecting Platform Work to Codebase Reality
Platform teams need to understand how engineers actually work, not how they say they work. Codebase intelligence helps here.
Which teams are using the golden path? Which have custom deployments, and what's actually different about them? You might discover five teams have built nearly-identical deployment logic in their Makefiles. That's a platform candidate.
Which services are missing observability or alerting? This tells you whether your observability tooling is hard enough to set up that teams are skipping it, which is a platform problem, not a team discipline problem.
Which services violate your platform's service size guidelines? If you've decided services should stay under a certain size and you have ten monoliths growing unchecked, that's valuable signal about where the golden path isn't being followed and why.
At Glue, we're building the layer that surfaces this gap between platform intent and codebase reality. The honest challenge: detecting "platform compliance" from code alone is imprecise. We can see patterns and flag deviations, but the why behind each deviation still requires human context. We're getting better at it, but it's not fully automated yet.
Platform Engineering in 60 Seconds TL;DR
Platform teams scale engineering productivity. Not needed at 10 engineers, essential at 100. Platforms provide self-service: deploy without ops, monitor automatically, manage secrets safely. The golden path is the boring, well-paved way to do the common thing, and it should be the easiest thing. Platforms are products that need a PM. Don't over-invest before you need it. Don't build bureaucracy disguised as a platform.
Frequently Asked Questions
Q: How big does a company need to be for a platform team?
Typically 50-80 engineers is when the pain is acute enough. Before that, the overhead of a separate team outweighs the benefits. Watch for the inflection point: when infrastructure questions are regularly blocking product development, when new engineer onboarding takes weeks because of tooling complexity, or when you have more than three different ways to deploy across teams.
Q: Should platform engineering report to DevOps, Infrastructure, or Engineering?
To engineering or the CTO. If it reports to DevOps or Infrastructure, it stays infrastructure-focused. If it reports to engineering, it stays product-focused. Platforms are products for engineers. They should report alongside the teams they serve.
Q: How do we migrate existing services to the platform?
Incrementally. Pick your simplest service first. Onboard it. Document what was hard. Improve the platform. Pick the next service. In parallel, ensure all new services use the platform from day one. Don't let new services build around it. After a year, most services should be on it.
Related Reading
- CI/CD Pipeline: The Definitive Guide to Continuous Integration & Delivery
- Observability: Beyond Monitoring
- How to Choose Your Technology Stack
- Deployment Frequency: The DORA Metric That Reveals Your True Engineering Velocity
- Developer Experience: The Ultimate Guide
- Feature Flags: The Complete Guide to Safe, Fast Feature Releases