Blueprint, competency, skill: three words that aren't the same thing

Three words, three scales

The difference between the three is scale — how much of a person's ability each one is trying to capture. Start where the decision is actually made, at the role, and work down.

A role blueprint is a reusable "recipe for the role": it names the competencies the job requires and, for each one, a target proficiency level, an importance weight, and whether it is a deal-breaker. It is the container that turns a loose set of abilities into a bar a candidate is measured against.

A competency is a broad, observable area of capability that predicts success in the role — "problem-solving", "written communication", "judgment under pressure". It is the level at which results are reported and at which the role's bar is expressed, because it is the level a hiring manager actually reasons about.

A skill is the concrete, measurable ability that sits underneath a competency — "write a root-cause summary", "escalate a ticket to the right team", "structure a discovery question". It is narrow enough to be captured by a single task, and it is where the evidence is actually collected.

The hierarchy: blueprint → competency → skill → task

The three nest inside one another. A blueprint contains several competencies; each competency breaks down into several skills; each skill maps to one or more tasks a candidate actually completes. That nesting is not bureaucracy — it is the path evidence travels.

Evidence flows upward. A candidate produces something on a task; the underlying skill is scored against a rubric; skill scores roll up into a competency result; the competency is compared to the blueprint's target. This upward chain — role down to task on the way in, task up to decision on the way out — is what selection science calls a content-valid design, and it is the backbone of a defensible decision.

It also explains why the middle two words are so easy to confuse. A competency feels concrete enough to test directly, and a skill feels broad enough to describe a whole person. But if you test at the wrong level, you either measure something too narrow to matter or score something too vague to defend.

• Blueprint — "Customer Support Specialist": four competencies, each with a target level and weight.
• Competency — "Problem-solving": target level 4/5, weight ×2.0, marked critical.
• Skill — "Root-cause analysis": scored against explicit rubric criteria.
• Task — a case ticket, an interview question, or a simulation step: where the candidate's evidence is produced.

Why conflating them breaks an assessment

The distinctions matter because each collapse has a predictable failure mode. Treat a skill as if it were a competency, and you mistake one narrow ability for a whole area of capability — you decide someone is a strong problem-solver because they wrote one good SQL query, or a weak one because they fumbled a single edge case. The judgment is too confident for the evidence behind it.

Treat a competency as if it were a blueprint, and you lose consistency. If every hiring manager re-invents the bar for "good written communication" on the spot, two candidates for the same role are measured against two different standards, and you can no longer compare them or explain, later, why one advanced. The blueprint exists precisely so the bar is set once and applied evenly.

The healthy version keeps the labor of measurement where it belongs: skills are what you observe and score, competencies are what you summarize and report, and the blueprint is the standard you hold the summary against. Skill in, competency out, decision against the bar.

How the chain works in SkillCort

In SkillCort, this taxonomy is not a diagram in a slide deck — it is how the product is wired. The flow has four steps.

First, you define the role as a blueprint. You name its competencies and set, for each, a target level (1–5), a weight, and a critical flag. You can start from scratch or let AI draft the competency bar from a job description, but the draft is only ever a suggestion — nothing is saved until you approve it, and the bar is always yours to set.

Second, you link an assessment to the blueprint. That link prefills the brief with the role's targets and, more importantly, switches on the role-fit machinery from the very first candidate. Third, every task the candidate touches is mapped to skills, and those skills belong to competencies — so a candidate's work on a specific task can be attributed all the way up to the role's bar.

Fourth, the evidence rolls up. For the pool of candidates, you get a role-fit view: average fit per competency, how many candidates clear the bar, and — kept honestly separate — a check on whether the critical competencies were cleared, so a strong area can never paper over a critical gap.

One spine, three assessment modes

The most useful property of this design is that the spine is task-type agnostic. Whether you run a work-sample assessment, an AI interview, or a case simulation, the same skill-to-competency chain does the work underneath.

An interview question and a simulation step are mapped to skills and rubric criteria exactly the way a work-sample task is. So the choice of format is a choice about candidate experience and what you want to observe — not a choice about whether the role blueprint applies. Link a blueprint to an interview and every question maps to competencies; link it to a simulation and every step does. The bar, and the way evidence climbs back to it, is identical.

That is what lets a team mix formats within one hiring process and still compare candidates on the same competency bar — the thing a spreadsheet of raw scores can never quite do.

From skill scores to a defensible decision

Because evidence is attributed at the skill level and reported at the competency level, the role-fit view can also tell you how much to trust it. Each competency result is qualified by reliability: agreement between evaluators scoring the same candidates, and internal consistency across the criteria that make up the competency. When there is not enough data to estimate honestly, the product says so rather than inventing a number.

None of this replaces a human decision. The rollup is decision-support — a structured, reliability-qualified read on how a candidate pool measures against the role — not a verdict, and never an automated advance-or-decline. Predictive claims about future job performance are earned slowly, as real outcomes accumulate for a role, and are framed as preliminary until then. The value is not a magic score; it is that the reasoning behind a decision is legible and consistent.

That legibility is the whole point of keeping blueprint, competency, and skill distinct. When you can say "we measured these skills, they rolled up to this competency result, and here is how it compares to the bar this role requires," you have a decision you can explain — to a candidate, to a hiring manager, or to anyone who asks you to justify it.

Where to start

Pick one role and write its blueprint first — three to five competencies that actually separate your strong performers from the rest, each with an honest target level and a weight, and only the true deal-breakers marked critical. Resist the urge to list twenty; a blueprint that tries to measure everything measures nothing well.

Then build the tasks so each one maps cleanly to a skill under those competencies, write the rubric before anyone responds, and run it as a full stage. When the results come in, read them at the right altitude: skills to see what happened, competencies to summarize it, and the blueprint to decide. Keep those three separate and the decision mostly explains itself.

Sources & further reading

• Schmidt & Hunter (1998), The Validity and Utility of Selection Methods in Personnel Psychology — Psychological Bulletin
• Roth, Bobko & McFarland (2005), A Meta-Analysis of Work Sample Test Validity — Personnel Psychology