How to design Skill Grids for your product design team
When you manage a team, you want to have a clear view of everyone’s skills. Not only to be able to fairly evaluate your collaborators, but also to be able to support their up skilling. That’s why, when I arrived at OpenClassrooms in March 2020, one of my first missions was to design my team’s skill grids: one for Product Designers, one for Ux Writers (that we call now “Content Designers”) and more recently, one for User Researchers.
Lucky me, OpenClassrooms being an online school, they already had a framework to design this kind of grid and I must tell you: it works really well!
In this article, I’ll share with you the different steps you need to go through to build great skill grids for your team, and how useful it is in a managers’ daily life.
Our grids are open source. Feel free to use & adapt them:
Define Hard skills & Soft skills
The first thing is to identify the hard & soft skills that are required for a specific job:
- Hard skills (also named “technical skills”) are teachable abilities or skillsets that are easy to quantify. They are related to technical knowledge, like tools or methodologies.
- Soft skills (also named “human skills”) are subjective skills that are harder to quantify. They are related to the way you interact with other people.
1. Ask people who practice this job every day
To identify hard and soft skills, the best way is to ask professionals who are doing that job on a daily basis. We sent a survey first to our teammates and then to Lead Designers and other experts of the position. We asked them to identify three to six key activities describing their job:
Regarding soft skills, OpenClassrooms already has a common framework of 9 soft skills, so we just asked participants to choose the three most important ones:
2. Group the answers and analyze the results
Once we had collected enough data, we had the team do an asynchronous grouping exercise: the goal was to identify answers that can be grouped into similar skill sets. We used Optimal Workshop, which offers a card-sorting tool to group similar categories and provides dendrogram visualizations of the results:
Then we went through a process of renaming precisely each skill and each category to be sure they’re clear and relevant to the job.
3. Identify methods and tools used within each skill context
Finally, for each skill, we define the most relevant methodologies and tools needed. For example, to create and maintain a Design System, you’ll need to master a design tool and a documentation tool, and to be comfortable with methodologies such as Atomic Design or semantics:
Define relative skills
Growing in a position requires the ability to collaborate with other people from other areas of expertise. To do this, an expert needs to acquire knowledge from these other areas. We call it the T-shaped skills.
As an example, we think that Product Designers should learn some basics among these other areas of expertise:
We represent these relative skills in exactly the same way we represent the core competencies, but in a dedicated section. In fact, core competencies in one position (Ex: Ux Writing) will become relative skills for another position (Ex: Product Designer). We don’t ask people to master all the competency blocks, but only one or two, depending on what kind of Product Designer they want to be (Ex: more data-oriented or more brand-oriented). It also helps us with recruitment, as we will take a closer look at profiles that have a background in one of those domains.
Define levels of competency
For each skill, each collaborator needs to define their level of competency. At OpenClassrooms, we have 4 levels:
- Unskilled: team members are unconsciously incompetent in the specific skill. A lack of knowledge prevents them from fully understanding the scope of the skill.
- Semi-skilled: team members are consciously incompetent in the specific skill. They are aware of what the skill entails and have a sense of where their ability falls short.
- Skilled: team members are consciously competent in the specific skill. Their experience is starting to turn into expertise.
- Highly skilled: team members are unconsciously competent in the specific skill, and it is second-nature.
When they join OpenClassrooms, collaborators are invited to assess their skills through the grid:
This helps collaborators identify their primary strengths and areas for improvement. We also encourage team members to comment on their assessment for each skill:
- For example, if they selected “semi-skilled” for a specific skill: are they semi-skilled at 20%? Or already at 90% and therefore really close to the “skilled” level?
- They can also highlight the skills they particularly want to improve and think about what their next steps are in order to succeed.
Final result
Thanks to these different steps, we now have a ready-to-use skill grids for our team. Here is an example of the final result for the Ux Writer’s skill grid:
We use this grid every three or four months in 1:1s to monitor a team member’s progression and plan their next career steps.
To go further
It’s just incredible what you can achieve with this amazing management tool! Here are some examples of workshops we regularly run around skills:
Define levels for the entire team
Being able to place themselves on a personal skill grid is valuable for collaborators, as they can monitor their own progression. But it can be difficult for them to define their skills level in comparison to their teammates. That’s why every year, we run a “Competency Workshop” in which team members place themselves on the grid and then place their peers. We then discuss the positioning of everyone, improve the understanding of our main skills, and refine the grid if needed:
This kind of workshop is not easy to run, as it can create some debates within the team and sometimes people can feel that their true level is not sufficiently recognized by their peers. That’s why hard skills must never be the only way to evaluate collaborators. We also take into account soft skills, Quarterly Goals, engagement with our values, and impact across the team, the squads, and the whole company. Collective intelligence is a great starting point, but we also need managers who will recalibrate the different levels and keep the global overview.
Monitor quarterly progression
Thanks to these grids, my team managers and I are are now able to map the skills level of each team member to better monitor their main strengths and ways to improve:
This visualization is also very useful when it comes to up skilling the team: we can easily identify who needs to be trained on a specific skill, and who is able to train others.
Identify the most needed skills per squads
In order to effectively place people within the squads, we also try to understand what it takes to be Product Designer for that specific squad.
That’s why, when we open a new squad, we run a workshop with Product Managers and Product Owners to map the main skills needed. Depending on the collaborators’ expertise and career wishes, we are then able to find the perfect match:
Recruit new team members
When we have a good knowledge of main competencies per squad, we are able to define which next recruitment we should do in terms of the skills we already have within the team and the skills that are missing. This allows us to make more relevant recruitments:
Thanks to this process, we decided last year to recruit an Interaction Designer and a Service Designer that bring new expertise to the team!
Next challenges
At OpenClassrooms, the Technology Team has a strong policy of salary transparency. And I have to say, it’s not always easy to manage. Salary transparency means that everyone in the team knows each other’s salary, so we need to make sure that the remuneration is fair and reflects the skills level of each collaborator. This is a day-to-day challenge and we constantly do benchmark checks to ensure our skills are aligned with the industry and that our grids are still relevant regarding the market and our newcomers’ skills levels.
And even if skill grids are helpful, we know that we still need to go further. Collaborators ask for more accurate tools to assess their skills on the grid as tests or quizzes to check competencies. We will therefore continue to work on improving our skills assessment process. That will surely be another amazing journey and a good topic for a new article ;)
Our grids are open source. Feel free to use & adapt them:
