Deciding which skills to include in a team’s framework

This article is for HR Business Partners and Function Leads.

Every position within a team’s framework should include skills — these form the criteria to track and evidence progress, and give employees the clarity they need to understand what’s expected of them right now, and what they need to do to grow.


This article covers what you need to consider when deciding which skills to include in a team’s framework, plus some top tips to help you get started.

💡 We typically see HR Business Partners and Function Leads work together to define the skills that’ll go into a team’s framework, with Function Leads then building out the content for each skill. We’ll cover skills in the HRBP and Function Leads onboarding session, which usually takes place in the third week of the project.

Pre-build considerations

Number of skills

While there’s no limit to the number of skills a position could have, we strongly recommend anything from eight to 12, 12 being optimal.

Core skills

The Project Lead will have saved you some work already by creating a group of core skills and adding them in the framework template. These are required skills for every position within the organisation.

These core skills will either be locked, meaning you’ll pull them into the positions in your framework as they are, or you’ll have the option to create a skill variant. With skill variants you can create ‘child’ versions of a core ‘parent’ skill tailored to your teams’ disciplines.

Category split

Skills will be distributed across categories, most commonly domain-specific, core and leadership. The category split will depend on the position. For example, an IC position is likely to have fewer leadership skills than a position in a management track.

Start small

If you’re feeling daunted at the sheer volume of skills you think you’ll need to create, focus in on the most popular position in the team and build out skills for that first. It’ll help you flesh out the expectations of the other positions as you get to them, and help you ship the most value fast.

Getting started

Research and write

  1. Start by making a list of all the job titles within a team, then gather their corresponding job descriptions.

  2. Pick out the skills needed for each position, then list these out in order of importance — if you’ve got a lot of skills to work through, focus on a handful of the most important ones.

  3. Identify groups of skills that can be distilled down into a single skill, and choose a collective title.

For example, you might have a list of skills like:

  • Can establish purchase timeline

  • Closes the sale

  • Can drive buying decisions

  • Understanding buying process

  • Differentiates and overcomes objections

  • Can negotiate a price

  • Is results driven

This can be summarised as Negotiating and Closing.

Your final number of skills will depend on the number of core skills your framework’s required to have and how many skills can be shared across positions within the team.

Try to share skills across positions where you can — it’ll make it far easier to update and maintain them, and for employees to compare their position with another and see where they can go next.

Remember, a framework with fewer skills is easier to build, quicker to roll out, and simpler to manage day-to-day, so start small!

4. List out example behaviours for each skill — you should aim for at least three. For the Negotiating and Closing skill, the examples might be:

  • Establishes the buying process

  • Overcomes objections

  • Drives buying decisions

5. Enter the skill name, skill type and example behaviours into the AI Build Assistant.

6. Review and tweak the AI-generated content to make it your own.

You can also draw inspiration from our extensive library of skills — simply search for the skills you’d like to add, pull them into your framework then edit as needed.


Skills should be co-owned. Don’t spend hours labouring over a first draft — get the basics down, then build out with your teams.

Block out some time to sit down with the managers in the team and ask them what they think’s missing or irrelevant. Managers should do the same thing with their reports after the initial roll out, and again every six to twelve months to keep things relevant and up to date.

This isn’t a one and done project — your framework will evolve with real world usage. So remain open to feedback and make changes little and often.

It’ll save you time, and your employees will be bought in because they’ve had a hand in improving the content.

💡 But don’t design for Dave. Even though he has the loudest voice in the room. It’s important to capture everyone’s feedback on the skills, not just Dave’s. And remember, it’s about consultation, not group decisions — don’t let differences of opinion stop you from shipping quickly. Start using what you’ve got and change it later. Sorry Dave.