Career Frameworks 🪜 — part 2
How to create the right one for your team, get buy-in, and roll it out.
Hey! Today we are back with the second half of this two-part series about career frameworks.
I tried to take your very best ideas and incorporate them in this second part — and that especially includes the awesome folks in the community.
Last week was about theory and some good examples. Now it’s time to go in the trenches and talk of:
🔨 How to create the right framework for your team
🎓 How to define skills
🪜 How to identify levels
🚚 How to roll out the framework
Let’s go! 👇
🔨 How to create the framework
How do you get started when you are doing this from scratch?
Whatever process you adopt to create the framework, you will spend time and energy aligning your ideas with those of the various stakeholders. So, if you haven’t already, I would start with creating general engineering principles 👇
1) Start with principles 🌟
When you need to converge with people around something, going top-down from first principles is often the most efficient way. On the contrary, when you start bottom-up, you may find people disagreeing on things without really knowing why.
For career frameworks, engineering principles are even more useful because they are like high-level expectations that stand true for all roles and levels. They are not only useful to bring people together, they are actual groundwork that you will use down the road.
If you are skeptical about the usefulness of this, let’s make a concrete example taken from one of the most popular career frameworks out there: the one from Rent the Runway, created by Camille Fournier.
The Senior Engineer I role has the following description of what is expected of their technical skills:
Demonstrates knowledge of industry trends, our infrastructure and our build system, including maven, jenkins, and git.
The Senior Engineer II role has this one:
Provides technical advice and weighs in on technical decisions that impact other teams or the company at large. Researches and proposes new technologies.
I have put in bold two parts that are relevant to me, about staying on top of tech trends.
How do you come up with these? A healthy way is to have a broad company principle which values personal growth and encourages spending time learning new things. The principle triggers discussions about how to make this happen, and you may end up allocating some fixed engineering time on this, creating personal OKRs, or whatever.
Without the principle, it is not trivial to recognize this as a company-wide need and to agree with people about it.
Of course, things do not flow top-down only. While principles may influence role descriptions, the opposite is also true. You may recognize the need for a new principle while in the process of creating role descriptions, and iterate from there.
2) Start with simple guidelines 📋
The best way to think about a career framework is to consider it as guidelines about what is expected of people at work.
You start with principles because they are what is expected of everybody, and then create levels when it is time to separate guidelines across the various roles.
When you replace career framework with guidelines, it is clear that these are useful even when your team is small and you have maybe just a couple of different roles / levels.
Even if you don’t do performance reviews, or you don’t have hiring managers and all the things people usually associate with career frameworks, guidelines help people behave consistently and help you have grounded conversations about their growth.
In my experience, it’s never too early for this.
3) Levels come before skills 🪜
Big career frameworks usually have separate concepts of levels and skills. A same set of skills is defined and reused across levels and tracks.
Some examples: