Skills matrices for infrastructure teams: knowing who can cover which client

It is a Friday evening and the engineer who looks after a retail client's storage arrays has called in sick. The client has a failed disk alert. The operations manager scrolls through the team chat, trying to remember who else touched that environment last year. Three people are guessed at, two are on leave, and the sixth message in the thread is a plea.

That scramble is what a skills matrix is meant to prevent. This post shows how to build one that people actually keep current, using only the information your team already has.

A skills matrix is a grid. Down the side are your engineers. Across the top are the things the work needs: client environments, platforms, tools and tasks. Each cell holds a rating of how well that person can handle that item without help.

It is not an appraisal and it is not a certification list. A person may hold a cloud certificate and never have handled a production outage. Another may have no certificate and may have rebuilt a client's firewall twice. The matrix records working ability, which is what covering a client really needs.

Teams often start with fifty columns and give up by week two. Begin with the client accounts, because cover is a client question first. For each account, list the three or four technologies that matter most, such as the hypervisor, the backup tool, the monitoring stack and the ticketing process. If you run a cloud services practice, add the cloud accounts and the infrastructure code repositories by name.

• One column per client account that has its own runbook or access.
• One column per shared platform that several accounts use.
• One column per recurring task that only some people are trusted with, such as patch windows, failovers or firewall rule changes.
• Leave out anything that every engineer on the team already does daily.

A five or ten point scale invites arguments about whether someone is a six or a seven. Four levels are enough for cover planning. Write each level as a sentence that anyone can test.

• Level 0: has not seen this environment or tool.
• Level 1: has shadowed someone and can follow a runbook with a senior on call.
• Level 2: has handled routine tickets and incidents on this alone.
• Level 3: can diagnose unfamiliar faults here and can teach others.

1. 1

   List accounts and tasks

   Pull the client list from your service desk and the on-call rota. Agree the columns with the team leads on one call.

2. 2

   Pre-fill from tickets

   Export the last six months of tickets by assignee and account. Mark a draft level 2 wherever someone has closed several tickets alone.

3. 3

   Hold a short review per person

   Ten minutes each. Confirm or change the draft, and ask what they would like to learn next.

4. 4

   Mark the red cells

   Shade any column where fewer than two people sit at level 2 or above. These are your single points of failure.

5. 5

   Turn red cells into tasks

   For each gap, name a learner, a teacher, a first task and a date. Put it on the same board as client work.

Look down the columns first. A client with one person at level 2 is a resignation away from a crisis. Then look across rows. An engineer who is the only cover for four accounts is both valuable and overloaded, and may be quietly looking elsewhere.

The matrix also helps with on-call design. If your night roster pairs two people who both sit at level 1 for a critical account, the pairing is a risk. Our note on rosters for a security or network operations centre covers fairness, and the matrix gives you the cover logic to go with it.

Cross-training works best when it is paired with real work. A learner shadows the owner on a patch window, then leads the next one with the owner watching, then does the third alone. Record each step in the matrix by moving the cell up a level. Engineers like seeing their own cells turn from 0 to 2, and it gives you a plain record for conversations about growth. This links naturally to competency and talent management, where the same skills data feeds career paths.

Sheet 1 columns: Engineer, Team lead, Date last reviewed.
Sheet 1 account columns: Account A, Account B, Account C (one per client).
Sheet 1 platform columns: Backup tool, Monitoring, Virtualisation, Firewall, Cloud account.
Cell values: 0, 1, 2 or 3, with a comment box for the evidence.
Bottom row: count of people at level 2 or above, shaded red if fewer than two.
Sheet 2: Gap list with learner, teacher, first task, target date, status.

• Review it in the first team meeting of every quarter.
• Update it within a week of any resignation, new client or tool change.
• Add it to the checklist for hiring: a new joiner's first columns should be filled within the first month.
• Keep the sheet in the same folder as your runbooks, so the people who need it can find it at night.

Hiring also changes shape once the matrix exists, because you can write a brief around the exact gap. A team missing network depth needs a different person from one missing automation, as set out in our piece on hiring cloud and DevOps engineers.