Somewhere in your organization right now, three teams are building the same thing. One team in payments is writing a deployment pipeline from scratch because the one from the commerce team "doesn't quite fit." A team in identity is building a logging framework because they need structured logs and the existing one only does plaintext. A team in search is hand-rolling a circuit breaker because nobody told them the infrastructure team shipped one six months ago. Every one of these engineers is talented. Every one of them is wasting their time.
This is the default state of engineering organizations past about fifty people. Not because anyone decided it should be this way, but because nobody decided it shouldn't. Teams are given autonomy -- as they should be -- and they use that autonomy to solve the problems directly in front of them. The result is an organization where the same undifferentiated infrastructure gets built over and over, each version slightly different, each version carrying its own maintenance burden, and none of them as good as a single well-funded effort would have been.
The cost of this duplication is staggering, and most organizations have no idea how much they're paying.
The Multiplication Problem
Consider a concrete example. You have fifteen engineering teams. Each team needs a way to deploy their services, emit structured logs, manage secrets, handle authentication, implement retries and circuit breakers, and run integration tests in CI. These are table-stakes capabilities -- every team needs them, and none of them are what make your product unique.
Without a shared platform, each team spends roughly 20% of their engineering capacity on this undifferentiated infrastructure. They're not writing features. They're not improving reliability. They're not reducing latency or shipping experiments. They're gluing together Terraform modules, writing Dockerfile boilerplate, configuring log pipelines, and debugging authentication flows that six other teams have already debugged.
Do the math. Fifteen teams, each with six engineers, each spending 20% of their time on infrastructure work that could be shared. That's eighteen full-time-equivalent engineers worth of effort -- not building your product, not serving your customers, not creating competitive advantage. Eighteen engineers building the same deployment pipelines, the same logging wrappers, the same auth integrations, over and over again.
Now consider the alternative. A platform team of five engineers builds these capabilities once, well, with proper documentation, sensible defaults, and clean interfaces. Those five engineers replace the duplicated work of eighteen. The remaining thirteen FTEs of recaptured capacity go back to product work. And the shared implementations are better than any single team's version because they get full-time attention, cross-team feedback, and the benefit of solving the problem once with full focus.
This isn't theoretical. This is basic arithmetic. And yet most organizations resist it, because the cost of duplication is invisible and the cost of a platform team shows up on a headcount spreadsheet.
Why Teams Rebuild Instead of Reusing
Teams don't duplicate infrastructure out of ignorance or spite. They do it because the alternatives are worse -- or at least appear to be worse from where they're standing.
Discovery is broken. Most organizations have no catalog of shared capabilities. An engineer who needs a circuit breaker doesn't know that one already exists. So they build it themselves, because that's faster than sending Slack messages to fifteen channels hoping someone knows.
Existing solutions don't fit. Even when teams know about a shared tool, it often doesn't meet their needs. The API is awkward. The configuration is inflexible. It's genuinely faster to build from scratch than to wrestle with someone else's opinionated abstraction.
Adoption has too much friction. The shared deployment pipeline exists, but using it requires filing three tickets, waiting two weeks for onboarding, and then discovering it doesn't support the one thing your service needs. By the time you've navigated the process, you could have written your own pipeline twice over.
There's no trust. The last shared library the team adopted broke in production and the owning team took a week to respond. Dependencies on other teams become liabilities. Better to own everything yourself, even if it costs more upfront, because at least you control the outcome.
Every one of these reasons is rational. And every one of them is a failure of platform design, not a failure of the teams making the decision.
Golden Paths, Not Golden Cages
The answer to duplicated infrastructure is shared platforms. But the way you build the platform determines whether anyone actually uses it. The history of internal platforms is littered with mandated frameworks that teams resented, worked around, and eventually abandoned. If your platform strategy depends on a mandate from leadership, you've already lost.
The concept that works is the golden path -- a paved road that represents the easiest, fastest, most well-supported way to accomplish a common task. Not the only way. The easiest way. Teams choose the golden path not because they're told to, but because it's genuinely better than the alternative.
A golden path for deployment means a team can go from "I have a service" to "it's running in production with logging, metrics, alerts, and autoscaling" in under an hour. Not by reading a forty-page runbook. Not by filing tickets. By running a command, answering a few questions, and watching the platform handle the rest. If your golden path takes longer than building it from scratch, it's not a path -- it's a roadblock.
The critical design principle is that golden paths must be optional. The platform provides defaults, not mandates. If 80% of your teams can use the golden path without modification, you've won. The remaining 20% can build custom solutions, and that's fine -- you've still eliminated the vast majority of duplicated work. Those divergent teams also serve a vital function: they stress-test the boundaries of your platform and reveal gaps you should fill.
When to Centralize, When to Let Go
Not everything should be centralized. The decision of what belongs in a shared platform and what belongs with individual teams is a judgment call, and getting it wrong in either direction is expensive.
Centralize things that are undifferentiated and universal. Deployment, observability, secrets management, service-to-service authentication, CI/CD pipelines -- capabilities every team needs that don't vary meaningfully between teams. When every service deploys the same way, you can build tooling around that consistency. When every service emits logs in the same format, you can build a single query interface that works across the entire organization.
Leave things that are domain-specific and differentiating with the teams. Business logic, data models, API design, domain-specific algorithms -- these are what make your product unique. Centralizing them creates bottlenecks and strips context. The platform provides the foundation. The teams build the house.
A useful heuristic: if more than three teams are solving the same problem independently, it belongs in the platform. If only one team needs it, it doesn't. If two teams need it, watch and wait -- the third will tell you the answer.
Platform Adoption Is Product-Market Fit
Here's the mindset shift that separates good platform teams from bad ones: your platform is a product, and your engineering teams are your customers. If they're not adopting it, the problem is your product, not your customers.
Measure adoption the same way a product team measures engagement. How many teams are using the golden path for deployment? What's the time-to-first-deploy for a new service? How many teams started with the platform and then migrated away? What's the satisfaction score from your last internal survey? These aren't vanity metrics. They're signals of whether your platform is solving real problems or creating new ones.
When adoption is low, resist the urge to mandate. Instead, diagnose. Talk to the teams that aren't using your platform. Understand their objections. Fix the real issues. Maybe your CLI is confusing. Maybe your documentation assumes too much. Maybe your platform doesn't support their runtime. Maybe the onboarding process takes too long. These are product problems, and they have product solutions.
The best platform teams run their roadmap like a product team. They do user research. They track adoption funnels. They measure time-to-value. They have on-call for their platform, because when your deployment pipeline goes down, every team is blocked. They treat internal developers with the same care that product teams treat external customers.
The Economics of Doing It Once
At the team level, building your own solution feels cheaper. You control the scope, you build exactly what you need, and there's no coordination cost. Two engineers for two weeks. That feels manageable.
But zoom out. Multiply that cost by every team. Add the ongoing maintenance burden -- every custom solution needs updates, security patches, on-call coverage. Add the consistency cost -- when every team's logging is different, you can't build a single debugging workflow that works across services. Add the onboarding cost -- every new engineer learns bespoke infrastructure instead of a shared, well-documented platform. Add the reliability cost -- fifteen implementations means fifteen surfaces for bugs, fifteen configurations to audit.
The total cost of doing it fifteen times is not fifteen times the cost of doing it once. It's far worse. A single shared implementation gets hardened by use, improved by feedback, and maintained by a dedicated team. Fifteen individual implementations rot quietly, maintained by teams whose primary job is something else entirely.
The most expensive line of code in your organization is the one that's been written twelve times by twelve different teams, each convinced they were saving time.
Starting Without Boiling the Ocean
If you don't have a platform team today, the worst thing you can do is try to build everything at once. Start with the highest-pain, highest-frequency problem. In most organizations, that's deployment. Teams spend an astonishing amount of time getting code from a laptop to production, and the variation between approaches creates constant operational friction.
Build a deployment golden path that handles one language and one deployment target. Make it absurdly easy to use. Get three teams on it. Collect feedback. Iterate. Then expand to the next language, the next target, the next capability. Let adoption pull you forward rather than pushing a grand vision onto teams that aren't ready for it.
The platform team's first job is to earn trust. Ship something small that works perfectly. Then ship something slightly bigger. Build a reputation for reliability, responsiveness, and developer experience. Once teams trust the platform, adoption accelerates on its own. Teams start asking you to solve their next problem instead of building it themselves. That's the inflection point. That's when the economics start compounding in your favor.
The goal isn't to eliminate all duplicated work overnight. The goal is to make it obvious, over time, that the shared path is faster, more reliable, and better supported than going it alone. Build nothing twice -- not as a mandate, but as a natural consequence of making the right thing the easy thing.