Writing – or not writing – your first Levels & Expectations Framework
AKA Career Ladder, Career Progression Framework, etc.
There comes an inevitable moment in the growth of an organisation where someone sensibly suggests formalising titles, levels and criteria for progression. Once that cat is out of the bag, there is no putting it back in until you have written a raft of documentation, rocked several apple carts, and eventually deployed a set of organisational changes and a new way for everyone to think about their job, development areas, and place within the wider business.
The good news is that design teams rarely reach this moment of need first. In large tech orgs. engineering is typically first to scale to the point where this need becomes acute.
This is good news and bad.
The Bad News
Engineering are going to be off writing their L&E framework, likely lifted from whichever FAANG company the CTO worked at previously. In doing so, they will be creating a format and a structure which you are going to be locked into. HR teams and leadership do not relish having to learn and switch between different versions of these same artefacts in cross-disciplinary forums, even if they are serving wildly different populations within the company. So, hope your pals in engineering accidentally make decisions that serve the wider organisation, or better still, work with them on their L&E framework knowing that you will be inheriting a bunch of their work in writing your own.
Because Engineering is a completely different role which draws in completely different kinds of people and is asked to do completely different things to designers, there will limited utility in the actual content of the engineering framework, but there will be some…
The Good News
Whilst design and engineering are rarely on a level playing field, this is one opportunity to narrow that gap. If you can cast aside your understandable concerns about the framework you are inheriting, you will be able to:
Create parity across the career ladder - If there is a Vice President role in the engineering framework, there is now one in the design framework too, and whilst it may sit vacant for some time as the organisation matures, its very presence is a helpful nod to that ambition. Throughout the ladder you can create comparable roles across disciplines, and create shared expectations beyond the production aspects of the work.
Just replace the verbs - It may be that you can almost completely replicate the engineering rubric, replacing only those aspects of it which refer to specifics of the role. This will help to elevate the role of design as the “soft skills” which form the other half of the framework are very often areas in which designers excel beyond the typical performance levels of their peers in Engineering.
Codifying expectations reduces bias - Organisations which use observation-driven performance management processes are prone to being tainted by a bunch of biases which a well written set of expectations can help to reduce. A framework which can describe both output and behavioural expectations makes it more difficult for outlying feedback to overwhelm that at the centre, and can mean that groups who are less representative of the overall company - and wider industry - benefit disproportionately from a framework, even if it was derived from that written for the dominant group.
Done well, a career development framework becomes a useful tool for individuals, managers and the organisation at large. Whilst it can be a significant effort to create, the earlier in your companies scaling you do so, the easier it will be to maintain, evolve and adapt as time goes by. Some things to try and avoid as you put pen to paper:
Create as few levels as possible - (notwithstanding the point above on duplicating the engineering levels) It is nigh on impossible to remove levels later, so resist the temptation to create a 9 level ladder from day one. Instead, look at the team you have, and consider where it is headed over the next 18-24 months in terms of career development and likely hiring. If you’re not going to be hiring at or promoting to Senior Staff levels in that window, don’t create that level.
Make sure you aren’t myopically focussed on outputs - This is an opportunity to enshrine elements of *how* people should work into the fabric of their role. If it’s important to you that people aren’t arseholes, then make sure you codify what good communication and collaboration skills look like, and how those expectations rise through the levels, not decline.
Don’t make changes mid-cycle - Once you’ve rolled this document out, you need to let it go largely unchanged during performance cycles. It is manifestly unfair to change expectations in the middle of a period where performance is being measured. Non-trivial changes should be bundled, and enacted with prior warning at the end of an annual cycle. This is the minimum timeframe over which an organisation can digest these types of changes.
Stuart.
Levels & Expectations frameworks resources:
Progression.fyi - Software to define and measure career growth for your team
Buzzfeed - Product Design Roles
One thing I’ve found useful creating these frameworks is to get input from the people in your org while you’re designing it. They can often help you identify what’s unclear, missing, or unreasonable. It also becomes easier to get people’s buy-in if it was made with them and given to them as a resource and growth tool instead of something that was created in a vacuum and thrust upon them.
Thanks for sharing, Stuart!! 😄