Last quarter, your company launched an internal platform with a portal, pipeline builder, and kickoff deck featuring “revolutionize all the things”. Six months later, developers still ask colleagues for databases, copy Terraform scripts from each other, and paste secrets manually. Everyone is busy, but progress is slower than expected.

This guide covers the 20% of platform engineering that delivers 80% of the work. You’ll leave with a ranked backlog from five interviews, a one-page team charter, a documented golden path, a three-bin governance sort, and a request-to-fulfillment metric. It ends with curated videos, podcasts, books, and online resources, including often-skipped business-strategy reading.

What You’ll Learn

  • What platform engineering is and how it differs from DevOps, SRE, and business strategy’s use of “platform.”
  • When to fund a platform team, and when a wiki page is enough.
  • How Team Topologies defines platform teams and their role in reducing cognitive load.
  • Define a minimal viable platform and create a golden path developers choose.
  • Where to draw the line between governance and freedom.
  • How to measure a platform and spot a team slipping into the Capability Immaturity Model.
  • The six reasons developer platforms fail, Suresh GP’s three anti-patterns (one about hiring and two about scope), and a fix for each.

Before You Start

Required. Authority (or an authorized sponsor) to interview engineers across teams, publish a team charter, and present one metric to leadership. At least three product teams share the same infrastructure backlog.

Not required. Kubernetes, Backstage, or any specific tool. Every move in this guide works with a wiki page and a spreadsheet.

The Basics

Platform engineering builds and runs an internal developer platform: curated self-service capabilities that help product teams ship software. It provides shared plumbing—pipelines, environments, databases, observability, and identity—that teams would otherwise rebuild. Microsoft’s guide describes it as a practice “built up from DevOps principles,” aiming to improve “security, compliance, costs, and time-to-business value through improved developer experiences and self-service within a secure, governed framework” (What is platform engineering?).

The difference from DevOps is who does the work. DevOps asks every team to build and run its own software. Platform engineering preserves that ownership while adding a dedicated team to package shared components as a product. The Cloud Native Computing Foundation (CNCF) describes this as “an explicit form” of the cooperation DevOps promised (CNCF Platforms White Paper). The white paper states the motivation plainly: process improvements over the past two decades have shifted increasing infrastructure responsibility to product teams, and platforms aim to give them that time back.

Site reliability engineering (SRE) is another term often confused with these two. Suresh GP’s talk on platform engineering anti-patterns distinguishes them, but the slide deck is unpublished; his profile is the closest public reference.

SRE ensures system reliability and performance; DevOps improves collaboration and delivery; platform engineering maintains the infrastructure supporting both.

Suresh GP’s third anti-pattern is a platform that “caters differently” to DevOps and SRE with separate tools and paths. One platform should serve both.

In business strategy, a “platform" can mean a two-sided market that grows through network effects (Strategies for Two-Sided Markets). Both types depend on others choosing to build on them. Steve Yegge’s 2011 Google and Amazon rant offers the same golden rule for both: “eat your own dogfood” (Stevey’s Google Platforms Rant)."”

Primary Use Cases

  • An organization where each product team manages its own deployment scripts, cloud accounts, and monitoring.
  • A compliance-heavy environment where security, data handling, and cost controls are built in from the outset rather than audited after the fact.
  • A company whose engineers focus more on infrastructure than the product they were hired to build.

Less Suitable Use Cases

  • With twelve people, a shared README on “how we provision things” is the platform; a dedicated team would cost more than it saves.
  • An organization unable to fund a permanent team keeps its platform at the lowest maturity level; volunteer hack-week staffing leaves it to decay between bursts of attention (Platform Engineering Maturity Model).
  • One-product company with a working deployment path. Solve the next bottleneck.

When to Use Platform Engineering

Start a platform team when three or more product teams repeatedly face the same undifferentiated work and leadership will fund it as a product, not a cost center. Microsoft cites an undated Gartner forecast that around 80 percent of engineering organizations would have a dedicated platform team by 2026. It also notes that teams under 20 people can support thousands of developers (What is platform engineering?).

A platform team is worthwhile only if it reduces users’ work; a layer they must learn and work around adds to it.

The 20% That Does 80%

Treat the Platform as a Product

Manuel Pais, co-author of Team Topologies, says a platform’s first goal “should be to reduce cognitive load on the stream-aligned teams." The platform team is also stream-aligned, with internal customers (How Team Topologies Supports Platform Engineering). So, interview users, publish a roadmap, prioritize capabilities most teams need over those demanded by the loudest team, and remove unused features.

The CNCF white paper lists attributes of product thinking (CNCF Platforms White Paper).:

  • Consistent experience across CLI, API, and portal.
  • Documentation and onboarding.
  • Self-service with no ticket in the loop.
  • Reduced cognitive load.
  • Optional and composable.
  • Secure by default.

Microsoft’s four principles overlap with CNCF’s list and add asset inventories: prioritize each customer, adopt a product mindset, enable self-service, and manage assets through inventories (Platform engineering guide).

Product thinking also shapes hiring. Suresh GP’s first anti-pattern is staffing platform teams based solely on technical skills. An unattributed survey in his slides ranks a product manager’s key contributions: strategic thinking, translating strategy into plans, cross-team collaboration, prioritization, and interpreting qualitative data (Anti Patterns of Platform Engineering).

The survey found 58% of platform teams belong to infrastructure or DevOps groups, while 40% have direct leadership representation. Without a product owner or leadership seat, teams build what interests them.

The move. Before building, interview five developers from different teams for 30 minutes each. Ask how they last obtained a database, test environment, or production service, and how long each step took. Record the steps and delays; rank your backlog by how many teams faced each obstacle.

What you get. Recurring waits, ranked by how many teams reported them. The top wait is your first capability.

Lower Cognitive Load With the Right Team Shape

Team Topologies names four team types and three interaction modes (Team Topologies):

  • Stream-aligned teams own a slice of the product end to end.
  • Enabling teams teach a skill and step back.
  • Complicated-subsystem teams own something that needs deep specialists.
  • Platform teams provide internal services others consume with minimal coordination.
graph TB S1[Stream-aligned team: checkout] -->|self-service, X-as-a-Service| P[Platform team: internal developer platform] S2[Stream-aligned team: search] -->|self-service, X-as-a-Service| P E[Enabling team: security] -.->|teaches, then steps back| S1 E -.->|teaches, then steps back| S2 P -->|thin layer over| C[Cloud providers and managed services]

Pais warns that a platform can become “a bucket for everything, and just becomes a huge mess with lack of ownership, lack of focus and a lot of waste” (How Team Topologies Supports Platform Engineering). In medium or large organizations, platforms comprise teams that each own a cohesive service, such as infrastructure or data services, through consistent interfaces, allowing them to evolve independently.

Suresh GP calls a platform that “includes everything you need in future” his second anti-pattern. His scope survey shows where practitioners draw the line: about two-thirds include services for app teams to build, deploy, and run, infrastructure provisioning, and workflow automation. Cost and resource management ranks last: fewer than half include it, while 13 percent say it should not be (Anti Patterns of Platform Engineering). Your charter’s “refuses to own” list starts at the chart’s bottom.

The move. Write a one-page platform team charter naming its customers, three owned capabilities, and what it refuses to own. Review quarterly. An empty “refuses” list signals the bucket problem has begun.

What you get. A charter short enough to read in two minutes, with a “refuses to own” list that has at least one entry.

Start With the Thinnest Viable Platform

Microsoft’s guide promotes the thinnest viable platform as the starting point: a minimum viable product for your platform that you build on feedback (What is platform engineering?). Pais is blunter: at a startup, “the platform might just be some sort of Wiki page” that explains how to create a database the recommended way (How Team Topologies Supports Platform Engineering). The CNCF adds that platform teams should rely on managed providers and internal infrastructure teams for implementation and own the interfaces: the portal, the API, the template, and the docs (CNCF Platforms White Paper).

Suresh GP presents twelve options as a “self-service buffet,” from policy as code to KPI automation (Anti Patterns of Platform Engineering). Choose one, not all twelve.”

The move. Pick one capability that came up in every interview, usually getting a new service into production. Document the recommended path from start to finish, including every click and command. Automate only the slowest step. Ship it, then time an engineer from another team who has never used the path. A new hire is ideal, but a volunteer from the interviews works too.

What you get. Document one new engineer’s path and time to production: record when they request the path and when the service goes live. These timestamps provide the first data point for the Measure section’s metric.

Pave Golden Paths, and Keep Them Optional

Spotify coined “Golden Path” for “the opinionated and supported path to build something,” with tutorials for each engineering discipline that new hires are encouraged to complete within two weeks (How We Use Golden Paths). Microsoft’s “paved path” metaphor describes trails paved as more people use them, maintaining velocity while guiding developers through security and compliance (What is platform engineering?).

Three lessons from Spotify matter more than the metaphor: tutorials should mirror the actual path, and if it’s too long, shorten the path—not the tutorial. Engineers can leave the path, “but then you will not have the same support.” Every new hire tests the tutorials, driving ongoing platform fixes (How We Use Golden Paths).

Yegge’s rule applies: if the platform team bypasses its own golden path, others will too (Stevey’s Google Platforms Rant).

The move. Create a golden path repository and fill in one path first:

golden-paths/
  backend-service/
    README.md          # the opinionated path, every step, in order
    template/          # scaffold a new service from here
    checks.yml         # what "on the path" means, machine-checkable
  CONTRIBUTING.md      # how a product team proposes a change to the path

Keep checks.yml small and literal. Each entry names one testable requirement for a service on the path:

# checks.yml: one entry per thing a service on the path must have
template-version-file: .golden-path-version
deploy-pipeline: shared/deploy.yml
health-endpoint: /healthz

Choose any script-readable format. Make “on the path” objective: first check your platform’s services, and ensure they all pass before asking a product team to run it.

What you get. An afternoon path for new engineers, with a scaffold for a deployable service. Checks evolve into Spotify’s “Golden State” idea, showing which systems follow the path and which have drifted (How We Use Golden Paths).

Draw the Line Between Governance and Freedom

Matt Cobby’s “gravity well” model guides what a platform standardizes: capabilities an organization depends on more are standardized and slower to change.

Cobby divides capabilities at a “value line.” Capabilities above it drive revenue and need room to move quickly. Those below it, such as Kubernetes, pipelines, and cloud accounts, must be delivered well at the lowest unit cost; no one benefits from every team implementing them differently. Exceptions include high-risk areas like data and security, where “solid, tested, and certified” components should be available on demand (Can You Have Both Governance and Freedom in Developer Experience?).

Cobby’s tool for distributed decisions is a brief set of engineering principles, not a standards document. A good principle’s opposite must be nonsense. Examples include “build differentiators, buy commodity” and “end-to-end ownership,” each paired with an intent statement to help engineers make trade-offs without consulting an architect (Can You Have Both Governance and Freedom in Developer Experience?).

The move. Sort platform capabilities into three bins: deep in the well (standardize, one way), above the value line (recommend, allow alternatives), and high-risk (certified components required). Publish the classifications and debate them openly before a release gate does it for you.

What you get. A published list showing which capabilities have a defined or recommended approach, and which require certified components.

Measure the Platform, and Watch for Immaturity

The CNCF white paper groups platform metrics into three buckets (CNCF Platforms White Paper):

  • User satisfaction and productivity: active users, retention, and survey scores.
  • Organizational efficiency: request-to-fulfillment latency, time to deploy a service, and time for new users to ship their first change.
  • Product delivery: the four DORA metrics from Google’s DevOps Research and Assessment program.

Start with request-to-fulfillment latency: it’s cheap to measure and developers feel it.

The CNCF’s maturity model then describes five aspects (investment, adoption, interfaces, operations, measurement) across four levels. Adoption is the aspect to watch:

Provisional: erratic Teams find tools through rumors and chance conversations; each team maintains its own deploy scripts.
Operational: extrinsic push Mandates and incentives drive use. Teams with unmet needs can’t extend the platform, so they work around it.
Scalable: intrinsic pull Teams choose the easiest platform, then check it first after a good experience.
Optimizing: participatory Product teams contribute fixes and capabilities; platform engineers join product planning.

The authors caution that higher maturity levels require more funding and staff time, so reaching the top “should not be a goal in itself” (Platform Engineering Maturity Model).

Maturity models have a built-in trap. Carnegie Mellon’s Capability Maturity Model Integration (CMMI) rates organizations from level 1 to 5 (Capability Maturity Model Integration). The parody beside it, the Capability Immaturity Model, is more useful for platform teams. It ranges from level zero to minus three (Capability Immaturity Model):

  • Negligent (level 0): lip service and fanfare with no follow-through.
  • Obstructive (minus one): process followed with rigor while the product is incidental.
  • Contemptuous (minus two): fudged metrics and activity counted instead of outcomes.
  • Undermining (minus three): sabotaging the teams that are improving.

A platform team that counts “pipelines created” while developers copy YAML around it is at level minus two. A platform team that mandates adoption and blocks releases to meet a usage target is at level minus one. The CNCF model’s “extrinsic push” level is the polite name for the same place.

The move. Track one metric: median time from “I need X” to “I have X” for your top capability. Take the first from the original ticket, chat, or form; take the second from the engineer’s confirmation that it works. Publish monthly. If the time rises, the platform is adding load, not removing it.

What you get. One number on a wall, tracked monthly. Start with a timed walk on the thinnest viable platform section; establish the median as more teams use the path. Any later rise signals a need to interview again.

If a Move Stalls

  • No shared wall in the interviews. Stop. The platform team’s leverage isn’t there yet; a wiki page is the right platform for now.
  • No funding for a durable team. Ship the wiki-page platform from the thinnest viable platform section, and bring the wall metric to the next budget review.
  • A team wants a refused capability. Refer to the charter’s “refuses to own” list and next quarterly review. Add the capability only if at least three teams report the same wait.
  • The governance sort deadlocks. Put the disputed capability in the “recommend, allow alternatives” bin; revisit after one month of metrics.
  • Nobody walks the golden path. Check whether the platform team uses it for its services, then retest with a new engineer.

Beware of These Potential Failures

InfraCloud’s six platform engineering failure causes each map to a fix above (How to Fail at Platform Engineering).:

  • Product misfit. Developers weren’t involved, so the platform solves problems they don’t have. Fix: interview them.
  • Overly complex design. Too many options, nonstandard configuration languages, and a steep learning curve. Fix: the thinnest viable platform.
  • Swiss knife syndrome. A platform that integrates with everything but does none well. Fix: the charter’s “refuses to own” list.
  • Insufficient documentation. Developers ask colleagues instead of reading docs, piling up support tickets. Fix: a golden-path tutorial that stays on track.
  • Siloed development. Platform and product teams rarely share work. Fix: shared channels, a published roadmap, and product team contributions.
  • Stagnant platform. Teams drift away when tool versions lag and features stall. Fix: set a roadmap and track a monthly metric..

InfraCloud cites the 2023 State of Platform Engineering report, where 32 percent said poor team communication causes platform failure (How to Fail at Platform Engineering). Four of six failures are communication problems disguised as technical ones: misfit, missing docs, silos, and an unshared platform roadmap.

Suresh GP’s three anti-patterns concern team and scope, mapping the same way (Anti Patterns of Platform Engineering).:

  • Hiring for technical skills alone. No product manager, strategy, or prioritization. Fix: appoint the product owner from the first section.
  • A platform that includes everything you will ever need. Fix the charter and the survey’s bottom rows.
  • Separate platform paths for DevOps and SRE. One infrastructure, one toolset: make reliability and delivery teams customers of the same platform, not separate toolchains.

His closing slide lists five areas covered above: developer productivity, collaboration and standardization, automation, security and compliance, and self-service.

Learn Platform Engineering: Beyond the Basics

You have the essentials: product mindset, team structure, a minimal viable platform, golden paths, governance, one honest metric, and six failure modes. Watch the Team Topologies video, read the CNCF white paper, then choose one book on leadership and one on strategy.x

Video

Audio and Podcasts

  • Platform Engineering Podcast, interviews with the people running internal platforms at large companies.
  • Ship It! on Changelog, a podcast about shipping software and the platforms that make it possible. The show ended in December 2024 after 135 episodes; the archive is still online.
  • Team topologies: Organizing teams for fast flow on the Scandinavian Product Podcast, an interview with Manuel Pais on team shapes, cognitive load, and platform teams.

Books

Online

References

Related Content