Limited-time introductory pricing — save up to 50%. Start free →
PointFactors
Colleagues discussing data trends on a whiteboard with graphs and charts.

Competency Framework: How to Build One That Fits Your Job Architecture

Date Published

Competency Framework: How to Build One That Fits Your Job Architecture

Most competency frameworks die in a shared drive. A task force spends four months writing 60 competencies, ships a 90-page PDF, and eighteen months later nobody can tell you which competencies apply to a Senior Analyst or what "Advanced" means in practice. The framework was not wrong. It was unusable — too many competencies, too little differentiation between levels, and no connection to the structures managers actually touch.

A competency framework earns its keep when it does one job well: describing, in observable terms, what good performance looks like at each level of each job family. That makes it a sibling of your job architecture, not a replacement for it. This guide covers how to scope a framework, how to write proficiency levels that actually discriminate, and — the part comp teams care about most — where competencies belong in pay decisions and where they absolutely do not.

TL;DR

  • A competency framework defines the skills, knowledge and behaviors a person needs to perform a role well, described at multiple proficiency levels.
  • Keep it small. Eight to twelve core competencies plus a handful per job family beats 60 enterprise-wide.
  • Proficiency levels must be behaviorally distinct. If a manager can't tell Level 2 from Level 3 without the labels, the level doesn't exist.
  • Competencies describe people. Compensable factors describe jobs. Do not use a competency framework to set grades.
  • Map competencies onto the job architecture you already have — job families and levels — instead of inventing a parallel structure.

What a competency framework actually is

A competency is a cluster of related knowledge, skills, abilities and behaviors that drives a meaningful part of performance in a role. A competency framework is the organized set of those clusters, plus a scale describing what each one looks like as someone gets better at it.

The U.S. Department of Labor's Competency Model Clearinghouse uses a nine-tier "building blocks" structure that's a useful mental model even if you never adopt it. The bottom tiers cover personal effectiveness and academic and workplace competencies that apply to nearly everyone. The middle tiers cover industry-wide and industry-sector competencies. The top tiers cover occupation-specific technical competencies. Specificity increases as you move up.

That layering is the single most useful idea in framework design, because it tells you where to stop. You write the bottom layer once for the whole company. You write the middle layer once per function. You only write the top layer where the work is genuinely specialized and the business case justifies the effort.

Competency framework vs competency model

People use both terms interchangeably, and in practice the distinction is soft. When there is a difference: a model is usually the set of competencies for one role or role family, and a framework is the full architecture — all the models, the shared proficiency scale, and the rules for how they connect. If a vendor or consultant uses one word where you'd use the other, it isn't worth the argument.

Step 1: Decide what the framework is for

Write down the decisions this framework will inform before you write a single competency. The honest list is usually two or three items:

  • Development and career conversations. What does a Level 3 engineer need to demonstrate to be ready for Level 4?
  • Hiring and interview design. What are we actually assessing in the loop?
  • Learning investment. Where is the org thin, and what should L&D fund?

Notice what's not on that list: setting pay grades. That's deliberate, and I'll come back to it.

Scope creep kills frameworks. A framework built to answer three questions can be finished in a quarter. A framework built to answer eleven questions never ships.

Step 2: Choose your competencies — and cap the number

Two failure modes, both common. Too few competencies and the framework is a poster of corporate values. Too many and no manager will ever open it.

A working target for a 500-person company:

Layer

Count

Applies to

Core (all employees)

6–8

Everyone

Leadership

4–6

People managers and above

Functional

5–8 per family

One job family

Technical/specialty

3–5 per family

Deep specialists only

An individual contributor in Finance would therefore be measured against roughly 13 to 16 competencies, not 45. That's a number a manager can hold in their head during a development conversation.

For the core layer, borrow rather than invent. SHRM's Body of Applied Skills and Knowledge organizes nine behavioral competencies into Leadership, Interpersonal and Business clusters — a structure that transfers cleanly to non-HR functions. For functional and technical layers, O*NET's Content Model gives you occupation-level skills, knowledge and work activities for nearly a thousand occupations, collected from job incumbents and occupational experts. Starting from published, research-backed descriptors is faster and more defensible than starting from a whiteboard.

Write competencies as observable behavior

"Strategic Thinking" is a label, not a competency. The competency is what you'd see someone do. Compare:

  • Weak: Strategic Thinking — thinks strategically about the business.
  • Usable: Strategic Thinking — connects team-level decisions to stated business objectives, identifies second-order consequences before committing resources, and revises plans when leading indicators change.

If two reasonable managers watching the same person for a month would disagree about whether the behavior occurred, rewrite it.

Step 3: Build a proficiency scale that discriminates

Most frameworks use four or five levels. Four is easier to calibrate; five gives you a middle. Either works. What matters is that adjacent levels differ on something you can point at.

The three dimensions that reliably separate levels:

  1. Scope of application — own task, own team, own function, enterprise.
  2. Supervision required — needs direction, works independently, sets direction for others.
  3. Novelty handled — routine situations, variations, ambiguous or unprecedented situations.

A four-level scale for Data Analysis, written against those dimensions:

Level

What it looks like

1 — Foundational

Runs existing queries and reports with review. Escalates anomalies rather than interpreting them.

2 — Proficient

Builds new analyses independently for defined questions. Chooses appropriate methods for standard problems.

3 — Advanced

Frames ambiguous business questions as analyzable problems. Reviews others' work and catches methodological errors.

4 — Expert

Sets analytical standards for the function. Advises leadership where the data is thin and the decision is still required.

Now test it. Take ten real people, have two managers independently rate them on three competencies, and compare. If agreement is below roughly 70% on exact level — and it usually is on the first pass — your level descriptions are doing less work than you think. Rewrite the pairs that disagreed most, then retest.

Building a career framework and a competency framework at once? Get the job architecture right first — levels, families, and the evaluation logic underneath them. PointFactors scores jobs against weighted compensable factors so your levels are defensible before you layer competencies on top. See how job evaluation works.

Step 4: Map competencies onto your existing job architecture

This is where frameworks either integrate or float away. You already have — or should have — a job architecture: job families, levels within families, and a consistent way of describing roles. The competency framework attaches to that skeleton. It does not replace it, and it must not contradict it.

Practically:

  • Use your existing job families as the unit for functional competencies. One competency set per family, not per job title. If you have 340 titles and 22 families, you write 22 sets.
  • Align proficiency levels to your job leveling structure, but don't assume a 1:1 mapping. A framework with 4 proficiency levels can serve 8 job levels — an L5 and an L6 engineer might both be expected at Proficiency 3 on most competencies and differ on scope of two or three.
  • Expect to find contradictions. If your leveling guide says an L4 works independently but your competency framework puts independence at Proficiency 3 and most L4s sit at 2, one of the two documents is describing the company you wish you had. Fix the mismatch before launch, not after.

Where competencies belong in pay — and where they don't

Here's the line that saves comp teams the most trouble: competencies describe people; compensable factors describe jobs.

A job evaluation plan scores the position against weighted compensable factors — skill, effort, responsibility and working conditions, with sub-factors under each. The score is the same whether the seat is filled by a nine-year veteran or a new hire, and that stability is the entire point. It's what lets you say two different jobs are of equal value, and what you'll rely on if you ever have to defend a grade in an appeal or an equal-value claim.

A competency rating moves when the person moves. Feed competency ratings into grade assignment and your grades start drifting with tenure and manager generosity. Two people doing the same job end up in different grades, which is the exact internal-equity failure the whole structure exists to prevent.

Legitimate uses of competencies in pay:

  • Position in range. Where someone sits between minimum and maximum, alongside performance and experience.
  • Promotion readiness. Evidence that someone should move to a higher-graded job — the grade comes from the new job, not the rating.
  • Skills-based pay premiums for specific, verified, business-critical skills, administered as a defined premium rather than baked into the grade.

What to avoid: using competency scores as the input to grade assignment, or treating the competency framework as a substitute for job evaluation. They answer different questions.

Step 5: Launch small, then maintain

Pilot with two job families, not twenty-two. Run one full performance or development cycle. Collect the questions managers ask — the confusions are your rewrite list.

Then set a maintenance rhythm, because this is what separates living frameworks from shared-drive fossils:

  • Annually: review functional competencies in fast-moving families. Technical competencies in engineering and data roles go stale in about two years.
  • Every 2–3 years: revisit core and leadership competencies. These should be stable; frequent changes signal the original set was wrong.
  • On any reorg: re-check the family mapping. New families need competency sets before anyone is rated against nothing.

Name an owner. A framework with no owner has a shelf life of one leadership change.

FAQ

How many competencies should a framework have in total? Across all layers, 30 to 50 for a mid-sized company is typical, with any individual employee measured against 12 to 16. If your total exceeds 60, you have overlapping competencies that should be merged.

What's the difference between a competency framework and a skills taxonomy? A skills taxonomy is a flat, granular list of discrete skills — "Python," "contract negotiation," "SQL" — often numbering in the thousands. A competency framework is a much smaller set of broader behavioral clusters with proficiency definitions. Many organizations run both: the taxonomy for workforce planning and internal mobility, the framework for development and assessment.

Should competency ratings feed into performance reviews? They can, but keep them distinct from goal attainment. A competency rating says "here is your current capability level"; a performance rating says "here is what you delivered this cycle." Blending them makes both less useful, and makes development conversations feel like judgment.

Can a competency framework replace job descriptions? No. A job description states the purpose, scope, accountabilities and requirements of a position. A competency framework describes capability levels that apply across many positions. You need both, and the job description should reference the relevant competency set rather than restate it.

Do we need a framework before we can do job evaluation? No — the reverse order usually works better. Job evaluation needs accurate job documentation and a defined set of compensable factors, not competencies. Getting your levels and grades right first gives the competency framework a stable structure to attach to.

How long does building one take? For two to three job families as a pilot: six to ten weeks with a dedicated owner. Enterprise-wide across 20+ families: two to three quarters, and it should be phased by family rather than launched all at once.

Who should own the framework? Usually HR business partnering or talent development, with a named steward per job family — typically a senior leader in that function who signs off on changes. Comp should review it, specifically to confirm it isn't quietly being used to set grades.

Get the structure right first

A competency framework built on a shaky job architecture inherits every flaw underneath it. If your levels were set by negotiation and your grades by market data alone, adding competencies on top just documents the inconsistency in more detail.

PointFactors evaluates jobs against weighted compensable factors and produces a defensible point score for every role — the structural layer your competency framework needs to attach to. Build the skeleton, then add the muscle. Book a demo and see your own jobs scored.

Justin Hampton is founder and CEO of PointFactors.