We Found 3 Single Points of Failure in an 11-Person Team: the 7-Step Skills Matrix I Wish We Had Built in January

The audit started for a boring reason. An engineer asked for three consecutive weeks of leave in December and the lead said he would have to check. Checking took a day, the answer was effectively no, and nobody could explain why in a way that survived a follow-up question. So we mapped it: eleven engineers, nineteen failure modes. Three of those nineteen had exactly one person who could handle them, and one of those three was the engineer asking for leave. He got the leave. What changed was everything we did in the eight weeks around it, and this is the method that fell out of it.

Step 1: Write Failure Modes, Not Skills

A skills list is an inventory and an inventory invites completeness. You end up with ninety rows, most of them irrelevant, and no appetite to score any of them a second time. A failure mode list is a different object: it only contains things with consequences, and it is therefore naturally short.

So write each row as something that goes wrong. “A payment reconciliation mismatch is reported and nobody can trace it to a root cause.” “A schema change needs reviewing and the only person who understands the constraint is unavailable.” “An alert fires at 2am on the ingestion pipeline and the responder does not know the normal baseline.” Each of those names a capability without naming a technology, and each one is immediately scorable, because somebody in the room either can handle it or cannot.

Nineteen rows was right for eleven people. The discipline worth keeping is that a row has to describe something that would actually inconvenience a customer or a deadline. If the worst case for a row is that work is slightly slower, it is not a failure mode and it does not earn a line.

Step 2: Build the First Draft From Records, Not a Survey

This is the step I would most want to pass on. Do not open with a questionnaire. You already hold better evidence than a questionnaire can produce, and it costs nothing to extract.

Three sources carry most of it. The on-call log tells you who was actually paged for which system and who got escalated to afterwards. The review history tells you whose approval changes in an area waited on, which is a sharper signal of real ownership than any job title. The incident record tells you who found root cause, which is different again from who was assigned the ticket.

Draft the whole grid from those three and only then take it to the leads. The conversation that follows is a correction rather than a confession, and that distinction is the entire difference between usable and useless data. When you hand an engineer a row that says they are the sole holder of something, based on the review log, they argue with the evidence rather than with their own modesty. Twice in our case the argument was right and the row had a second holder nobody had recorded.

Step 3: Three Depth Bands, Plus the Holder’s Route

Three bands are enough: cannot handle it, can handle it with help, can handle it alone. Four or five bands create arguments about the boundary and do not change any decision you are going to make.

Then add the column that makes this a Singapore matrix rather than a generic one. Next to each holder, record their employment route: local hire, employment pass, or contractor. This is not about anybody’s standing in the team. It is about how long replacement takes, because the practical path back to a productive person differs by route, and a pass route may add application and relocation steps on top of a notice period. Our notes on the employment pass process for tech talent cover what that sequence actually looks like in practice.

The route column changes which rows worry you. A failure mode with two holders looks safe until you notice both are on the slowest replacement route and one has a renewal coming. A row with one local holder and one contractor is a different risk again, because the contractor’s knowledge leaves on a known date. Depth alone cannot show you either of those.

Step 4: Test Against Three Weeks of Leave

The standard stress test is to ask what happens if a person resigns. It does not work, and the reason is social rather than analytical. Nobody wants to say a colleague is irreplaceable in front of them, nobody wants to hear that they are, and the question invites reassurance.

Ask about three weeks of leave instead. It is mundane, it has usually already happened, and the answers come back concrete: this release waits, that review queues behind one person, this alert routes to somebody who does not know the baseline. You get the resignation answer without the discomfort, and because leave is far more frequent than resignation, the evidence is recent.

Run every row through it. Ours produced the three single points of failure, and more usefully it produced a fourth category we had not expected: two rows where the team coped fine with absence but only by deferring work that then arrived as a cluster afterwards. That is not a skills gap, it is a capacity gap wearing a skills costume, and it belongs in capacity planning rather than in a requisition.

Step 5: Fork Each Gap Four Ways

The default move is to turn every gap into a requisition. It is the wrong default in most markets and it is particularly wrong here, because the training branch is unusually strong in Singapore: structured upskilling support exists, it is well used, and an engineer reaching competence in eight weeks frequently beats a search that concludes in twelve.

Our three critical rows went three different ways, which is the point. Payment reconciliation became a training assignment, because a second engineer was already at “with help” and only needed review time. Schema review became a hire, because nobody was close and the need was permanent. The pipeline on-call row became a documentation and rotation fix, which cost nothing and was the only one where I had initially assumed a hire. On the pass-route branch, eligibility depends on a points-based framework that weighs the role and the shape of the existing team, which our notes on scoring a developer pass application go through step by step.

Step 6: Sequence by Lead Time, Not by Severity

This is where plans lose a quarter, and we nearly did. The instinct is to start with the worst gap. The correct move is to start with the slowest route, because the binding constraint is elapsed time to a productive person and not the ranking of your worries.

Lay the four branches out by realistic duration. A documentation and rotation fix lands in days. A training assignment produces a second holder in weeks, assuming somebody is genuinely at “with help” and a reviewer is named. A local search runs for a couple of months before anybody is productive, because notice periods here are commonly one to three months on top of the search itself. A pass route adds further steps before a start date exists.

So the slowest branch starts first, even when its row is third on your severity list. We started the schema review search in week one and did the reconciliation training in week three, which felt backwards and was correct: the training finished before the search produced a shortlist. Had we run them in severity order, both would still have been open in December with the one person who could do either of them away on the leave that began the whole exercise.

One more sequencing note specific to this market: an internal transfer is often the fastest branch of all and the one least likely to be considered, because the person is already here and already eligible. It is worth checking before a search, and our notes on internal developer transfers cover how to do it without simply moving the gap to another team.

Step 7: Re-Run on Events, Not on the Calendar

A quarterly review sounds disciplined and it misses things, because the events that change a matrix do not arrive on quarter boundaries. Three triggers are worth wiring in instead.

Any departure or internal move, because that is when a row silently drops to one holder, and the day you learn it should be the day the move is announced rather than six weeks later. Any newly committed deliverable, because a row nobody worried about becomes load bearing the moment dated work depends on it. And any contractor ending, because their knowledge leaves on a date everybody can already see in a calendar and almost nobody connects to the grid.

Each re-run is twenty minutes once the grid exists, since you are updating a handful of cells rather than rebuilding. The thing to protect is the correction pass with leads, which is where the real information still lives. And keep the grid away from the appraisal cycle permanently: the moment people suspect their row affects progression, scoring becomes negotiation and you lose the instrument. Our notes on training an interview panel cover how to move a row into a screening scenario once a gap does turn into a hire.

What the Exercise Actually Changed

He took the leave. The reconciliation row had a second holder by the time he left, not a confident one but enough to triage and escalate sensibly, and the one incident that occurred during those three weeks was handled without calling him. The schema review hire started in February. The pipeline row turned out to need a rotation and a page of documentation rather than a person, which was the cheapest finding and the one I was most wrong about.

The part worth stealing is not the grid. It is the sequence: failure modes rather than skills, records rather than a survey, leave rather than resignation, and lead time rather than severity. Each of those four swaps removes a specific way the exercise normally goes wrong, and together they take an afternoon. The alternative is finding out which rows have one holder when that holder hands in notice, which is the version most teams run without choosing to.

FAQ: Skills Gap Audits for Singapore Engineering Teams