Quick answer: Platform engineering is the discipline of designing and running an internal developer platform (IDP): a curated set of self-service tools, golden paths and infrastructure that lets product teams ship software without each team re-solving infrastructure, security and compliance. It is run as a product by a dedicated platform team, and it succeeds when it measurably reduces developer cognitive load and lead time while raising reliability.
Most large Australian engineering organisations now have something they call a platform team. Fewer have a platform. The difference matters in 2026-2027 because the two biggest forces on engineering budgets, AI-assisted development and cloud and AI cost control, both land on the platform. The 2025 DORA research found that AI tools amplify whatever is already there: teams with a quality internal platform convert AI speed into delivery, while teams without one convert it into instability.
This guide is for CTOs, heads of engineering, platform leads and architects at enterprise and government scale. It covers what platform engineering is, how it differs from DevOps and SRE, what belongs in an internal developer platform, how to size and fund the team, how to run the platform as a product, and how to prove it is working.
What is platform engineering?
Platform engineering is the practice of building and operating an internal developer platform that product teams consume as a service. Where DevOps asked every team to own its pipeline, infrastructure and operations, platform engineering recognises that at scale this produces hundreds of slightly different pipelines, inconsistent security controls and a cognitive load that slows everyone down.
The platform team's job is to turn the organisation's infrastructure, tooling and policy into paved roads ("golden paths") that are the easiest way to do the right thing. A team spinning up a new service should get a repository, CI/CD pipeline, Kubernetes namespace or serverless target, observability, secrets management, identity integration and the organisation's security baseline in minutes, by filling in a template rather than raising six tickets.
Three ideas underpin the discipline:
- Platform as a product. The platform has customers (internal developers), a backlog, a roadmap, adoption metrics and a product manager. It competes with the alternative of teams doing it themselves, so it has to be better, not mandated.
- Thinnest viable platform. Team Topologies (Skelton and Pais) coined the term: start with the smallest platform that lets stream-aligned teams move faster, often a wiki and a few templates, and grow only where demand proves it.
- Self-service with guardrails. Developers consume the platform without waiting on humans, and the guardrails (policy as code, approved modules, pre-wired security scanning) are built in rather than inspected afterwards.
Gartner's often-cited 2022 forecast was that 80% of large software engineering organisations would have platform engineering teams by 2026. Whether or not the figure was hit, the direction was right: platform engineering is now the default organisational answer to Kubernetes complexity, multi-cloud, and the compliance load that regulated industries carry.
Platform engineering vs DevOps vs SRE
These are not competing philosophies; they are different layers of the same system.
- Core idea — DevOps: Break the wall between dev and ops; teams own what they build · Site reliability engineering: Apply software engineering to operations; manage reliability with SLOs and error budgets · Platform engineering: Build an internal product that makes the DevOps way easy and consistent at scale
- Unit of ownership — DevOps: Each product team · Site reliability engineering: Reliability of services, often shared · Platform engineering: The platform and its golden paths
- Typical failure mode — DevOps: Every team re-invents tooling; "you build it, you run it" becomes "you build it, you drown in it" · Site reliability engineering: Becomes a renamed ops team · Platform engineering: Becomes an ivory-tower infrastructure team that nobody adopts
- What good looks like — DevOps: Fast feedback, small batches, shared accountability · Site reliability engineering: Error budgets drive prioritisation · Platform engineering: Developers choose the platform because it is the fastest path
A useful test: if your "DevOps team" is a central group that other teams raise tickets with, you already have a platform team, just one without a product mindset or a self-service interface. Platform engineering is what that team becomes when it stops being a queue.
What goes into an internal developer platform?
An internal developer platform is not one tool. It is a layered capability, and most enterprises assemble it from a mix of open source, cloud-native services and commercial products.
- Developer portal (the front door) — What it does: Service catalogue, software templates, documentation, scorecards, ownership · Common building blocks: Backstage (Spotify, now CNCF), Port, Cortex, Atlassian Compass
- Golden paths and templates — What it does: Scaffolds new services with pipeline, infra, observability and security pre-wired · Common building blocks: Cookiecutter-style templates, Backstage scaffolder, internal CLI
- CI/CD and delivery — What it does: Build, test, scan, deploy; progressive delivery · Common building blocks: GitHub Actions, GitLab, Buildkite, Argo CD, Flux
- Infrastructure orchestration — What it does: Turns an abstract "I need a Postgres and a queue" into environment-specific infra · Common building blocks: Terraform/OpenTofu modules, Crossplane, Humanitec-style platform orchestrators
- Runtime — What it does: Where workloads run · Common building blocks: Managed Kubernetes (EKS, AKS, GKE), serverless, PaaS
- Observability and operations — What it does: Logs, metrics, traces, SLOs, cost visibility by team · Common building blocks: OpenTelemetry, Datadog, Grafana, New Relic, cloud-native tooling
- Security and compliance — What it does: Identity, secrets, policy as code, supply-chain controls, Essential Eight alignment · Common building blocks: OIDC/workload identity, Vault, OPA/Kyverno, SBOM tooling
- Data and AI services (emerging) — What it does: Approved model gateways, vector stores, evaluation harnesses, AI usage and cost controls · Common building blocks: Cloud AI gateways, internal LLM proxies
The developer portal gets most of the attention because it is visible, but it is the least valuable layer on its own. A portal that catalogues services nobody can self-provision is a prettier ticket queue. Build the golden path end to end for one workload type first, then put the portal in front of it.
How big should a platform team be, and who is on it?
There is no formula, but there are reliable patterns from Australian enterprises and government agencies running platforms for 300 to 3,000 engineers:
- Ratio. Mature platforms tend to run somewhere between one platform engineer per 15 and one per 40 product engineers, depending on how much is bought versus built and how regulated the environment is. Below that ratio the platform becomes a bottleneck; above it, you are probably running infrastructure that a managed service could.
- Roles. A platform product manager (the single most under-hired role), platform engineers with infrastructure and software skills, an SRE or two for the platform's own reliability, a developer-experience or technical-writing function, and a security engineer embedded rather than consulted.
- Structure. Team Topologies' model fits most organisations: one or more platform teams, enabling teams that help product teams onboard, and stream-aligned product teams as the customers. Keep platform teams small and multiple (identity, delivery, runtime, data) rather than one 40-person group.
- Funding. Treat the platform as a run-and-change budget line owned by the CTO, not as cross-charged consulting. Cross-charging early kills adoption; show-back of consumption and cost per team is useful once adoption is real.
Running the platform as a product
The reason most platform efforts stall is not technology. It is that the platform team behaves like an infrastructure team: it builds what it finds interesting, mandates adoption through policy, and measures itself by features shipped.
Run it like a product instead:
- Discover before you build. Interview product teams. Map the end-to-end journey of "new service to production" and "incident to fix" and count the handoffs, waits and tickets. The biggest waits are your first golden path.
- Pick one workload type and go deep. A containerised API on Kubernetes with the organisation's standard observability and security baseline is the usual first path. Make it brilliant before adding a second.
- Make adoption voluntary and then make it obvious. If teams are not choosing the path, the path is not good enough. Mandate only the non-negotiables (identity, logging, supply-chain controls), and build them into the path so compliance is a side effect.
- Publish a roadmap and a changelog. Platform users need to plan around you. Deprecations with migration tooling, not emails.
- Staff a support rotation and measure it. Time-to-first-response and the top ten support topics are a product backlog in disguise.
- Treat documentation as a feature. Golden paths without a tutorial are not golden paths.
How do you measure platform engineering success?
Measure the platform the way you would measure any product: adoption, outcomes for customers and cost.
- Adoption: percentage of services on golden paths; weekly active developers in the portal; percentage of new services scaffolded from templates.
- Developer outcomes: lead time from commit to production and time to first deploy for a new service (the DORA metrics at team level); onboarding time for a new engineer; developer satisfaction and perceived cognitive load from a quarterly DevEx survey (the SPACE framework is a good structure).
- Reliability and risk: change failure rate and recovery time for services on versus off the platform; percentage of workloads meeting the security baseline automatically; audit findings closed by the platform rather than by each team.
- Cost: infrastructure cost per team and per service, visible to the teams that incur it; platform cost per supported engineer.
Two cautions. First, DORA's own 2024 research found that platform engineering was associated with higher individual and team productivity but, in some organisations, with lower throughput and stability, a sign of platforms that added process without removing friction. Measure the outcome, not the existence of the platform. Second, never set platform adoption as a target for product teams; it turns a product into a mandate and hides the signal that tells you the path is wrong.
Platform engineering in the age of AI coding assistants
Two shifts make the platform more important, not less, as AI coding assistants and coding agents spread through enterprise teams:
- The platform is where AI tooling is governed. Model access, data boundaries, licence management, usage and cost telemetry, and the review gates that catch AI-generated mistakes all belong in the platform rather than in each team's settings.
- Golden paths are what agents follow. A coding agent asked to "create a new service" will do whatever the repository and templates teach it. Well-maintained templates, conventions and documentation are now machine-readable instructions, and the DORA 2025 AI Capabilities Model lists quality internal platforms among the conditions under which AI investment pays off.
Platform teams that treat AI as another capability to productise (approved assistants, evaluation harnesses, prompt and context libraries, cost guardrails) are already seeing it drive adoption of the rest of the platform.
Common mistakes
- Buying a developer portal before building a golden path.
- Mandating the platform by policy instead of winning adoption.
- Running the platform as a project with an end date rather than a product with a budget.
- No product manager, so the roadmap is whatever engineers find interesting.
- Building what hyperscalers already sell as managed services.
- Measuring features shipped rather than lead time, reliability and developer satisfaction.
- Ignoring the brownfield: most value is in migrating the 300 existing services, not the 10 new ones.
Key takeaways
- Platform engineering is DevOps at enterprise scale: a platform team productises tooling and guardrails so product teams can ship safely without re-solving infrastructure.
- Build one golden path end to end before buying a developer portal; the portal is the front door, not the platform.
- Run it as a product with a product manager, a roadmap, voluntary adoption and a support rotation; mandate only non-negotiable controls and build them into the path.
- Size for roughly one platform engineer per 15-40 product engineers, in several small teams.
- Measure lead time, reliability, developer satisfaction and cost, not features shipped or adoption targets.
- AI coding assistants and agents make the platform the control point for governance, cost and the conventions agents follow.
Join your peers at the Clutch Engineering and DevOps Summits
Clutch Events runs free-to-attend, invite-curated, practitioner-led Engineering and DevOps summits for senior engineering, platform and DevOps leaders at Australian enterprises and government:
- Melbourne Engineering and DevOps Summit 2026 — 15 October 2026
- Sydney Engineering and DevOps Summit 2027 — 9 September 2027
- Melbourne Engineering and DevOps Summit 2027 — 7 October 2027
See all upcoming Clutch events · More guides on Clutch Events Insights