One of the ways Octopus engineering changed as we scaled was by modifying our role definitions for engineers. We wanted to provide a resource for our engineering managers to give consistent guidance to our engineers for their careers at Octopus.
Our old definitions were fine and had worked well for us so far. We stored them in Github, so you can see them here. Here’s an example of one role:
Senior Software Engineer
I am a highly sought-after member of an Octopus team with a proven record of shipping high-quality code to production.
I am trusted to ship shaped pitches (or vertical slices of larger products) from idea to production
- I am proficient with my tools and the core building blocks used by our team.
- I can confidently step outside my comfort zone and adapt quickly to new technologies.
- I am proficient at qualifying and reducing technical debt.
- I am comfortable pulling together the Lego blocks of shaped pitches.
- I am comfortable setting up an automated integration and delivery pipeline.
- I am comfortable determining technical direction within brown-fields projects.
- I know how to make pragmatic decisions in order to ship a product.
- I know when to call out for help and how to do it effectively.
- I am technically persuasive.
- I am proficient at delivering software projects using agile practices.
I am a technical mentor
- People tend to ask me for my opinion when making technical decisions because I have a proven track record of making wise choices.
- I am fuelling the team’s desire to learn, perhaps by mentoring, running brown-bag sessions, sharing useful videos/blogs/papers.
- I use code reviews as an opportunity to teach and show others alternate, cleaner ways to implement functionality in an ego-less manner. That way the whole team together learns how to deliver a higher quality, more maintainable product.
- I can manage difficult conversations and tactfully challenge others, leaving them with a positive impression of myself and Octopus.
- I can effectively coach people and pass on my knowledge.
- I am a confident and proficient teacher of my craft.
I am focused on the success of my team and my customers, without the need to boost my ego
- I add value to my team by being a trusted, proactive supporter of my team and its leadership, and by delivering high quality work with a minimum of fuss.
- I seek to understand the real needs of my customers, and I am comfortable building requirements and technical recommendations off those.
- I recognise problems early and get in and fix them regardless of whose fault it is.
- I am good at recognising problems outside the scope of my work and eagerly get involved in improving our product, our environment, and our processes.
- I happily tackle all problems regardless of difficulty, and I support my team by solving them in a pragmatic way.
- Every venture has mundane tasks, but I’m the one that can be trusted to get them done and get them done right, and usually with a handful of ingenuity.
- I recognize and accept that change is constant, and my approach allows me to tactfully challenge, or confidently adapt, depending on which I deem appropriate.
- I have proven I can decompose larger requirements into smaller, more manageable pieces, to deliver functionality in an incremental and iterative manner.
- I possess writing skills that let me be clear, concise, articulate, and persuasive.
I’ve become a student of my craft
- I am devoted to learning; it’s become a natural part of my life.
- I am actively introspective and take time to work on my personal and professional development.
- I happily take responsibility for my own mistakes and I learn from the mistakes of others.
So what’s wrong with that? It had served us well when we only had one manager for all of the engineers, and worked when we added a couple more. But then we added even more engineers and even more managers. And what we found was that when engineers asked their managers “what do I have to do in order to move from my current level to the next level?” many of the newer managers were having a hard time working that out and communicating it based on the current definitions. Some of the managers that had been there longer felt confident in making this assessment, but their assessments could be different to other managers. This made calibration discussions difficult, and provided an inconsistent experience for engineers in their careers at Octopus.
We wanted to design something new, with the following goals:
- To serve as a documented resource for engineering level definitions at Octopus
- To be useful to managers in evaluating performance of direct reports
- To be useful to engineers in evaluating their own performance and understanding how to progress their career at Octopus
- To be useful to hiring managers and interviewers in evaluating candidates and designing interview process
- To clarify the existing definition in Octopus People without devaluing anybody’s current position
- To remain clear and relevant as we scale
We decided to try a role matrix.
What is a role matrix?
A role matrix is a way to present the career paths in your company that makes it easy to compare the skills required between role levels. For example, here is part of a role matrix that we experimented with at Octopus (no longer in use – we’ll get to that later!):
If you read it vertically you can see the skill expectations for a single role. If you read it horizontally, you can compare the skill expectations between the different levels. This can provide a simple resource for managers to help engineers understand what they might need to focus on in order to be ready for promotion.
Having different levels side by side can be helpful to explain a single role within the context of the levels either side of it. A “mid-level” engineer is defined differently at every company so it can be hard for a newer manager to understand what it means at this one. Comparing it to the expectations of a junior and a senior engineer can start to give the manager and the engineer a better idea of how the role is defined and assessed.
I used a similar format when working at Google in 2015. I found it useful at the time, although I’m sure they’ve made a lot of changes since then. I also introduced this tool to a 50 person software company in 2020, which proved useful to them. It didn’t suit Octopus.
- Engineers found the spreadsheet format overwhelming
- Due to the spreadsheet format we couldn’t keep it on Github or Confluence
- Engineers tended to fixate on the bullet point differences between roles, treating them like a checklist for their next promotion. Instead, we wanted the bullet points and examples to contribute to a whole understanding of that element of the job.
- It encouraged thinking about the career ladder at all times, which can lead to a culture where engineers and managers are fixated on promotions rather than mainly doing excellently in their current roles.
However, there were some things we liked:
- Breaking each role into consistent subheadings “Domain Expertise”, “Teaching and Mentoring”, “Culture & Leadership”, and “Customer Success” helped managers and engineers focus on broad areas for growth and show the value in that growth area.
- The changes to the existing definitions proved to help clarity.
In fact, most of the changes proved helpful. It was just the matrix format that was not working for us. So we moved to another approach.
Octopus career framework
We took the best parts of the role matrix changes and moved them into a format similar to the one we had at the beginning. Here’s what the Senior Software Engineer role looks like now:
L3: Senior Software Engineer
I am a highly sought-after member of an Octopus team with a proven record of shipping high-quality code to production.
Planning horizon: Current and next cycle
Impact radius: Peers (2-5)
Evaluation: Manager
Responsibility and direction needed: Takes vertical slices of larger products from idea to production.
? Domain expertise
- I am advanced in my team’s domain.
- I can confidently step outside my own comfort zone and adapt quickly to new technologies.
- I am able to design interfaces and reusable components for my team.
- I make appropriate scaling, reliability, and maintenance trade-offs as they occur in practice.
- I identify, qualify and reduce technical debt as appropriate to my team’s priorities.
Examples
- I set up or maintained an automated integration and delivery pipeline.
- I determined the technical direction within a brown-field project.
- I made the pragmatic decision not to investigate an interesting technical rabbit hole, in order to prioritise shipping a valuable feature to customers.
- I guided my team’s choice of safety nets, making appropriate risk trade-offs to balance delivery and quality
- People asked me for my opinion when making technical decisions because I had a proven track record of making wise choices.
? Teaching and Mentoring
- I consistently help new hires and more junior engineers to “level up” and become more proficient over time.
- I invest time in mentoring, coaching or teaching other engineers on my team in 1:1 or group settings.
- I am fuelling my team’s desire to learn.
Examples
- I ran a knowledge sharing session.
- I mentored a more junior developer and they went on to achieve something they couldn’t have before.
- I shared useful videos/blogs/papers that led to some action.
- I used code reviews as an opportunity to teach and showed others alternate, cleaner ways to implement functionality in an ego-less manner.
? Culture and Leadership
- I collaborate on and occasionally lead technical direction within already-defined projects.
- I continuously maintain and improve quality across the stack.
- I am willing to take on the necessary and unglamorous work needed to get things done.
- I take responsibility for my own mistakes and learn from the mistakes of others.
- I manage difficult conversations and tactfully challenge others.
- I improve the productivity and delivery of my team.
- I help raise the bar for working at Octopus by providing regular code reviews and / or interviews for engineering candidates.
Examples
- I performed regular interviews for engineering candidates, and provided detailed and useful feedback.
- I took on a significant share of unplanned work and other “housekeeping” tasks.
- I spotted a contentious issue that could have gone badly and facilitated everyone toward a decision that resolved the situation.
- I recognised a problem early and got in to fix it even though it wasn’t my fault.
- I wrote a clear and concise proposal that persuaded the team to act on my idea.
? Customer Success
- I confidently and autonomously lead the shipping of well-shaped ideas from conception to production.
- I advocate for customer needs and motivations.
- I decompose larger requirements into smaller, more manageable pieces, to deliver functionality in an incremental and iterative manner.
- I build requirements and technical recommendations based on the real needs of customers.
Examples
- I led a shaped pitch from idea to production, working with less senior colleagues to get the work shipped on time.
- I gave an early access version to our customers to get feedback during development, and acted on that feedback.
- I helped unblock the delivery pipeline to make sure we could verify the expected behaviour of the changes we made to production.
- I analyzed telemetry to make technical and scope decisions during a build.
>>> You can see the full Octopus career framework here.
We didn’t invent this format – we found a great example of this from Dropbox, and another one from Urban Airship.
We made this change 3 years ago and it has served us well with only small adjustments needed along the way.
What’s next?
While we moved engineering roles to this format, most of the other career ladders at Octopus still follow the old format. Engineering is the biggest function at Octopus so maybe the other functions have not yet grown to a size where it is important to them to change.
In my research into career frameworks, I was recommended the Radford Job Leveling system. I think this is a good example of a system built for a large company requiring a career framework that caters for scale and complexity. Octopus is a long way from needing a solution this heavy. However, it is interesting to see that one problem it addresses is identifying transferable skills between completely different roles, for example a software engineer and a sales engineer. That’s not something that our current career framework addresses, especially as the functions outside engineering use different formats. However we haven’t needed it yet.
Here’s that link again
>>> You can see the full Octopus career framework here.
Please feel free to take inspiration from our career framework and copy and adapt it for your own company. If you do, I’ll be interested to hear what you learn along the way so do reach out.
Photo by Khashayar Kouchpeydeh on Unsplash