What Does Competency Mean? A Guide to Competency Models, Level Definitions, and Measurement in Corporate L&D

When the word “competency” is assumed to be “understood by everyone” inside an organization, it usually splits into three different meanings in the same meeting two months later: one person says “knowledge,” another says “skill,” and another says “performance.” Then the training budget flows not toward the target, but into the gap between words.

I treat competency as a three-cornered thing: role, behavior indicator, and evidence. The role says “what must I achieve?” The behavior indicator says “how do I do it?” Evidence closes the question “can I really do it?” If these three don’t exist together, “competency” becomes just a nice label.

Below, step by step, I’ll explain how to make a competency model concrete in corporate L&D; how to write level definitions; which data to use to find gaps; and how to design measurement. I’ll also weave in areas like GDPR and HSE where “evidence” is vital—because these two topics quickly remind you that a competency model is not romantic; it’s operational.

“The map is not the territory.” [Alfred Korzybski, 1931]
The competency model is the map; not the work itself. If the map isn’t good, even the best-intentioned journey gets lost.

1) Competency, skill, knowledge: Without distinctions in the corporate glossary, you can’t measure

The most common mistake I see in corporate training is this: knowledge, skill, and competency get thrown into the same box; then that box becomes the “training catalog.” But they are different things.

A practical distinction I use:

• Knowledge: Being able to recall what’s correct.
  Example: “Under what conditions is explicit consent required in GDPR?”
• Skill: Being able to apply what’s correct (usually in a controlled environment).
  Example: “Being able to write a draft data breach notification.”
• Competency: In the context of a role, consistently demonstrating the right behavior and producing results.
  Example: “In a team working with customer data, embedding data minimization into processes to reduce breach risk.”

For a moment I was going to write “competency = skill + knowledge”; that’s incomplete. Competency includes context and consistency. If you do it right one day and fall apart the next, you may have skill; competency hasn’t settled yet.

Clarifying these two sentences in your corporate glossary directly impacts the budget:

1. “Is this solved through training (knowledge/skill), or through job design and management (competency)?”
2. “To prove this competency, which behavior will we see, with which work output?”

Mini example glossary (same topic, three different layers)

Don’t store this table as “the corporate glossary”; make it the front door of your competency model. Because measurement design starts here.

2) Competency model: The role × behavior indicator × evidence triangle

It’s easy to think of a competency model as a “list.” Making lists is comforting: you write 12 items and you’re done. But a competency list alone doesn’t do anything; like Borges’ infinite library, everything exists but you can’t find what you’re looking for (Borges, “The Library of Babel”, 1941).

For me, a model must answer three questions at the same time:

1. Role: What is the definition of success for this role? (output, responsibility, risk)
2. Behavior indicator: What does a successful person do, and how? (observable)
3. Evidence: When we say “they did it,” what will we have in hand? (assessment / work output / data)

Think of this triangle as a template. When writing a competency, force the sentence like this:

• “Competency X” → in which role?
• “good communication” → with which behavior?
• “completed” → with which evidence?

Template (can be standardized internally)

Competency name:
Linked role(s):
Definition (1 sentence):
Behavior indicators (3–6 bullets, observable):
Level definition (L1–L4 or Junior–Senior):
Evidence types (at least 2):
Related KPI / risk / compliance topic:

The “evidence types” line is critical. Because every competency you write without “evidence” eventually becomes just an excuse to assign training.

3) Role-based competency matrix: How do you write level definitions?

Writing level definitions feels strangely hard for people. Because many organizations confuse “junior–senior” with years of tenure. Years can matter, but what determines competency level, in my view, is more this: autonomy, complexity, scope of impact, and risk management.

When building a level framework, 4 steps are enough for most organizations:

• L1 (Beginner): Does it with guidance; recognizes what’s correct
• L2 (Applies): Applies independently in standard situations
• L3 (Masters): Manages exceptions; becomes a model for others
• L4 (Shapes): Improves the process/standard; scales the impact

You don’t have to say “L4 = manager.” In some specialist roles, L4 is not management; it’s system building.

Example: “GDPR-Compliant Data Processing” competency (behavior-based levels)

On the HSE side it’s similar: L1 “knows the rule,” L2 “applies,” L3 “makes the right decision in exceptions,” L4 “improves the system.”

Converting into a role-based matrix

Build the matrix on two axes:

• Rows: roles
• Columns: competencies
• Cell: target level (L1–L4) + critical behavior + evidence

At this point, organizations usually keep the matrix in Excel. That’s not bad; but Excel is weak at keeping “evidence” alive. Because evidence fragments over time: a quiz is in one place, a certificate PDF in another, 360 notes in emails.

At Nextrain, to reduce this fragmentation, I use Passport: collecting employees’ roles, competencies, training history, and certificates in a single profile takes the matrix off “paper.” Especially in audit-heavy topics like HSE and GDPR, closing the question “who has taken what?” in 3 seconds increases the practical value of the competency model.

4) Competency gap analysis: Which data finds it, and what mistakes are made?

Competency gap analysis is not the difference between two numbers; it’s the difference between two definitions:

• Target: the required level for the role (written in the matrix)
• Current: the person’s current level evidence (coming from measurement)

To find the gap correctly, you first need to measure “current” correctly. People love shortcuts here: “Completed the training → competency completed.” This is the most expensive misconception for me.

I like to look for the gap with three classes of data:

1. Assessment data: mini quiz, case, rubric score, checkpoint results
2. Behavior data: where they got stuck in the content, how many attempts, which question they struggled with
3. Work evidence: real work output, observation, 360 feedback, quality/error records

On the Nextrain side, what I call “behavior data” is what the system tracks at event level: views, clicks, answers, time. These are not competency by themselves; but they answer “where are they struggling?” extremely well. If an employee watches a module three times, sometimes it’s not motivation; sometimes it’s uncertainty. (Sometimes they just left it open in the background; yes, I’ve seen that too.)

6 common mistakes (and how to fix them)

• Mistake 1: Writing the competency abstractly.
  Instead of “leadership,” write a behavior like “structuring a difficult conversation.”
• Mistake 2: Equating level definition with years of tenure.
  Level = autonomy + complexity + impact + risk management.
• Mistake 3: Deciding with a single measurement.
  Build a combination of mini quiz + on-the-job evidence.
• Mistake 4: The same competency set for every role.
  Create a shared core + role-specific set.
• Mistake 5: Trying to close the gap by “assigning training.”
  Sometimes the issue is process, tools, goal conflict, or manager behavior.
• Mistake 6: Gluing the KPI link on afterward.
  Choose the KPI upfront: “If this competency increases, what decreases/what increases?”

I also see people wanting two opposite things on the same day: they say “everyone should reach the same standard,” then they say “but don’t waste anyone’s time.” Both are reasonable. The solution is to lock the standard with evidence, and shorten the path by personalizing it.

5) Measurement design: Rubric, mini quiz, on-the-job evidence, 360 (and when to use which?)

My core rule in measurement design is: If competency is behavior, measurement should get close to behavior. If you only measure knowledge, you only develop knowledge.

Think about the following four tools together:

5.1 Rubric (the measurement language of behavior)

A rubric translates “good” into words. It makes observable what a manager calls “not bad.”

A simple rubric example (sales call – objection handling):

• Criterion 1: Clarifying the problem
  • 0: Responds without asking questions
  • 1: Asks a single question; stays on the surface
  • 2: Clarifies the need with 2–3 questions
  • 3: Clarifies and confirms the need + risk perception

A rubric also makes 360 feedback less “opinion” and more “evidence.”

5.2 Mini quiz (knowledge + fast screening)

I like mini quizzes because they’re fast; but I don’t like making the quiz the “final.” Good use: screening and a gate.

In Nextrain, I can build this “gate” logic with AI Gates: if they fail, they repeat training; if they pass, they move to the next level. This mechanism turns measurement into not just a report, but a flow decision.

5.3 On-the-job evidence (touching the real world)

On-the-job evidence turns “I learned” into “I did.” Examples:

• GDPR: checking and correcting a sample information notice with a correction record
• HSE: on-site risk notification + action follow-up
• Operations: error rate reduction, rework reduction

A caution here: Not every work output is competency evidence. You need to connect the output to the person’s “behavior.”

5.4 360 feedback (not perception, pattern)

360 can be risky on its own; it can turn into a popularity contest. But combined with a rubric, it becomes very useful: you look at the same behavior indicator through multiple eyes.

I find 360 especially meaningful in two situations:

• When the competency is multi-actor, like “collaboration/coordination”
• When the competency is “ethics/compliance” and can’t be measured only by outcomes (sometimes outcomes are invisible)

6) Linking to KPIs: The competency model is not a “report,” it’s a decision system

When the KPI link isn’t made, the competency model eventually gets treated like an “HR document”: it exists, but nobody uses it to make decisions.

A practical way to build the link:

1. Select the competency (in role context)
2. Write the behavior indicator (observable)
3. Select the evidence (assessment + work evidence)
4. Select the KPI (business metric / risk metric)
5. Define the time window (30-60-90 days)

Example mappings:

• HSE risk awareness → increase in near-miss reporting (an initial increase can be a good sign) + accident rate trend
• Running GDPR-compliant processes → decrease in number of breaches / wrong-sharing incidents + fewer audit non-conformities
• Sales objection handling → margin protection + close rate + time per meeting

On the Nextrain Analytics side, when I build this relationship, I like monitoring training data on a “single screen” and, when needed, asking Akira questions in natural language to get quick breakdowns. “Which region has a low score?” looks simple; but when asked correctly it makes the competency gap visible at the role + region + training step level. Then intervention design begins: is it content, level, or the work process?

A small note here: Not all your KPIs live inside the training system. Some are in CRM, some are in HR. That’s why you need to think about data flow. At Nextrain, because real-time data flow can be designed from HR systems, CRM, and internal tools via DataBridge, the bridge between “training score” and “business outcome” requires less manual effort.

7) Step-by-step implementation plan (getting a competency model up in 90 days)

When a competency model is packaged as a “big project,” organizations either never start or, 9 months later, are still debating the glossary. I prefer a smaller, more evidence-focused plan.

0–30 days: Glossary + pilot role

• A 10–15 term mini glossary: knowledge/skill/competency distinction
• Choose 1 pilot role (e.g., Field Sales Specialist or Warehouse Operator)
• Define 6–10 competencies (core + role-specific)
• For each competency: 3–6 behavior indicators + at least 2 evidence types

Most organizations at this stage say “let’s cover every role.” No. The pilot role is the laboratory for your model.

30–60 days: Level definition + measurement prototype

• Lock the L1–L4 level framework
• Write rubrics for 2 competencies
• Design 1 mini quiz + 1 case assessment
• Define on-the-job evidence (which output, who approves, when)

At this stage, there’s a tendency to squeeze measurement into a “single exam.” When I see this, I usually remember the sentence Saadet Dinç (our “We’ll Handle It” Specialist) hears most often from customers: “We delivered the training, but nothing changed in the field.” What doesn’t change in the field is often because measurement never touches the field.

60–90 days: Gap analysis + flow decision

• Collect current level data (assessment + behavior data + work evidence)
• Make the gap visible by role
• Choose the intervention type:
  • content improvement
  • level journey (basic → advanced)
  • managerial support (coaching, shadowing)
• Connect measurement to a “gate”: if successful, advance; if not, repeat/reinforce

In Nextrain, because this “gate” logic can be designed with AI Gates and user-specific flows with AI Rules, the competency model can become not just a “target table,” but a living journey. And yes: it matters that this is visible to employees. That’s why Passport collecting competencies and certificates in one place on the profile reduces the “where am I?” question.

Notes

1. Alfred Korzybski, Science and Sanity: An Introduction to Non-Aristotelian Systems and General Semantics (1931) — “The map is not the territory.”
2. Jorge Luis Borges, “The Library of Babel” (1941) — the problem of finding direction within unlimited information.