A skills matrix for a team of eight
The useful output is not who is good at what. It is the list of capabilities exactly one person can do.
A skills matrix is usually built for development conversations and then abandoned because nothing depends on it. Built for resourcing instead, it answers two questions a headcount total cannot: whether a piece of work can be staffed at all, and which capabilities would leave the building with one person. The method is a grid of capabilities against people, a four-level scale that describes evidence rather than confidence, and a coverage count per row that turns the whole thing into a risk register.
Build it for staffing, not for appraisals
Most skills matrices die because they are built as a development artefact. Someone rates everyone, the file is saved, and no decision ever consults it. A matrix built for resourcing survives, because it is the thing you open when a project arrives and you need to know whether you can staff it.
That changes what goes in it. Not job titles or seniority bands, but the capabilities a piece of work actually demands. Atlassian's definition of capacity planning names this explicitly: it is determining the resource needs of your project by analysing workloads, team availability and individual skillsets. Skillsets sit alongside availability, not underneath it. Two hundred available hours of the wrong capability is zero hours of capacity.
It also changes who maintains it. A matrix owned by whoever assigns work stays current, because it is wrong in a way they notice. A matrix owned by nobody is out of date within a quarter and quietly misleading for years.
Pick rows at the grain of a work assignment
The hardest part is choosing the rows, and the failure is at both extremes. Rows like analytics or engineering are too coarse to staff against. Rows like a specific vendor's connector version are too fine to maintain and too volatile to be useful.
The right grain is the level at which you would assign a piece of work. GA4 and GTM implementation. Warehouse modelling. Paid search account structure. Client-facing programme reporting. Incident response on ad platforms. If you can imagine writing that phrase on a ticket, it is a row.
Aim for a number you can review in twenty minutes, because that is how often it needs revisiting. For a team of eight, somewhere between twelve and twenty rows usually covers everything you sell without collapsing into a taxonomy exercise.
Add one row that firms consistently forget: client-facing judgement. The ability to run a difficult conversation, say no to a request, or explain a technical constraint to a sponsor is a capability, it is unevenly distributed, and it is frequently held by one person. Leaving it off does not make it less scarce.
Score against evidence, not confidence
| Level | What it means | Evidence required | Can be assigned |
|---|---|---|---|
| 0 | No working knowledge | None | No |
| 1 | Can do it with review | Output reviewed by a level 2 or 3 at least twice | With a named reviewer |
| 2 | Can do it independently | Shipped to a client without correctness findings | Yes |
| 3 | Sets the standard | Has reviewed others and handled a non-standard case | Yes, and can cover a 2 |
Self-assessment on a five-point scale produces noise, because the scale measures self-belief. Anchor each level to something observable instead, so two people scoring the same person land in the same place.
Four levels are enough. Zero means no working knowledge. One means they can do it with review, and someone has actually reviewed their output. Two means they can do it independently and have shipped it to a client. Three means they can set the standard, review others and handle the unusual case.
The word that does the work is shipped. A person who has read the documentation and a person who has run a migration under a vendor deadline are not the same score, however similar the conversation sounds. Anchoring on delivered work also makes the matrix defensible when someone disagrees with their rating, because the disagreement is about a fact rather than about esteem.
The coverage count is the whole point
Once the grid is filled in, add one column at the end of every row: how many people are at level 2 or above. That single number converts a development artefact into a risk register, and it is the only output most firms will ever act on.
A count of zero means you are selling something nobody can independently deliver, which is usually a surprise to whoever wrote the proposal. A count of one is key-person risk with a name attached. Two is workable but fragile across a holiday. Three or more is genuine resilience.
Read the counts against your revenue rather than in isolation. A capability with a count of one that appears in ten percent of your work is an inconvenience. The same count on the capability that underpins your largest retainer is the single largest operational risk in the business, and it will not appear on any financial statement.
That is the direct input into succession work: the rows returning one are the list, in priority order, and what to do about them is set out in succession planning when one person knows everything.
What the matrix tells you that a headcount cannot
Check demand against the matrix rather than against the team total. A project needing eighty hours of warehouse modelling and a hundred and twenty of coordination is not covered by two hundred available hours of a senior engineer, however encouraging the total looks.
Microsoft's Azure Boards documentation draws the same distinction on the time side: capacity is set per sprint because it takes into account variation in work hours, holidays, vacation days and nonworking days. Capability is the second axis of the same problem. Someone can be available and still not be able to do the work in front of them.
Run both checks together and the answer stops being a debate. The full subtraction on the hours side is in capacity planning for a team that also sells, and the shape of the team that results is the subject of team topology for multi-client delivery.
A migration of 154 data sources to Tableau Cloud that ran with zero unplanned production outages consumed a specific mix of capabilities in a specific order. No headcount figure would have told you whether that mix existed. The matrix would.
Turning a count of one into a count of two
There are only three moves, and the matrix tells you which is available. Train somebody already at level one. Hire or contract for it. Or stop selling it.
The third is a legitimate answer and it is almost never considered. A capability held by one person, sold rarely, and carrying real delivery risk may be worth retiring from the offer rather than resourcing. That decision is easier when the count is written down next to the revenue it supports.
Where training is the answer, the cheapest mechanism is pairing on real client work rather than a course, because level two requires shipped output and a course cannot produce it. Atlassian's resource management guidance notes that maintaining a view of allocation helps teams identify potential constraints or bottlenecks before they impact project timelines, which is what a coverage count is for. Fund the second person before the constraint bites, not during the incident.
Where the honest answer is that nobody has time, the matrix has just told you what your bench time is for, and the argument for spending it deliberately is made in what to do with bench time before it becomes a cost.
Keeping it alive
Review it quarterly and at two events: when someone ships a piece of work that changes a score, and when a project cannot be staffed. The second is the more valuable trigger, because a staffing failure is the matrix telling you a row is missing or a score is wrong.
Keep the history. A capability that has been at a count of one for four consecutive quarters is a decision nobody has made, and seeing that stated as a number is more persuasive than any amount of discussion about resilience.
Do not let it become a performance instrument. The moment scores affect pay, they stop being evidence and start being negotiation, and the coverage count, which is the only part that ever prevented anything, becomes unreliable.
Where the matrix keeps saying the same row is uncovered and nothing changes, the constraint is usually not skills at all. It is that nobody owns sequencing the work so the gap can be closed between engagements, which is the job a fractional technical project management engagement is normally brought in to do.