Advanced Vocabulary for Platform Engineering: IDP, Paved Road and More

Platform engineering has emerged as a discipline focused on building products for internal developers. If you work in or alongside a platform team — or if you want to discuss the field in English at a senior level — you need the specific vocabulary that practitioners use.

Internal Developer Platform (IDP)

An Internal Developer Platform (IDP) is the set of tools, workflows, and self-service capabilities that a platform team builds and maintains for application developers.

“The IDP abstracts away infrastructure complexity so developers can deploy without filing tickets.”

Key phrases:

• build an IDP — create the platform product
• the IDP surface — the user-facing interfaces and APIs of the platform
• IDP adoption — the degree to which developers use it
• embed the IDP into the developer workflow — integrate it with existing tools

IDP vs. PaaS

• An IDP is built in-house for a specific organisation’s needs.
• A PaaS (Platform as a Service) is a commercial product (e.g., Heroku, Fly.io).
• “Our IDP is built on top of Kubernetes but hides that complexity from application teams.”

The Paved Road

The paved road is the set of recommended, well-supported ways to build and deploy software within an organisation. It is metaphorically the smooth, maintained route that platform teams provide.

• “Follow the paved road and you get monitoring, alerting, and CI/CD out of the box.”
• “Teams can go off the paved road but must maintain their own tooling.”
• “The paved road reduces decision fatigue by providing sensible defaults.”

Related term: the Golden Path

Some organisations use golden path (from Spotify’s engineering culture) with the same meaning:

• “The golden path is the opinionated workflow the platform team recommends.”
• “We document the golden path so new engineers are productive from day one.”
• “A golden path is not mandatory — teams can diverge with justification.”

The distinction is subtle: “paved road” emphasises infrastructure and operations; “golden path” emphasises the developer journey and onboarding experience.

Self-Service Portal

A self-service portal (or developer portal) lets developers provision resources, view documentation, and manage their services without waiting for a platform team response.

Describing the portal

• “Developers can spin up a new service in under five minutes via the self-service portal.”
• “The portal exposes a catalogue of pre-approved infrastructure templates.”
• “We track portal adoption rates as a key platform engineering metric.”
• “The portal is backed by Backstage — the open-source developer portal framework.”

Common features to discuss

Cognitive Load Reduction

A central goal of platform engineering is reducing cognitive load — the mental effort required for developers to build and operate software.

Types of cognitive load (from the Team Topologies framework)

• Intrinsic cognitive load — the inherent complexity of the problem (unavoidable)
• Extraneous cognitive load — complexity imposed by tools and processes (reduceable)
• Germane cognitive load — effort that builds useful understanding (valuable)

Using these terms

• “The platform team’s job is to reduce extraneous cognitive load on stream-aligned teams.”
• “Our nine-step deployment process was adding unnecessary cognitive load — we automated it.”
• “By standardising the CI pipeline, we let developers focus on product logic.”

Stream-Aligned Teams and Platform Teams

These concepts come from Team Topologies (Skelton & Pais) and are widely used in platform engineering discussions:

• Stream-aligned team — a team aligned to a flow of user value (a product or service)
• Platform team — provides internal products that reduce stream-aligned team cognitive load
• Enabling team — helps other teams adopt new tools or practices
• Complicated subsystem team — owns a technically complex component

In conversation

• “The platform team serves the stream-aligned teams as internal customers.”
• “We measure platform success by how much toil we remove from product teams.”
• “The enabling team ran a guild on observability best practices.”

Measuring Platform Success

Platform teams need to discuss metrics in English:

• DORA metrics — Deployment Frequency, Lead Time, Change Failure Rate, MTTR
• “Our platform improved deployment frequency from weekly to daily across all stream teams.”
• “We reduced time to onboard a new service from two weeks to one day.”
• “Developer satisfaction (measured via NPS or quarterly surveys) is our north star metric.”

Key Takeaways

• IDP — the internal platform product built for developer self-service
• Paved road / golden path — the recommended, supported engineering path
• Self-service portal — the interface where developers access platform capabilities
• Cognitive load reduction — the primary value proposition of a platform team
• Stream-aligned vs. platform team — Team Topologies vocabulary for organisational structure
• DORA metrics — the standard measurement framework for platform impact

Navigating the Nuances: Common Misunderstandings & Clarifications

Many developers learning professional English, particularly those transitioning from languages with different phrasing conventions, find certain terms in platform engineering surprisingly complex. It’s not simply about knowing the definitions; it’s about how those terms are used – the subtle implications and expectations they convey within a DevOps culture. Let’s address some frequent stumbling blocks and offer practical guidance.

One area of confusion often centers around “paved road.” The phrase is frequently used to describe an Internal Developer Platform (IDP) that provides a streamlined, well-defined path for developers to deploy applications – essentially reducing friction and ambiguity. However, it’s not just about ease of use; it implies a level of stability, predictability, and governance. A “paved road” doesn’t mean developers are completely free from responsibility or can simply ignore best practices. Instead, it suggests the IDP provides the foundational tools and processes to support those best practices, minimizing manual intervention and reducing the risk of errors. Think of it like a well-maintained highway versus an unmapped dirt track – both get you to your destination, but one is significantly more reliable and efficient. This understanding is crucial when discussing with stakeholders; saying “we’re building a paved road” immediately communicates that you’re focusing on reliability and consistency, not just simple convenience.

Another frequent misunderstanding arises around the concept of “cognitive load reduction.” This isn’t about making things easier in a superficial way, but rather about strategically minimizing the mental effort required for developers to perform their core tasks. Consider a Slack message: “Hey team, can someone please provide the exact command to deploy this to staging? I’ve tried deploy --environment staging and it’s failing.” A developer struggling with that would be experiencing high cognitive load – they’re battling unfamiliar commands, troubleshooting errors, and potentially consulting multiple sources. An IDP designed for cognitive load reduction would offer a single, intuitive command, or perhaps even an automated deployment process triggered by a simple action, removing the need for developers to wrestle with complex configurations.

Finally, when describing an IDP’s capabilities in a Pull Request description, avoid overly technical jargon that might intimidate less experienced team members. Instead of saying “We’re leveraging declarative infrastructure-as-code via Terraform and implementing a custom policy engine,” try something more accessible: “This PR automates the deployment process for new features using our Internal Developer Platform, streamlining the workflow and reducing potential errors.”

# Example: Using kubectl to deploy a simple pod
kubectl apply -f my-pod.yaml

This command itself is straightforward, but the context – that it’s part of an automated deployment process managed by the IDP – is where the real value lies. Focusing on outcomes and benefits (reduced cognitive load, increased reliability) will resonate more effectively than simply listing the tools being used.