DevOps & Platform Engineering: SFIA levels and developer seniority
Fennec team · 9 Mar 2026 · 4 min read
DevOps and platform engineering is judged less by what you personally shipped and more by how much friction you removed for everyone else. It covers CI/CD, internal tooling, and the golden paths that let other engineers ship faster and safer without having to think about the plumbing.
SFIA levels here track a shift from following a deploy runbook, to building the platform that makes runbooks unnecessary in the first place.
1
Level 1: Follow
“I understand what CI/CD means and can follow deployment runbooks. I know what containers are but haven't operated them in production.”
Evidence at this stage is about exposure more than output: deploys you executed by following a runbook, notes from the first time you ran a container locally, or a pipeline run you watched from trigger to completion with notes on what each stage actually did.
Get comfortable running and building containers locally before you need to under pressure. Shadow a deploy or a full pipeline run, and practice reading a CI log until you can spot why a build failed without asking someone else to interpret it for you.
2
Level 2: Assist
“I maintain existing pipelines and deploy applications following documented procedures. I can resolve basic infrastructure issues.”
The evidence here is maintenance done well: pull requests fixing or maintaining an existing pipeline, infrastructure tickets you resolved by following documented steps, or a short runbook you wrote for something that previously only lived in someone's head.
Fix a flaky step in an existing pipeline yourself rather than routing around it, write down a process that isn't documented anywhere yet, and take an on-call shadow shift, since seeing what actually breaks is worth more than any amount of reading about it.
3
Level 3: Apply
“I build and own CI/CD pipelines, containerise and deploy applications, implement monitoring, and automate operational tasks. I do this without needing runbooks or supervision.”
Ownership is the theme here: a CI/CD pipeline you built and now own outright, a monitoring or alerting setup you implemented from nothing, or a manual operational task you automated because you noticed nobody else was going to.
Own a pipeline through its failures as much as its successes, that's what separates building something from being responsible for it. Automate one recurring manual task this quarter, and introduce a piece of monitoring nobody asked for but you knew was missing.
4
Level 4: Enable
“I'm the person who designs the deployment platform and sets the standards the team uses. I drive reliability practices, introduce advanced patterns like GitOps or progressive delivery, and lead incident response.”
By this point the evidence is standards other people follow: a deployment platform or standard you designed that your team relies on daily, a GitOps or progressive-delivery pattern you introduced, or an incident response you led complete with the retro and its follow-up actions.
Propose and build the next deployment standard for your team instead of waiting for the gap to become urgent. Lead an incident retro through to a concrete, tracked action rather than a list of good intentions, and start mentoring engineers on operational practice, not just code.
5
Level 5: Ensure & Advise
“I define our DevOps transformation strategy and platform engineering roadmap. I build the internal developer platform that enables the engineering organisation.”
The evidence spans multiple teams now: an internal developer platform you built or led the design of, a DevOps transformation roadmap you authored, or delivery metrics you measured and reported across the organisation rather than just your own team.
Write a platform roadmap, not just the next pipeline improvement, and build tooling that serves more than one team by default. Measuring and reporting delivery metrics across the organisation is often what makes the case for the platform investment you're proposing.
6
Level 6: Initiate & Influence
“I set engineering delivery strategy and culture at an organisational level.”
At the top, the evidence is cultural: an organisation-wide delivery culture or strategy you set, external talks or writing on platform engineering, or a visible shift in how the whole engineering organisation ships software that traces back to decisions you made.
From here, publish your platform thinking externally, own delivery strategy at the organisation level, and expect your role to be about setting the culture around how software ships as much as building any specific tool.
Go deeper
Research-backed metrics and practices for software delivery performance.
The CNCF working group defining GitOps principles.
Community and resources for the platform engineering discipline.
Knowing where you sit is one thing, proving it later is another. Fennec lets you log devops & platform engineering evidence as you go, a shipped feature, a decision, a review, tagged to the level it demonstrates, so the case for your next step is already made when you need it.