Vocabulary for Platform Engineers

Platform engineering has emerged as one of the most important disciplines in modern software organisations. Platform teams build the internal tools, workflows, and infrastructure that enable product developers to ship faster and more reliably. The field has its own vocabulary — much of it borrowed from Team Topologies, DevOps, and developer experience (DevEx) practice.

This guide covers the essential terms you need to participate in platform engineering conversations and write clearly about platform work.

---

Core Concepts

Internal Developer Platform (IDP)

An Internal Developer Platform (IDP) is a self-service layer that abstracts away infrastructure complexity and allows developers to provision, deploy, and manage their applications without needing deep infrastructure knowledge.

“Our IDP lets developers spin up a new service in under ten minutes, including the CI/CD pipeline, monitoring, and database provisioning.”

“We’re building out the IDP incrementally — starting with deployment automation, then moving to self-service database creation.”

Note: IDP is sometimes confused with Internal Developer Portal (also IDP). The portal is the user interface for the platform; the platform is the broader set of capabilities.

Developer Portal

A developer portal is the web interface through which developers interact with the internal platform — discovering services, provisioning resources, reading documentation, and monitoring their applications.

“The developer portal centralises everything a developer needs: service catalog, runbooks, deployment status, and cost dashboards.”

“We use Backstage as the foundation for our developer portal.”

Self-Service

Self-service means developers can complete infrastructure and tooling tasks without opening a ticket or waiting for a platform team member to act manually.

“The goal of platform engineering is to make infrastructure self-service — developers should never need to ask us to provision a database.”

---

Paths and Standards

Golden Path

A golden path (sometimes called a paved road) is the opinionated, supported, and recommended way to build and deploy services within an organisation. It is not a mandate — but it is the path the platform team makes easiest to follow.

“Our golden path uses TypeScript, GitHub Actions, and PostgreSQL on RDS. Teams can deviate, but they own the maintenance of anything off the path.”

“We invest heavily in the golden path so that following best practices is the path of least resistance.”

Paved Road

Paved road is an alternative term for golden path, emphasising that the recommended approach is smooth and well-maintained:

“If you stay on the paved road, the platform handles observability, scaling, and security patching automatically.”

Service Catalog

A service catalog is a registry of all internal services — showing ownership, documentation, dependencies, and operational status.

“The service catalog shows that the payments service is owned by Team Bravo, runs on two instances, and has a 99.95% availability SLO.”

---

Team Topologies Vocabulary

Team Topologies is a widely-referenced book and framework for organising engineering teams. Its vocabulary has become common in platform engineering discussions.

Stream-Aligned Team

A stream-aligned team is focused on delivering value along a single product or user journey. Most product teams are stream-aligned.

“The checkout team is stream-aligned — they own the entire customer checkout experience end to end.”

Platform Team

A platform team provides internal services to stream-aligned teams to reduce their cognitive load.

“The platform team provides deployment tooling, observability stacks, and developer environments so that product teams don’t have to build these themselves.”

Enabling Team

An enabling team helps other teams adopt new capabilities or practices — coaching rather than doing.

“The security enabling team ran workshops to help product teams implement threat modelling in their design process.”

Cognitive Load

Cognitive load is the mental effort required to work effectively. Platform engineering aims to reduce the cognitive load on product teams.

“Every infrastructure decision a product developer has to make is cognitive load we’ve failed to absorb as a platform team.”

---

Developer Experience (DevEx)

Developer Experience (DevEx or DX)

Developer experience is the overall quality of the experience developers have when building, testing, deploying, and operating software within an organisation.

“We measure developer experience through quarterly surveys and track metrics like time-to-first-commit for new engineers.”

Shift Left

Shift left means moving a practice (typically testing or security) earlier in the development lifecycle.

“Our platform shifts security left by running SAST scans automatically on every pull request, rather than waiting for a security review before release.”

DORA Metrics

DORA metrics (from the DevOps Research and Assessment programme) are four key measures of software delivery performance:

• Deployment Frequency — how often you deploy to production
• Lead Time for Changes — time from code commit to production
• Change Failure Rate — percentage of deployments that cause incidents
• Time to Restore Service — how quickly you recover from failures

“We track DORA metrics quarterly. Our deployment frequency is now 12 times per day, up from twice per week before the platform investment.”

---

Practical Phrases for Platform Engineers

• “The goal of this feature is to reduce the cognitive load on stream-aligned teams.”
• “We’ve defined the golden path for deploying a new service — documentation is in the portal.”
• “Self-service database provisioning is available via the IDP — no ticket required.”
• “We’re measuring the impact of this change on DORA metrics.”
• “Teams that deviate from the paved road own the operational consequences of that decision.”

---

Platform engineering vocabulary is evolving quickly, but the terms above are stable enough to serve as a foundation. Using them precisely will help you write clearer design documents, speak credibly in architecture reviews, and communicate the value of platform work to leadership.

Navigating the Landscape – A Practical Approach to Platform Engineering

As we’ve discussed, the term “platform engineering” itself can feel a bit abstract. It’s not just about tools; it’s fundamentally about designing systems that empower developers. For non-native English speakers, this shift in mindset—from simply building things to architecting developer experiences—can be particularly challenging. Let’s unpack some of the key concepts and how they translate into practical scenarios, focusing on clarity and reducing potential ambiguity.

One core concept is the golden path, often described as a simplified, streamlined route for developers to access common functionality – think deploying a simple application or integrating with a specific service. It’s not about limiting choice, but rather providing a paved road—a well-defined, documented, and supported pathway that avoids unnecessary complexity. This contrasts sharply with the idea of a “snowflake” architecture where each developer builds their own isolated solution, creating a tangled mess of dependencies. The goal isn’t to force standardization, but to provide an efficient starting point for most common needs.

Consider a Slack message from a developer struggling with a new API: “This is so confusing! I don’t know how to integrate this into my workflow.” A response focusing purely on technical details – “You need to use the POST method with JSON data and handle error codes…” – will likely exacerbate the issue. Instead, a helpful engineer might respond with: “Let’s explore the golden path for integrating external services. We have a pre-built connector that simplifies this process and provides clear documentation. Let’s walk through it together.” This framing emphasizes the broader system design and available support rather than getting bogged down in low-level technicalities, acknowledging the developer’s potential frustration with unfamiliar terminology.

Another area where clarity is crucial is understanding Team Topologies. Recognizing that different teams operate best using various structures – from Streamlined to Nexus – can prevent miscommunication and duplicated effort. Framing it as “how teams work together” rather than a rigid set of rules allows for more flexible implementation and reduces the risk of feeling overwhelmed by complex organizational models. It’s about understanding the why behind the structure, not just memorizing the terminology.

# Example CLI Usage (Terraform) - Demonstrating Infrastructure as Code

terraform {
  required_providers {
    aws = { ~> 1.38 }
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "example" {
  ami           = "ubuntu/latest"
  instance_type = "t2.micro"

  tags = {
    Name = "MyExampleInstance"
  }
}

This simple Terraform example illustrates how a core platform engineering concept—Infrastructure as Code—is implemented. The use of ami, instance_type, and tags are all clearly defined terms within the context of managing cloud infrastructure, which is a common area for Platform Engineers to work on. The key takeaway here isn’t just the code itself, but how it contributes to a well-defined, automated process – aligning with the principle of a “paved road” for deploying and managing resources. Understanding these underlying concepts allows for more effective communication and collaboration within an engineering team.