Skip to content
Menu

Career ladder template

DevOps engineer career ladder template

Four levels from Junior to Staff DevOps Engineer, across six competencies from infrastructure to developer enablement.

Free plan · No credit card required

This career ladder is for DevOps, platform and infrastructure engineers in companies of roughly 20 to 200 people. At that size the infrastructure team is usually one to six people who run the cloud accounts, the delivery pipelines, monitoring and on-call, and who spend as much time helping developers as touching servers. It describes four levels, from someone making well-scoped infrastructure changes to the person who owns the company's platform direction. Its top level, Staff DevOps Engineer, is an individual-contributor level; managing the infrastructure team is a separate job.

Each level is defined by what a person does and how much of the system they are trusted with, not by years of experience or the number of tools on their CV. Read a row of the competency matrix from left to right to see how one expectation grows; read a level's section to see everything expected at that level. Use it to explain what the next level means, to structure check-ins, and to make promotion decisions you can defend.

Adapt it before you publish it. Replace the generic wording with your own stack and practices, and drop the parts that belong to another team — for example, if security or databases are owned elsewhere.

The levels at a glance

  1. Junior DevOps Engineer

    Makes well-scoped changes to infrastructure and pipelines with review and learns how production runs.

    Scope
    Individual changes in existing infrastructure code and pipelines, planned and reviewed by someone more experienced.
  2. DevOps Engineer

    Owns parts of the infrastructure end to end and takes a full share of on-call.

    Scope
    Services, environments or pipelines for one or two product teams, from design to day-to-day operation.
  3. Senior DevOps Engineer

    Designs and leads infrastructure projects that several teams depend on, and raises the reliability bar.

    Scope
    Shared infrastructure used by most of engineering, and projects such as migrations that touch every team.
  4. Staff DevOps Engineer

    Sets the direction of the company's platform and answers for its reliability, security and cost.

    Scope
    The whole production platform, its multi-year direction and its budget, across all engineering teams.

Competency matrix

Each row is a competency and each column a level. Read a row from left to right to see how the expectation grows.

What each competency means

Infrastructure as code
Building and changing infrastructure through reviewed, repeatable code rather than by hand.
Build and delivery pipelines
Getting code from a merged pull request to production quickly and safely.
Reliability and incident response
Keeping production available and recovering quickly when it is not.
Monitoring and observability
Making it possible to see what production is doing and to know when it is going wrong.
Security and access
Protecting systems and data through secure defaults, least privilege and fast patching.
Developer enablement and collaboration
Helping developers run their own services and sharing knowledge so the platform does not depend on one person.
DevOps Engineer: expectations by competency and level
CompetencyJunior DevOps EngineerDevOps EngineerSenior DevOps EngineerStaff DevOps Engineer
Infrastructure as codeMakes changes to existing infrastructure code by following the patterns already in place, checks the planned diff before applying it, and never changes production by hand without asking first.Writes reusable infrastructure modules for new services and environments, keeps state and secrets handled safely, and removes resources that are no longer used.Designs the layout of the company's infrastructure code and environments, leads changes such as network or cluster upgrades with a tested rollback plan, and keeps cloud spending visible per team.Chooses the platform's core building blocks and providers for the next few years, sets the standards every team's infrastructure follows, and owns the infrastructure budget with leadership.
Build and delivery pipelinesFixes broken pipeline steps and adds simple jobs to existing pipelines, and explains to a developer why their build failed.Builds and maintains the full pipeline for a service — build, tests, artefacts, deploys to every environment — and shortens slow steps that developers complain about.Designs shared pipeline templates every team uses, introduces safer release methods such as canary or blue-green deploys, and tracks deployment frequency and failure rate.Defines how the whole company ships software, from branching to rollback, and removes the bottlenecks that slow delivery across all teams.
Reliability and incident responseShadows on-call, follows runbooks for known alerts, and escalates quickly with the information the next person needs.Takes a full share of on-call, resolves most incidents in their area without help, writes runbooks for what they fixed, and tests backups by actually restoring them.Leads response to major incidents, runs blameless post-mortems and sees follow-up actions through, and plans capacity and failover for critical systems.Sets reliability targets with product and leadership, designs the on-call and incident process for all of engineering, and plans for disasters such as losing a region or a provider.
Monitoring and observabilityAdds dashboards and alerts by following existing examples, and checks the logs and metrics first when something looks wrong.Sets up logging, metrics and alerts for new services, tunes alerts so that every page needs action, and helps developers find what they need in the data.Designs the observability approach for the company's main systems, defines the service health signals teams are measured on, and cuts alert noise across teams.Chooses the company's observability tooling and its cost model, and makes sure leadership can see the health of the platform without asking an engineer.
Security and accessFollows the team's rules for secrets and access, applies routine patches, and reports anything that looks like a security problem straight away.Manages access and secrets for their services with least privilege, patches vulnerabilities by their severity, and fixes the findings from security scans.Designs network boundaries, identity and secrets management across the platform, prepares evidence for customer security reviews, and leads the response to security incidents.Owns the platform's security posture together with leadership, sets the controls compliance requires (for example, SOC 2 or ISO 27001), and makes the secure path the easiest one for every team.
Developer enablement and collaborationAnswers developers' questions about environments and pipelines, documents the fixes they make, and asks for review early.Writes clear guides for common tasks, pairs with developers on deploying and debugging their services, and onboards new teammates to the infrastructure.Builds self-service tooling that lets teams create services and environments without filing a ticket, mentors other DevOps engineers, and takes part in hiring.Shapes the platform as an internal product with developers as its users, decides what teams own versus what the platform team owns, and grows the next senior engineers.

Scroll the table sideways to see every level.

Download as CSV Opens in Excel, Google Sheets or Numbers.

Junior DevOps Engineer: what is expected

Makes well-scoped changes to infrastructure and pipelines with review and learns how production runs. Individual changes in existing infrastructure code and pipelines, planned and reviewed by someone more experienced.

Infrastructure as code
Makes changes to existing infrastructure code by following the patterns already in place, checks the planned diff before applying it, and never changes production by hand without asking first.
Build and delivery pipelines
Fixes broken pipeline steps and adds simple jobs to existing pipelines, and explains to a developer why their build failed.
Reliability and incident response
Shadows on-call, follows runbooks for known alerts, and escalates quickly with the information the next person needs.
Monitoring and observability
Adds dashboards and alerts by following existing examples, and checks the logs and metrics first when something looks wrong.
Security and access
Follows the team's rules for secrets and access, applies routine patches, and reports anything that looks like a security problem straight away.
Developer enablement and collaboration
Answers developers' questions about environments and pipelines, documents the fixes they make, and asks for review early.

DevOps Engineer: what is expected

Owns parts of the infrastructure end to end and takes a full share of on-call. Services, environments or pipelines for one or two product teams, from design to day-to-day operation.

Infrastructure as code
Writes reusable infrastructure modules for new services and environments, keeps state and secrets handled safely, and removes resources that are no longer used.
Build and delivery pipelines
Builds and maintains the full pipeline for a service — build, tests, artefacts, deploys to every environment — and shortens slow steps that developers complain about.
Reliability and incident response
Takes a full share of on-call, resolves most incidents in their area without help, writes runbooks for what they fixed, and tests backups by actually restoring them.
Monitoring and observability
Sets up logging, metrics and alerts for new services, tunes alerts so that every page needs action, and helps developers find what they need in the data.
Security and access
Manages access and secrets for their services with least privilege, patches vulnerabilities by their severity, and fixes the findings from security scans.
Developer enablement and collaboration
Writes clear guides for common tasks, pairs with developers on deploying and debugging their services, and onboards new teammates to the infrastructure.

Senior DevOps Engineer: what is expected

Designs and leads infrastructure projects that several teams depend on, and raises the reliability bar. Shared infrastructure used by most of engineering, and projects such as migrations that touch every team.

Infrastructure as code
Designs the layout of the company's infrastructure code and environments, leads changes such as network or cluster upgrades with a tested rollback plan, and keeps cloud spending visible per team.
Build and delivery pipelines
Designs shared pipeline templates every team uses, introduces safer release methods such as canary or blue-green deploys, and tracks deployment frequency and failure rate.
Reliability and incident response
Leads response to major incidents, runs blameless post-mortems and sees follow-up actions through, and plans capacity and failover for critical systems.
Monitoring and observability
Designs the observability approach for the company's main systems, defines the service health signals teams are measured on, and cuts alert noise across teams.
Security and access
Designs network boundaries, identity and secrets management across the platform, prepares evidence for customer security reviews, and leads the response to security incidents.
Developer enablement and collaboration
Builds self-service tooling that lets teams create services and environments without filing a ticket, mentors other DevOps engineers, and takes part in hiring.

Staff DevOps Engineer: what is expected

Sets the direction of the company's platform and answers for its reliability, security and cost. The whole production platform, its multi-year direction and its budget, across all engineering teams.

Infrastructure as code
Chooses the platform's core building blocks and providers for the next few years, sets the standards every team's infrastructure follows, and owns the infrastructure budget with leadership.
Build and delivery pipelines
Defines how the whole company ships software, from branching to rollback, and removes the bottlenecks that slow delivery across all teams.
Reliability and incident response
Sets reliability targets with product and leadership, designs the on-call and incident process for all of engineering, and plans for disasters such as losing a region or a provider.
Monitoring and observability
Chooses the company's observability tooling and its cost model, and makes sure leadership can see the health of the platform without asking an engineer.
Security and access
Owns the platform's security posture together with leadership, sets the controls compliance requires (for example, SOC 2 or ISO 27001), and makes the secure path the easiest one for every team.
Developer enablement and collaboration
Shapes the platform as an internal product with developers as its users, decides what teams own versus what the platform team owns, and grows the next senior engineers.

How to adapt this ladder

  1. Name your stack in the expectations

    Generic phrases like “infrastructure code” or “pipelines” are easy to agree with and hard to assess. Replace them with your real tools and practices, so that a junior engineer knows exactly what they are expected to learn first.

  2. Wait to introduce the Staff level

    With one to three DevOps engineers, junior, mid and senior levels are usually enough. Add Staff when someone is actually setting platform direction and owning its budget across all of engineering, not as a title for the most experienced person on a small team.

  3. Write your on-call rules into the ladder

    Say at which level people join the rotation, when they lead incidents, and how on-call time is compensated. Unwritten on-call expectations are one of the most common reasons infrastructure engineers burn out and leave.

  4. Match the levels to your software engineer ladder

    Map each DevOps level to the software engineer level with the same scope and pay. Platform work is engineering work, and keeping the two ladders aligned makes moves between product and platform teams straightforward.

FAQ

Questions about this ladder

What is the difference between a DevOps engineer, an SRE and a platform engineer?

Strictly, DevOps is a way of working rather than a job title; in practice, in companies of 20 to 200 people the titles mostly describe the same job with a different emphasis: SREs focus on reliability targets — typically SLOs and error budgets — and incidents, platform engineers on self-service tools for developers, and DevOps engineers on pipelines and infrastructure. One ladder usually covers all three; adjust the wording of the competencies rather than creating separate ladders.

When does a startup need its first DevOps engineer?

Usually when developers spend a noticeable part of their week on deploys, environments and production issues instead of features, or when customers start asking for uptime commitments and security reviews. For many companies this happens at around 15 to 30 engineers.

Should on-call work count towards a DevOps engineer's promotion?

Yes, but count what people learn and improve, not how many pages they answered. Leading a major incident well, writing post-mortems whose actions get done, and reducing alert noise are clear evidence for the next level. Being on call often is not.

Do cloud certifications matter for a DevOps engineer's level?

They can help someone learn a platform, but they should not decide a level. Assess what the person has built and run in your environment against the competency matrix. A certificate without that evidence does not show the next level; that evidence without a certificate does.

How many levels does a DevOps engineer career ladder need?

Three or four, because infrastructure teams in companies of this size are small. This template uses four — Junior, DevOps Engineer, Senior and Staff — and works well alongside a five-level software engineer ladder, with the Staff levels lined up.

Build this career ladder in LadderKit — free

Set up its levels and skills for your team, assess people against them in check-ins, and keep promotion decisions consistent.

Free plan · No credit card required

  • Engineering

    Software Engineer

    Five levels from Junior to Principal, across six competencies from shipping code to growing the team.

    • 5 levels
    • 6 competencies
  • Engineering

    QA Engineer

    Four levels from Junior QA to Lead QA Engineer, across six competencies from test design to quality practices.

    • 4 levels
    • 6 competencies
  • Engineering

    Engineering Manager

    Four levels from Engineering Manager to VP of Engineering, across six management competencies.

    • 4 levels
    • 6 competencies

Browse all templates