Core Competencies Framework: Defining and Using Competencies for Performance and Growth

Most organizations have a competency framework somewhere. It's usually a spreadsheet or a PDF that HR built during a talent management initiative two or three years ago, and it's almost never opened. Managers write performance reviews from memory and gut feel. Interviewers ask whatever questions occur to them. New hires get a job description with a list of duties and no sense of what "good" actually looks like at their level.

The problem usually isn't that the framework is wrong. It's that it was built as a compliance artifact instead of a working tool. A competency framework that managers use daily looks different from one that exists to satisfy an HR audit, and the difference comes down to three things: the competencies are specific enough to be useful, the proficiency levels describe observable behavior instead of vague adjectives, and the framework is actually referenced in the moments where it matters, hiring, reviews, and development conversations.

This guide covers how to build that kind of framework, whether you're creating one from scratch or fixing one that's been sitting unused.

What a Competency Framework Actually Is

A competency framework defines the behaviors and skills that predict success in a role or across an organization, and it describes what different levels of proficiency in each one look like. It sits between two things organizations already have: job descriptions (which describe duties and outcomes) and performance ratings (which describe how well someone did). The framework fills the gap by describing how someone should be doing the work, not just what they're doing or how it turned out.

There are two broad categories worth distinguishing, because conflating them is one of the most common design mistakes:

Core (or organizational) competencies apply to everyone regardless of role. Things like communication, accountability, collaboration, and adaptability show up in almost every serious framework because they predict success across functions. SHRM's Body of Applied Skills and Knowledge, the competency model it maintains for the HR profession, is built on exactly this split: nine behavioral competencies that apply broadly, plus one technical competency covering role-specific HR expertise. That structure, behavioral competencies layered with role-specific technical depth, is worth borrowing even outside HR.

Role-specific (or functional) competencies vary by job family. A sales competency framework needs negotiation skills and territory judgment. An engineering framework needs technical depth and code quality judgment. A management framework needs delegation and coaching skills. Trying to capture both categories in a single flat list is what makes most frameworks unwieldy, ten pages of competencies that apply to nobody's actual job in full.

Choosing Which Competencies Belong in Your Core Set

The instinct when building a framework is to include everything that sounds important. Resist it. A core competency framework with 20 items is one nobody memorizes, and a framework nobody remembers doesn't change behavior.

Most functional core frameworks land between 5 and 8 competencies. To get there, start with your organization's actual failure patterns, not an aspirational list. Ask: when someone underperforms here, what's usually missing? When someone gets promoted, what did they visibly do differently? The answers tend to cluster around a handful of recurring themes: how people communicate, how they handle ambiguity or change, how they take ownership of outcomes, how they work with others, and how they think through problems.

A reasonable starting core set for most organizations includes:

• Ownership and accountability: following through on commitments and owning outcomes, not just tasks
• Communication: clarity in writing and speaking, and the judgment to know which one a situation calls for
• Collaboration: working effectively across teams and functions, not just within one's own group
• Adaptability: handling ambiguity, changing priorities, and new information without needing everything mapped out in advance
• Critical thinking and judgment: reasoning through problems rather than defaulting to the first plausible answer
• Results orientation: a consistent bias toward finishing and delivering, not just activity

From there, layer in role-specific competencies for each job family. A business acumen competency matters enormously for a strategy role and barely at all for an entry-level operations role, so it belongs in some role-specific sets and not the universal core.

Writing Proficiency Levels That Aren't Vague

This is where most frameworks fail even when the competency list itself is reasonable. "Demonstrates strong communication skills" tells a manager nothing they didn't already believe about the employee they're rating. Proficiency levels need to describe observable behavior at each level, specific enough that two different managers rating the same person would land on the same level.

A workable structure uses four or five levels, moving from foundational to expert. For a competency like ownership and accountability, that might look like:

The test for whether a level description is good enough: could a manager point to a specific instance from the last quarter and say "that's a proficient-level example" or "that's advanced"? If the description is too abstract to test against a real example, rewrite it until it isn't.

Connecting the Framework to Where It Actually Gets Used

A framework that lives in a document and nowhere else will not survive its first year. It needs to show up in at least three places to earn its keep.

Hiring. Interview questions should map to specific competencies at the level the role requires. If a role requires "advanced" collaboration, the interview should include a behavioral question designed to surface evidence at that level, not a generic "tell me about a time you worked on a team" question that could apply to any level.

Performance reviews. This is the most direct connection, and it's covered in depth in the performance review framework guide: reviews that reference the competency framework give employees a concrete map of where they are and what the next level looks like. Reviews without that anchor default to vague, unfalsifiable feedback like "be more strategic."

Development planning. Once someone's current level on a given competency is identified, the framework should point to what closes the gap. If a report shows someone is "developing" on giving feedback, the manager and employee should be able to identify specific practice opportunities in the next quarter, not just note the gap and move on.

Deloitte's research on skills-based talent models, based on an analysis of 87 organizations testing more than 28 different skills-related strategies, found that the organizations creating measurable value from their skills work started by anchoring the framework to a specific business outcome rather than building comprehensive skills infrastructure first and hoping managers would find a use for it. The same principle applies at the competency-framework level: pick the one or two decisions (hiring, promotion, development budget) you most want the framework to improve, wire it into those decisions first, and expand from there.

Calibrating Across Managers

A framework only works if "proficient" means roughly the same thing regardless of who's rating. Without calibration, one manager's "proficient" is another manager's "developing," and employees in different parts of the organization are effectively held to different standards while everyone believes the ratings are objective.

Calibration sessions, where managers compare notes on borderline cases before finalizing ratings, are the mechanism that keeps this honest. They're uncomfortable the first time because they surface real disagreement about what a level actually requires, but that disagreement is the point. It's better to argue about the standard in a calibration meeting than to let inconsistent standards quietly erode trust in the whole system.

Common Mistakes When Building a Framework

Building it in isolation from the managers who'll use it. A framework designed entirely by HR without input from people managers tends to describe an idealized version of the role rather than what actually predicts success in it. Involve managers early, even if it slows the process down.

Too many competencies, not enough discipline. Twelve core competencies is not a core framework, it's a wish list. If everything is core, nothing is prioritized, and managers will quietly ignore the ones they don't have time to assess properly.

Proficiency levels written as adjectives instead of behaviors. "Excellent," "good," "needs improvement" are ratings, not descriptions. If the level definitions don't tell a manager what to look for, they're not doing their job.

No mechanism for updating the framework. Competencies that mattered five years ago (deep expertise in a specific tool, for instance) can become less relevant as work changes, while new ones (working effectively with AI-assisted workflows) become newly relevant. A framework reviewed once and never revisited drifts out of date quietly.

Treating the framework as a rating tool only. If the only place the framework shows up is the annual review, employees will experience it as a judgment mechanism rather than a development tool, and engagement with it will be defensive rather than genuine.

Getting Started

If you're building a core framework from scratch, start small: pick 5-6 core competencies using the failure-pattern exercise above, write four proficiency levels for each using specific, testable behaviors, and pilot it with one team before rolling it out organization-wide. Get feedback from the managers who used it in that pilot quarter before finalizing anything. A framework that's been stress-tested against real performance conversations will be far more durable than one designed entirely on a whiteboard.

If you're fixing an existing framework that's fallen out of use, start by asking a handful of managers whether they've referenced it in the last quarter. If the honest answer is no, the fix usually isn't more content, it's fewer competencies, sharper level descriptions, and a specific decision (like the next hiring round or review cycle) where you deliberately force its use.

Related Resources

• Performance Review Framework - Connecting competency assessment to formal review conversations
• Accountability - A close look at one of the most common core competencies
• Communication - Defining proficiency levels for a universally core skill
• Coaching Skills for Managers - Using the framework to structure development conversations
• Giving Feedback Effectively - Turning a competency gap into specific, actionable feedback
• Decision Making - A role-agnostic competency relevant across nearly every job family
• Organizational Capability Building - Connecting individual competency systems to organization-wide capability