Almost three years ago we introduced one of the first career progression frameworks at Monzo, the engineering progression framework (you can still see our version 1.0 on sites like Progression.fyi). At the time we were an engineering organisation of around 30 people, and we built a set of behaviours and characteristics that best represented our team, and our aspirations.
Around one and a half years ago we found this document was hurting, rather than helping career conversations with our engineers. What was once a clear picture of a high performing engineer had become a checkbox exercise, a frustration for both engineers and managers, and an outdated view of our organisation.
So, we set out to change it.
We identified 5 problems with our old engineering progression framework
A small team of engineering managers and I pulled together feedback from around the company. We polled to see where our career framework was providing value to engineers, and where it was falling short. About 40% of our engineers said our progression framework wasn't useful in supporting conversations around their development. This was too high.
We spoke to both engineers and managers, ultimately ending up with a set of problems to solve.
Our framework was too specific. It attempted to codify the work an engineer would do day to day, rather than articulating the size or scale of impact expected at each level.
It had too many things. We were treating it as a checkbox in some cases, a list to burn through in order to progress.
It didn’t take into account the key differences between working in a platform/infrastructure role and one of our product teams.
It had no framing and expectation setting. It was being treated as a GPS, when in fact what we needed was a compass. No document can provide an exact route for your career, but it can point you in the right direction.
It didn’t account for the fact that the scope of your role grew as you progressed.
After iterating on the format, framing and behaviours for a number of weeks, we ended up with a new tool to aid our engineers in career and growth conversations. In the past year we’ve seen a massive difference in how we approach these kinds of conversations.
So, what did we change?
We made changes to create v2.0 of our engineering progression framework
Firstly, we removed the old five column structure. It was too broad, and there were too many categories for a behaviour to belong to, which overcomplicated the design. We settled on a new design with three categories instead.
We grounded the framework in impact. Impact is the measure of how you're contributing to Monzo’s overall success, and can mean many different things. We didn’t try to codify exactly what someone needs to achieve, but focussed on the scale and scope, which'll naturally grow as you progress in your career.
To achieve impact as an engineer, you’ll rely on a broad set of skills, which we’ve codified into two categories: technical skills, and behaviours.
Technical skills refer to the unique toolset of an engineer, and link back to our overall view of engineering excellence. This starts off pretty specific, for example - setting expectations on things like the quality of your code, and become broader as you progress.
We have a high bar for engineering excellence, and it was important we recognise technical ability as important in our framework, but not in isolation. We didn’t set out to be exhaustive with enumerating these skills, just to cover off the important cornerstones of each level.
Behaviours refer to “other” skills, whether that’s the strength of communication, contributions to interviewing, or providing mentorship to other engineers. The job of an engineer isn’t just to craft code, and our framework should represent that.
We see these two groups as the “means to demonstrate impact”, or the “how”. It’s just as important for us to recognise the way in which people achieve an outcome, as the outcome itself.
We launched version two of our progression framework at the start of last year, using it to aid and inform career conversations between managers and engineers.
But what about engineering managers?
For a while now we’ve been building and iterating on our engineering management discipline. Jimi wrote recently around how we’ve changed our approach, embedding managers in teams to not only support individual engineers, but to enable our teams to run consistently and performantly.
Engineering managers are technical leaders for our business, in the last 18 months we’ve refocused the role to be much closer to the outcomes for a team (EMs now directly manage the team rather than a set of engineers distributed across different teams) but also to directly empower them as leaders. For example - managers are expected to properly understand and make judgement calls on when to prioritise technical work alongside “new feature development”, as well as form a strong partnership with their adjacent product managers. We’re looking to managers to make decisions based on what is right for the company and the individual, not just the individual.
“The goal of the engineering manager is to create an autonomous, high performing team - to foster an environment where decisions are delegated and can be made and communicated effectively. It is not the role of the manager to make these decisions, but to ensure they are made.”
Last month, we launched our engineering management progression framework, covering the Engineering Manager, Senior Engineering Manager, Engineering Director and Vice President of Engineering roles.
We needed different scaffolding for our management framework. We evaluate managers at Monzo based on their ability to support and develop our engineers, as well as their ability to enable a team to execute on their goals.
We settled on “Team and execution”, “People” and “Leadership” as the three pillars to align our behaviours to.
Team and execution is focussed on just that: the manager's ability to support and enable the team to achieve its goals. At Monzo, engineering managers are there to amplify and enable the team, not to act as a single point of failure. And we expect managers to effectively partner with Product managers, to remove blockers, and to help the team measure and understand their own performance.
The behaviours in People are aligned around a manager's ability to develop the engineers that they manage, creating an inclusive environment for their team to succeed, and hiring (and retaining!) amazing engineers.
Finally, leadership is there to recognise the organisational leadership role managers play at Monzo. It covers a wide range, from delivering feedback through to the ability to lead complex, cross team projects when the need arises.
Typically engineering managers progress with their organisation. As managers begin to manage larger, more complex parts of the company, so do the behaviours and skills they need to succeed. Just like the engineering framework, our manager framework is a guide to help our managers understand the expectations of their current role, as well as where to invest next as their organisation grows.
It’s early days for this document, we’ve been using it for about a month, but we’re already seeing the benefits of a consistent baseline, and a concise way to represent the role of the engineering manager in our teams. It’ll be exciting to see how we learn and iterate on this as we go. And I’d love to hear from your experiences using these different tools in your role.
If these documents create a spark of excitement, why not check out some of our open roles? We’re actively hiring across all levels of engineer and engineering manager.