A skill is a specific ability a person has learned. A competency is a job-relevant bundle of skills, knowledge, and behavior tied to a work outcome. Proficiency is how well the person performs either one, measured on a scale. Three words, three different objects, and most workforce frameworks blur them into one.
The blurring is expensive. When "skills" and "competencies" mean the same thing in a framework, the taxonomy grows to 400 items nobody can assess. When "proficiency" gets folded into "competency," ratings become a yes/no checkbox and the organization loses the ability to see who is one level away from qualified. The three terms are doing different jobs. Keep them separate and the framework gets smaller, sharper, and usable.
The Difference at a Glance
| Skill | Competency | Proficiency | |
|---|---|---|---|
| What it is | A learnable ability | A cluster of skills, knowledge, and behavior tied to a job outcome | A measured level of performance |
| Scope | Narrow, specific | Role-relevant, composite | Applies to a skill or a competency |
| Example | Write a SQL join | Build reporting pipelines finance signs off on | Level 3 of 5 on that competency, assessed last quarter |
| How it is written | Noun or short verb phrase | Action verb, object, standard, result | Level descriptors with behavioral anchors |
| How it is measured | Has it or not; sometimes a simple scale | Leveled rubric | The scale itself |
| Who owns it | Skills library | Job family or role framework | Assessment process |
| Decays? | Yes, by practice | Yes, as the role changes | Yes, recency matters |
Skills are the base unit. Competencies organize skills into what a role needs. Proficiency measures where a person stands against either. The rest of this post takes each pair in turn, because each pair is a question people actually ask.
Skills vs. Competencies
Skills and competencies are similar in one way: both describe a capacity to perform, and both are acquired through practice and training. That is where the similarity ends.
A skill is specific and often assessed simply. Can this person weld a TIG joint on stainless? Can they configure a VLAN? Can they run a pivot table? The skill tells you whether the person can do the discrete thing. It says little about whether they can do the job.
A competency is what the job actually needs, written as a package. It combines several skills with the knowledge to know when to use them and the behavior to apply them under real conditions. "Weld a TIG joint" is a skill. "Produce code-compliant stainless welds on pressure-bearing assemblies, inspect them against the WPS, and document results for the quality record" is a competency. The competency is assessable at levels, points at an outcome an auditor or a customer cares about, and would appear in a role profile. The skill would appear in a skills library.
The practical test: if you can imagine a course teaching it in an afternoon, it is probably a skill. If you can imagine a manager rating someone on it across a year of work, it is probably a competency. How to write competencies that pass that test is covered in What Are Competencies? Definition, Types, and Examples.
Why the distinction matters in a framework
Organizations that treat every skill as a competency end up with frameworks that are too large to assess. Organizations that treat every competency as a skill end up with binary checklists that cannot distinguish a new hire from a twenty-year expert. The healthy structure is a skills library of specific abilities, with role competencies assembled from them. A role typically requires 8 to 12 competencies, each drawing on a handful of skills. That is small enough to assess quarterly and rich enough to plan against.
Competence vs. Competency
This one is a spelling question that hides a real distinction, and almost nobody answers it well.
Competence is a state. It is the condition of being able to do something to the required standard. "She has demonstrated competence in medication administration." It is uncountable in ordinary usage; you do not have three competences, you are competent or you are not, in a given domain.
Competency is a thing. It is a defined, named, assessable unit inside a framework. "Medication administration is one of nine competencies in the nursing framework." Competencies are countable, written down, leveled, and assigned to roles.
So the sentence "we assess competence against competencies" is correct and not redundant. The framework lists competencies. The assessment establishes whether the person has reached competence in each. British and American usage both accept this split, and it is the split that regulated industries lean on: an auditor asks whether you can demonstrate competence, and your evidence is a set of assessed competencies with dates and levels.
Where people go wrong is using "competences" as a plural of "competence" to mean framework items. Some published frameworks do this, and it is not wrong, but inside one organization pick one convention. The cleanest is the one above: competency for the framework item, competence for the state a person achieves.
Competency vs. Proficiency
A competency is what the role requires. Proficiency is how well a specific person performs it today.
The competency is fixed at the role level. "Diagnose process faults using P&ID drawings, instrument readings, and shift logs, and escalate per protocol" is the same competency for every operator on the unit. Proficiency varies by person and by time. One operator is at level 2, another at level 4, and the level 4 operator who has been on desk duty for a year may have slipped to a 3.
That is why proficiency needs a scale with described levels, not a checkbox. A useful five-level scale for the fault-diagnosis competency reads:
- Foundational. Recognizes standard alarms and follows the checklist with guidance.
- Developing. Diagnoses routine faults independently; escalates anything unfamiliar.
- Proficient. Diagnoses complex and compound faults; coaches level 1 and 2 operators through them.
- Advanced. Anticipates faults from leading indicators; contributes to procedure revisions.
- Expert. Sets the standard; designs the training and assessment for the competency.
The same scale shape works for skills. "Write SQL" can be assessed at level 1 through 5 just as a competency can. Proficiency is the measurement layer that sits on top of both. How to build these scales, choose the number of levels, and write anchors that managers apply consistently is in Proficiency Levels: Scales, Examples, and How to Define Them.
One more property of proficiency that competencies do not have: it decays. A role competency is stable until the role changes. A person's proficiency drops when they stop practicing. A framework that records proficiency without a date is recording history and calling it current state.
Eight Worked Examples
The fastest way to internalize the three layers is to see them stacked. Each row maps one skill to the competency it serves and what proficiency looks like at the low and high end.
| Skill | Competency it belongs to | Proficiency level 2 looks like | Proficiency level 4 looks like |
|---|---|---|---|
| Write SQL queries | Build reporting pipelines that finance relies on for close | Writes correct queries against documented tables with review | Designs pipelines, validates against source systems, owns data quality checks |
| Read a P&ID drawing | Diagnose process faults and escalate per protocol | Locates instruments and traces routine flows | Diagnoses compound faults from drawings plus live readings |
| Operate a CNC lathe | Produce first-pass-yield parts to the control plan | Runs proven programs with setup verified by a lead | Sets up new jobs, adjusts offsets, holds tolerance across a shift |
| Take a patient history | Complete admission assessments that drive the care plan | Gathers required fields with prompts | Elicits risk factors patients do not volunteer; flags them to the team |
| Run a discovery call | Qualify opportunities so pipeline forecasts hold | Follows the script and records answers | Adapts questioning to surface the buying process and decision criteria |
| Configure a VLAN | Deliver network changes without unplanned outages | Implements approved changes in the maintenance window | Designs segmentation, writes the rollback plan, reviews others' changes |
| Build a project schedule | Control scope and schedule to the approved baseline | Maintains a schedule from a template | Rebaselines with sponsor approval and quantified impact |
| Coach a direct report | Develop people so the team's bench strength grows | Holds regular one-on-ones with agreed goals | Moves people up a proficiency level per year with evidence |
Read down the first column and you have a skills library. Read down the second and you have a piece of a role framework. Read across and you have the assessment. That is the whole model.
Why Organizations Need All Three
The original version of this post argued that organizations should focus on competencies rather than skills. Years of implementations have made me more precise about that. You need all three layers, and you need them to stay distinct.
Skills give you a shared vocabulary that survives reorganizations (the types and how skill sets group them are in What Are Skills? Types, Examples, and Skill Sets). A skills library written in the organization's own language is the raw material every role draws on, and it is what lets you spot the person in operations who has the skill the analytics team is hiring for.
Competencies give you role definitions that hiring, assessment, and succession can all reference. They keep the framework small enough to run. They are what you assess against when someone asks whether a team is qualified for the work.
Proficiency gives you the truth about today. It tells you who is one level away from qualified, whose currency has lapsed, and where the training budget will move the needle. Without it, the framework describes the organization you wish you had.
Vocabulary Is Infrastructure
The three words look like a semantics problem. They are a data model. Skills are the entities, competencies are the role-level structures built from them, and proficiency is the measured attribute with a timestamp. Get the model right and every downstream question, from staffing to succession to audit, has an answer with evidence behind it. Get it wrong and the organization is running its workforce decisions on a glossary.