Engineering
Software Engineer
Five levels from Junior to Principal, across six competencies from shipping code to growing the team.
- 5 levels
- 6 competencies
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.
Makes well-scoped changes to infrastructure and pipelines with review and learns how production runs.
Owns parts of the infrastructure end to end and takes a full share of on-call.
Designs and leads infrastructure projects that several teams depend on, and raises the reliability bar.
Sets the direction of the company's platform and answers for its reliability, security and cost.
Each row is a competency and each column a level. Read a row from left to right to see how the expectation grows.
| Competency | Junior DevOps Engineer | DevOps Engineer | Senior DevOps Engineer | Staff DevOps Engineer |
|---|---|---|---|---|
| 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. | 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 pipelines | Fixes 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 response | Shadows 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 observability | Adds 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 access | Follows 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 collaboration | Answers 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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
Five levels from Junior to Principal, across six competencies from shipping code to growing the team.
Engineering
Four levels from Junior QA to Lead QA Engineer, across six competencies from test design to quality practices.
Engineering
Four levels from Engineering Manager to VP of Engineering, across six management competencies.