Skills Assessment for the Team You Already Have, Not Just the People You Are Hiring

Every person you hire has to prove, under observation, that they can do the job in a real environment. The people already on the team were asked the same thing once, some of them years ago, about a stack that has since been replaced twice.

So the gaps stay invisible. They surface at the worst possible moment: a migration starts and two people quietly cannot do the thing, or somebody takes annual leave and it turns out they were the only one who could deploy.

An internal skills check fixes that, and almost nobody runs one, because the obvious version of it feels like an exam and lands like a threat.

Why the obvious version fails

A questionnaire asking engineers to rate themselves from one to five produces a map of confidence, not of capability. The strongest people mark themselves lower. The least experienced mark themselves higher. You get a chart that is worse than nothing because it looks like data.

Certifications have the same problem one level up: they tell you who had time to study, not who can restore a backup at nine on a Monday.

The version that works has three properties. It is the same task for everyone, it is done in a real environment rather than described, and the individual results do not go to management.

What to actually measure

Pick the four or five things that would hurt most if only one person could do them. For most teams that is some subset of:

• Restore a database from a backup, and say how much data was lost.
• Read an infrastructure change and say what it will destroy.
• Find out why a deploy failed, using only what the pipeline gives you.
• Take a page: find the failing component in a system nobody explained to you.
• Roll back a release, cleanly, under time pressure.

Those are deliberately operational. Nobody needs a skills matrix that tracks which framework version each person has used. You need to know who can stop a bad day from getting worse.

How to run it without it feeling like an exam

Make it a drill, not a test. Frame it the way a fire drill is framed: we are checking the process, not the person. That is also true, because most failures in this exercise are documentation failures wearing a person's name.

Run it in pairs, or with the result private. Individual scores going upward is what makes people perform rather than learn. If the output is a team-level map plus private feedback, you get honest behaviour.

Give everyone the same environment. Not production, not somebody's laptop. The same disposable workspace with the same seeded fault, so two engineers' experiences are comparable and nobody is slowed by setup.

Timebox it to an hour and schedule it like a meeting. A skills exercise that needs a free afternoon never happens.

What comes out of it

Three things, and all three are useful immediately.

A bus factor list. Not a feeling, a list: these two tasks only one person completed. That is your most urgent training priority and it is often a surprise, because the single point of failure is usually not the person everyone names.

A training plan written from evidence. Instead of a budget spent on whatever course was marketed hardest this quarter, you have four specific gaps and the people who have them. The decision of what to train versus what to hire gets easier too, and we wrote about that trade in closing the skill gap: when to train, when to hire.

A documentation backlog. Every task where several capable engineers got stuck in the same place is a runbook that does not exist. This is the cheapest output of the whole exercise and usually the highest value.

What to do with the results, and what not to do

Use them for training, for pairing and for deciding what to document. Do not use them for performance reviews, ever, including the next one, including informally.

The moment a skills drill becomes an input to promotion, it stops measuring capability and starts measuring preparation. You will get better scores and worse information, and you will not get an honest result again.

Say that out loud before the first one and then keep to it, because the first time the rule is bent, everybody learns the new rule.

Where EasyEnv is different

This whole idea rests on everybody getting the same environment with the same fault, and on it being disposable enough that breaking it does not matter. Running a drill on staging is how a drill turns into an incident.

EasyEnv gives each engineer their own workspace from one recipe: the same database with the same backup, the same broken deploy, the same half-updated infrastructure. Nobody shares, nobody waits, and nothing anybody does reaches a real system. The workspace disappears afterwards, which also means nobody keeps the exercise around to practise on quietly before the next one.

The limits, plainly. Building the first scenario takes a day, and it has to reflect your stack to be worth anything. Somebody senior has to review what happened rather than just collect completions. And a team of three does not need this: you already know who can do what, and the exercise costs more than the information is worth.

The short version

You test every candidate in a real environment and you have never tested the team. Pick four operational tasks where a single point of failure would hurt, give everyone the same disposable workspace, run it for an hour, and keep the individual results away from management.

What comes out is a bus factor list, a training plan built from evidence, and a pile of missing runbooks. All three are more useful than a self-assessment matrix, and the exercise is cheaper than the outage it prevents.