Team Competency Matrix


Each member of a team has their set of skills that contribute to the overall skillset of the team. However, quite often, these skills are not aligned with the skills that are necessary to develop the future product or service.

To determine and to subsequently decide how to close these gaps, the so called Team Competency Matrix can become useful. This article outlines my experience with this Management 3.0 practice and shows some extensions that I find useful.


Skill Matrix - Preparation
Figure 1: Team Competency Matrix – Preparation
  • Draw a matrix as illustrated in figure 1 on a large whiteboard. In the column headers, write the names of all team members.
  • Bring some sticky dots in three different colours to the workshop


Step 1 – Gather the required skills

Skill Matrix - Step 1
Figure 2: Team Competency Matrix – Step 1
  • In the first column list the skills that are present and the ones that are necessary to build the future product, together with the team.
    • Show the story map, the road map, or the product backlog to support the team.
    • These include technical and functional skills, technologies, tools, processes, practices and can also include soft skills.
    • I recommend, to arrange these competencies in the time these skills are needed (for later prioritisation).
    • I recommend, that the skills itself are defined more precise, e.g. instead of writing “JavaScript”, be more specific, e.g. “JavaScript performance optimisation” or “JavaScript Testing”; instead of “DevOps Skills” write “Docker”, “Chef” or, “Vagrant” or similar etc.
  • In the second column (optional) write down when the skill might be required – (roughly) derived from the roadmap
  • In the third column (optional), write down the duration the skill is needed. This can help to decide later how to improve this skill.
  • In the fourth column (optional), write down the reason why we need to have these skills. This is particularly useful to remember later why developing this skill is important.
  • In the fifth column write down the level and number of skills that are needed
    • Jurgen Apello suggests a simple measurement.
      • Expert Knowledge – I can teach others (green)
      • Practitioner – I have done it before (yellow)
      • Novice – I only have a vague understanding what you are talking about (red)
    • This coarse scale might not be able to represent the skill levels realistically; however, I find that anything more granular would make it more complicated for the team to agree on. You can compensate this drawback by defining the skills more precise, as mentioned above.

Step 2 – Collect the skills of the team members

Skill Matrix - Step 2
Figure 3: Team Competency Matrix – Step 2
  • In the next step, the participants should do a self-assessment of their expertise in these skills by placing dots (in the colours above) in the concrete columns.
  • Discuss the skills when you see the bigger picture (the skillset of the whole team).

Step 3 – Find ways to develop the missing skills

Skill Matrix - Step 3
Figure 4: Team Competency Matrix – Step 3
  • The aim is to align the skills of the team with the skills that are needed to build the product.
  • In the last column write down the action items (todos) that are necessary to close the competency gaps, e.g. training for …, pair-programming of … with …, tech talk about …, invitation of experienced mentors who teach the team in … etc.
  • As we agreed on the order of the items, we already know the priority of the action items (e.g. when to hire an external coach).


  • Place the list of required skills in your workplace. Mark them if this capability was improved as needed.
  • Consider skills building as agreed on above (during the Sprint Planning to include pair programming, as topic for a tech talk, to hire consultants or coaches or support from other departments on time etc.)


  • The Team Competency Matrix can boost the self-confidence of the team (“look how good we already are, we will even get better if we develop …”).
  • I recognised that it often uncovers concealed skills of team members (“I didn’t know that you also have a strong UX background …”).
  • It creates transparency for management and shows how skills building is necessary to develop the future product. This makes it easier to get training, coaching, others approved.

Further Readings


(Title Image by Paul Papadimitriou, Creative Commons 3.0)