Platform Adoption Language: English for Internal Platform Teams

Internal platform teams face a communication challenge that external product teams rarely encounter: their customers are other engineers, who are often sceptical, opinionated, and capable of building their own solutions if the platform does not meet their needs. Getting engineers to adopt a platform requires more than good technology — it requires compelling communication, clear documentation, and a language that respects developer autonomy while demonstrating the value of the platform’s guardrails and defaults. This guide covers the key vocabulary and phrases for platform adoption communication.

Key Vocabulary

Golden path The recommended, well-supported way to accomplish a common task on the platform — the path that comes with the most tooling, documentation, and team support.

“The golden path for deploying a new service is to use the platform’s service template — it includes CI/CD, observability, and secret management out of the box.”

Dogfooding The practice of the platform team using their own platform for their own services — validating the developer experience firsthand and demonstrating confidence in what they are asking others to adopt.

“We dogfood the deployment platform for all our own services. If it’s painful for us, we fix it before rolling it out to other teams.”

Developer experience (DX) The overall quality of the experience a developer has when using a tool, platform, or API — including documentation quality, error messages, setup time, and cognitive load.

“Our Q1 DX survey showed that the biggest pain point was the time to first successful deployment for new engineers — the golden path reduced this from three days to four hours.”

Platform champion A developer on a product team who has adopted the platform and advocates for it internally — a bridge between the platform team and other engineers.

“We’ve identified platform champions in six product teams. They get early access to new features and a direct line to the platform team for escalations.”

Onboarding The process of getting a new team or engineer up and running on the platform — includes documentation, guided setup, and first-use support.

“We’ve redesigned the onboarding flow so that a new team can deploy their first service within two hours of reading the getting-started guide.”

Migration support Assistance provided to teams who are moving from an older or ad-hoc solution to the platform — including migration tooling, documentation, office hours, and paired sessions.

“We’re offering migration support for the next quarter — any team migrating from the old deployment system can book a paired session with the platform team.”

Paved road A metaphor similar to golden path — the routes through the platform that are well-maintained and have sensible defaults, contrasted with “off-road” usage that is technically possible but unsupported.

“The paved road handles 95% of our use cases. Teams that go off-road can — but they own the maintenance of that path themselves.”

Useful Phrases

Introducing a platform capability:

“We’re rolling out the new secrets management system across all services this quarter. The golden path is already documented — most teams can migrate in under a day. I’ll walk you through the key steps and what’s different from the current setup.”

Communicating the value proposition:

“The reason we’re pushing teams towards the shared observability stack isn’t to add bureaucracy — it’s so that when you have an incident, you’re looking at the same dashboards as the on-call engineer, the SRE, and the product manager. Shared context makes incidents shorter.”

Requesting feedback via DX survey:

“We’re running our quarterly developer experience survey this week. It takes about five minutes and directly shapes the platform roadmap. Last quarter’s survey is why we simplified the local development setup — we want to hear what’s still painful.”

Acknowledging limitations honestly:

“The current job scheduling system doesn’t support distributed tracing yet. That’s on our roadmap for Q3. If this is blocking you, we have a workaround documented in the platform wiki, and I’m happy to walk through it with you.”

Supporting a migration:

“We know migrating the deployment pipeline is not zero-cost engineering work, and we want to make it as easy as possible. We’ve built a migration script that handles 80% of cases automatically. For the remaining 20%, we’re offering pairing sessions every Tuesday — book a slot and we’ll work through it together.”

Common Mistakes

Mandating instead of demonstrating Platform teams that say “all teams must migrate to the new system by Q3” without demonstrating the value often encounter resistance and workarounds. English has a more effective register for platform adoption: “We’ve seen teams that have migrated spend 40% less time on deployment-related incidents. We’d love to help you get there too.” Persuasion through demonstrated value is more durable than mandates.

Using “just” to minimise migration effort “You just need to update your deployment config and it should work” underestimates effort and sets a frustrating expectation for the engineer doing the work. Replace “just” with a more honest framing: “The migration involves three steps. For most services it takes about half a day — here’s what the process looks like.”

Failing to close the feedback loop When platform teams run DX surveys and never publicly acknowledge what they heard or what they changed as a result, engineers stop responding. Closing the loop builds trust: “Based on your feedback last quarter, we rebuilt the CLI error messages — they now include the specific fix rather than a generic error code. Thank you to everyone who flagged this.”

The most successful internal platforms are adopted because they make engineers’ lives better — and communicating that value clearly and honestly is as much a part of platform engineering as the technology itself.