Platform: The most misunderstood word in organizations
The problem
The CTO announces a “platform initiative.” John, a senior engineer, expects improved efficiency from shared tools. Sarah in Finance expects increased returns. Six months later, nobody’s happy. John faces confusing adoption metrics instead of streamlined workflows. Sarah questions the lack of expected growth. Teams complain about waiting in queues.
Everyone blames everyone else. But the real problem started in that first meeting: three people heard “platform” and imagined three completely different things. This confusion wastes millions in misallocated investment and creates structural problems that persist for years.
Two completely different worlds
The word “platform” refers to two completely different things. They share a name but nothing else.
External platform: a product.
Economists define platforms as two-sided markets that connect distinct user groups with network effects (Rochet & Tirole, 2003). Uber connects drivers and riders. Airbnb connects hosts and guests. More drivers mean shorter wait times, which attract more riders, which in turn attract more drivers. The value grows with adoption.
AWS and Azure are NOT platforms by this definition. They’re products. When you use AWS, it doesn’t become more valuable because another company also uses AWS. There’s no cross-side network effect connecting distinct user groups. Parker, Van Alstyne & Choudary (2016) make this distinction explicit: infrastructure sold to customers is a product, not a platform. AWS Marketplace has platform characteristics (connecting sellers and buyers), but core compute and storage services are just products you purchase.
External platforms are products with network effects. Success is driven by product development: market fit, user acquisition, network effects, and revenue growth. You measure product-market fit, retention, lifetime value, and growth rate.
Internal platform: a shared service.
Within organizations, “platform” usually refers to a centralized team that other teams depend on, such as CI/CD, data infrastructure, CRM, or ERP. These are not products. They don’t connect external groups. They don’t have network effects. Calling them “platforms” borrows the term without the economics.
Consider Sam, an engineer who spends hours each week waiting in a ticket backlog. The centralized team is a bottleneck. Sam can’t make progress independently. This is the blocking problem that destroys internal platforms.
Internal platforms are shared services. Success is driven by three criteria: voluntary adoption, non-blocking delivery, and cost savings. You measure wait time, self-service percentage, and actual costs versus the distributed alternative.
| External Platform | Internal Platform | |
|---|---|---|
| What it is | Product connecting external groups | Shared service for internal teams |
| Economic driver | Network effects (Rochet & Tirole) | Internal economics |
| Success criteria | Market fit, growth, revenue | Adoption, non-blocking, cost savings |
| Failure mode | No network effects, no growth | Queues, cost of delay, wasted resources |
| Examples | Uber, Airbnb, iOS App Store | CI/CD team, data platform, CRM team |
This document covers only internal platforms. External platforms (products with network effects) are a discipline entirely different from the one.
I use “internal platform” throughout, not “shared service.” Adding yet another term would only increase the confusion.
The three criteria
An internal platform only creates value when three criteria are ALL true:
- Adoption - teams actually use it voluntarily (not because it’s mandated)
- Non-blocking - zero wait time (self-service for 95%+ of requests)
- Internal economics - real cost savings exist (not speculative “it will pay off”)
If anyone fails, the platform destroys value:
- High adoption + non-blocking but bad economics = waste of money
- Good economics + non-blocking but low adoption = nobody uses it
- High adoption + good economics, but blocking = cost of delay destroys the savings.
Measure the three criteria directly:
| Criterion | Metric | Target |
|---|---|---|
| Adoption | Voluntary usage rate (without mandates) | >80% of eligible teams |
| Non-blocking | Self-service percentage (no human in the loop) | >95% of requests |
| Economics | Actual cost savings vs. distributed alternative | Positive and measurable |
If you can’t demonstrate all three criteria with real numbers, you’re either in transition (acceptable) or wasting resources (not acceptable).
Examples
Spotify (failure). Shared infrastructure serving 100+ squads created queues (Lee, 2020). Squads waited weeks. They tried reallocating resources, new scheduling procedures, and better prioritization. None of it worked. The infrastructure team’s vision didn’t align with what the squads actually needed. The cost of delay compounds into massive organizational damage. The queues weren’t “growing pains.” They were a failure.
Netflix (success). Centralized platform teams work because they invest heavily in self-service. Product engineers trade flexibility for not owning infrastructure at 3 am.
What happens without centralization
Distribution has real costs: duplicated work, inconsistent implementations, knowledge silos, upgrade coordination hell, junior engineers drowning in unfamiliar infrastructure.
But here’s the uncomfortable truth: distributed chaos with zero wait time is often better than elegant centralization with queues. Distribution costs are constant. Cost of delay compounds.
The question: can you centralize WITHOUT creating blocking dependencies? If yes, centralize. If not, accept the distribution costs. A blocking internal platform is worse than no internal platform.
The non-blocking criterion
Internal platforms can create leverage: when the CI/CD team improves build times by 30%, every team benefits simultaneously.
But leverage only exists if the service is non-blocking. If product teams wait in queues, the cost of delay destroys the leverage. Kingman’s formula shows why: waiting time grows exponentially as utilization increases. At 80% utilization, small variability creates significant delays. At 90%, delays explode. Multiply across multiple blocking services, and you get multi-week lead times for work that should take days.
The criterion is binary. Is it non-blocking? If yes, centralization can create value. If not, centralization destroys value. There’s no “acceptable queue time.” Any wait time compounds.
When can you make it non-blocking?
| Factor | Non-blocking centralization possible | Distribute instead |
|---|---|---|
| Request patterns | Predictable, automatable | Highly variable, needs human judgment |
| Self-service investment | Can fund multi-year platform development | Cannot afford self-service tooling |
| Customization needs | Low (one-size-fits-most works) | High (every team needs a different config) |
| Compliance requirements | Standardization required anyway | Flexibility acceptable |
If you can’t make it non-blocking, distribute. The distributed costs (duplication, inconsistency) are real, but they don’t compound as delay costs do.
The hard problems
Even non-blocking services create a cost of delay when they push changes onto product teams. Every migration you force onto them is a delay. Every breaking change is delayed. Every security upgrade you mandate is delayed (sometimes necessary, but not free).
The best platforms are boring and stable, not constantly improving. Every change you push is a tax on product delivery.
When internal platforms make sense
Centralize ONLY when you can meet all three criteria:
| Question | If yes | If no |
|---|---|---|
| Will teams adopt voluntarily? | Proceed | Don’t build (or fix the value proposition) |
| Can you make it non-blocking? | Proceed | Don’t centralize; distribute instead |
| Do economics work? | Proceed | Don’t build (it’s a waste) |
Centralize when self-service for 95%+ of requests is achievable, the capability is stable, real cost savings exist and are measurable, and you have the capacity to build proper self-service.
Don’t centralize when teams won’t voluntarily adopt (the service isn’t good enough), you can’t make it non-blocking, cost savings are speculative, or requirements change faster than self-service can evolve.
Sometimes centralization is forced regardless of preference: regulatory separation of duties, contractual SLAs, audit requirements, organization-wide security tooling. In regulated industries, compliance forces centralized models regardless of what’s theoretically optimal for flow.
Hybrid models (transition strategies)
Every model below only works if it’s non-blocking. These are ways to GET TO non-blocking, not alternatives to it.
| Model | How it achieves non-blocking | Works when | Fails when |
|---|---|---|---|
| Thin Platform | Stable abstractions; product teams own everything above | Abstractions are genuinely stable | Requirements change faster than abstraction evolves |
| Embedded Specialists | Infrastructure engineers sit with product teams, coordinate via guild | Enough specialists to embed (1 per 2-3 teams) | Can’t hire enough; guild becomes toothless |
| Golden Path | Opinionated supported path; divergent teams own their complexity | Can invest in making the path excellent | Path isn’t good; teams diverge because it’s bad |
| Self-Service + Guardrails | Automated tooling with built-in compliance; humans only for exceptions | 80%+ requests fit standard patterns | Exceptions are actually 50% of requests |
Most organizations mix models. The mix evolves. What doesn’t change: blocking is not acceptable.
You already have internal platform teams
Evaluate against the three criteria. If any fail, you’re in transition (or should be).
Low adoption means the service isn’t good enough. Improve it dramatically or eliminate it. Mandating usage hides the problem, doesn’t fix it.
Blocking means you need to make aggressive investments in self-service (multi-year, primary focus). If you can’t make it non-blocking within 12 months, distribute the capability or eliminate the service.
Bad economics means you need to do the math honestly. Include coordination costs, queue costs, and migration burden on product teams. If the numbers don’t work, eliminate the service.
The one option that doesn’t exist: “Keep it because it provides value in ways we can’t measure.” If you can’t measure the value, it probably doesn’t exist.
How internal platform teams should operate
If you run an internal platform team, your only job is to be non-blocking. Focus on time-to-hello-world: how fast can a new team start using your service?
Self-service comes first. Every request that requires human intervention is a failure. Invest in self-service tooling before features, before improvements, before everything. Target 95%+ of requests automated.
Stability comes second. Every change you push to product teams creates a cost of delay for them. Minimize migrations, breaking changes, and forced upgrades. The best platform is one that teams forget exists.
Measure wait time (target: minimal), self-service percentage (target: 95%+), and change burden on product teams (target: decreasing). Don’t measure satisfaction; captive users normalize waiting.
Define a shutdown threshold. If wait time exceeds X days or self-service falls below Y%, distribute or eliminate the service. Without this threshold, you’ll keep a blocking service because “it provides value” (it doesn’t).
Summary
An internal platform only creates value when all three criteria are true:
| Criterion | Test | If it fails |
|---|---|---|
| Adoption | Teams use it voluntarily, not because mandated | Service is irrelevant; eliminate it |
| Non-blocking | 95%+ self-service, zero wait time | The cost of delay destroys any savings |
| Internal economics | Real, measurable cost savings | Service is a waste of money |
If anyone fails, fix it or eliminate the service.
The end state is simple: teams voluntarily use a non-blocking service that saves money. If you’re not there, you’re either transitioning toward it or wasting resources.
Sources
Platform Economics:
- Rochet, J.C. & Tirole, J. (2003). Platform Competition in Two-Sided Markets. Journal of the European Economic Association, 1(4), 990-1029.
- Parker, Van Alstyne & Choudary - Platform Revolution (2016)
- HBR - Pipelines, Platforms, and the New Rules of Strategy
Organization Design:
- Martin Fowler - How Platform Teams Get Stuff Done
- Conway, M. (1968). How Do Committees Invent? Datamation, 14(4), 28-31.
- Pragmatic Engineer - Profit Centers vs Cost Centers
- Jeremiah Lee - Failed Squad Goals (Spotify critique)