One of the projects that I've now led twice - once at TravelLocal, and once, more recently, for a client - is the establishment of a software engineering career framework. Nowadays, career frameworks for engineering organisations are ubiquitous, especially in larger teams. However, when I started my software engineering journey in the early 2010s, they had not yet been popularised. I distinctly remember the first time I encountered one, reading this blog post by Camille Fournier about her experience introducing an engineering career framework at Rent The Runway. More than anything, I was impressed by the intent behind the framework - providing clarity to team members wishing to progress in their roles.
In the 10+ years since then, examples of career frameworks have proliferated, with plenty of high-profile examples in the public domain - GitLab's and CircleCI's are two that I've referenced myself in the past. There's even a whole website, https://progression.fyi/, dedicated to sharing open examples. In that time, I've also come to believe that a well-designed career framework is a key tool in successfully growing an engineering org.
- What is a career framework?
- Why do we need a career framework?
- How do we get started?
- Embedding the career framework
What is a career framework?
To put it simply, a career framework is a document or tool that outlines the expectations for each role in your engineering organisation. These expectations are usually defined as a set of behaviours or competencies that are expected to be fulfilled by a person working in that specific role. Unlike a job description (more on that later), a career framework is a living document that grows and evolves with your organisation.
Why do we need a career framework?
It can be tempting to think that establishing a career framework is unnecessary work when your team is small - and if you're a handful of engineers, you're probably right. However, a timely introduction of a career framework can make your life as an engineering leader significantly easier.
To me, a career framework solves three core challenges for your team. These are the challenges of clarity, consistency, and ambition.
Clarity
In many jobs, your job description is the only written record of your expectations in the role. However, job descriptions are designed for a specific purpose - hiring - and so are not optimised for people already in the role. They become outdated as soon as the role is filled. What this means is that starting from day one, a team member has a growing gap around the question "What is expected of me?"
Good managers will regularly fill this gap in 1:1 conversations, performance reviews, and by defining clear goals for their team members. However, in all of these cases, the context for expectations is largely in the heads of manager and team member. If, as an engineer, I want to clearly establish what I need to do to succeed, I have no quick point of reference. If, as a manager, I want to evaluate the progress and contributions of my team, I have no easy and consistent method of comparison.
A career framework solves this issue by taking the majority of this context, and making it explicit. A document can't - and shouldn't try to - replace the relationship between team member and manager. But by establishing an agreed-upon set of behaviours for each role, it provides a shared understanding and point of reference to answer the key question of "What is expected of me?" This gives agency to team members to own their own performance and progression, and provides a fair and equal baseline for managers to evaluate the success of their team.
Consistency
Fairness leads directly to the second key challenge answered by a career framework. Establishing a shared understanding of what is expected of team members in each role means that everyone is being evaluated against the same, known behaviours. This can go a long way towards preventing a situation in which success in the organisation is predicated purely on the whims of your manager. Nobody wants to work in an organisation where people succeed or fail thanks to some opaque system of assessment that involves pleasing certain key figures - and yet, many orgs operate this way. By putting the expectations out in the open - and using them in processes such as hiring, performance management, and promotions - team members can feel confident that they are aiming for the same benchmark as their peers.
"But I judge the performance of my team fairly and objectively!" Sorry, but you probably don't. Unconscious bias is a real phenomenon, and no matter your intentions, it's all too easy to see one person's confident decision-making as another's reckless risk-taking. Establishing clear behaviours beforehand goes some way to eliminating these inconsistent perceptions of the same actions across your team. This is particularly relevant for team members from minority backgrounds, who are disproportionately negatively impacted by opaque hiring or promotion processes.
Ambition
People enjoy challenge and progression in their work. By clearly documenting expectations at each level of your engineering organisation, a career framework gives team members a signpost for what they could achieve within the org. This allows them to own their self-development in a structured way. For example, perhaps a key behaviour for Senior Engineers in your organisation is technical leadership of projects. An aspiring engineer might choose to focus on developing this behaviour by shadowing an existing tech lead, or proactively requesting to take on the tech lead role for a smaller project.
Without clarity around the roles that exist in the org and what they entail, ambitious team members may feel that their opportunities to grow within the team are limited. This can lead to challenges with retention as high performers seek more well-defined opportunities by taking another job.
With a career framework in place, conversations with high-performing team members can focus on what behaviours they should develop, not whether opportunities for growth in the team exist.
How do we get started?
Hopefully I've convinced you of the value of establishing a career framework for your team. So how do we go about doing that?
Wait until you need it
It can be tempting to think that before you start hiring for your fledgling engineering team, you need to have a career framework in place. In my experience, making a career framework too early is almost as bad as not making one at all. For one, it may be wasted work - in an early-stage organisation, nothing is guaranteed, and you could almost certainly be focussing on a higher-leverage activity that would increase the org's chances of success. Secondly, you simply won't have enough information to clearly define the potential roles in your team. While some behaviours are fairly consistent across organisations, the culture and best practices of your team, and the specific goals of your org will significantly affect what 'good' looks like. Trying to anticipate this before you've even hired your first team member is unlikely to produce anything that has meaning and relevance once your team has grown and established its ways of working.
A better time to make a career framework is when you are starting to feel the friction of not having one. Once you have a few engineers who are working effectively, and the core of the team is established, your focus may turn to developing your existing team or expanding the team with new skills. At this point, questions like "How can I grow in my role?" or "How do we fairly evaluate these candidates for a new hire?" may come to the fore. This is a great time to make a first pass of your framework, knowing that it will have immediate applications.
Keep it simple
A good career framework provides enough information to give clear direction to the team, but not so much that it's overwhelming. What that looks like will be different depending on your team size and seniority mix - a team of five engineers with around the same experience needs way less detail than a team of 100 engineers with a wide variety of experience levels. But in all cases, try to keep things a simple as possible. A framework with tens of behaviours at each level simply won't be read and used by the majority of your team.
To be concrete about this, when you're starting out, make a short list of key behaviours for your most common role. These should cover the core activities and responsibilities of the job. If most people are Senior Engineers, define that role first, as you'll have the most actual experience to draw on in terms of what is working and what isn't in your team. Structure the behaviours as clear, one-or-two sentence statements, for example:
I deliver high-quality, readable code that follows the team’s conventions. I seek feedback through pairing and reviews to improve the quality of my contributions.
Behaviours should be things that people do! The framework should consist of actions that it is possible to clearly demonstrate, not intangibles like 'has good architecture sense'.
Once you've established a baseline of key behaviours for your most common role, sense check them with those people actually doing that job. Do the behaviours reflect their experience of their day-to-day work? If not, why not? Iterate until you've got something that feels true of your org as it is now. Only then should you start to deepen and expand.
Copy and customise
As mentioned above, you'll need to have an understanding of your team as a living, working entity to be able to make a useful career framework. However, that doesn't mean that you have to start completely from scratch. Unless you're working on something truly unique, or working in a radically different way from every other engineering team out there (and you probably aren't), the behaviours needed to be an effective software engineer at your organisation are likely to overlap significantly with those at other orgs.
Take some time to read through the existing state of the art, looking at both industry-leading orgs for inspiration, but also for orgs that are more reflective of your scale and maturity. If you see behaviours that reflect the best practices you feel should exist in your team, feel free to incorporate them. Think about the categories of behaviour that are covered by existing frameworks - does your framework broadly cover the same main aspects of everyone's job?
While you may need to customise behaviours to fit into the context of your team, drawing on existing open frameworks will give you a good sense of whether your framework is covering the correct bases.
Aim for good enough, then evolve
As mentioned above, a career framework should be a living document. The documented behaviours should reflect the expectations of the team you have now, not the team you want to have when your org has grown to 1000 engineers. With this in mind, challenge yourself to get something simple and meaningful in front of your engineers as soon as possible. By starting with your most common role, you can validate the approach early and see if it resonates with your existing team members.
Once you've got the framework out in the open in the team, actively solicit feedback while building it out to cover all of the existing roles in your team. For small teams, this might only be two or three roles: Engineer, Senior Engineer, and Staff Engineer, for example. Only once you've got clear expectations for each existing role should you start thinking about extending the framework to cover aspects of your hypothetical org chart. Try to link behaviours from one level to the next - behaviours at Senior level should be a natural progression from those at Engineer, and so on. Some behaviours will be the same in multiple roles, and that's fine!
You can evolve your framework in several ways as the situation demands. Maybe you've hired your first engineering manager - this could be a good time to split your framework into distinct Individual Contributor and Management tracks. Or you might find your most senior engineer is going above and beyond what's defined in their role; this could be a signal to introduce a Principal Engineer role for them to aim for. Perhaps you find yourself in a situation where you have lots of team members at the Engineer level, and some clearly have greater responsibilities than others. Maybe you need to start considering if you need multiple intra-role levels (e.g. E1, E2).
I personally find it helpful to write a short accompanying document alongside the career framework itself, explaining where and how it will be used. This explainer will also evolve as you embed the framework in more aspects of your process.
Finally, as time goes on, what behaviours are expected of each role will likely evolve as the team does. It's good to build in a process to review the framework on e.g. an annual basis, to ensure it's still relevant for the team. The best way for a framework to become obsolete is to let it diverge too far from the reality of your team.
A note about salaries
I am strongly of the opinion that you should align salary bands within your org with your career framework. It simplifies a whole class of difficult management problems around fair compensation if you can confidently state that everyone in a certain role is within a given salary band. Whether you choose to transparently surface these bands alongside the roles, how wide the bands are, and whether the bands between different roles overlap - all of these will depend on your own situation, constraints and preferences. But whether or not the bands are visible to the team, being able to comfortably justify to yourself why someone's salary is at a certain level relative to their peers will set you up for productive conversations with team members and prospective hires on the topic of remuneration.
Embedding the career framework
Well done - you've done the hard work of designing and rolling out your career framework. Now you have to use it! In future posts, I'll cover three areas where you can make the career framework a core part of your process: hiring, performance management, and professional development.
Until then, if you have any thoughts about the post, or questions about establishing your own career framework, drop me an email at work at jw.pe.