How to Create a Competency Model That People Actually Use

A competency model defines what capabilities matter in a role and how much of each is expected at each level of progression. Building one is a sequencing problem before it is a writing problem. The order in which you define competencies determines whether you end up with a structure you can maintain or a library of documents that drift out of date within a year.

Most teams start at the role. That is the expensive way to do it. This guide walks the sequence that holds up: organization level first, then leadership, then role families, then individual roles.

If you are still deciding whether a competency model is worth the investment, or you want the definitions and the case for building one, start with our guide to competency models and what makes them operational. This piece assumes that decision is made and covers the build.

Why the Build Sequence Decides the Outcome

Starting at the role feels productive. You pick a job, write the competencies that describe it well, and produce something concrete in an afternoon. Repeat that across 60 roles and you have 60 unrelated documents with overlapping language, inconsistent proficiency definitions, and no shared spine. Every role change means editing a standalone file, and nobody can compare capability across functions.

Starting at the organization level inverts the work. You define the competencies that apply to everyone once, add the layer that applies to people leaders, and then descend to the specifics that genuinely differ by function. Most of the model gets written once and inherited everywhere, which is what makes it maintainable as the org grows.

The sequence also matches how employees experience progression. A person moving from analyst to senior analyst is being asked for more depth in the same core competencies. A person moving into management is being asked for a new category of capability. Building the tiers in that order keeps the model aligned with the moves people actually make.

What to Settle Before Step One

Three decisions belong upstream of any competency writing.

A defined job architecture. A competency model describes capability inside roles, so the roles need to exist as a stable structure first. If titles are inconsistent and levels mean different things across functions, the model inherits that confusion. Job architecture fundamentals covers the diagnostic starting point.

One proficiency scale for the whole model. Define the scale before you write a single competency description. Four levels works for most organizations: Foundation, Intermediate, Advanced, and Expert. Three levels is too coarse to guide a development conversation. Five or more produces false precision that managers cannot rate consistently.

Keep the proficiency scale distinct from your job levels. Proficiency describes how deep someone's capability runs in a specific competency. Job levels describe how scope, impact, and autonomy grow across a career path, which is the work of a job leveling framework. The two connect, and conflating them produces a leveling document with competency labels on it.

A named owner after launch. Someone has to keep the model current as roles evolve. Decide who that is while the project has attention, because the question gets much harder to answer once the build is finished.

Step 1: Define the Core Competencies Everyone Shares

Start at the organization level with the competencies that apply to every employee regardless of function or level. These are the durable capabilities: critical thinking, decision-making, accountability, adaptability, communication, collaboration. Six is a workable number. Career Bird's structure uses six core competencies for exactly this reason, because a shorter list gets ignored as generic and a longer one dilutes the signal.

Write each one at the behavior level rather than the trait level. "Communicates effectively" gives a manager nothing to rate. "Adapts communication style to the audience, translating technical detail into plain language for stakeholders outside the function" describes something two managers can observe and agree on.

Then define what each core competency looks like at Foundation, Intermediate, Advanced, and Expert. The expected proficiency rises with level while the competency stays the same, which is what lets you compare capability across an entire organization on one vocabulary.

The output of this step is a single artifact that covers every employee you have. One tier of writing does most of the work for the entire model.

Step 2: Add the Leadership Layer

The second tier covers the capabilities that begin to matter when someone takes responsibility for other people or for organizational outcomes beyond their own work. Talent development, change management, results management, and strategic direction are the usual four.

Keep this layer separate from the core tier instead of folding leadership behaviors into the general competencies. Separation does two useful things. It keeps the core model honest for the individual contributors who make up most of your headcount, and it makes the transition into leadership legible as a distinct capability shift rather than a vague expectation that senior people will figure it out.

Career Bird's model carries four leadership competencies alongside the six core, applied at the levels where people leadership and senior individual contribution begin. Define proficiency expectations for these the same way, on the same scale.

Naming the category also sharpens diagnosis later. "We need better managers" is not something you can act on. "We have a leadership-competency gap in talent development at the senior-manager level" points directly at the development action.

Step 3: Work Down to Role Families

Only now do you descend to function. Role families group jobs that share a common function and skill trajectory: Engineering, Product, Go-to-Market, Finance, People. Five to eight families is typically the right scope for a mid-market organization on version one.

For each family, add the competencies that genuinely differentiate performance in that function and are shared across the roles inside it. A Go-to-Market family might add customer discovery, commercial judgment, and value communication. Every role in that family draws on all three, at different depths.

Resist the urge to re-state core competencies here with a functional flavor. If a competency you are about to write is a specialized wording of one from Step 1, adjust the Step 1 proficiency descriptions instead. Duplication across tiers is the most common source of model bloat, and it is what makes managers stop trusting the ratings.

Step 4: Add Role-Based Competencies Where the Work Demands Them

The final tier is the role-specific technical and functional capability: financial modeling for an analyst, renewal motion design for a customer success manager, systems design for an engineer. Career Bird's structure supports twelve role-based competencies, which is enough to describe a role with precision and few enough to keep assessment realistic.

Two disciplines keep this tier from sprawling.

First, add a role-based competency only when it differentiates performance within the family. If every role in Engineering needs it equally, it belongs at the family level from Step 3. If it describes a task rather than a capability, it belongs in the job description.

Second, stop at the roles that carry real headcount or real progression significance. You do not need a complete model for every job code before the model is useful. Cover your largest families and your most common progression paths, publish, and extend from there.

Step 5: Validate Each Tier With the Business

HR owns the design. The business owns the truth about what drives performance. Validate at each tier rather than saving one review for the end, because a flaw in the core competencies propagates into everything built on top of it.

For the core and leadership tiers, review with your executive team. These competencies describe the organization's expectations of everyone, so they need leadership endorsement to carry weight. For each role family, run one focused session with three to five senior practitioners and high performers in that function. Ask a direct question: does this describe what actually separates strong performance here from adequate performance?

Accuracy is the goal of these sessions. Leaders will surface nuances the design missed and push back on competencies that read as generic. Consensus is not required, and one session per tier is usually enough.

Step 6: Connect the Model to Skills Assessment

A model that is never assessed against stays a description. Connecting it to assessment is what turns the finished structure into development activity.

Map each competency to the underlying skills it draws on. Value communication might draw on data analysis, executive communication, and business acumen. Once that mapping exists, you can measure where someone actually stands instead of recording whether a box was checked during a review cycle. McKinsey research finds that the large majority of organizations either already face skill gaps or expect to within the next several years, and a model with no measurement layer cannot help you close them.

Assessment then routes into two places. Gaps feed a skills gap analysis that shows where capability is thin across teams, and they feed learning recommendations aimed at the specific competency at the specific level. Both connections are also what give managers something concrete to work from in career development conversations, where the reference becomes what the target role requires and where the employee stands today.

What the Finished Structure Looks Like

Following the sequence above produces three tiers on one proficiency scale:

• Six core competencies, org-wide, applied to every employee at rising proficiency by level
• Four leadership competencies, applied where people leadership and senior individual contribution begin
• Twelve role-based competencies, describing the technical and functional capability specific to a role

Career Bird organizes competencies into this structure across four proficiency levels (Foundation, Intermediate, Advanced, Expert), and the same categories and scale carry into skills assessment, learning recommendations, and career paths. Because the model and the assessment share one vocabulary, a manager rates against the model directly and the gap falls out of the comparison with no translation step.

The structure is also what makes the model legible to employees. A person can see the six competencies expected of everyone, the four that come with leadership, and the specific capability their function requires, along with the proficiency the next role asks for.

Sequencing Mistakes That Force a Rebuild

Writing role competencies first. The result is a large volume of documentation with no shared spine, and the fix is a rebuild rather than an edit.

Setting the proficiency scale last. Descriptions written before the scale exists rarely map cleanly onto it, so someone rewrites all of them.

Skipping the leadership tier. Organizations that fold leadership behaviors into core competencies lose the ability to describe the management transition, and manager development becomes guesswork.

Building for completeness instead of connection. A model designed to cover every job code looks different from one designed to route into assessment and learning. The connected version is the one that gets used, so decide how the model will feed those systems before you write the content.

Treating the build as a project with an end date. Roles change, functions emerge, and the value of specific skills shifts. The model needs an owner and a review cadence, or it quietly stops describing the organization it was built for.

A Realistic Timeline

For a mid-market organization with a defined job architecture, the core and leadership tiers take two to four weeks including executive validation. Role families run one to two weeks each and can be worked in parallel across HR business partners. Role-based competencies for your highest-headcount roles add another two to four weeks.

That puts a usable first version at roughly one quarter, with coverage extending afterward. Organizations that try to publish complete coverage on day one generally take a year and publish something already out of date.

Frequently Asked Questions

Where should you start when creating a competency model?

Start at the organization level with the core competencies that apply to every employee, then add the leadership layer, then work down to role families and individual roles. Starting at the role level produces unconnected documents with inconsistent language and no shared proficiency standard, which is the most common reason a competency model becomes unmaintainable.

How many competencies should a competency model have?

A workable structure is six core competencies applied org-wide, four leadership competencies applied where people leadership begins, and up to twelve role-based competencies describing the technical capability specific to a role. That gives enough precision to guide development while keeping assessment realistic for managers.

How long does it take to build a competency model?

A mid-market organization with a defined job architecture can produce a usable first version in about a quarter: two to four weeks for the core and leadership tiers, one to two weeks per role family, and two to four weeks for the role-based competencies of the highest-headcount roles. Coverage extends from there rather than being completed up front.

Who should be involved in building a competency model?

HR owns the design and the sequence. Validate the core and leadership tiers with the executive team, since those competencies set expectations for everyone. Validate each role family with three to five senior practitioners and high performers in that function. Name a single owner responsible for keeping the model current after launch.

What is the difference between a competency model and a leveling framework?

A competency model defines what capabilities matter in a role and the proficiency expected at each level. A leveling framework defines how scope, impact, and autonomy grow across levels. The two connect, because proficiency expectations rise as levels rise, and they answer different questions. Building one while calling it the other is a frequent source of confusion in talent architecture projects.

Should competencies be written as behaviors or as traits?

Write behaviors. "Shows initiative" is a trait, and two managers will rate it three different ways. "Identifies work that falls outside defined ownership and proposes a path forward before being asked" describes something observable that a manager and an employee can assess against the same definition. Consistent assessment is what allows the model to connect to skills data.

‍

The competency model is the foundation that skills assessment, career paths, manager conversations, and learning recommendations are built on. Its value shows up in what happens after it is finished, which is why the sequence matters: build the shared layer first, and every tier above it inherits a consistent standard.

If you are planning a competency model build and want to see how the tiers connect to assessment, learning, and career paths in one system, Career Bird unifies job architecture, competency definitions, skills assessment, and career pathing for mid-market organizations. Request a demo and our team will walk you through the structure.