Building a Competency Framework
Most organisations don't build a competency framework. They download one, rename a handful of boxes to match their own job titles, and call it finished. That's how you end up with a document nobody recognises and a set of "core competencies" describing an idealised employee rather than anyone who actually works there.
Building a competency framework properly means starting from the actual work being done, not a template, and constructing definitions, behavioural indicators, and proficiency levels a manager could use in a real conversation about performance. It is slower than adapting an existing model, and it is the only version of this exercise that produces something people trust.
What Is Building a Competency Framework
Building a competency framework is the process of designing, from organisational data rather than a borrowed template, the specific set of competencies, their definitions, and their proficiency levels that describe how work is actually performed in a given organisation or role family.
That means the output is not a list of admirable traits. It is a structured reference tool: each competency has a precise definition, a small number of proficiency levels (typically three to five), and behavioural indicators that describe what each level looks like when someone is doing the job. If a competency framework doesn't let two different managers independently rate the same employee and land on a similar answer, it hasn't been built well enough to use.
The distinction between building and buying matters here. Plenty of organisations adopt an off-the-shelf competency model wholesale and never touch it again. That's adoption, not construction, and it produces a different set of trade-offs I'll come back to later in this article.
Why It Exists
Organisations build competency frameworks because generic role descriptions and vague performance criteria don't survive contact with real decisions. When you're deciding who to promote, what to assess in an interview, or what a learning and development budget should fund, you need a shared, specific definition of what "good" looks like at each level. Without one, those decisions get made on gut feel, which is inconsistent across managers and hard to defend when challenged.
The functional purpose is coordination. A well-built framework gives HR, line managers, and employees a common vocabulary for capability that doesn't exist by default in most organisations, underpinning recruitment criteria, performance conversations, succession planning, and workforce capability audits from the same set of definitions.
How It Works in Practice
Building a competency framework from scratch follows a reasonably consistent sequence, regardless of sector.
1. Scope the framework. Decide whether you're building for a single role family, a function, or the whole organisation. Scope creep is the most common reason these projects stall, because a framework trying to describe every job at once ends up too abstract to be useful for any of them.
2. Gather real job data. This means structured interviews with subject matter experts and high performers, direct observation where practical, and review of existing role documentation. The goal is to capture what distinguishes strong performance from average performance in the actual work, not what a job description says the role should involve.
3. Draft competency definitions and behavioural indicators. Each competency needs a definition precise enough that two assessors would apply it the same way, plus observable behavioural indicators for each proficiency level. This is where most of the real work sits, and it's the stage where the structural decisions behind capability framework design become relevant, because how you group and layer competencies determines how usable the framework is downstream.
4. Set proficiency levels. Most frameworks use three to five levels. Fewer than three doesn't allow meaningful differentiation; more than five becomes hard to assess reliably in practice.
5. Validate with the people who'll use it. Test draft definitions against real employees the SMEs already agree are strong or weak performers. If the framework can't correctly differentiate between them, the definitions need revision before rollout.
6. Pilot, then embed. Run the framework through one performance cycle or recruitment round before rolling it out organisation-wide, and fix what doesn't work in practice.
A well-known example of this process applied to a specific role is the agile coaching competency framework, which was built from observed practice in agile delivery roles rather than adapted from a generic leadership model, precisely because the generic models didn't capture what agile coaches actually do.
What It Is NOT
Building a competency framework is not the same as writing a values statement. Values are aspirational and organisation-wide; competencies are specific, assessable, and often role-differentiated.
It is also not the same as writing a job description. A job description lists duties and responsibilities. A competency framework describes the underlying capability required to perform those duties well, independent of any single role's task list.
It is not interchangeable with a capability framework, even though the terms get used loosely and often incorrectly in practice. I've set out the practical distinction in detail in capability and competency framework, but the short version is that capability frameworks tend to describe broader organisational or strategic capacity, while competency frameworks describe individual behaviours and skills at role level.
And critically, building a competency framework is not the same exercise as adopting one. If your organisation has taken SFIA, a Korn Ferry model, or a generic leadership competency set and applied it without adapting the language or validating it against your own roles, you have adopted a framework, not built one. That's a legitimate choice in the right circumstances, but it carries different risks, which I'll cover under trade-offs below.
Named Frameworks and Standards Worth Knowing
You don't need to invent competency methodology from scratch. Several established references are worth understanding before you start building, even if you don't adopt them directly.
CIPD's competency factsheet sets out the core distinction between competence (what someone can do) and competency (the behaviours that produce that performance), and provides practical guidance on balancing detail against flexibility when a framework is first drafted, a tension every framework builder eventually runs into.
SHRM took a research-heavy approach to building its own competency model, running focus groups with more than 1,200 HR professionals across 29 cities before validating the draft model with roughly 32,000 respondents globally. A peer-reviewed study of competency framework development for HR management documents a comparable structured process: literature synthesis, SME input, and staged validation, which mirrors the sequence most organisations should follow at a smaller scale.
For technical and digital roles specifically, SFIA remains the most widely referenced skills framework internationally, and Korn Ferry (incorporating the earlier Lominger model) is the most commonly licensed leadership competency library. Government bodies have also built their own: the OECD's framework for digital talent and skills in the public sector is a useful reference for anyone building a competency framework inside a government agency, since it was constructed specifically to reflect public sector constraints rather than adapted from a private-sector leadership model.
Common Failure Modes
The most common mistake is scope inflation: trying to build one framework that covers every role in the organisation at a level of detail that satisfies none of them. Frameworks built this way describe competencies so generically ("communicates effectively") that they can't differentiate performance at all.
A close second is skipping SME validation. HR or an external consultant drafts the framework in isolation, and it gets rolled out without being tested against real employees whose performance is already known. The result looks credible on paper and fails the first time a manager tries to use it in a real assessment.
Vague behavioural indicators are another recurring problem. "Demonstrates strong stakeholder management" tells an assessor nothing to look for. A usable indicator describes an observable behaviour at a specific level, something like "identifies and adapts communication approach for different stakeholder groups without prompting."
Finally, frameworks fail when nobody owns their maintenance. Roles change, and a framework built once and never revisited drifts out of relevance within a couple of years, at which point it quietly stops being used.
Trade-offs and Constraints
Building a competency framework from scratch is resource-intensive. It requires structured SME time, careful drafting, and a validation cycle, which typically means months rather than weeks, and it is not the right choice for every organisation.
Adapting an established model, such as SFIA for technical roles or a licensed leadership model for management competencies, is faster and benefits from validation the model has already been through. The trade-off is fit: adapted frameworks need careful localisation to your own language and role structures, or they end up feeling foreign to the people using them.
Building from scratch makes most sense when role families are distinctive enough that generic models don't fit, when you have the internal capability to run a proper SME process, or when the framework needs to withstand scrutiny in a regulated context. Adapting an existing model suits smaller organisations, common role types unlikely to differ meaningfully from an established model, or situations where speed matters more than a perfect fit.
Neither approach is inherently superior. The failure mode in both directions is the same: skipping validation against the specific roles the framework is meant to describe.
Frequently Asked Questions
How long does it take to build a competency framework?
For a single role family, expect two to four months from scoping through to a validated draft, including SME interviews and a pilot cycle. Organisation-wide frameworks covering multiple role families typically take six months or longer.
Do I need external consultants to build a competency framework?
No, but you do need structured access to subject matter experts and someone with experience drafting behavioural indicators. Many organisations run the process internally using HR or organisational design capability, provided they follow a validated methodology rather than drafting definitions from opinion alone.
How many competencies should a framework include?
Most well-built frameworks land between eight and twelve core competencies per role family. Beyond fifteen, frameworks become difficult to assess against consistently and lose practical use in performance conversations.
What's the difference between building and adapting a competency framework?
Building starts from your organisation's own job data and produces bespoke definitions. Adapting takes an established model, such as SFIA or a licensed leadership framework, and localises it to your context. Both are legitimate; the right choice depends on how distinctive your roles are and how much time you have.
Should competencies differ by role level or apply organisation-wide?
Most effective frameworks include a small set of organisation-wide core competencies alongside role-specific or level-specific competencies. A single flat list applied identically to every role, regardless of seniority or function, is a common design mistake because it can't differentiate a graduate from a director.
How do you validate a newly built competency framework?
Test draft definitions and proficiency levels against real employees whose performance is already agreed upon by their managers or SMEs. If the framework consistently distinguishes known strong performers from known weak performers, it's ready to pilot. If it doesn't, the definitions need revision before rollout.