The Four Layers of the People Capability System

The Four Layers of the People Capability System

The Four Layers of the People Capability System

The four layers of the People Capability System are strategy, capability, competency and skill. The order is not decoration. It is the direction of derivation. Each layer exists because the layer above it required it, and if you build them in any other order you have described your existing work and mapped a strategy onto it, which is the thing the system exists to stop.

The full working paper is at peoplecapabilitysystem.com. This article defines the layers and defends the order.

What are the four layers of the People Capability System?

The four layers of the People Capability System are strategy, capability, competency and skill. Strategy is the input the system reads from. Capability is the durable human layer, derived from the strategic bets and held across all roles. Competency is the role-level layer, derived from capability. Skill is the discrete, binary layer where work is executed, derived from competency.

The layers nest. They do not sit side by side. That distinction carries more weight than it looks like it should.

Layer one: strategy

Strategy is the bets the organisation is making about where it is going and how it intends to win.

Strategy is not a layer the system builds. It is the input everything below is derived from and answerable to. Get this wrong and nothing below it can be right. If the bets are not explicit, the build has nowhere to start, and I have watched people try to compensate for a vague strategy with better facilitation. It does not work. A vague strategy produces a vague capability framework, every time.

The bets also have to be owned. If leadership treats them as a communications artefact rather than as the actual bets, everything derived from them is derived from nothing.

Layer two: capability

Capability is a broad, durable area of ability that a person owns and carries with them across roles, tasks and contexts.

Three things about this matter.

It is human. It belongs to people, not to the organisation. What an organisation collectively can do is a different construct, organisational capability, which is what the dynamic capabilities literature is about. That construct is real and useful and it is deliberately out of scope here. Keeping the two apart is the only way to stop the word doing two jobs at once.

It is defined across all roles. That does not mean it is a capability of the organisation as a whole. It means it is defined once across the whole role landscape and then held by individuals.

It is derived from the bets. This is the part that gets skipped. Most capability frameworks are derived from the roles that already exist, then mapped to strategy afterwards. If your capability framework would look the same regardless of what the strategy said, it was not derived. I have set out the broader case for capability frameworks separately.

Layer three: competency

Competency is the integration of skills, knowledge, judgement and behaviour, applied effectively in the context of a role.

A competency describes what good performance looks like as observable behaviour, held at a defined level of proficiency. It is not a task. It is not a single skill. It is scoped to the role, and that scoping is the point of it. This is the definition I hold to whenever I write about what competency actually means.

The tradition behind it is well established. McClelland argued that testing for competence, the behaviour that actually produces results in a role, predicts performance better than testing for intelligence in the abstract. Boyatzis, then Spencer and Spencer, built that out into behaviour causally linked to superior performance, assessed against observable indicators rather than self-belief.

In this system, a competency exists because a capability had to be delivered inside a role. That is where it comes from.

Layer four: skill

A skill is a discrete, learned ability to do something specific.

Skills are granular and transient. They shift as tools, technology and methods change. A skill is the level at which work is executed, and it is the unit where the human, augmented or automated decision gets made, which is why this layer matters more now than it did five years ago.

At assessment, a skill is largely binary. A person has it at the level required, or there is a gap to close. That binary quality is a feature. It makes the bottom of the line tractable.

International definitions converge here. The European Commission's ESCO definitions treat a skill as the applied use of knowledge to complete a task or solve a problem, narrower than competence. Australia's National Skills Taxonomy is building a shared national language on the same basis. I have written separately on what skills and skills taxonomies actually are.

Why this order

Capability sits above competency because it is the layer that survives a change of role. A person keeps their capability when they move, and their role competencies get rebuilt around the new job. Because capability is durable and forward-looking, it belongs next to strategy, which is also about where the organisation is going. Competency and skill describe the present role and the present task, so they sit lower, closer to the work.

Read top to bottom, the layers move from the most durable and strategic to the most granular and immediate. That movement is the direction of intent, and it is the spine of the whole system.

Why the layers nest rather than sit side by side

This is the part I would push hardest on.

The system has to roll one layer up into the next. Skills evidence a competency. Competencies express a capability. Capability answers a strategic bet. A structure of siblings, four boxes in a row with arrows between them, cannot do that.

Most capability architectures I have audited are sibling structures pretending to be nested ones. They have a capability list, a competency list and a skills list, and a diagram with arrows. Nothing actually rolls up, because nothing was derived. The lists were written separately and mapped afterwards, which is not the same thing, and the mapping quietly stops being true.

Why it may not match yours

This will not match every framework a reader already runs, and the differences are worth naming rather than glossing.

Some organisations use capability to mean what the organisation can do and competency to mean what the individual can do. This system uses capability for the durable human layer and keeps organisational capability out of scope, so the two senses never collide. SFIA, which many readers already run, levels skills against responsibility and uses the language of competence for a skill demonstrated in real situations. That maps cleanly into the skill and competency layers here. It simply stops short of a durable human-capability layer above the role.

My naming is not the only correct one. Each layer is defined by what it has to do in the system. If your model names these differently, the test is whether its structure can derive downward and roll up the way this one does.

Framework, model and matrix are not synonyms

One more distinction sits across the layers, and getting it wrong does as much damage as confusing capability with competency.

  • A framework is the organisation-wide governing structure for a layer.
  • A model is an applied instance of that framework for a particular role or cohort.
  • A matrix is the grid that shows what people hold against what their roles require.

The system builds frameworks once and generates models and matrices from them, rather than letting each team invent its own. This is exactly the conflation I have complained about at length, and it is not pedantry. If a framework and a model are the same word, you cannot tell whether a team has applied the governing structure or replaced it.

What each layer produces

Strategy produces nothing. Every layer below it produces exactly one governing artefact.

  • Strategy — Input, not an output.
  • Capability — Capability framework.
  • Competency — Competency framework.
  • Skill — Skills taxonomy.

Position descriptions are not a fifth artefact. They are a downstream composite, generated from the competency framework and the skills taxonomy. Change the competency framework and the position descriptions move with it, because they are drawn from it rather than copied out of it once. That is what keeps the line intact at the point people actually touch it.

FAQ

What are the four layers of the People Capability System?Strategy, capability, competency and skill. Strategy is the input. Capability is durable and human. Competency is scoped to the role. Skill is discrete and close to binary.

Why does capability sit above competency?Because capability survives a change of role and competency does not. Capability is durable and forward-looking, which puts it closer to strategy. Competency describes the present role.

Is capability in this system organisational or human?Human. Organisational capability is a different construct and is deliberately out of scope, so the word never does two jobs at once.

Why do the layers nest rather than sit side by side?Because the system has to roll each layer up into the one above. Skills evidence a competency, competencies express a capability, capability answers a bet. Siblings cannot roll up. A nesting can.

What is the difference between a framework, a model and a matrix?A framework is the organisation-wide governing structure for a layer. A model applies it to a role or cohort. A matrix shows what people hold against what their roles require.

Table of Contents

Want to chat about this?

I'm happy to talk through how it works.

Get in touch

Rethinking how work is structured? Let’s talk.

I don’t have all the answers... but I’m deep in the questions. If you're thinking about jobs, skills, or AI’s impact on work, I’d love to connect.

Rethinking how work is structured? Let’s talk.