I Mapped 14 Engineers Against 31 Skills and Found We Were Hiring the Wrong Role: the 7-Step Gap Analysis

We had a senior backend requisition open for five weeks and I could not explain, in one sentence, what the person would do that nobody already did. That is an uncomfortable position to be in with a budget approved. So I spent an afternoon building a grid: 14 engineers down one axis, 31 capabilities across the other. The requisition was wrong. We did not need another senior backend engineer. We needed one person who could own data modelling, which exactly one engineer could do and she was the only one, and we needed a contract for a migration nobody should be hired permanently to perform. Here is the method, including the two columns that made the difference.

Step 1: Write Capability Rows, Not Technology Rows

The first version of my grid listed technologies, on down the stack until I had more than ninety rows and no appetite to score any of them. Technology rows feel rigorous because they are concrete, and they are nearly useless for a hiring decision. They measure familiarity rather than ability, they double count the same person, and they go stale the moment you change a framework.

Rewrite each row as something the team must be able to do, with no product name in it. “Design a schema that survives a tenfold growth in rows without a rewrite.” “Take a service from first alert to root cause without escalating.” “Decide what to log, and prove a change improved a metric.” “Review somebody else’s migration and catch the dangerous part.” Those rows survive a stack change, they cannot be satisfied by having read the documentation, and each one maps to a question you could actually ask in an interview.

Aim for twenty to forty rows. The constraint is not completeness, it is whether the whole grid can be re-scored in an afternoon, because a matrix that is never re-scored is a slide and not an instrument. My rule for admitting a row: if its score would not change a hiring, training or staffing decision in the next two quarters, leave it out.

Step 2: Score on Four Levels, Against Evidence

Use four levels, not five, because five gives everybody a comfortable middle. I use: cannot do it yet, can do it with support, can do it alone, can set the standard and teach it. The last level is deliberately hard to reach and should be rare.

The important half of this step is the anchoring. Every score needs an artefact behind it that somebody else could look at: work merged in that area in the last two quarters, an incident handled without escalation, a design document others followed, a review that caught something real before it shipped. Record the artefact in the cell, not just the number. When you re-score next quarter, the artefact is what tells you whether a score moved or your memory did.

Let people self-score first, then reconcile with their lead against the evidence. Self-assessment on its own is not a measurement, because it tracks confidence and tenure as much as ability and the error does not point the same way for everybody. The reconciliation conversation is frequently more valuable than the resulting grid: it is where you find out that the person you considered your platform expert has not touched that area in eight months.

Step 3: Add the Two Columns Everybody Omits

This is the step that changed our requisition. Alongside the scores, add two summary columns per capability row.

Bus factor: how many people score at “can do it alone” or above. Not an average, a count. An average of 2.4 across fourteen engineers looks healthy and can describe a row where one person holds everything and thirteen hold nothing. Our data modelling row averaged respectably and had a count of one.

Recency: when did each person last do this work. A capability someone genuinely held two years ago and has not used since is not available to you next quarter at the level the grid claims, and it is the single most common way a matrix lies. A dated cell makes that visible without anybody having to admit anything.

Sort your rows by bus factor ascending and you have a risk register you did not have yesterday. Every row with a count of one is a single point of failure. Every row with a count of zero that your roadmap needs is the real hiring conversation, and it is rarely the role you had already written.

Step 4: Overlay the Roadmap, Not the Org Chart

A gap only matters if something you have committed to depends on it. So take the next two or three quarters of actual dated work and mark which capability rows each piece requires. Not the aspirational roadmap, the work with a date and an owner.

Three useful things fall out immediately. Some gaps turn out to be irrelevant, because nothing committed touches them, and you can stop worrying about a row that looked alarming. Some comfortable rows turn out to be load bearing for three separate deliverables at once, which is a capacity problem rather than a skills problem and belongs in engineering headcount planning instead. And a small number of rows are both empty and required by dated work, which is your genuine hiring shortlist.

Do not overlay the org chart. Titles tell you what people were hired to do and not what the team can currently do, and in a team that has grown through a couple of reorganisations the two have usually drifted apart. The matrix is interesting precisely because it ignores titles.

Step 5: Split Every Gap Into Hire, Train or Contract

This is where most skills matrices quietly fail: every gap becomes a requisition, the budget goes on the broadest-sounding role, and nothing gets measurably better. Sort each surviving gap on two axes instead. How durable is the need, and how long would it take an existing engineer to reach “can do it alone”.

Our fourteen-person grid produced nine gaps. One was a hire, the data modelling row with a count of one. Two were training, both rows where somebody was eight months out of practice rather than incapable. One was a contract for a migration with an end date. The remaining five were not gaps at all once the roadmap overlay removed them. The original senior backend requisition was none of the above, which is why it had stayed open for five weeks: nobody could describe the work, because the work did not exist in that shape.

Step 6: Write the Requisition From One Matrix Cell

A requisition that comes out of a matrix cell writes itself, and it is noticeably better than one written from a title. You already know the capability, the evidence that would prove somebody has it, the dated work that needs it, and who in the team will be the second holder afterwards.

Put four things in writing before the first screening call. The capability in plain language, lifted from the row. The screening scenario, built from the artefact you used to score it internally, which is the approach in our notes on building a technical interview scorecard. The first ninety days expressed as the specific gap this person closes, which doubles as the start of a UAE probation plan. And the walk-away number, set against a basket you rebuilt yourself rather than one a tool served you, as covered in our notes on building a Dubai salary benchmark.

One cell, one requisition. Resist bundling two gaps into a single role to save a hiring round. The composite job description is how you end up interviewing for a person who does not exist, rejecting strong candidates for missing half of an invented profile, and reopening the search in March.

Step 7: Re-Score on a Cadence and Read the Drift

A matrix scored once is a snapshot and mildly interesting. Scored every quarter, it becomes the earliest warning a hiring plan can get, because what matters is not the absolute scores but the movement between them.

Three patterns are worth acting on. A row dropping from two holders to one, which usually precedes somebody leaving or a project absorbing them. A row where recency slips for everybody at once, which usually means the capability has quietly migrated to a vendor. And a row improving without anybody planning it, which identifies the person growing fastest and most worth retaining deliberately.

Put it on a fixed date, keep it to an afternoon, and do it with leads rather than in a workshop. In the UAE the cadence earns its keep for a structural reason: much of the engineering talent here is on employment visas tied to the employer, so departures remove a capability outright instead of thinning it, and replacement runs through offer, notice, visa processing and medical before any code is written. Discovering a bus factor of one in the exit interview is the expensive version, which is partly why we keep notes on what exit interviews reveal about attrition in Dubai. The matrix costs an afternoon a quarter.

What the Afternoon Actually Changed

We closed the senior backend requisition and opened a data modelling role written from one row, with a screening scenario taken from the design document our single holder had produced the previous quarter. We put a second engineer alongside her with an explicit objective of reaching “can do it alone” on that row, which gave her something she had been asking for without using these words: somebody to review her work. We signed a three-month contract for the migration. And we found two rows nobody had worried about where recency had slipped past a year, both of which turned out to have moved to a vendor without a decision ever being taken.

The uncomfortable part is that the matrix taught me nothing the leads did not already know in pieces. It only put the pieces in one grid where the pattern was unavoidable. That is also why the quarterly re-score matters more than the first build: the first tells you what you half knew, and every one after tells you what changed. For the equivalent exercise on the code rather than the people, our notes on running a technical debt audit before hiring cover the other half.

FAQ: Engineering Skills Matrices and Gap Analysis in Dubai