The Tension Which Breaks Career Frameworks and How to Solve It

Writing good career frameworks isn’t easy.

If you’re a manager who’s been frustrated by a bad framework, you might have said (approximately) one of these two things:

‘This is useless.  It’s way too broad and doesn’t give me enough information to know how to progress my team and get them promoted.’

‘This is useless.  It’s way too specific.  My team are going to follow this as a check-box exercise but it’s not actually going to build the skills they need to get promoted.’

This is the tension at the heart of all career frameworks.  

How do you give your bright, creative, independently-minded team enough guidance on how to advance at your company without stifling exactly that initiative and drive which is also key to their progression? 

It’s a thorny problem which hinders companies from implementing good career frameworks.  It’s a shame, because when done well, the clarity they offer employees can be transformative.  

In the first instance, they demonstrate that you care about employee progression at your firm.  It’s inspiring for staff to see pathways to success, and it builds trust that you have their interests at heart.  It’s also an opportunity for you to define performance, state clearly what your firm values, and how people can have maximum impact.  They’re also a foundational asset for better career conversations between managers and team members.  Needless to say, all this significantly helps with retention.

It’s also important to note what happens if you don’t put these frameworks in place.  Progression doesn’t just stop.  Instead it becomes governed by informal understanding, bias, and favouritism.   This has a shuddering impact on diversity, equity, and inclusion along with team morale, motivation, and retention.

We want more companies to implement great frameworks.  So if you’re writing a framework from scratch or looking to improve your existing one, hopefully this article can help remove this tension and help you build something which truly supports your team’s progress.

Kommon helps you put these frameworks into practice and translate them into goals, milestones, and career progress.  Click here to learn more about how.

Treat your Career Framework like a Product

We’ve said it before and we’ll say it again, the road to HR hell is paved with other people’s solutions. 

Career frameworks are no different.

There are countless (often excellent) examples of career frameworks which other companies have been kind enough to publish publicly.  Whilst these are helpful inspiration, and by all means check them out (see our link below), they will almost certainly not be the perfect fit for your company, culture, and people.

So how do you create one which is a better fit?

Think about your framework like one of your products. One with customers who you need to help and please.

So when you build a framework, who are your customers?

• Team Members: for these purposes ‘team member’ will refer to the individual who is trying to use your framework to advance their career.  Clearly, your framework needs to be useful to them. 

• Managers: team members don’t work alone. Career progression in most companies is heavily influenced by an individual’s manager, and how they work together to shape the team member’s work. In addition to helping the individual, managers also need to be happy with your framework otherwise they won’t use it with their teams (no matter how much team members might like it). 

• Promotion decision-makers: a key part of progression is getting promoted.  Your framework will need approval from whoever is key to making those decisions.  That may be the manager again, but it may also involve other stakeholders.  If managers and team members don’t have faith that using your framework will help with promotions, again, they won’t use it.

Your framework needs to be valuable to each of these groups for it to be a success.

Fortunately, they can all offer critical advice on the problems they want your framework to solve, and how to solve them.  So go talk to them.

They will be the main source of the insights and language which will enable you to craft something which genuinely helps your people progress. 

Stay Focussed at the Start

Before we go and talk to these customers, a note on scale.

As lean product development 101 will tell you, you don’t start by building a fully-featured product for all users.  You start by solving a specific problem, getting feedback, iterating, and then scaling.

Career frameworks are no different.

It can be tempting to think that the ‘problem’ can’t be broken down.  You may see your challenge as ‘improving career development pathways’ and you look at other companies’ beautiful multi-level frameworks and think, ‘that’s what I want from this excercise’.

And it may be where you end up, but it’s probably not where you want to start.  

Because for most companies, although the ambition may be to have a framework for the whole firm, there will be specific pressure points on certain pathways in certain roles.  

Perhaps you’ve had consistent feedback in 1:1s that junior software engineers aren’t sure how to progress.  Or you’ve found that your last three product managers left after short tenures citing a lack of progression in their exit interviews.  We’re sure you can think of examples in your firm.

Wherever the development pressure points are, that’s where your focus should be. 

Pick one or two key career transitions in your firm that you want your framework to assist with and start there.  If you can succeed there, you will:

1. Solve a key pain point for your business on a much shorter timeframe than building out a company-wide framework
2. Gather valuable feedback on improving your framework to incorporate other roles
3. Convince other potential users in your firm of the validity of your approach and the success of your ‘product’, improving future adoption.

Talk to your Customers

Once you’ve selected a career transition to focus on, you’re ready to gather the insights which will inform your framework.  For this example, let’s call this the transition from ‘Software Engineer L1’ to ‘Software Engineer L2’, but it could be any role. 

(Note that this article assumes you have already defined the roles you want people to move through in their progression).

To create our framework, we need to establish two things:

• What are the challenges faced by team members, managers, and promotion decision-makers in progressing someone from L1 to L2
• What characteristics does an individual have to demonstrate at your company to progress from L1 to L2?

Many frameworks divide this second point into something roughly analogous to the following sections (they may split these categories down further but the intent is similar):

• Impact: how is an individual expected to directly benefit the business
• Competencies: what skills are they expected to have.
• Behaviours: how are they expected to approach their work. 

At the end of your conversations with your customers you should have a clear view on these questions from the range of perspectives you need to put together your framework.

Team Members

Your team members are those who will be most impacted by your framework and often know most about the realities of the roles you will be describing.

For our L1-L2 progression framework, you ideally want to speak to two people who are currently L1 and cover something like the following areas:

1. What would you describe as the key impact, skills, and behaviours of a good L1 software engineer?
2. What do you think are the main differences between an L1 and an L2 software engineer?
3. Are you working with your manager to progress to L2?  How is that going?  Are there any particular challenges?
4. On a scale of 1-10, how clear are you on what you need to do to get to L2?
5. What more could the company be doing to support you?

You should then get perspective on questions 1 and 2 from a couple of current L2s.  

The final two questions don't relate directly to your framework but are a great opportunity to assess the scale of the problem, and also whether there's other solutions (in addition to frameworks) which your interviewees feel you should be looking at.

Managers

Following those conversations, you should speak to (ideally) two managers of L1 and L2 engineers and ask them some similar questions:

1. What would you describe as the key impact, skills, and behaviours of a good L1 software engineer?
2. What do you think are the main differences between an L1 and an L2 software engineer?
3. Are you working with any L1s to progress them to L2?  How is that going?  Are there any particular challenges?
4. Have you had any issues getting L1s promoted?

Promotion Decision-Makers

Finally, head to the promotion-decision makers (or the manager if the same):

• What would you describe as the key impact, skills, and behaviours of a good L1 software engineer?
• What do you think are the main differences between an L1 and an L2 software engineer?
• When you’ve seen L1s get promoted, where have they excelled?
• When you’ve seen L1s get turned down for promotion, why was that?

Although there's clearly lots of overlap in the questions, we've found you can get subtly different perspectives from the different audiences which will inform your approach.

With this information collected, you will be able to pull out the key competencies, skills, and behaviours which differentiate L1 and L2, and describe them in the language of your stakeholders.

For the precise format of your framework, you have several options.  Again, you can be inspired by others on this, but take note of what you were told in your user conversations in terms of what would be the right fit for your people and culture.  We’ll do a follow-on article in future breaking down various options in detail.

Get Feedback, Iterate, and Scale

Whichever format you choose, your initial framework will be a first draft, your MVP.

Before launching it for use, take it back to your users and ask them for feedback. Do they think this will help them solve the problems they identified in their initial conversations with you?

Hopefully the answer to that question is yes, at which point, managers can start using it with their teams.  Don’t forget to check back in after a month or so to see how the framework is holding up when teams have to use it in the context of their actual work.  In particular, revisit your customers when it comes to using it for promotion conversations.

You can then start thinking about which roles and career transitions to turn to next.  You may choose to carry on (L3, L4) or you may decide that other roles in your company warrant more urgent attention.  

Either way, whatever the role, this process should give you a good shot at creating something useful and meaningful for your teams to use.  

By centring your approach on the needs of your people, and the context of your culture, rather than focussing too much on what you think the solution ‘should’ look like, you can walk the tightrope of giving people guidance whilst supporting the independence and creativity you hired them for in the first place.

Kommon helps you put these frameworks into practice and translate them into goals, milestones, and career progress.  Click here to learn more about how.