Competency Matrix Template: How to Build One People Actually Use

A competency matrix is a grid: competencies down the side, people across the top, a level in each cell. That is the whole structure. Everything that makes one useful or useless happens in the definitions behind the grid.

The two definitions that matter are the competency statements and the level descriptors. Get those right and scoring becomes almost mechanical. Get them wrong and every review meeting turns into an argument about what a 3 means.

Five levels, 0 to 4, with behavioural descriptors. Resist adding half-points; the precision is imaginary and it slows scoring down.

One row per competency, grouped into three or four families so the grid stays readable. A worked example for a customer support team:

• Start with a verb the person performs, not an attribute they possess. "Diagnoses", "writes", "handles" — not "attention to detail".
• One competency per row. If the statement contains "and", it is probably two rows.
• Make it observable. If two managers watching the same person could not independently arrive at the same level, the statement is too vague.
• Keep it durable. Competencies tied to a specific tool version go stale every release; competencies tied to the underlying capability do not.

Score in one sitting, per competency rather than per person. Going down a row and rating everyone on the same competency produces far more consistent results than going down a column and rating one person on everything, because the comparison set stays fixed.

Where the competency is critical, back the score with evidence rather than impression. A short assessment gives you a repeatable number; a work sample gives you a defensible one. For everything else a manager rating is proportionate — just record that it was a rating, so nobody later mistakes it for a measurement.

Read down the columns for individual development plans: the two largest gaps between required and current are that person's next quarter. Read across the rows for team risk: any critical competency where only one person is at level 3 or above is a single point of failure, and that is usually the most valuable thing the matrix tells you.

The bus-factor read is worth doing explicitly. Count, for each critical competency, how many people sit at level 3+. Anywhere the count is one, you have a staffing risk that no amount of individual development addresses — you need a second person, and the person at level 4 is the one who should train them.

A competency matrix decays for a predictable reason: the competency definitions are stable but the scores are a manual snapshot, so within one quarter the grid describes a team that has changed. The document then gets quietly ignored, which is worse than not having it, because decisions still reference it.

The fix is to separate the two halves. Keep the competency and level definitions as a deliberate, slow-moving document reviewed once or twice a year. Let the scores come from something that refreshes on its own — recurring short assessments, ticket quality sampling, or structured observation on a schedule. When the score half updates without anyone opening the file, the matrix stays true.