Every organization already has a competency framework. Most of them just haven't written it down. It lives in the heads of the managers who decide who gets the hard project, who gets promoted, and who gets quietly routed around. The framework exists. It's just invisible, inconsistent, and impossible to develop against.
Quick reference: Competency Framework — the short version of this post, with the one table that matters.
Writing it down is the easy part. The hard part is writing down the one that's actually true for your organization, in your language, at a level of detail people will use — and then connecting it to something that measures whether anyone meets it.
This article covers what a competency framework is, the four ways organizations build competency models, a six-step method for building a framework that gets used, a worked example, and the mistakes that turn frameworks into shelfware.
What Is a Competency Framework?
A competency framework is a structured definition of the competencies an organization needs, organized by role, job family, or level, with each competency described at defined proficiency levels. A competency is a cluster of related skills, knowledge, and behaviors that together produce effective performance in a role — "incident response," for example, rather than the dozen individual skills it contains. The framework states which competencies each role requires and what "meets the bar" looks like at each level, in observable terms. It is the reference point for everything downstream: what to assess, where the gaps are, what to train, who is ready for the next role, and what a candidate needs to show. A framework that stays in a document is a job description with extra steps. A framework connected to assessment becomes the operating system for talent decisions, because the definition of "good" and the measurement of who meets it live in the same place.
Framework vs. Model vs. Library
The terms overlap, and vendors don't help.
| Term | What it is | Scope |
|---|---|---|
| Competency model | The set of competencies and levels for one role or job family | One role or family |
| Competency framework | The organization's full structure of models, shared competencies, and the scale they use | Whole organization |
| Competency library | The catalog of competency definitions available to build models from | Reference material |
A model is the answer for one role. The framework is how all the models fit together. The library is the parts bin. Most of the confusion in this space comes from vendors selling a library and calling it a framework.
The Four Ways to Build a Competency Model
There are four established methods for defining what a role requires. Each has a cost, a speed, and a failure mode.
Externally developed models
Pre-built frameworks from industry bodies, consulting firms, professional associations, or government sources. The fastest way to start from zero.
Use them when you have no framework at all and need a defensible starting point, or when the role is heavily standardized by an external body — nursing, project management, cybersecurity.
The cost is fit. External models describe the role in someone else's language, at someone else's level of granularity, and they inevitably include competencies nobody in your organization recognizes and omit the ones that actually differentiate performance. Every organization we have worked with in 18 years that adopted an external model unchanged ended up with a checkbox exercise. The ones that used it as raw material and rewrote it in their own words got a framework people used.
Expert panel workshops
Bring the people who actually know the role — the top performers, their managers, the customers of their work — into a room and define the competencies together.
Use this for roles where performance is understood but undocumented, and where buy-in from the function matters as much as the output. It's fast, it produces language people recognize, and the people who wrote it will defend it.
The cost is bias. Panels converge on what's familiar. They overweight the competencies of the people in the room and underweight the quiet ones that predict success. Structured facilitation and a diverse panel mitigate it. They don't eliminate it.
Competency surveys
Ask a broad population — everyone in the role, their managers, adjacent teams — to rate the importance and frequency of a candidate set of competencies.
Use surveys to validate or prioritize a model that already exists, or to reach populations too large or dispersed for panels. Done through a survey tool, it's the cheapest method per person and the only one that scales to thousands.
The cost is that surveys can only rank what you put in front of them. A competency missing from the instrument is missing from the result. Survey quality is model quality.
Job task analysis
Break the role into its tasks, then derive the competencies required to perform each one. Rigorous, task-anchored, and the standard approach for highly technical or safety-critical roles.
Use it where the consequence of a competency gap is an incident: operations, maintenance, clinical, regulated manufacturing. It produces the most defensible model and the one auditors like best.
The cost is time and detail. Task analysis generates hundreds of line items, and without a discipline for rolling tasks up into competencies it produces a procedure manual, not a framework. It also tends to over-describe routine work and under-describe judgment.
Which one, then
Almost nobody should pick one. The pattern that works: start from an external model or a library to avoid a blank page, run panels with the function to rewrite it in their language and cut what doesn't apply, validate and prioritize with a survey if the population is large, and use task analysis only for the roles where being wrong is expensive. The method mix follows the role's risk profile.
How to Build a Competency Framework in 6 Steps
1. Decide what the framework is for
Assessment, development planning, hiring, succession, compliance — the purpose sets the level of detail. A framework built for compliance needs task-level anchors. One built for career development needs fewer competencies with clearer progression between levels. Frameworks that try to serve every purpose at once serve none of them.
2. Start with roles, not competencies
Inventory the roles and group them into job families. The framework hangs off roles; competencies that don't attach to any role are decoration. If your job architecture is a mess, fix enough of it to know which roles exist before you define what they require.
3. Define the competencies in your own language
Use whichever of the four methods fits each role's risk. Write each competency as a competency definition: a name, a one-sentence statement of what it enables, and the skills and behaviors it contains. Aim for eight to fifteen competencies per role. Beyond that, nobody assesses honestly.
4. Set the proficiency scale and anchor every level
Pick one scale for the whole framework — four or five levels is standard — and write observable anchors for each competency at each level. "Level 3: independently diagnoses and resolves incidents on production systems without escalation" is an anchor. "Intermediate" is not. The scale is what makes the framework measurable; see proficiency levels for how to build one.
5. Set the required level per role
For each role, mark the level required in each of its competencies. This is the bar. It is also the moment the framework becomes useful, because required-versus-actual is a gap, and a gap is something you can close.
6. Connect it to assessment, then revise
A framework that is never assessed against is fiction. Run the first assessment cycle within a quarter of publishing the framework. The results will show you where the anchors are unclear, where the required levels are wrong, and which competencies nobody can evaluate. Revise. A good framework changes every year; a dead one is perfect and untouched.
Competency Framework Example
A compressed example for a data center operations job family, three roles, five shared competencies, on a four-level scale (1 Foundational, 2 Working, 3 Advanced, 4 Expert). The number in each cell is the level the role requires.
| Competency | Facilities Technician | Shift Lead | Site Operations Manager |
|---|---|---|---|
| Critical systems operation (UPS, generators, cooling) | 3 | 3 | 2 |
| Method-of-procedure execution (MOP/SOP discipline, revision control) | 3 | 4 | 3 |
| Incident response (detection, escalation, containment, root cause) | 2 | 4 | 3 |
| Compliance and evidence (audit trails, certification currency, documentation) | 2 | 3 | 4 |
| People leadership (coaching, scheduling, performance conversations) | 1 | 3 | 4 |
Read across a row and you see how a competency changes meaning by level. Read down a column and you see the role's shape. Compare a person's assessed levels against their column and you have their development plan. Compare a Facilities Technician's assessed levels against the Shift Lead column and you have their readiness for promotion. That's the whole point of the grid.
Anchors sit behind each cell. Incident response at level 2 might read "recognizes alarm conditions and escalates within defined thresholds." At level 4: "leads response across sites, directs containment, owns root-cause analysis and corrective action." Same competency, different job.
Where Frameworks Go to Die
Imported and never translated. A framework adopted wholesale from a generic taxonomy looks impressive in a demo and withers on the vine, because no two organizations define competency the same way. If the people being assessed don't recognize the language, they don't engage with the assessment, and the framework becomes shelfware inside a year.
Levels without anchors. "Basic, Intermediate, Advanced" with no observable behavior behind each word produces assessments that measure the assessor's mood. Every level of every competency needs a sentence that two managers would read the same way.
Too many competencies. Forty competencies per role is a job description, not a framework. Nobody can hold forty in their head, and assessment fatigue sets in by number twelve.
Never connected to assessment. The framework is published, admired, and filed. Without an assessment cycle it cannot tell you where the gaps are, and a framework that can't find gaps can't justify its own existence at budget time.
Frozen. Roles change. Technology changes. A framework locked to protect the effort that built it is measuring last year's job.
The common thread is that the framework was treated as a document. It's infrastructure. It has to be built in the organization's own language, carry a scale people can apply, and sit inside a system that assesses against it, finds the gaps, and drives development — which is what competency frameworks in a skills platform are for.
The Framework Is the Definition of Good. Assessment Is Whether Anyone Meets It.
A competency framework is where an organization writes down what it means by good work, role by role, level by level. Done well, it stops being an HR artifact and becomes the reference every talent decision points at: what to hire for, what to develop, who is ready, and what the audit needs to see. Done badly, it's a PDF. The difference is not the method you chose to build it. It's whether you built it in your own words and connected it to measurement.