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.
First of all, I want to thank you all because the response to the first post has been amazing! So many of you reached out to share their experience, ask more questions, or just say thanks.
I tried to take your very best ideas and incorporate them in this second part — and that especially includes the awesome folks in the Refactoring 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 👇
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.
To learn more about creating good engineering principles, you can check out this previous Refactoring article 👇
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.