Modern Platform Engineering: Golden Paths, Not Gates

Here's my definition. A platform is something that lets other parties integrate with it, is extensible, and includes at least one killer app or API. Without apps, you don't have a platform. You just have some code.

The CNCF's Platforms White Paper says it more formally: "an integrated collection of capabilities defined and presented according to the needs of the platform's users." Team Topologies, the book that gave the field its vocabulary, calls it "a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product." Every definition I've seen lands on the word product.

A portal is not a platform. An internal developer platform (IDP) is the whole layer: CI/CD, environments, infrastructure, secrets, monitoring, templates, and the docs and support around them. A developer portal (Backstage, Port, Cortex) is one UI on top of that—a catalog and a front door. Installing Backstage doesn't give you a platform any more than buying a cash register gives you a store. Spotify's own leadership has said adoption inside Spotify is around 99% while a lot of outside adopters get stuck around 10%. What's different is everything behind the portal.

The job is cognitive load. Team Topologies borrows three kinds from learning science. Intrinsic is the basics of the work—your language, your domain—and you handle that with hiring and training. Germane is the actual business problem, which is where you want people's brain cycles going. Extraneous is the environment: how do I deploy, where are the secrets, which of the seven wikis is current. That's what the platform is for. Netflix's "Paved Road" team has a hard rule about it—a tool only makes the paved road if it reduces overall cognitive load for the majority of Netflix engineers.

The platform has one job: reduce cognitive load. Standards, control, and the Kubernetes migration are side effects at best. Every feature gets one question—does this let a product engineer think less about infrastructure and more about the customer?

Spotify coined "golden path" in 2020 after years of squad autonomy left them with what they called rumour-driven development—the only way to learn how to do something was to find a coworker who'd done it. A golden path is the opinionated, supported way to build a given kind of thing: a backend service, a web app, a data pipeline. Spotify's stated reason was so teams "don't have to reinvent the wheel and have fewer decisions to make." Not to limit anyone.

That distinction is the whole game. Here's how I tell a path from a gate:

You can't mandate adoption. You have to compete for it. Your platform is competing with "I'll just write my own GitHub Actions workflow." That option has no onboarding, no ticket queue, and the developer already knows how it works. To win, the golden path has to be faster for the developer on day one—not just better for the org on a slide. Humanitec surveyed 300+ platform teams in 2024 and the most common adoption plan was "build it and they will come" (37%), then mandates (17%). Both lose to the developer's own workflow.

Start with the thinnest viable platform. Team Topologies calls the smallest set of APIs, docs, and tools that speeds teams up the Thinnest Viable Platform. Their example: a TVP "could be just a wiki page" that says which cloud services to use and how. The CNCF says the same thing—build the thinnest layer over managed services.

In practice, your first golden path is the one thing every team does and every team does differently. At 8x8 that was "get a service from a laptop to Kubernetes." Once we built the tooling and the path, a new hire could deploy a microservice to production in about 20 minutes their first week, following a recorded session on the onboarding site. That one path did more for adoption than any mandate could have.

Now the part nobody puts on a slide. That same DORA 2024 data found platform users had 8% lower change throughput and 14% lower change stability. DORA's read is the J-curve every transformation goes through: early wins, then a dip while teams migrate and the platform matures, then recovery. If you don't budget for the dip, the platform gets cancelled in month nine. I've watched it happen.

DORA also found "developer independence"—people getting things done without filing a ticket with the platform team—was worth another 5% in productivity. If your platform just swapped one ticket queue for another, you renamed the queue.

And then there's AI. DORA's 2025 report, all about AI-assisted development, found a direct link between good internal platforms and an org's ability to get anything out of AI tools. Their line: AI doesn't fix a team—it amplifies what's already there. "Quality internal platforms" is one of the seven capabilities in their AI model. If your deploy process is tribal knowledge, AI-generated code just reaches the tribal knowledge faster.

Building a platform isn't just about APIs or abstractions. It's about enabling others to move faster, with consistency and confidence. I've done this at scale. Here's how I approach it, in order.

1. Get the right people in the room early. You can't build a successful platform in a vacuum. Engage stakeholders from engineering, product, security, compliance, support—everyone who either builds on the platform or depends on it. Transparency isn't optional. Participation drives buy-in. At 8x8 the first thing I did was get everyone involved into a weekly cadence. I used the allegory of the cave to show where we were and where we wanted to be (the outside world). Every week we'd hash out request and response styles, date formats, response times. Not glamorous. But if you want people to care about the platform, let them shape it.

2. Set the vision. Clarify what you're trying to achieve. "We want to enable X so that Y becomes easier, faster, cheaper, or more secure." A strong vision grounds every decision after it. Without one, you're just building tools—and tools with no vision turn into the seven wikis you were trying to replace.

3. Anchor in the value proposition. Why does this matter? For the business? For developers? Be specific. Reduce time-to-market. Improve reliability. Simplify onboarding. Enforce consistency. Accelerate compliance. Pick the two that matter most and say them out loud. If your platform doesn't solve real pain, it's just overhead.

4. Audit first, not last. Before writing new code, take inventory of what exists. Map systems, services, ownership, dependencies, and known pain points. Then stack-rank by business impact and technical importance. Start where you can win early.

5. Listen to friction. Feedback is gold, even when it's noisy. Complaints often mask legitimate patterns. Find the root cause, not just the loudest voice. Every "this sucks" is a potential platform feature waiting to be discovered. At 8x8 the teams who worked closest with our API customers—the ones everybody thought of as the hackers of the company—had more insight into integrating with our products than anyone else by a long shot. They were our underdog champions and we learned a lot from them. Find yours.

6. Write it down: standards, not secrets. Don't wait for perfection. Document the platform's intended usage, service standards, API contracts, lifecycle guarantees. People can't adopt what they don't understand. The best way to find the right answer? Publish a wrong one and listen.

7. Use it yourself. The best platforms are battle-tested in-house before being scaled outward. Build your own app on it—something that shows what the platform can do and solves a problem people have. Internal usage reveals blind spots, rough edges, and missing features. You earn credibility by dogfooding. Solve for yourself as if you were a third party, with the leverage a first party has.

8. Measure and iterate relentlessly. Track adoption, usage, support tickets, deployment times, onboarding effort, and DX satisfaction. Measure against two pillars: Vision (are we enabling what we set out to?) and Value (is it actually making life better?). Developer experience should never be a secondary concern. It's a core feature.

Almost 30% of platform teams in Humanitec's 2024 survey don't measure their success at all. That's how platforms get cancelled—nobody can prove they're working.

Beyond that, I track two kinds of numbers. Adoption and health: the percentage of services on a golden path (and the trend month over month), weekly active users per team, the teams that left the path and why (talk to every one of them), support tickets per 100 developers going down, and platform satisfaction from your DevEx survey. Outcomes: time to first deploy for a new service, time to first merged change for a new hire, DORA metrics for teams on the path vs. off it, change stability during the migration (watch for the dip), and security findings per service on-path vs. off-path.

If you want to know where you stand, the CNCF Platform Engineering Maturity Model scores five things (investment, adoption, interfaces, operations, measurement) on four levels: Provisional (ad hoc, a couple of heroes and a wiki), Operationalized (a dedicated team, requests come in as tickets), Scalable (platform as a product, with feedback loops and self-service), and Optimizing (extended by the people who use it). Most of the platforms I've been brought in to help with are stuck somewhere between two and three. Aim for three.

"If you build it, they will come." The platform team ships a beautiful portal and waits. Six months later adoption is 12% and the CFO has questions. If you build it, they won't come. You have to tell them about it, over and over, everywhere. Chat, all-hands, onboarding, tech talks in every office. The onus of communication is on the communicator. Treat the launch like a product launch with champions on real teams, because that's what it is.

Swinging the hammer. "Everyone's on the new platform by Q3, or else." Teams comply on paper and route around it in practice. Getting buy-in was crucial at 8x8. I knew I couldn't just go in swinging a hammer saying "we're doing this, or else!"—that simply wouldn't work. It's much easier, and more fun, to get people involved and be part of the process. You need a strong opinion, but you can't be dogmatic or have a big ego if you need to change course. Pulling in 17 different directions gets you nowhere.

Confusing the portal with the platform. Backstage is installed. The catalog has 400 entries. Nobody deploys any faster than before. Build one golden path end to end—template to production with monitoring attached—and then put a portal on it.

No product owner. The infra team "owns" the platform as a side job. Nobody talks to users. The roadmap is whatever broke last week. Only 38% of platform teams in Humanitec's survey had real funding and clear responsibilities. Give the platform a product manager, user interviews, and a roadmap people can see. Roadie's 2025 survey of Backstage adopters found understaffed rollouts were the most common way they fail.

Building the whole thing before anyone uses any of it. An 18-month roadmap covering all 13 CNCF capability areas before the first team is onboarded. Thinnest viable platform instead. One path, one killer app your own team built on it, one metric (0 to 200) that gets better. Then the next path.

Panicking at the dip. Throughput drops during the migration, leadership reads it as failure, and the platform loses its budget right before it pays off. Show leadership DORA's J-curve before you start and tell them a dip is coming. Track the leading numbers (time to first deploy, satisfaction) that improve before the lagging ones (throughput, stability) recover.

This month, inventory every way a service currently gets to production and count the variants—that number is your pitch. Time "0 to 200" for a new service and a new hire, by hand, with a stopwatch, and write down every wait. Get engineering, security, and product in a weekly room and agree on the vision sentence and the two value props.

Next month, pick the most common service type and build the template, CI, deploy, and monitoring for it, end to end. Build one real first-party service on it yourselves and fix everything that hurt. Write the doc, publish the standard, and record a 20-minute laptop-to-production walkthrough.

Month three, onboard two or three volunteer teams (your underdog champions). Sit with them. Watch where they get stuck. Re-time 0 to 200 and publish the before and after to the whole org. Then open up the roadmap and let the loudest legitimate pattern in the feedback pick the next path.

Platforms are about people. Code is the medium, but trust, consistency, and experience are what make it usable. You won't get everything right the first time—and that's okay. Just keep shipping value, listening hard, and building for others like you'd want them to build for you.

And if you're somewhere between "we installed Backstage" and "our engineers actually like this"—drop me a note. I've been there.

-Matt