How to build an employee skills matrix that leads to better decisions
A team can have several experienced developers and still depend on one person to investigate a failed data import. A list of job titles will not reveal that dependency. An employee skills matrix can, if its ratings describe work people can actually do.
A skills matrix maps people against the capabilities a team needs. Its purpose is to support a decision: where to provide practice, who can pair on a task, or which capability needs more coverage. This guide shows how to build a small version for a tech team in 2026, including the judgement needed around AI-assisted work.
Start with the next piece of work
Choose one upcoming outcome, such as making a customer onboarding process more reliable. List six to ten capabilities needed to deliver it. Use observable activities: investigate an import failure, explain a data retention decision, test keyboard navigation or review an AI-generated summary against its sources.
Avoid a column called simply “AI”. Using a tool to draft text and checking whether its output is trustworthy require different capabilities. Keep collaboration visible too: explaining a technical constraint or facilitating a decision can matter as much as writing the implementation.
The SFIA framework can help teams find a shared vocabulary for digital skills. SFIA 9 is the current version at this review. The simple scale below is a local exercise, not a SFIA assessment or a mapping to its seven responsibility levels.
Build the matrix in four steps
1. Describe what each level means
Purpose: Make ratings discussable and consistent.
Use “not yet assessed” separately from a demonstrated beginner level. Someone who has not had an opportunity to perform a task should not automatically receive the lowest rating.
- 1, supported: can complete a defined task with guidance and explain the main steps.
- 2, independent: can complete and check a routine task, recognising when to ask for help.
- 3, supports others: can handle relevant exceptions, explain trade-offs and guide a colleague.
Write one example for each capability. For import failures, level 2 might mean locating the failed records, identifying the cause and validating a safe correction in a test environment. Course attendance alone does not demonstrate this.
2. Add evidence and opportunity
Purpose: Understand what sits behind the rating.
Ask each colleague to propose a level and a recent example. Discuss it together rather than assigning scores in private. Record the example date, relevant context, whether help was needed and an agreed review date. Link only to work that the intended viewers are permitted to access.
Keep interest and opportunity in separate fields. A colleague may want to learn deployment but never have been invited to help with a release. That calls for access to practice, rather than a conclusion about motivation. Make expectations and routes to reassessment available to everyone.
3. Look at coverage before averages
Purpose: Find dependencies that could interrupt delivery.
Illustrative example: a fictional team has assessed three colleagues against three capabilities. For import investigation, Asha is level 2, Beth level 1 and Cara not yet assessed. For keyboard testing, Asha is level 1, Beth level 2 and Cara level 2. For AI-summary verification, Asha and Beth are level 1 and Cara level 2.
If the team agrees that two people should be able to work independently on each critical capability, import investigation has one of two required people, keyboard testing has two of two, and AI-summary verification has one of two. These are discussion thresholds chosen for the example, not universal staffing requirements.
Do not average the ratings into an overall employee score. That would hide the dependency and treat different capabilities as interchangeable. Availability, system access and capacity still need checking before assigning work.
4. Turn one gap into supported practice
Purpose: Give the matrix a consequence people can see.
For the import gap, agree that Beth will pair with Asha on a test failure, then investigate a second example while Asha observes. Protect time for both people. The evidence to review is Beth’s diagnosis and validation, not the number of tutorials completed.
Record the practice task, support person, time allocation, evidence and review date. Ask whose existing work must move to make this possible. Adding training to an already full workload makes the development plan difficult to deliver.
Keep the information useful and fair
Agree who can view individual evidence, how colleagues can correct it and how long it remains useful. Share team-level coverage more widely where that is sufficient. Exclude health details, speculative personality judgements and private review notes from a shared capability grid.
When tools change, review the capability rather than simply adding another brand name. For AI-assisted work, ask whether someone can identify unsupported output, protect confidential inputs and decide when a human review is necessary. A tool’s fluent answer is not evidence of the operator’s independent competence.
Try a 30-minute first version
Choose one delivery decision and three capabilities. Spend ten minutes agreeing the definitions, ten discussing evidence and ten choosing a supported practice opportunity. Let people correct the draft afterwards. Book a review after that practice has happened, or sooner if the work changes.
The useful result is an agreed next action: who will practise what, with whose support, and what will demonstrate progress. If the matrix cannot help you make that decision, simplify it.
Sources and review
Reviewed 19 October 2026. Framework context: SFIA 9 browsing guide and how SFIA combines skills and responsibility. The local scale, fictional team and workshop are original illustrative exercises.
You May Also Like
Town hall meetings for companies: a practical guide for tech teams
Unleashing Creative Innovation: “Design the Thought”
