A skills matrix turns a judgment about people and skills into a grid that can be discussed and checked. Two useful versions answer different questions: a team-level discipline matrix shows which skills are available and where capacity is thin; a role-level matrix describes what performance looks like at each seniority level. Tailor either one to the work and the organization rather than treating a template as universal. section 4.2.2 section 7.1.1
To map the team's disciplines before a hiring decision:
- List the broad skills needed for projects and business objectives, then score each team member's competence in each skill. Mark a skill held by only one person so a satisfactory score does not conceal dependence on that person. section 4.2.2
- Compare current capability with the need. Revisit the need as projects change; separate columns can distinguish current projects, the next six months, and later work. section 4.2.2
- Use the gaps to question an immediate request for a particular job title. Consider which combination of skills would relieve pressure, support the project, and remain useful afterward. section 4.2.2 section 4.2.1
A gap that a total can hide
A team may appear to meet its AWS requirement while relying on one person for all of that skill. The hiring question is not simply whether the current total is adequate, but what happens if that person leaves. By contrast, a shortfall in another discipline points to a different kind of need. section 4.2.2
The team grid shows individual scores, skills held by only one person, current totals, need, and the resulting gap. section 4.2.2
For reviews, make a separate matrix for each role. Put competencies down one axis and seniority levels across the other. Include both technical and interpersonal expectations where they matter: an engineering role might cover discipline knowledge, business knowledge, communication, planning, ownership, problem-solving, and mentoring. Write one or two sentences in each cell describing success at that level. The descriptions should be specific enough to support concrete examples, but short enough to talk through. section 7.1.1 section 7.1.2
Table 7.1 Basic matrix structure—Developer (view table figure)
The developer grid illustrates how expectations change from junior to senior across competencies such as communication and planning. section 7.1.2
Before a review, give the person their role matrix and ask them to assess their level with examples; prepare a manager assessment as well. Compare the two, concentrate the conversation on differences, and rate where the person performs consistently rather than letting one incident decide the result. If promotion expectations are not yet met, identify what must change and set a date to revisit them. The same defined areas can also shape interview questions and candidate ratings. section 7.1.3 section 7.1
