How the People Capability System Works
The People Capability System works by deriving the work from the strategy rather than describing the work and mapping the strategy onto it afterwards. That derivation, done downward, produces a line. Running the system upward reads that line back. Almost every capability effort I have seen does neither, and instead produces a document with a slide at the end showing alignment that was never designed in.
The complete argument is at peoplecapabilitysystem.com. This article explains the mechanism.
How does the People Capability System work?
The People Capability System works by intending each layer to the layer above it during the build, which creates a clear line from a strategic bet down to a discrete skill, and then reading each layer upward during the run, which produces a live answer to whether the strategy is executable by the people you have.
Build is design. Run is operation. Keeping them separate is what stops the line from decaying.
Building it: intending the work to the strategy
Building starts with the bets and moves downward. Each step exists because the step above it required it.
- Name the bets. Do this with leadership, not for them, and do it before anything else. If the bets are not explicit, surface them. A vague strategy produces a vague framework, and design craft does not rescue it. This is also where acceptance starts, because a bet leadership will not own is not a bet.
- Derive the capability framework. Define the durable human capabilities those bets require, across all roles rather than tied to any one of them. Derive them from the bets, not from the roles you already have. Keep the number small enough that a person can hold it in their head. A long catalogue is a sign the derivation was never done and the existing work was described instead. The design choices in a capability framework do most of their work here.
- Define the competency framework. For each role, specify the competencies that turn those capabilities into delivered work, with proficiency levels and observable indicators. Most of the design effort sits here, and the structural rules are the ones that govern any well-built competency framework.
- Specify the skills taxonomy. Structure the skills under each competency, with levels, so a skill means the same thing wherever it appears rather than drifting team by team.
- Generate the position descriptions. Assemble them from the competency framework and the skills taxonomy. Do not write them freehand. This is the step people skip, and it is why position descriptions drift away from the line inside a year.
By the time you reach a skill, you can walk back up to a bet without a mapping slide. That is intent, and it is a structural property rather than a communications one.
The line has to be clear and accepted
Clear means walkable in both directions. Point at any skill and name the bet it serves. Point at any bet and name the work that delivers it, in which roles, at what level.
Accepted means leadership owns the bets, and the people in the roles agree the line runs through their work. A correct line that nobody in the role believes gets ignored the first time it costs them something. I would take a rougher line that people accept over a perfect one they do not.
Running it, bottom up
Once the line exists, the work reports up through it.
- Check the skill. Is it present at the level the role needs. Close to binary. Evidence is demonstrated performance or verified output, not a completion record.
- Evidence the competency. Is it held, not just claimed. Assessed against levelled behavioural indicators by the person and their supervisor, anchored to observable behaviour, triangulated against real work.
- Read the capability. Is it deep enough across the workforce. Read from accumulated evidence of performance under real conditions, not from a score on a designed test.
- Roll it up. Given the people we have and the level they are at, is this strategy executable.
Build has an end date. Run does not. A read produced once a year, in an event cut off from the work, is not a run.
Why this drives performance
Three mechanisms, all visible in the structure.
Effort is aimed at what the strategy needs, by construction
Because every layer was derived from the one above, people work on the capabilities and skills the strategy actually requires, levelled to their role, rather than on whatever a generic framework happened to list. Effort stops leaking into work no bet needs. That is a property of the build, not a motivational intervention.
Alongside it sits a separate empirical claim about role clarity. Peer-reviewed meta-analysis finds role ambiguity is negatively related to job performance, and work engagement, which has clarity of expectations at its base, predicts task and contextual performance. The build makes the local role standard explicit and levelled, which is exactly the condition that research is about.
The run loop keeps the state of capability visible
Because the system reads upward continuously, you hold a current picture rather than an annual guess. The discipline is evidencing rather than asserting. A supervisor-verified record of competence on real work is a different object from an attendance list, and only one of them is worth anything.
Development is wired in, and the mix inverts as you climb
The same structure that measures also tells you how to develop. Closing a skill gap is mostly formal and social learning. Building a durable capability is mostly deep experience, stretch work and reflection, because capability is revealed and grown under novelty and consequence rather than in a classroom. The 70-20-10 mix inverts as you move up the layers, which is why generic development spend produces so little change. It is decoupled from the layer it was meant to serve.
A worked example
Take a customer operations team leader, and a bet many service businesses are making right now: resolve complex, non-standard cases at first contact rather than handling them fast and passing them on.
Built down from the bet. The human capability that bet requires is sensemaking under ambiguity, reading a situation that does not fit the script and choosing a path. The role competency is resolving complex cases to completion, at a level that means working across more than one system, deciding within policy without escalating, and closing the loop with the customer. The skills underneath are navigating the case management system, applying the hardship and remediation policies, de-escalating a distressed customer, and writing a clear resolution summary.
Note what did not happen. Nobody listed the team's existing skills and mapped them to the priority afterwards.
Run back up. Skills: after onboarding, most of the team has the four at the required level. Competency: here the gap appears, because standard cases get resolved and non-standard ones get quietly escalated. Capability: sensemaking under ambiguity is thin, so when the script runs out people freeze or hand the case on. Strategy: fast handling is executable today, first-contact resolution of complex cases is not yet.
The gap is capability, not skill. So the development is experience and reflection, not another short module. A mapped architecture would have seen the skills present, called the team compliant, and bought more content.
What running it produces
One artefact per layer, and one composite. Capability produces a capability framework. Competency produces a competency framework. Skill produces a skills taxonomy, the levelling logic for which is well established in practice, most visibly in SFIA's levels of responsibility. Strategy produces nothing, because it is the input you read from rather than an output you build.
Position descriptions are a downstream composite, generated from the competency framework and the skills taxonomy. That is what stops the line decaying at the point people actually touch it.
The hard part is not the design
The framework is the easy part. The hard part is acceptance, and it is behavioural and political rather than methodological.
Make the system useful to the individual before it is useful to the organisation, as a route to development, internal moves and a career path a person can see, so they have a reason to give honest evidence rather than to game it. Calibrate and moderate, so a rating means the same thing across teams. And make leadership use the read in real decisions about staffing, development spend and succession, because a system that visibly changes nothing gets filled in carelessly within a cycle. Most capability efforts that fail do not fail on design. They fail here.
FAQ
How does the People Capability System actually work?It is built once from the top down, deriving capability from the strategic bets, competency from capability, and skills from competency. It is then run continuously from the bottom up, checking skills, evidencing competencies, reading capability, and rolling that into a view of whether the strategy is executable.
What is the line in the People Capability System?The traceable connection from a strategic bet down to a discrete skill and back up again. It exists because each layer was derived from the one above rather than written independently and mapped afterwards.
How is capability assessed if it cannot be tested on demand?It is not scored in a test. Evidence is accumulated as capability shows up in real work over time, weighted towards the non-standard situations where it actually appears. That read is longitudinal, and it is the least mature part of the system.
How often should the run cycle happen?Light and continuous updates as the work changes, with a review of the frameworks against strategy on a set rhythm. Once a year is usually enough for the framework review. An annual event on its own is not a run.
Who owns the run?A named capability lead in human resources or organisation development, who maintains the frameworks and calls the assessment cycle. A committee that meets and disperses is not an owner.