To develop a capability framework, you define the broad, durable human capabilities your people need, set proficiency levels for each one, and write the observable behaviours that show each level. It is design work, not drafting. This page sets out the seven steps I use, a worked example and a review checklist. It sits under my pillar on the capability framework, which covers the definition, levels and failure modes in full.
One distinction runs through every step. A capability is a broad, durable area of ability that a person owns and carries across roles. A skill is a discrete, learned ability that shifts as tools change. A framework built from skills dates within a year or two. A framework built from capabilities lasts, because it describes what people can do across roles rather than what they can do with this year's tools.
What is a capability framework?
A capability framework is an organisation-wide structure that defines and organises the human capabilities people need to deliver the strategy, built to evolve as technology and strategy shift. Developing one means producing four things: a set of capability domains, a definition for each capability, a proficiency scale, and a behavioural indicator for each capability at each level.
It is not a list of skills, a set of position descriptions or a performance rating form. It is also not organisational capability, which is what the business as a whole must be able to do. In this framework, capability is held by a person.
A note on terminology. A competency framework is also called a competency model, especially in the United States. I use competency profile for the competencies and required levels for one role, and competency matrix for the grid of required against current proficiency. Usage varies by region, and I explain the differences in this competency model definition.
How to Develop a Capability Framework in Seven Steps
Allow six to ten weeks for an organisation of a few hundred people. The steps run in order, because each one fixes the input to the next.
Step 1: Start from the strategy and the work
List the three to five things the organisation must do differently over the next three to five years. Then list the work that delivers them. Capabilities are chosen to support that work, not copied from another organisation's framework. Interview ten to fifteen people across levels and ask what separates strong performance from adequate performance in their work.
Step 2: Choose the capability domains
Group capabilities by the area of human functioning they draw on, not by job function. Marcus Bowles groups them as Thinking, Personal and Action, and that pattern travels well. Avoid role-specific technical categories. Technical expertise belongs in role profiles or in a skills framework. Three to five domains is workable.
Step 3: Define each capability
Aim for twelve to twenty capabilities in total, with one definition sentence for each. Test every candidate with two questions. Does it carry across at least three different roles? Will it still matter in five years? If either answer is no, it is probably a skill or a task, and it stays out. Keep behaviours out of the definition as well. Behaviours belong in the indicators.
Step 4: Set the proficiency levels
Use four to six levels. Set them by scope, autonomy, complexity and impact, never by seniority or years of service. SFIA is a well-tested precedent. It is structured around seven levels of responsibility, and it describes each level using autonomy, influence and complexity, with business skills and knowledge alongside them.
Name the levels in plain words and use the same names for every capability. My page on capability framework levels covers how many to use and what goes wrong.
Step 5: Write behavioural indicators
Write two to four indicators for each capability at each level. Each indicator is an observable behaviour in a work situation. It describes what a person does, not what they are like, and it is descriptive rather than evaluative. Then check the progression. Each level should differ from the one below by scope or complexity, not by a stronger adjective. If you swap "occasionally" for "consistently" and call it a level, the level does not exist.
Step 6: Build capability profiles for roles
Select the capabilities and the required level for each role family. Restraint matters here. The NSW Public Service Commission's 2014 Role Description Development Guideline allows four to ten focus capabilities for a role, asks for at least one from each capability group, and says the levels chosen for a role should not generally span more than three consecutive levels. I treat that as a sound rule of thumb in any sector.
The profile then feeds the position description. The Victorian Public Sector Commission explains that in a position description its Capability Framework informs the key selection criteria, while a separate set of job descriptors informs the accountabilities. For worked profiles across sectors, see my capability framework examples.
Step 7: Test, govern and release
Test the framework before release. Ask ten managers to level five real people each against the indicators, then compare the results. Where managers disagree, the indicators are unclear, so fix them. Then name an owner, set a review cycle of two to three years, and decide who is allowed to change a definition. A framework with no owner starts to drift within a year.
What does it look like when you develop a capability framework in practice?
The example below is illustrative. A 400-person state agency wants one framework to support recruitment, development and career paths.
| Step | Output in the example |
|---|---|
| 1. Strategy and work | Two shifts identified: moving services online and working across agencies. Twelve interviews held. |
| 2. Domains | Three domains: Thinking, Personal and Action. |
| 3. Capabilities | Fourteen capabilities, such as Analytical thinking, Adaptability, Collaboration and Service delivery. |
| 4. Levels | Five levels: Foundational, Intermediate, Proficient, Advanced and Leading. |
| 5. Indicators | Three indicators per capability per level, 210 in total. |
| 6. Profiles | Twenty-two role profiles with six to eight focus capabilities each. |
| 7. Test and govern | Eight managers level the same five people. Seven indicators rewritten. Owner and review date set. |
Review checklist for a capability framework
- Every capability carries across at least three roles and will matter in five years.
- No capability is really a skill, a tool or a task.
- The same level names are used for every capability.
- Levels are set by scope, autonomy, complexity and impact, not by seniority.
- Each indicator is an observable behaviour, written without evaluative words.
- Each level differs from the one below by scope or complexity, not by adverbs.
- No role profile asks for every capability at the top level.
- Managers who level the same person reach similar answers.
- An owner and a review date are recorded.
Where does developing a capability framework go wrong?
- Skills creep in. A list headed "capabilities" fills with software names and methods. These change quickly and belong in a skills framework.
- Levels follow seniority. A level that means "manager" tells you nothing about what the person can do.
- Too many capabilities. Beyond about twenty, nobody can hold the set in their head and profiles become shopping lists.
- Another organisation's framework is copied. The words fit, but the work does not.
- Nobody owns it. Definitions drift and the framework stops matching the work.
I cover the wider pattern in why most capability frameworks fail.
When is developing a capability framework the wrong choice?
Developing a capability framework carries a cost in time and in ownership. It is the wrong choice in three situations.
- The need is short term. If you need to match people to this quarter's work, a skills framework serves you better.
- The organisation is very small. Under about fifty people, a handful of role profiles is usually enough.
- Nobody will own it. An unowned framework does more harm than none.
The design choices behind these trade-offs, such as how to organise domains and how many levels to use, are set out in my taxonomy of capability framework design.
FAQ
How long does it take to develop a capability framework?
Six to ten weeks for an organisation of a few hundred people, if interviews and testing are scheduled early. Writing the indicators takes the longest.
How many capabilities should a capability framework have?
Twelve to twenty is a workable range. Fewer than ten usually means the definitions are too broad to use. More than twenty usually means skills have crept in.
What is the difference between developing a capability framework and developing a competency framework?
The method is similar. The difference is the unit. A capability is broad, durable and carried across roles, while a competency integrates skills, knowledge, judgement and behaviour in the context of a role. A capability framework therefore changes less often.
Should a capability framework include technical skills?
No. Technical skills are specific and change with tools. Keep them in role profiles or a separate skills framework, and link the two.
Who should own a capability framework?
One named person in the people function, with a review date and a rule for who may change a definition. Shared ownership usually means no ownership.
