Quick Navigation
- Start here — What a platform is
- Why platform thinking matters now
- The platform team model
- Designing for adoption
- What makes a good platform
- Platform governance
- The journey from projects to platforms
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
As organisations scale, every team rebuilding the same foundation — CI/CD, observability, deployment, authentication, data access — becomes wasteful. But centralising everything creates a bottleneck. Platform thinking is the third path: build a shared foundation that teams consume as a product. I've seen "platform initiatives" that were just centralised teams doing work for other teams. That's not a platform. That's a bottleneck with a different name.
Platform thinking is the shift from building one-off solutions to building reusable internal platforms — shared foundations that allow teams to build and deliver independently without solving the same problems repeatedly.
Platforms are internal products. They're built for developer experience, not just function. A platform no one uses is worse than no platform — adoption is a design problem, not a mandate problem. Platform teams must treat internal teams as customers.
Keep it in mind.
1. What a platform is — And how it differs from a shared service or a framework
"Platform" is used loosely — sometimes for a shared service, sometimes for a framework, sometimes for a centralised team. Without a clear definition, organisations build things they call platforms but that function as bottlenecks.
A platform is distinct from related concepts:
flowchart TD
PLATFORM["📦 Platform"] --> DIFF_SS["vs Shared Service\nShared service: request and wait\nPlatform: self-service and go"]
PLATFORM --> DIFF_FW["vs Framework\nFramework: code you import\nPlatform: infrastructure you consume"]
PLATFORM --> DIFF_CENT["vs Centralised Team\nCentralised: they do the work\nPlatform: you do the work\nwith their foundation"]
DIFF_SS --> CLEAR["✅ Platform =\nSelf-service foundation\nTeams consume independently\nNo requesting, no waiting"]
DIFF_FW --> CLEAR
DIFF_CENT --> CLEAR
The platform test — is it really a platform?
| Question | If yes | If no |
|---|---|---|
| Can teams use it without asking permission? | Platform | Shared service |
| Can teams provision and configure it themselves? | Platform | Centralised team |
| Do teams choose to use it because it's better? | Platform | Mandated tool |
| Does the platform team measure adoption? | Platform | IT project |
Platform components: Infrastructure — compute, storage, networking. Kubernetes clusters, managed databases. CI/CD — build, test, deploy pipelines. Pipeline templates, deployment automation. Observability — logging, metrics, tracing. Centralised logging, dashboards. Security — identity, encryption, secrets. IAM, secrets management. Data — data access, storage, processing. Data catalogue, streaming connectors. Developer tools — templates, documentation, golden paths. Service templates, API scaffolding.
Platform maturity levels: L0: Documented — wiki pages with instructions. Teams follow instructions manually. L1: Scripted — scripts and automation. Teams run scripts. L2: Self-service — UI/API for provisioning. Teams provision themselves. L3: Golden paths — opinionated defaults, one-click. Teams follow the path. L4: Invisible — platform is the default. Teams don't think about it.
A platform = self-service, no permission needed, teams choose it because it's better — if you have to ask, it's not a platform.
Try it yourself — The platform test
Take something your organisation calls a "platform." Run it through the test:
| Question | Your answer |
|---|---|
| Can teams use it without asking permission? | |
| Can teams provision and configure it themselves? | |
| Do teams choose to use it because it's better? | |
| Does the platform team measure adoption? |
If you answered "no" to two or more, it's not a platform. It's a shared service or a centralised team.
2. Why platform thinking matters now — The scale problem it solves
At small scale, every team building their own CI/CD, monitoring, and deployment is manageable. At scale — 10, 20, 50 teams — it becomes wasteful, inconsistent, and a security risk. Platform thinking solves the scale problem.
The cost of not having a platform grows with team count:
flowchart TD
SCALE["📈 Scale"] --> SMALL["<5 Teams\nEvery team builds own\nManageable duplication"]
SCALE --> MEDIUM["5-15 Teams\nDuplication becoming painful\nInconsistency growing"]
SCALE --> LARGE["15+ Teams\nDuplication unsustainable\nPlatform is essential"]
SMALL --> COST_S["Cost: Low\nTolerable"]
MEDIUM --> COST_M["Cost: Growing\nVelocity declining"]
LARGE --> COST_L["Cost: Critical\nWithout platform, delivery stalls"]
What platform thinking solves:
| Problem | Without platform | With platform |
|---|---|---|
| Duplication | Every team builds their own CI/CD | One platform, all teams consume |
| Inconsistency | Every team deploys differently | Consistent deployment patterns |
| Onboarding | New team members learn each team's setup | One platform, faster onboarding |
| Security | Every team configures security differently | Security built into the platform |
| Speed | Teams spend 30% on infrastructure | Teams spend 5% — rest on features |
The platform ROI model: Without platform — 15 teams × 2 days/month on infrastructure = 30 engineer-days/month. Cost: £45K/month in wasted capacity. With platform — platform team: 5 engineers = £50K/month. Teams: 0.5 days/month on platform = 7.5 engineer-days/month. Cost: £50K + £11K = £61K/month. Initially, the platform costs more. But after platform maturation (6 months): teams spend 0.2 days/month = 3 engineer-days/month. Cost: £50K + £4.5K = £54.5K/month. After platform maturity (12 months): teams spend 0.1 days/month = 1.5 engineer-days/month. Cost: £50K + £2K = £52K/month. The ROI isn't just cost savings — it's velocity, consistency, and risk reduction.
At scale, the cost of not having a platform exceeds the cost of building one — platform thinking solves the scale problem.
Try it yourself — The scale check
How many teams do you have? How much time do they spend on infrastructure?
| Metric | Your number |
|---|---|
| Number of teams | |
| % of time spent on infrastructure | |
| Number of different CI/CD setups | |
| Onboarding time for new team members |
If you have more than 5 teams and they're spending more than 20% on infrastructure, you need platform thinking.
3. The platform team model — Ownership, funding, and accountability
Platform teams fail when they're funded as projects, measured by features delivered, or treated as a cost centre. They succeed when they're funded continuously, measured by adoption, and treated as a product team.
The platform team model is different from a project team:
flowchart TD
TEAM["👥 Platform Team"] --> FUND["💰 Funding\nContinuous, not temporary\nBudget, not project"]
TEAM --> MEASURE["📊 Measurement\nAdoption, not features\nSatisfaction, not tickets"]
TEAM --> OWN["🎯 Ownership\nEnd-to-end\nBuild, run, evolve"]
FUND --> PRODUCT["✅ Product Team\nNot a project team"]
MEASURE --> PRODUCT
OWN --> PRODUCT
Platform team success factors:
| Factor | What it means |
|---|---|
| Continuous funding | Funded like a product — ongoing, not project-based |
| Adoption metrics | Measured by adoption rate and developer satisfaction |
| Product management | Has a product manager who understands developer needs |
| Self-service focus | Builds self-service, not ticket-based services |
| Clear scope | Owns the platform — not every team's infrastructure |
| Feedback loops | Regularly collects and acts on developer feedback |
Platform team structure: Product manager — what to build: developer needs, roadmap, prioritisation. Platform engineers — build and maintain: infrastructure, tooling, automation. Developer experience — documentation, onboarding, support. SRE — reliability, monitoring, incident response.
Platform team anti-patterns: Ticket team — teams submit tickets; platform team fulfils. Fix: build self-service instead. Feature factory — measured by features shipped. Fix: measure by adoption. Ivory tower — builds what they think teams need. Fix: talk to teams; collect feedback. Cost centre — funded as overhead. Fix: fund as product investment. Scope creep — owns everything infrastructure. Fix: define clear boundaries.
Fund platform teams continuously, measure by adoption, treat as a product team — not a project team.
Try it yourself — The team check
How is your platform team funded and measured?
| Factor | Current state | Should be |
|---|---|---|
| Funding model | Continuous | |
| Success metrics | Adoption, satisfaction | |
| Product management | Dedicated PM | |
| Service model | Self-service |
If your platform team is funded as a project or measured by features shipped, you're setting them up to fail.
4. Designing for adoption — Internal developer experience as a product problem
The biggest risk of platform thinking is building a platform nobody uses. Teams will route around a platform that's slow, confusing, or frustrating — just as customers route around a bad product.
Adoption must be designed, not mandated:
flowchart TD
PLATFORM_D["📦 Platform"] --> MANDATE["❌ Mandate\n'You must use this'\nTeams comply reluctantly\nLow quality, resentment"]
PLATFORM_D --> ATTRACT["✅ Attract\n'This is better'\nTeams choose to use it\nHigh quality, satisfaction"]
MANDATE --> FAIL["Platform fails\nAdoption is compliance\nnot choice"]
ATTRACT --> SUCCEED["Platform succeeds\nAdoption is voluntary\nbecause it is better"]
What makes teams adopt a platform:
| Factor | Impact |
|---|---|
| It saves time | Teams adopt what makes them faster |
| It reduces risk | Teams adopt what prevents known failures |
| It is easy to consume | Teams adopt what requires minimal effort |
| It is well-supported | Teams adopt what has someone to call when it breaks |
| It is not mandated | Teams adopt what they choose, not what is forced |
The adoption measurement framework:
| Metric | What it measures | Target |
|---|---|---|
| Adoption rate | % of teams using the platform | >80% |
| Self-service rate | % of requests handled without help | >90% |
| Time to first deploy | How fast a new team can deploy on the platform | <1 hour |
| Developer satisfaction | Do developers find the platform helpful? | >70% positive |
| Net Promoter Score | Would developers recommend the platform? | >30 |
The golden path approach: Instead of providing options and expecting teams to choose correctly, provide one opinionated path that works. "Here's how to deploy a new service: 1. Clone the template repository. 2. Run make init. 3. Write your code. 4. Run make deploy. No decisions needed. No configuration to figure out. It just works."
Teams can deviate from the golden path — but 80% shouldn't need to.
Adoption is designed, not mandated — if teams have to be forced to use it, it's not a platform.
Try it yourself — The adoption check
Why do teams use (or not use) your platform?
| Factor | Present? | Evidence |
|---|---|---|
| It saves time | ||
| It reduces risk | ||
| It's easy to consume | ||
| It's well-supported | ||
| It's not mandated |
If fewer than three are present, adoption will be a struggle.
5. What makes a good platform — Self-service, opinionated defaults, and clear boundaries
Bad platforms share common traits — they require tickets, they offer too many options, and they have unclear boundaries. Good platforms share different traits — they're self-service, opinionated, and bounded.
Three characteristics define a good platform:
flowchart TD
GOOD["⭐ Good Platform"] --> SELF["🚀 Self-Service\nTeams provision\nand configure\nwithout asking"]
GOOD --> OPINION["💡 Opinionated Defaults\nSensible choices\nthat work out of the box"]
GOOD --> BOUNDARY["🚧 Clear Boundaries\nPlatform provides foundation\nTeams own application"]
SELF --> RESULT["✅ Teams love it\nAdoption is high\nVelocity increases"]
OPINION --> RESULT
BOUNDARY --> RESULT
The platform quality checklist: Self-service — teams don't need to ask permission or submit tickets. Opinionated defaults — the default choice works for 80% of use cases. Clear boundaries — platform provides foundation; teams own application logic. Documented — getting started takes <1 hour, not days. Observable — teams can see what the platform is doing for them. Supported — when it breaks, someone responds quickly.
The opinionated defaults spectrum: Fully opinionated — one way to do everything. "Use this template, deploy to this cluster." Opinionated with escape hatches — defaults that can be overridden. "Default is PostgreSQL; override if you have a reason." Guided options — curated choices. "Choose from these 3 databases." Open choice — teams decide everything. "Use whatever you want."
Good platforms are opinionated with escape hatches — defaults work for 80%, overrides available for the 20%.
The boundary definition: Platform owns — CI/CD infrastructure, Kubernetes clusters, logging infrastructure, IAM and security baseline, data platform infrastructure, API gateway. Teams own — application code, service deployment, application logs, application-level security, domain data and queries, API implementation.
Good platforms = self-service + opinionated + bounded — teams don't need to think about the platform, they just use it.
Try it yourself — The quality check
Rate your platform on each characteristic:
| Characteristic | Present? | Evidence |
|---|---|---|
| Self-service | ||
| Opinionated defaults | ||
| Clear boundaries | ||
| Documented (<1 hour to start) | ||
| Observable | ||
| Supported |
If fewer than four are present, your platform needs work.
6. Platform governance — How to avoid platforms becoming bottlenecks
Platforms can become the very bottleneck they were designed to eliminate — if the platform team becomes a gatekeeper, if every change requires their approval, or if the platform evolves too slowly.
Platform governance must balance coherence with speed:
flowchart TD
GOVERN["🏛️ Platform Governance"] --> AVOID["❌ Avoid\nPlatform as gatekeeper\nEvery change needs approval\nEvolves too slowly"]
GOVERN --> ENABLE["✅ Enable\nPlatform as enabler\nTeams move fast\nPlatform evolves with needs"]
AVOID --> BOTTLENECK["Bottleneck\nTeams route around\nthe platform"]
ENABLE --> ADOPTED["Adopted\nTeams choose\nthe platform"]
Platform governance principles: No gatekeeping — teams don't need platform team approval to use the platform. Fast evolution — platform evolves based on team feedback — not on annual planning. Automated compliance — standards enforced by the platform, not by review. Transparent roadmap — teams know what's coming and can plan accordingly. Feedback loops — regular mechanisms for teams to influence platform direction.
Platform governance mechanisms: Platform roadmap — communicates what's planned — teams can plan around it. RFC process — teams propose changes to the platform — collaborative evolution. Office hours — regular time for teams to ask questions and give feedback. Adoption dashboard — transparent view of who is using what. Deprecation policy — clear process for retiring platform capabilities.
Platform governance = enable, don't gatekeep — if teams need approval to use the platform, it's already a bottleneck.
Try it yourself — The bottleneck check
Is your platform a bottleneck?
| Question | Your answer |
|---|---|
| Do teams need approval to use the platform? | |
| How fast does the platform evolve? | |
| Are standards enforced by the platform or by review? | |
| Is the roadmap transparent? | |
| Are there feedback loops? |
If the answer to the first question is "yes," you have a bottleneck, not a platform.
7. The journey from projects to platforms — How organisations make the shift
The shift from project-based delivery to platform-based delivery doesn't happen overnight. It requires a deliberate, staged journey — starting with the pain, building the foundation, and growing adoption organically.
The platform journey has four stages:
flowchart LR
PAIN["🔴 Pain\nEvery team rebuilding\nthe same foundation"] --> EXTRACT["📦 Extract\nIdentify shared capabilities\nBuild first platform"]
EXTRACT --> ADOPT_P["📈 Adopt\nTeams consume platform\nGrow adoption organically"]
ADOPT_P --> MATURE["✅ Mature\nSelf-service platform\nTeams don't think about it"]
The staged journey:
| Stage | Focus | Duration | Key activity |
|---|---|---|---|
| 1. Pain identification | What are teams rebuilding? | 1-2 weeks | Interview teams, map duplication |
| 2. Capability extraction | Build the first shared capability | 2-3 months | Start with the most painful one |
| 3. Organic adoption | Teams choose to use it | 3-6 months | Make it better than the alternative |
| 4. Platform maturity | Self-service, golden paths | 6-12 months | Product management, feedback loops |
The anti-pattern — big bang platform: Don't build a "platform" for 12 months and then announce it. Build one capability, get adoption, then build the next. Incremental delivery, incremental adoption.
The first platform capability — what to start with: High pain — is every team struggling with this? Clear value — can teams see the benefit immediately? Bounded scope — can it be built in 2-3 months? Visible — do teams interact with it frequently?
Common first capabilities: CI/CD pipeline templates. Service deployment automation. Observability (logging + metrics). Secrets management. Environment provisioning.
Start with pain, build one capability, get adoption, then expand — don't big-bang a platform.
Try it yourself — The journey check
Where is your organisation on the platform journey?
| Stage | Evidence | Ready for next? |
|---|---|---|
| Pain identification | ||
| Capability extraction | ||
| Organic adoption | ||
| Platform maturity |
If you're trying to jump to maturity without going through the earlier stages, you're setting yourself up for failure.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
PROBLEM["📈 Scale Problem\nEvery team rebuilding\nthe same foundation"] --> THINK["💡 Platform Thinking\nShared foundation\nconsumed as a product"]
THINK --> TEAM_P["👥 Platform Team\nFunded continuously\nMeasured by adoption"]
THINK --> DESIGN_P["🎯 Design for Adoption\nSelf-service · Opinionated\nBounded · Golden paths"]
THINK --> JOURNEY_P["🛤️ Journey\nPain → Extract → Adopt → Mature\nIncremental, not big-bang"]
TEAM_P --> VALUE["✅ Value\nTeams deliver faster\nConsistency · Security\nNo bottlenecks"]
DESIGN_P --> VALUE
JOURNEY_P --> VALUE
The foundation:
Platforms are internal products with internal customers. If teams hate using it, it's not a platform. Adoption is a design problem, not a mandate problem. Fund platform teams continuously, measure by adoption. Not by features shipped, not by tickets closed. Adoption rate and developer satisfaction are the metrics. Start with pain, build one capability, get adoption, then expand. Don't big-bang a platform. Incremental delivery, incremental adoption. A platform no one uses is worse than no platform. Make it better than the alternative, and teams will choose it.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Platform | Self-service foundation consumed as product | If you have to ask, it's not a platform |
| vs Shared service | Platform = self-service; shared service = request | Build self-service, not tickets |
| Platform team | Product team, not project team | Fund continuously, measure adoption |
| Adoption | Designed, not mandated | Make it better than the alternative |
| Good platform | Self-service + opinionated + bounded | Golden paths for 80% |
| Governance | Enable, don't gatekeep | No approval needed to use |
| Journey | Pain → Extract → Adopt → Mature | Start small, grow organically |
How to know if this landed
You'll know this has landed when someone stops building one-off solutions and starts asking "can this be a platform capability?" Can explain the difference between a platform, a shared service, and a framework. Platform team is funded continuously, not as a project. Adoption rate is measured — target >80% of teams. Self-service rate is measured — target >90% without tickets. Developer satisfaction is measured — target >70% positive. Platform has golden paths — opinionated defaults that work out of the box. And platform journey is incremental — not big-bang.
What changes when the mental model clicks
I've run this session with an e-commerce company with 20 engineering teams — each with their own CI/CD, monitoring, and deployment setup. New team members took 2 weeks to onboard to each team's unique setup. Security review overwhelmed — every team's infrastructure configured differently. Previous "platform initiative" had failed — 12-month big-bang project that nobody adopted. The gap at the start is usually not about understanding platforms — it's about not treating them as products.
What changes after this session:
Teams stop building one-off solutions and start asking "can this be a platform capability?" The pain identification exercise — "what are teams rebuilding?" — is always the moment things click. People stop treating platforms as mandates and start treating them as products. Their results get better. They stop building platforms nobody uses when the real problem was that they didn't design for adoption.
The golden path exercise tends to immediately change how teams think about their platform design. They start providing opinionated defaults with escape hatches. Their adoption rates go up. They stop offering 20 options when the real problem was that teams just wanted something that works.
Book a Workshop
Ready to build a platform that teams choose to use?
or
1-day workshop includes pain identification — map what your teams are rebuilding independently, platform scoping — define what the platform should provide, first capability selection — choose the highest-pain, highest-visibility starting point, golden path design — create an opinionated default for your context, adoption strategy — design for voluntary adoption, not mandate, platform team design — structure, funding, and measurement, and platform strategy canvas + internal platform design guide + shared capability register.