Skip to content
SkillPilotNavigate Your Career

Platform Engineer Roadmap

The path DevOps engineers move into — building an internal developer platform as a product, covering Kubernetes as substrate, IaC at scale, GitOps, golden paths, portals, policy, multi-tenancy and adoption.

Entry level
$105,062
Platform Engineer salary report, early career (1-2 years experience), United States
Mid level
$130,978
Platform Engineer salary report, mid-level (2-4 years experience), United States
Senior level
$165,664
Platform Engineer salary report, senior level (5-8 years experience), United States
Salary.com

This path assumes two or more years running production infrastructure. It is the move DevOps engineers make when the bottleneck stops being the pipeline and starts being everyone else's pipeline.

The shift is uncomfortable and it is the entire job: your users are engineers, and they can refuse you. An internal platform nobody adopts is not a platform, it is a side project with a Kubernetes bill. That is why adoption is a phase rather than an afterthought, and why the portal comes after the golden paths — a catalogue of services nobody wants to use is a directory.

Write code, not just YAML. Phase three onward assumes you can build a controller, not only configure one.

Expect 8–11 months. Phase two is the longest for a reason: everything above it fails in ways you have to be able to debug.

Your progress0%

The path, phase by phase

  1. Platform Thinking

    A platform is a product, and its customers are engineers who can ignore it. This phase is about naming that customer, learning what they actually struggle with, and deciding what you will not build. Done when you have interviewed at least five engineers outside your team and written a one-page platform charter naming your users, the three problems you will solve first, and what stays out of scope.

    3-4 weeks
    8 Skills
    Platform as a Product
    Internal Customer Discovery
    Cognitive Load Analysis
    Team Topologies
    Scope & Non-Goals
    Platform Charter Writing
    DORA Metrics
    Developer Experience Research
    Show details, projects and resources

    Skills you'll master

    Platform as a Productadvanced
    Internal Customer Discoveryadvanced
    Cognitive Load Analysisadvanced
    Team Topologiesintermediate
    Scope & Non-Goalsintermediate
    Platform Charter Writingintermediate
    DORA Metricsintermediate
    Developer Experience Researchadvanced

    Hands-on projects

    1. 01Interview five engineers from teams you do not sit with, and write down the top three things that slow them down in their words rather than yours
    2. 02Write a one-page platform charter naming your users, the first three problems you will solve, and an explicit list of things the platform will never do
    3. 03Map the full path from a developer's commit to production for one real service, timing each step — the waiting is usually longer than the working
    4. 04Measure your organisation's current DORA four keys from real data, not from a survey, and note which one you cannot compute yet
    5. 05Take one recurring support request your team answers by hand, and write down what it would cost to make it self-service instead
    6. 06Write the argument for why a platform team should exist here, in a form a director would forward — and include what it costs

  2. Kubernetes as a Substrate

    Most platforms sit on Kubernetes, and platform engineers are on the operating side of it, not the deploying side. Control planes, extension points, the reconciliation loop, and what breaks a cluster other teams depend on. Done when you have written a controller that reconciles a custom resource you defined, and can explain what happens to it when the API server is briefly unavailable.

    5-7 weeks
    9 Skills
    Kubernetes Control Plane Internals
    Custom Resource Definitions
    Controllers & Reconciliation Loops
    Operator Pattern
    Admission Control
    API Aggregation
    Cluster Lifecycle & Upgrades
    Scheduling & Node Management
    Helm & Kustomize
    Show details, projects and resources

    Skills you'll master

    Kubernetes Control Plane Internalsadvanced
    Custom Resource Definitionsadvanced
    Controllers & Reconciliation Loopsadvanced
    Operator Patternadvanced
    Admission Controladvanced
    API Aggregationintermediate
    Cluster Lifecycle & Upgradesadvanced
    Scheduling & Node Managementintermediate
    Helm & Kustomizeintermediate

    Hands-on projects

    1. 01Define a CRD for something your organisation provisions by hand, and write the controller that reconciles it
    2. 02Make your controller idempotent under repeated reconciliation, then prove it by deleting the underlying resource behind its back and watching it recover
    3. 03Upgrade a multi-node cluster across a minor version with workloads running, and record every deprecated API you had to fix first
    4. 04Write a validating admission webhook, then deliberately break it and document what happens to every deployment in the cluster
    5. 05Package one platform capability as a Helm chart with sane defaults, so a team gets a working install without reading the values file
    6. 06Compare a CRD against an aggregated API server for one use case, and write down why you chose the one you chose

  3. Infrastructure as Code at Scale

    Writing Terraform is not the skill; designing modules fifty teams consume without forking them is. Composition, versioning, state boundaries, and control planes that provision infrastructure from a Kubernetes API. Done when a team you did not help provisioned real infrastructure through a module or composition you published, using only its documented inputs.

    4-6 weeks
    8 Skills
    Module Design & Composition
    Terraform at Scale
    State & Blast Radius Boundaries
    Crossplane
    Abstraction API Design
    Module Versioning & Release
    Drift Detection & Reconciliation
    Infrastructure Testing
    Show details, projects and resources

    Skills you'll master

    Module Design & Compositionadvanced
    Terraform at Scaleadvanced
    State & Blast Radius Boundariesadvanced
    Crossplaneadvanced
    Abstraction API Designadvanced
    Module Versioning & Releaseintermediate
    Drift Detection & Reconciliationadvanced
    Infrastructure Testingintermediate

    Hands-on projects

    1. 01Publish a versioned module that provisions a complete service environment, then hand it to a team with nothing but its README and see what they ask you
    2. 02Split one monolithic state file into bounded states, and document what a mistake can now no longer destroy
    3. 03Build a Crossplane composition that exposes a single claim — "I need a database" — and hides the twelve resources behind it
    4. 04Design the abstraction API for one capability, deliberately leaving out an option people asked for, and write the reason you left it out
    5. 05Add automated tests to a module so a breaking change fails in CI rather than in a consumer's plan
    6. 06Detect and reconcile drift on a resource somebody changed by hand, and decide whether you revert it or adopt it

  4. CI/CD & GitOps Delivery

    Deployment becomes a property of a repository rather than a job someone runs. Pull-based reconciliation, environment promotion, secrets that never sit in Git, and rollbacks that are a revert. Done when a service deploys to production purely by merging to a branch, and you can point at the exact commit that produced what is running right now.

    4-6 weeks
    8 Skills
    GitOps Principles
    Argo CD or Flux
    Environment Promotion
    Progressive Delivery
    Secrets Management in GitOps
    Pipeline Design & Reuse
    Supply Chain Provenance
    Rollback & Drift Correction
    Show details, projects and resources

    Skills you'll master

    GitOps Principlesadvanced
    Argo CD or Fluxadvanced
    Environment Promotionadvanced
    Progressive Deliveryadvanced
    Secrets Management in GitOpsadvanced
    Pipeline Design & Reuseintermediate
    Supply Chain Provenanceintermediate
    Rollback & Drift Correctionadvanced

    Hands-on projects

    1. 01Put a real service under GitOps reconciliation so the cluster converges on the repository without anyone running a deploy command
    2. 02Change a live resource with kubectl and watch the reconciler revert it — then write down which changes you deliberately let stand
    3. 03Build environment promotion from staging to production as a pull request between directories or branches, with the diff readable by a reviewer
    4. 04Deliver secrets to workloads without any secret material in Git, using sealed secrets or an external secrets operator, and document the recovery path
    5. 05Set up a canary rollout that aborts on a metric threshold rather than on somebody watching a graph, and prove it by shipping a deliberately bad build
    6. 06Write the reusable pipeline template three teams adopt unchanged, and count how many of them changed it anyway

  5. Golden Paths & Scaffolding

    A golden path is the way of doing something that is so obviously easier that nobody argues. Templates, scaffolding, sane defaults, and a documented escape hatch for the team that genuinely needs to leave the path. Done when a new service was created from your template by someone you never spoke to, and reached production without a single exception request.

    3-4 weeks
    7 Skills
    Golden Path Design
    Service Scaffolding
    Opinionated Defaults
    Paved Road vs Escape Hatch
    Template Maintenance
    Documentation as Interface
    Time-to-First-Deploy
    Show details, projects and resources

    Skills you'll master

    Golden Path Designadvanced
    Service Scaffoldingadvanced
    Opinionated Defaultsadvanced
    Paved Road vs Escape Hatchadvanced
    Template Maintenanceintermediate
    Documentation as Interfaceintermediate
    Time-to-First-Deployadvanced

    Hands-on projects

    1. 01Build a service template that produces a repository, a pipeline, a dashboard and a deployed staging environment from one form submission
    2. 02Measure time from 'I need a new service' to a running staging deploy before and after your template, and publish both numbers
    3. 03Define the escape hatch: write exactly how a team leaves the golden path, what they take on by doing so, and who approves it
    4. 04Update a template after ten services were already generated from it, and solve the harder half — getting the change into the ten
    5. 05Watch someone use your template without helping them, note every point they hesitated, and fix the three worst
    6. 06Write the golden path documentation as the interface itself, so the happy path needs no conversation with your team

  6. Developer Portals & Service Catalogue

    The front door. A catalogue that answers who owns this, where its docs are and what it depends on — kept accurate because it is generated, not maintained by hand. Done when the catalogue answers an ownership question faster than asking in chat, and its entries update from code rather than from someone remembering to edit them.

    3-4 weeks
    7 Skills
    Backstage
    Service Catalogue Modelling
    Ownership Metadata
    Catalogue Auto-discovery
    TechDocs & Docs as Code
    Portal Plugin Development
    Portal Information Architecture
    Show details, projects and resources

    Skills you'll master

    Backstageadvanced
    Service Catalogue Modellingadvanced
    Ownership Metadataadvanced
    Catalogue Auto-discoveryadvanced
    TechDocs & Docs as Codeintermediate
    Portal Plugin Developmentintermediate
    Portal Information Architectureintermediate

    Hands-on projects

    1. 01Stand up a developer portal and populate its catalogue by auto-discovery from repositories, not by hand-written entries
    2. 02Model ownership so every service resolves to a team that still exists — the orphans you find are the real finding
    3. 03Publish service documentation from the same repository as the code, so a docs change ships in the same pull request as the change it describes
    4. 04Write a portal plugin surfacing one thing engineers currently look up elsewhere, then check whether they stopped going elsewhere
    5. 05Wire the catalogue into your scaffolding so a new service registers itself at creation and nobody has to remember
    6. 06Race the portal against your chat channel on an ownership question, and record which was faster

  7. Policy as Code & Guardrails

    Guardrails let people move fast without a review queue, and a guardrail engineers route around has made things worse than no guardrail. Admission policy, provisioning controls, and rejection messages that say how to comply. Done when a policy you wrote blocked a real non-compliant change, the author fixed it from the error message alone, and you can state its false-positive rate.

    3-4 weeks
    8 Skills
    Policy as Code
    Open Policy Agent & Rego
    Kyverno
    Admission Policy Rollout
    Audit vs Enforce Modes
    Actionable Policy Messages
    Exception Handling
    Compliance Evidence
    Show details, projects and resources

    Skills you'll master

    Policy as Codeadvanced
    Open Policy Agent & Regoadvanced
    Kyvernoadvanced
    Admission Policy Rolloutadvanced
    Audit vs Enforce Modesadvanced
    Actionable Policy Messagesintermediate
    Exception Handlingintermediate
    Compliance Evidenceintermediate

    Hands-on projects

    1. 01Write an admission policy that rejects workloads missing required ownership labels, and ship it in audit mode first
    2. 02Measure how much the policy would have blocked while in audit mode, then use that number to decide whether enforcement is safe
    3. 03Rewrite a policy rejection message so the author fixes the problem without contacting you — test it on someone who has never seen the policy
    4. 04Implement the same rule in both OPA and Kyverno, then write down which you would run in production here and why
    5. 05Build the exception process: how a team gets a documented, time-limited waiver instead of quietly working around you
    6. 06Generate compliance evidence automatically from policy results, so an audit question is a query rather than a fire drill

  8. Platform Observability

    You have to observe the platform itself, not just what runs on it. Platform SLOs, tenant-visible signals, and telemetry teams get by default instead of building each time. Done when you can state your platform's own SLO, report last month's compliance against it, and show that a tenant service got working dashboards and alerts without its team instrumenting anything by hand.

    4-5 weeks
    8 Skills
    Platform SLOs
    Observability as a Default
    OpenTelemetry Auto-instrumentation
    Multi-tenant Telemetry
    Dashboard Templating
    Telemetry Cost Control
    Platform Incident Response
    Golden Signals for Platforms
    Show details, projects and resources

    Skills you'll master

    Platform SLOsadvanced
    Observability as a Defaultadvanced
    OpenTelemetry Auto-instrumentationadvanced
    Multi-tenant Telemetryadvanced
    Dashboard Templatingintermediate
    Telemetry Cost Controlintermediate
    Platform Incident Responseadvanced
    Golden Signals for Platformsintermediate

    Hands-on projects

    1. 01Define and publish an SLO for one platform capability — deployment pipeline availability, provisioning latency — and report a month of compliance
    2. 02Make a new service arrive with dashboards and alerts already working, generated from its catalogue entry rather than from a copied JSON file
    3. 03Instrument the platform's own control loops, so you notice reconciliation falling behind before a tenant does
    4. 04Separate telemetry per tenant so one team's query load cannot degrade another team's dashboards, and prove it under load
    5. 05Write the platform incident runbook for the case where the platform is the outage — and note who tells fifty teams
    6. 06Cut platform telemetry spend without losing a signal you use, and write down the one you were tempted to drop and did not

  9. Multi-tenancy & Isolation

    Fifty teams on shared infrastructure, none of them able to hurt the others. Namespaces, quotas, network policy, node isolation, and the honest decision about where soft isolation stops being enough. Done when you have run a deliberate noisy-neighbour test — one tenant consuming everything it can — and shown the others kept meeting their SLOs throughout.

    4-5 weeks
    8 Skills
    Multi-tenancy Models
    Namespace & Tenant Boundaries
    Resource Quotas & Limits
    Network Policy
    RBAC Design at Scale
    Noisy Neighbour Mitigation
    Cluster Sharding Strategy
    Tenant Cost Attribution
    Show details, projects and resources

    Skills you'll master

    Multi-tenancy Modelsadvanced
    Namespace & Tenant Boundariesadvanced
    Resource Quotas & Limitsadvanced
    Network Policyadvanced
    RBAC Design at Scaleadvanced
    Noisy Neighbour Mitigationadvanced
    Cluster Sharding Strategyadvanced
    Tenant Cost Attributionintermediate

    Hands-on projects

    1. 01Run a noisy-neighbour test where one tenant consumes everything it is permitted to, and show the other tenants kept meeting their SLOs
    2. 02Design tenant onboarding as one automated action producing namespace, quota, RBAC and network policy together — never four tickets
    3. 03Apply default-deny network policy across a shared cluster, and document every legitimate flow you had to discover the hard way
    4. 04Write the decision record for shared cluster versus cluster-per-tenant here, with the cost of each and the trust assumption that decides it
    5. 05Set quotas from observed usage rather than from a round number, then track how often teams hit them and whether they were right to
    6. 06Attribute a shared cluster's cost down to tenant level, including idle capacity, and decide who pays for the slack

  10. Adoption & Platform as a Product

    The only phase that decides whether any of the previous nine mattered. Adoption you had to chaperone is a demo, not a platform. Done when a team you have never worked with adopted your platform end to end without you in the room, and you can report an adoption percentage, a satisfaction signal and a deprecation you completed on schedule.

    4-5 weeks
    8 Skills
    Adoption Measurement
    Platform Roadmapping
    Internal Developer Marketing
    Deprecation & Migration Management
    Developer Satisfaction Surveys
    Influence Without Authority
    Support Model & SLAs
    Platform Maturity Assessment
    Show details, projects and resources

    Skills you'll master

    Adoption Measurementadvanced
    Platform Roadmappingadvanced
    Internal Developer Marketingadvanced
    Deprecation & Migration Managementadvanced
    Developer Satisfaction Surveysintermediate
    Influence Without Authorityadvanced
    Support Model & SLAsintermediate
    Platform Maturity Assessmentadvanced

    Hands-on projects

    1. 01Publish an adoption metric — percentage of services on the golden path — and track it monthly after you stop actively promoting it
    2. 02Onboard a team you have never worked with using only your documentation, staying out of the room, and log every question they had to ask anyway
    3. 03Run a developer satisfaction survey, publish the results unedited including the bad ones, and change one roadmap item because of them
    4. 04Deprecate a platform capability on a published timeline and complete the migration, including the last three teams who ignored every notice
    5. 05Run a CNCF platform maturity assessment across the five aspects and turn the gaps into a prioritised six-month roadmap
    6. 06Write the platform's support model — what you respond to, how fast, and what teams own themselves — and hold to it for a quarter

What the job is actually like

Day to day
Product management with a terminal open. A normal week is talking to the engineers who use your platform about what is still painful, working out which of the ten requests are actually the same request, and building the paved road that makes the right thing the easy thing. There is real infrastructure work underneath — clusters, pipelines, policy — but the binding constraint is rarely technical. It is that you cannot force adoption, so anything harder than what teams already do simply goes unused. The uncomfortable part is that a successful week often produces nothing visible except other teams shipping faster.
The interview
A design round framed around users rather than throughput: design the deployment experience for fifty teams, with the follow-up always being what you would refuse to support. Kubernetes depth is assumed and probed, usually through a failure scenario rather than an architecture diagram. Expect a multi-tenancy question, because isolation is where internal platforms actually break. The round that surprises engineers is the product one — how do you know the platform is working, how do you handle a team that wants an exception, what do you deprecate and how. Answering entirely in technology is the usual way this interview goes wrong.
How people get in
Chiefly from the DevOps path, and that is the intended progression rather than a coincidence — the difference is building something teams choose to use instead of serving their tickets. Site reliability engineers arrive with the operational depth and have to develop the product instinct. Backend engineers with strong infrastructure interest are the third group, and they often have the best sense of what a developer actually wants because they were one recently. What does not transfer is the belief that a good tool sells itself, which is how internal platforms become expensive shelfware.
After senior
Principal platform engineer keeps the technical fork and widens into platform strategy across an organisation, close to the architecture path with a narrower and more concrete remit. Head of platform is a common and unusually early management step, because the role already involves roadmaps, users and prioritisation. A third route is developer experience as a discipline of its own, measured on the friction engineers feel rather than on the infrastructure beneath it. The vendor market for internal developer platforms also hires from here, and it hires the people who failed at adoption once and learned why.
Why people leave
Building a platform nobody uses is the failure that defines the discipline, and it almost always starts the same way — a team decides what engineers need without asking them, then treats low adoption as a training problem. The second is the abstraction that leaks under pressure: the platform hides Kubernetes right up until an incident, and then the user is debugging two systems instead of one. The third is a mandate without a product, where teams are ordered onto the platform, comply, and quietly build shadow tooling. If you cannot name your users and what they asked for last quarter, it is already drifting.

Frequently asked questions

Related certifications

Related roadmaps