Building an SRE Career Progression Framework

I often hear engineers ask…

• How do I become a better engineer?
• How do I contribute more to my organisation?
• How do I progress in my career?

…and not receive a meaningful answer.

I’ve even seen engineers leave their jobs in search of clearer career progression and meaningful feedback from their leaders.

I’ve been fortunate to be involved in multiple projects to address the problem of how to upskill engineers, incentivising retention, and I’d like to share a process for building such a framework within your organisation based on my own experiences, mistakes, and successes.

This article is based on my own discipline of Site Reliability Engineering (SRE), a notoriously difficult skillset to define, but this can easily be adapted to other engineering disciplines.

Why not use an existing framework?

A Google search will return many career progression frameworks. What you’ll find is that they each have different themes and focuses that might not align with the needs of your organisation.

Different organisations have different goals, team structures, cultures, and requirements. This is why it’s so important to tailor your career progression framework to the needs of your organisation.

The working group

Who should be involved?

This framework needs input from all engineering levels with guidance and facilitation from the leadership team. Perspectives from junior engineers are just as valid as lead or principal engineers. A key selling point of this framework is that it is written by engineers, for engineers.

How the working group will execute this work will depend on it’s size. Small groups should collaborate at almost every step, but a large group may benefit by being broken into smaller sub-groups with a regular sync meeting.

The skills

Skill tracks

To build a meaningful career progression framework for SRE, it’s important to understand that there are a multitude of skills outside of the ability to develop code to be an effective SRE.

So, you need to define discrete skill tracks that are important to the success of your organisation. These will differ between orgs, and may even differ between individual SRE teams.

These are some examples that may resound:

• Automation
• Development
• Operations
• Collaboration
• Influence
• CI/CD
• Observability
• Documentation
• Communication
• Evangelism
• …and so on

It’s important to consider the value that each of these skill tracks brings to the organisation. Be sure to describe why it’s important, and how proficiency in the skill track brings value to the org.

While I refer to these as skill ‘tracks’, progression doesn’t need to be linear. There are often different paths that an engineer can take to advance on each track.

Skill proficiency levels

Your working group needs to decide how many levels of proficiency will be defined. This number may depend on the size of your organisation and engineering hierarchy. Five levels will likely be enough, though large organisations with engineers ranging from interns through to global leaders may need to define 6 or more levels of proficiency.

The skill track behaviours and examples

I define ‘behaviour’ in this context as an action that an engineer could consistently demonstrate, which produces a positive outcome.

To grade an engineer at a level within a skill track, you need to describe the behaviours to be demonstrated, and assess the engineer against those descriptions.

Grammar

Before I go further into behaviours, I can’t stress strongly enough the importance that the grammar used to describe behaviours is consistent across levels.

Keeping grammar consistent avoids an imbalance of expectations. If level three on a skill track describes ‘mentoring’, and level four on another skill track also describes ‘mentoring’, then there’s an imbalance of expectations upon the engineers, and they will question it. In the early stages of the working group, define the grammar to be used at each skill track, with the intention of sticking to this as closely as possible.

For example, verbs to be used for level one may include:

• Seeks to understand
• Attends
• Shadows
• Recognises

In contrast, verbs at level three may include:

• Builds
• Designs
• Fosters
• Implements
• Applies expertise

Level five verbs may include:

• Pioneers
• Promotes
• Conducts research
• Informs leadership

Behaviours

Using this grammar as a guide, describe at least one behaviour expected to be demonstrated for each skill level in each skill track. For example:

Operations — Level 3
Fosters a culture that embraces reliability practices.

Evangelism — Level 5
Promotes the organisation’s SRE culture and practices to a wide audience .

Engineers should be expected to consistently demonstrate at least one behaviour to be graded at each skill level.

Behaviour examples

To further help the engineer demonstrate the behaviour, each level should also have examples of actions that would demonstrate the behaviour. The following would be valid examples to demonstrate the behaviours above:

Operations — Level 3
Facilitate post-incident reviews and ensure that understanding of the discovered failure mode is propagated.

Evangelism — Level 5
Produce a series of high-quality blog posts on a popular blogging platform.
Speak at an organisation-wide (or group-wide) forum about the importance of a Reliability culture within the org.

These examples could be turned into real actions, or they could spark new ideas for the engineer to demonstrate the behaviour.

Why not use languages and tools as skill tracks?

A strong temptation is to grade engineers on their ability to use a particular language or tool that is in-use by the organisation. I caution against this approach.

Languages and tools change over time.

Measuring an engineer’s ability to write code in the Go programming language may seem useful, but it’s only useful until the language is replaced, or new languages are added to your organisation’s stack.

Instead, measure the engineer’s ability to deliver value to the organisation by writing and contributing to a codebase, demonstrably following best practices.

Measuring an engineer’s ability to utilise particular features of a certain observability tool, especially as observability vendors are becoming more easily and quickly replaceable, is only useful while that subscription is still active.

Instead, measure the engineer’s ability to solve problems through the use of observability tooling, or their ability to identify gaps in tooling capability which are impacting operations.

Link to role titles

As any People Leader will know, there are many factors to consider when an engineer is being assessed for promotion.

I would caution against drawing a direct link between your career progression framework, and promotions. Instead of using the framework as a point-scoring system, use it as a conversation tool. Use assessments within the framework to identify strengths and gaps, and as an indicator for seniority.

Summary

• Form a working group, from new engineers through to your most senior.
• Define ten or so skill tracks that matter to your organisation.
• Set the number of levels of proficiency measured within your skill tracks.
• Describe behaviours for each skill track level that an engineer needs to demonstrate to be graded at that level.
• Define behaviour examples that would demonstrate this level of proficiency.
• To be graded at a skill track level, one or more behaviours must be consistently demonstrated by the engineer.
• To advance levels, the engineer can see what behaviours need to be demonstrated, and examples that would demonstrate those behaviours.
• The career progression framework may influence promotion of role title, but avoid drawing a direct link. Use it as a conversation tool.

Thanks for reading!