The People Capability System

The problem is not capability. It is assembly.

Walk into most mid to large organisations and you will not find a shortage of capability material. You will find a capability framework somewhere, a list of competencies in old role profiles, a learning catalogue, an engagement survey, position descriptions, and a skills field in the HR system that nobody trusts. The parts exist. They were just built at different times, by different people, for different reasons, and they were never wired together.

So the architecture is fragmented. Strategy sits in a board pack. The capability framework sits in a slide deck from a project two years ago. Competencies sit in position descriptions that have drifted from the work. Skills sit in a learning platform that talks to none of it. Along the way the language slips. Capability gets used to mean competency, skill gets used to mean capability, and a framework, a model and a matrix get treated as the same thing when they are not.4 Terms get conflated, frameworks pile up, and roles bloat.

The cost shows up as questions you cannot answer cleanly. Which capabilities does this strategy actually require, and at what level. Is this role staffed to the standard it is supposed to meet. Where is the gap, and what closes it. When an auditor asks for evidence of competence, when a regulator asks how you control a workplace hazard, or when a tribunal asks whether a person was held to a clear standard and supported against it, you assemble the answer by hand, each time, from sources that were never designed to talk to each other.

Artificial intelligence makes the cracks visible. As tasks shift to automation and augmentation, the live question becomes what humans still do and to what level they need to do it. A fragmented architecture cannot answer that, because it cannot trace a line from the strategy down to the task and back up again.

The fix is not one more framework. It is an architecture that holds the parts in a single structure and keeps them connected as the work changes. That is what the People Capability System is.

Four layers, defined so they cannot be confused

The system has four layers: strategy, capability, competency and skill. The whole thing depends on keeping these distinct, because the moment they blur, the architecture stops being able to trace anything. The definitions below are precise on purpose.

The order is deliberate. Capability sits above competency because it is the durable layer. It is what a person keeps when the role changes, so it belongs closer to strategy, which is also about the future. Competency and skill sit closer to the work, because they describe the present role and the present task. Read top to bottom, the layers move from the most durable and strategic to the most granular and immediate. That movement is the spine of everything that follows.

One more distinction matters for the rest of the paper. 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 then generates models and matrices from them, rather than letting each team invent its own.

Why this order, and why it may differ from yours

The ordering is a claim, not a convention, so it is worth defending rather than asserting. 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 are rebuilt around the new job. Because capability is the durable and forward-looking layer, 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. The layers nest rather than sit side by side for a specific reason: the system has to roll one up into the next, where skills evidence a competency, competencies express a capability, and capability answers a strategic bet. A structure of siblings cannot roll up like that. A nesting can.

This will not match every framework a reader already runs, and the differences are worth naming. 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. The Skills Framework for the Information Age, which many readers will know, levels skills against responsibility and uses the language of competence for a skill demonstrated in real situations.11 That maps cleanly into the skill and competency layers here, and it simply stops short of a separate, durable human-capability layer above the role. The point is not that this naming is the only correct one. It is that each layer is defined by what it has to do in the system, tracing from a bet down to a task and back up again, rather than by the label a given framework happens to use. If your model names these differently, the test is whether its structure can trace and roll up the way this one does.

Built once, top down. Run forever, bottom up.

A capability system is two different activities pointing in two different directions, and most efforts fail because they only ever do the first one. You build it once, top down, as a piece of design. Then you run it continuously, bottom up, as an operation.

Building runs downward from strategy. You name the bets the business is making. You derive the human capabilities those bets require, defined across all roles rather than tied to any one of them. You define the competencies each role needs to turn those capabilities into delivered work. You specify the skills that sit under each competency. Every step is answerable to the step above it, so by the time you reach a skill, you can trace a clean line back up to a bet. That line is line-of-sight, and it is the thing a fragmented architecture can never give you. Building is design work. You do it once and then maintain it as strategy moves.

Running goes the other way. Once the structure exists, the work reports up through it. You check whether a person has the skill at the level the role needs. You evidence whether the competency is held, not just claimed. You read whether the capability is deep enough across the workforce to actually execute. You roll that up into a single read: given the people we have and the level they are at, is this strategy executable. Running is operational, and unlike building it never stops. The state of the work becomes a live state of the strategy.

Keeping the two directions separate is what saves the system from the usual fate. Most capability work is all build and no run. A framework is designed, launched and admired, and then it sits on a shelf because nobody designed the operation that was meant to keep it alive. Build is a project with an end date. Run is business as usual with no end date. The system is only worth standing up if you intend to run it.

One durable artefact per layer, and one composite

Running the system needs something to run on. The build produces a small number of durable, governed artefacts, one for each layer below strategy, and the run reads and updates them. These artefacts are the difference between a system and a slide deck.

Strategy produces nothing here. It is the input you read from, not an output you build. Below it, each layer produces exactly one governing structure. The capability layer produces a capability framework, the organisation-wide structure of the human capabilities the strategy needs, built to evolve as technology and strategy shift.1 The competency layer produces a competency framework, the governing structure of role competencies with proficiency levels and observable indicators.5 The skill layer produces a skills taxonomy, a structured classification so that a skill means the same thing wherever it appears, rather than a flat list that drifts team by team.10

Position descriptions are the case that proves the point. In most organisations they are written by hand, role by role, and they drift from the work within a year. In this system a position description is not a separate thing you author. It is a 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.

Holding the artefacts this way is what makes the system governable. Models for specific roles and matrices for specific people are generated from the frameworks, so there is one source of truth instead of a hundred local versions. It is also what makes the system auditable, which becomes the basis for the defensibility this paper turns to later. For the skill layer, the levelling logic that makes a taxonomy assessable is well established, and the Skills Framework for the Information Age is the most widely used example of a structure that adds proficiency levels and application rules on top of a classification.11

How it drives people performance

The claim that this system drives performance is not a slogan. It rests on three mechanisms that are visible in the structure itself, and each one is backed by work that has held up for decades.

1. Line-of-sight aims effort at what the strategy needs

Because every layer is derived from the one above it, people end up working 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 things no bet needs. That is strategic alignment, and the system produces it by construction, because every requirement traces back to a bet.

There is a second and different claim often folded into the first, and it is worth separating them. Strategic alignment is about effort being aimed at what the strategy needs. Local role clarity is about a person knowing what is expected of them in their own role. The two are not the same thing, and the evidence for each is different. Alignment follows from the line-of-sight the build creates. Role clarity is an empirical claim about people, and the evidence for it is strong and, importantly, independent of any single provider. Peer-reviewed meta-analysis finds role ambiguity negatively related to job performance,28 and a separate meta-analysis links work engagement, which has clarity of expectations at its base, to task and contextual performance.29 Gallup's large-scale engagement work points the same way, placing knowing what is expected at the base of engagement, though it is correlational and produced by a single provider, so the independent studies are what the claim actually rests on.13

The system links the two claims in one move. The build creates the alignment as a structural property, and it makes the local role standard explicit and levelled, and therefore assessable rather than implied, which is precisely the condition the clarity research is about. A person can see what the strategy needs and what is expected of them, and the two turn out to be the same picture read at different heights.

2. The run loop keeps the state of capability visible

Because the system reads upward continuously, you hold a current picture instead of an annual guess: is the skill present, is the competency evidenced, is the capability deep enough, is the strategy executable by the people you have. Measurement you can act on is what separates managing capability from hoping about it. The discipline that matters here is evidencing rather than asserting. A skill is checked for presence, a competency is assessed against levelled behavioural indicators by the person and their supervisor, and a capability is read from evidence of performance in real conditions rather than from a course completion.

3. Development is wired in, and it inverts as you climb

The same structure that measures also tells you how to develop, and in what mix. This is where the 70-20-10 model earns its place. It came out of research at the Center for Creative Leadership, which found that managers attributed most of their development to challenging experience, a smaller share to other people, and a small share to formal courses.12 Read against the layers, the mix inverts as you climb. Closing a skill gap is mostly the formal ten and the social twenty: a course, a job aid, a peer. Building a durable capability is mostly the deep seventy: stretch assignments, exposure and reflection, because capability is revealed and grown under novelty and real consequence, not in a classroom.1516

The development mix also explains a common failure that has nothing to do with effort. A great deal of learning spend produces little change because the learning is decoupled from the work it was meant to serve. The research on training transfer has shown for years that most of what is taught never reaches performance.14 Tying each piece of learning to the specific competency or skill it serves, and matching the method to the layer, is what lifts transfer from an accident to a design choice.

Put the three together and the performance case is straightforward. Effort is aimed at what strategy needs, the state of capability is always visible, and growth is matched to the kind of development each layer actually responds to. None of those three is novel on its own. What is new is that one structure delivers all of them at once.

One role, traced down and back up

The model is easier to trust once you see it run on a single role. Take a customer operations team leader, and a strategic bet that many service businesses are making right now: move from rewarding speed of handling to resolving complex, non-standard cases at first contact. Here is how that bet travels down the four layers, and then what the run reads back up.

Built top down from the betone role, one strategic bet

Now run it back up

Once the structure exists, the work reports up through it, and the read is specific rather than general.

That single trace does several things at once. It gives the team leader and the team a clear, levelled picture of what good looks like, which is the role clarity that sits at the base of engagement and is also a named safety duty. It produces supervisor-verified evidence of competence on real cases, which is exactly what an auditor would ask to see. And if a person genuinely cannot reach the standard even with the right development, the documented standard and the record of support are already there, so a separate and properly run process has something fair to work from. One build, traced through one role, and the performance read and the evidence both fall out of it.

None of the parts is invented. That is the point.

A fair question to ask of any system like this is whether it rests on real evidence or on confident assertion. This one is deliberately built from constructs that have been defined, tested and argued over for decades. The originality is in the assembly, not in the pieces. Here is what each layer stands on.

Capability

The idea that human capability is a broad, durable, transferable quality, distinct from any single skill, has a long lineage. Its intellectual ancestor sits in development economics, where Sen's capability approach framed capability as what a person is substantively able to do and to be. That is a welfare and freedoms account rather than a workplace one, so it is used here as a conceptual root and not as direct support, but it is the source of the durable intuition that capability is about realised ability rather than credentials.2 Brought into work and education, the construct was developed by Stephenson as the integration of knowledge, skills and personal qualities applied with judgement in unfamiliar situations,3 and in the Australian applied tradition as the ability to apply skills, knowledge and behaviours in context, revealed under novelty and consequence rather than in routine.4 Recent work argues that as routine execution is automated, it is precisely this human capability that becomes the scarce and decisive input, and that organisations systematically confuse it with skills and underprice it as a result.1 A separate body of work on dynamic capabilities describes how organisations sense and reconfigure under change. That construct is organisational, not human, and the capability layer here is deliberately the human one. The two are related but they are not the same thing, and the system keeps them apart.17

Competency

The competency layer traces to McClelland's argument that testing for competence, the behaviour that actually produces results in a role, predicts performance better than testing for intelligence or aptitude in the abstract.5 McClelland opened the field, but the definition this layer actually uses was built out by those who followed. Boyatzis modelled competency as the underlying characteristics behind effective performance,23 and Spencer and Spencer codified it as behaviour causally linked to superior performance, assessed against observable indicators rather than self-belief.24 That is the form the competency layer takes here: an integrated set of behaviour applied in a role and held at a defined level of proficiency.

Skill

The skill layer rests on the most settled definitions in the field. International frameworks converge on a skill as the applied use of knowledge to complete a task or solve a problem, scoped to particular methods and settings, and narrower than competence.67 The same view runs through the work of the major labour and education bodies, which treat skills as learnable inputs that combine with knowledge and behaviour into higher-order capability.89 In Australia, the National Skills Taxonomy is building a shared language for exactly this.10 The levelling logic that turns a flat skills list into something assessable is well established in practice, most visibly in the Skills Framework for the Information Age and its levels of responsibility.11

Development and performance

The development mechanism rests on the 70-20-10 research from the Center for Creative Leadership,12 on the situated and reflective view of how capability is actually grown,1516 and on the long-standing finding that most formal training fails to transfer unless it is tied to the work.1432 The performance link rests on independent, peer-reviewed evidence that role ambiguity is negatively related to performance28 and that work engagement predicts task and contextual performance,29 alongside Gallup's large-scale engagement work, which points the same way but is correlational and produced by a single provider.13

Two cautions keep this honest. First, what is evidenced above is the components, one layer at a time. A set of individually validated parts does not entail a validated whole, and the interaction between the layers, which is where this system makes its claim, is exactly what the component evidence does not reach. The assembled system is therefore a conceptual proposition, and the burden of proving the composite sits with the research agenda set out later in this paper, not with the citations above. Second, this evidence is of uneven weight. The capability framing in particular leans on a recent position paper rather than on peer-reviewed work,1 which is a legitimate source for an argument but should be read as one. With those cautions stated, the claim is bounded and fair. The parts are credible, the assembly is a proposition, and the test is whether wiring them into one build-and-run structure produces the performance and the evidence this paper describes.

What came before, and what is actually new

This is not the first attempt to connect strategy, capability and roles, and an honest claim of novelty has to say what came before and where it stalled. There are three lineages a careful reader will already have in mind.

The closest is competency-based management. Boyatzis, and then Spencer and Spencer, built models linking competencies to superior performance,2324 and Lawler argued for organisations built around competencies rather than fixed jobs.25 This tradition produced the competency frameworks most organisations still run. Where it stalled is well documented. The frameworks became static documents, cut off from operation, and drifted from the work, which is the shelved-artefact problem this paper opened with. The construct was sound. The operating model was missing.

The second lineage is strategic human resource architecture. Lepak and Snell modelled how different parts of the workforce should be managed and developed according to their strategic value,26 and the workforce-architecture work associated with Becker, Huselid and Ulrich tied human resource systems to strategy and performance.27 This established that the workforce should be architected against strategy. Where it stops short is granularity. It reasons at the level of workforce segments and systems, not a line you can trace from a single strategic bet down to a task and back up again.

The third lineage is the skills-framework tradition, SFIA, O*NET, ESCO and the National Skills Taxonomy,11610 which levels skills and gives them a shared language, but carries no durable human-capability layer above the role and no run loop. The build-and-run distinction itself has antecedents too, in the older separation of capability as a stock from performance as a flow, and in the design-versus-operate split that runs through the routines and dynamic-capabilities literature.17 These are ancestors, not the same thing.

Set against that, the contribution is specific and limited. It is not the four constructs, which are borrowed. It is the assembly, and four claims are made for it. The first is the particular human spine, ordering durable human capability above role competency above skill, derived top down and rolled up bottom up, with organisational capability deliberately left out. The second is the explicit separation of build from run as an operating model, which is the thing competency-based management never made operational and the reason its frameworks shelved. The third is the artefact chain, in which position descriptions are generated as a composite rather than authored, giving one source of truth and a traceable line end to end. The fourth is the convergence claim, that one run produces both the performance read and the evidence that obligations as different as quality-system competence and the psychosocial role-clarity duty separately ask for.

Each of these moves has antecedents, and this section is a positioning claim rather than an exhaustive review. A fuller literature search may surface closer prior art, and if it does, the novelty claim should narrow to match. The honest position is that the assembly and its operating model are the contribution, and that this is itself a claim to be tested against the field rather than a settled fact.

Making the read trustworthy

Everything the system claims depends on the run producing a valid and current read of capability. That makes measurement the load-bearing question, and the place the system is most exposed, so it is worth confronting directly rather than assuming.

Skill is the most tractable layer. It is a presence check at a level, and the evidence is demonstrated performance or verified output rather than a course completion. Reliability comes from clear level descriptors and, where the skill matters, a practical demonstration in place of a claim.

Competency is harder, because it is assessed against behavioural indicators by the person and a supervisor, and the obvious risk is that two assessors read the same behaviour differently. The system handles this the way the assessment field does. Indicators are anchored to observable behaviour, calibration and moderation across assessors keep a rating meaning the same thing in different teams, and assessments are triangulated against real work rather than resting on a single judgement. The principle being applied is the one SFIA uses, that competence is recognised from demonstrated practice in real situations.11 None of this removes the problem of inter-rater reliability. It bounds it, and it makes the residual error visible instead of hidden.

Capability is the hard case, and the source seems to forbid it

Capability is the layer where measurement is genuinely unsolved, and the paper should say so plainly. You cannot validly score a durable human capability in a designed, on-demand test. The source this system draws on makes exactly that argument: capability resists being reduced to skills, standardised, elicited on demand or scored, and is revealed only under novelty and consequence.1 Taken at face value that reads as a contradiction, because the system proposes to assess capability at all. The reconciliation is in how. The system does not score capability in a test. It accumulates evidence of capability as it is expressed in real work over time, weighted towards the non-standard situations where capability actually shows, which is consistent with the situated and reflective accounts of how capability forms.1516 The capability read is therefore longitudinal and evidential, a pattern built from situated performance, not a number from an assessment event. A version of this system that tried to score capability on demand would be making the very error the source warns against.

Even with that distinction, capability measurement is the least mature part of the system. Establishing that a longitudinal evidence read is valid, that different assessors converge on it, and that it predicts later performance, is an open research problem rather than a solved one. So the claim is narrower than it can first appear. The system does not claim to have measured capability precisely. It claims to make the evidence of capability structured and visible, and so open to improvement, where today it is mostly invisible and anecdotal. That is a real gain, and it is also the part of the system that most needs validation, which is where the propositions that follow concentrate.

What it gives the rest of HR

The system is not a replacement for talent acquisition, learning, workforce planning or performance management. It sits underneath them as a shared evidence layer and hands each one a clean input it would otherwise have to invent for itself. This is the sense in which it touches, informs and supports the wider people function, rather than competing with it.

The distinction matters, so it is worth stating plainly. In each case below, the system informs the function. It is not the hero of the story and it does not run the process. It gives the people who run these processes a defensible standard and current evidence to work from, so their decisions rest on something other than memory and instinct.

1. Talent acquisition The competency framework and the levelled skills give hiring a real standard. The position description, generated from those sources, becomes the brief, and the same levelled indicators become the interview scorecard. You hire against the role's actual requirement rather than against a wishlist written the week the vacancy opened.
2. Onboarding The role's competency model is the ramp. From day one a new starter has a defined target for what good looks like and at what level, so onboarding has a destination instead of a tour. Time to productivity becomes something you can plan towards rather than hope for.
3. Learning and development The run side produces the gap, by person and by role. That gap drives the learning, and the 70-20-10 mix tells you the method. Spend stops going to generic catalogue content and starts closing the specific gaps that the strategy depends on, with the experiential and social channels used for capability and formal learning reserved for discrete skills.
4. Workforce planning The skills taxonomy and the capability framework give planning a supply read and a demand read in the same language. You can see where capability is thin against where the strategy is heading, which is the input planning needs and rarely has in a form it can act on.
5. Internal mobility and career pathing Because capabilities are defined across all roles and skills are structured rather than listed, adjacency becomes visible. You can see who is close to another role and what the short list of gaps is. Career paths stop being administrative ladders and become routes defined by capability and competency, which a person can actually see and aim at.
6. Succession planning The capability matrix shows who is ready now, who is close, and what the gap is for the roles that matter most. Succession moves from a private list in a leader's head to a read grounded in evidence of what people hold against what the role requires.
7. Performance management This is the case where the boundary is sharpest. The system does not run performance management and it does not rate or rank anyone. What it provides is the documented standard for the role and the evidence of where a person sits against it, which the performance process can draw on. The system informs the conversation. It does not own it. More on that boundary in the limits section.
8. Remuneration and reward Levelled competencies and responsibility levels give reward a defensible basis for banding and for explaining why one role sits where it does. The system does not set pay. It gives the people who do a consistent, role-based logic to anchor it to, rather than a negotiation settled by who argues hardest.

Read together, this is why the system earns its place. A single build feeds eight functions that would otherwise each commission their own version of the same underlying structure, in their own language, drifting apart from each other within a year. One source of truth, many consumers.

The defensibility dividend

Here is the part most capability efforts miss. The evidence the system produces when you run it is the same evidence three separate Australian obligations already ask you to hold. You are not doing compliance work on the side. You are running the system, and the documentation falls out of it as a by-product.

One point governs this whole section. The system informs these regimes. It does not replace a quality management system, it does not run a workplace safety program, and it does not conduct dismissals. It is the evidence layer those processes draw on. With that boundary clear, the three obligations are below.

Quality: ISO 9001, competence

Clause 7.2 of ISO 9001 requires an organisation to determine the competence necessary for people whose work affects quality, to ensure they are competent on the basis of education, training or experience, to act where there are gaps, and to retain documented information as evidence of competence.18 Read that against the system. The build side determines necessary competence, in the competency framework and the position descriptions drawn from it. The run side produces and retains the evidence, because evidencing competence is what running the system is. Auditors commonly look for a competence matrix linking roles to required competencies, with evidence beyond attendance records. That is an artefact the system already maintains.

Safety: the psychosocial duty

Australia's model work health and safety regulations now require a business to identify, assess, control and review psychosocial risks, and the model Code of Practice gives practical guidance on how.20 Lack of role clarity is a named psychosocial hazard in that Code, alongside low role clarity, poor role design and low opportunity to develop or use skills.19 The build side of the system is a direct, documentable control for that one hazard, because defining a role to a clear standard with levelled expectations is what role clarity means in practice. The scope of the claim has to be precise. The psychosocial duty is broad, and it also covers job demands, support, organisational justice and a range of other hazards that this system does not address. Controlling role clarity is one named control, not a discharge of the whole duty, and it should always be presented that way. Within that bound it is real and documentable. It also connects to the performance mechanism from earlier, because knowing what is expected of you is both the base of engagement and a named safety duty, and the same clear role standard answers both. Courts may treat an approved Code as evidence of what is reasonably practicable, so a documented control carries weight.

Fair process: the capacity limb of unfair dismissal

When the Fair Work Commission considers whether a dismissal was harsh, unjust or unreasonable, the first thing it weighs is whether there was a valid reason related to the person's capacity or conduct, and then whether the person was notified, given a chance to respond, and warned about performance before the decision.21 Case law treats a fair process as including clear job expectations and a real opportunity to improve, which often means development and support.22 The system does not run dismissals. What it holds is the documented role standard and the record of development offered against it. If a separate, properly run process ever has to address capacity, that material supports procedural fairness rather than leaving the organisation to assemble it after the fact.

The return, and an honest caveat about it

A system like this is usually justified by a return, and the return is real enough to model across eight distinct pillars. It is also the part of any capability business case that deserves the most caution, so the caveat comes first, before any of the pillars.

With that stated, the eight pillars are where the value shows up. Each one is a place where a clear, current, role-based view of capability changes a number the business already tracks.

1. Attrition reduction A meaningful share of voluntary turnover is driven by people who cannot see a path or feel under-developed. Giving development a visible structure addresses that segment, and avoided replacement cost is the return. The lever is retention of people who would otherwise leave for want of a path. Basis: lack of career development is a leading reason people quit (McKinsey, 2022);31 replacement cost runs from roughly one-half to two times annual salary (Gallup).30
2. Engagement and productivity Role clarity is the base of engagement, and engagement links to productivity and to the discretionary effort people choose to give. The build side makes expectations explicit, which lifts the clarity item that sits under everything else.13 Basis: Gallup's engagement research links role clarity and engagement to performance,13 supported independently by peer-reviewed meta-analyses of role clarity28 and of work engagement29 against performance. The Gallup evidence is correlational and single-provider, so the independent studies carry the weight.
3. Psychosocial hazard management Controlling the role-clarity hazard reduces the conditions that produce psychological injury claims, with their direct costs and premium impact. The same build that drives clarity is the documented control.19 Basis: the Australian return-on-investment analysis for mentally healthy workplaces (PwC and beyondblue, 2014);35 lack of role clarity is a named psychosocial hazard.19
4. Internal mobility When adjacency is visible, more roles are filled from inside, which is faster and cheaper than external hiring and tends to retain people longer. The lever is the substitution of internal moves for external hires where the capability is already close. Basis: employees stay markedly longer where internal mobility is strong (LinkedIn Workplace Learning Report, 2024).36
5. Learning spend efficiency Mapping learning to the specific competency or skill it serves cuts spend on content that does not close a real gap, and matching method to layer lifts the share of learning that actually reaches the work.14 Basis: the training-transfer research on why most training fails to reach the job (Baldwin and Ford, 1988).32
6. Performance management Clear standards and continuous evidence reduce the manager time spent constructing a case from scratch and reduce the noise in ratings. The system informs the process rather than running it, and a documented standard also supports fair process.22 Basis: idiosyncratic rater effects account for over half the variance in performance ratings (Scullen, Mount and Goff, 2000);33 the review process consumed close to two million hours a year at one large firm (Buckingham and Goodall, 2015).34
7. Compliance and audit readiness Competence evidence and traceability cut the time spent assembling documentation for an audit, and support broader human-capital and operational-risk obligations where capability of accountable people is in scope. Basis: human capital reporting under ISO 30414;38 operational-risk obligations under APRA CPS 230, where the capability of accountable people is in scope.39
8. Speed to productivity A role's competency model is the onboarding target, which shortens the time a new starter takes to reach full productivity. The lever is a faster ramp, repeated across every hire. Basis: structured onboarding lifts new-hire retention and time to productivity, yet few organisations do it well (Gallup).37

The pattern across all eight is the same. None of them is a new revenue line. Each is a place where having a clear, current, role-based picture of capability removes cost, friction or risk that a fragmented architecture leaves in place. Whether the total is large or modest depends entirely on the organisation, which is exactly why the caveat sits at the top of this section rather than the bottom.

If you need to build a case, the pillars are designed to be made numerical. A companion set of calculators takes your own inputs and assumptions for each pillar and produces a figure you can stand behind, with the assumptions visible next to the result. They are kept separate from this paper on purpose, so the argument here does not lean on numbers that would date, and so the figures you put in front of a board are yours rather than borrowed.

Standing it up, then running it

The operating model is only useful if it can be built and then kept alive. The build is a scoped project. The run is a standing operation with a named owner. Treating them as the same thing, or skipping the design of the run, is the most common way these efforts fail.

The build

1. Read the strategy and name the betsDo this with leadership, not for them. If the bets are not explicit, surface them, because everything below derives from this and a vague strategy produces a vague framework.
2. Derive the capability frameworkDefine the human capabilities the bets require, across all roles, built to evolve. Keep the number small enough to be real. A short list of durable capabilities beats a long catalogue nobody can hold in their head.
3. Define the competency frameworkFor each role, specify the competencies that turn those capabilities into delivered work, with proficiency levels and observable indicators. This is where most of the design effort sits.
4. Specify the skills taxonomyStructure the skills under each competency, with levels, so a skill means the same thing wherever it appears. Aim for a workable number per role rather than an exhaustive list.
5. Generate the position descriptionsAssemble them from the competency framework and the skills taxonomy rather than writing them freehand, so they stay tied to the sources and stop drifting.

The run

1. Assess against the standardCheck skills for presence, assess competencies through self and supervisor against the indicators, and read capability from evidence of performance in real conditions. Evidence, not attendance.
2. Roll the read upTurn the assessments into a gap view by person and by role, and roll that into a workforce-level read of whether the strategy is executable by the people you have.
3. Develop to the gapDirect development at the specific gaps, using the 70-20-10 mix by layer. Formal and social learning to close skills, experience and reflection to build capability.
4. Govern the frameworksMaintain the frameworks as strategy moves, keep one source of truth, and resist the local versions that pull the architecture back apart.

What running it actually takes

The run becomes real when it has somewhere to live and someone to hold it. Give it a named owner, a 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. Give it a system of record as well, because the artefacts have to sit somewhere that can be queried and read by the functions that consume them, rather than in documents and slide decks. That does not mean buying a new platform. It means giving the frameworks and the matrix a home, in the human resources system or a skills and capability tool, that can surface a current read on demand. And give it a cadence that rides the cycles you already run. Keep the updates light and continuous as the work changes, and review the frameworks against strategy on a set rhythm, where once a year is usually enough. A read produced once, in an annual event cut off from the work, is not a run.

Adoption is the hard part

The framework is the easy part of this work. The hard part is getting managers to assess honestly and people to engage with the result, and that is a behavioural and political problem rather than a methodological one. A few things move it. The first is to 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 actually see, so they have a reason to give honest evidence rather than to game it. Honest evidence also depends on calibration and moderation, so that a rating means the same thing across teams and does not drift upward to keep everyone comfortable. None of it survives unless leadership uses 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. It also helps to start where there is pull, with a leader who wants the read, rather than imposing it where there is none. Most capability efforts that fail do not fail on design. They fail here.

Two pieces of sequencing advice carry most of the risk. Start narrow and prove it, on one job family or on the roles that matter most, before scaling across the organisation. And decide who owns the run before you start the build, because a framework with no operational owner becomes the shelved artefact this paper opened with. Generative tools can accelerate the build by deriving and drafting framework content at speed, which is a real saving, but the validation has to stay human, against the strategy and against the glossary that keeps the language disciplined.

Limits and boundaries

A system is more trustworthy when it is clear about what it does not do and where it can be attacked. These are the boundaries and the soft spots, stated plainly rather than buried.

The biggest risk is adoption, not design.

The most likely way this system fails has nothing to do with the architecture. It is that managers do not assess honestly, people do not engage, and the read is never used in a real decision, so the whole thing decays into a form-filling exercise. This is a behavioural and political risk, and it is larger than any of the methodological soft spots below it. The implementation section sets out what moves it, but it belongs here too, because a sound design adopted badly produces nothing. Anyone weighing this system should weigh the change effort, not only the framework.

It is development-only. It is not a rating engine.

The system measures capability in order to develop it, not to rank or to discipline. It does not run performance management and it does not conduct dismissals. It informs those processes by holding a clear standard and the evidence against it, and the line is deliberate. The moment a development system is repurposed as a surveillance or policing tool, people stop giving it honest evidence, and the data that made it useful degrades. Keeping it development-only is what keeps it working.

The return is the most attackable part.

The eight pillars in the return assume that the system causes a slice of effects that always have many causes. Turnover, engagement and audit time move for reasons well beyond capability architecture. That is why the figures are framed as an illustrative model resting on stated assumptions, not a forecast, and why the honest reading is directional rather than precise. Anyone building a business case on these pillars should foreground the assumptions and avoid implying a clean causal line.

The development model is a heuristic, not a law.

The 70-20-10 mix came from executives reflecting on their own development, which is self-report with the limits that come with it.12 It is a sound design principle for balancing where development effort goes. It is not a measured constant, and the ratios should not be treated as precise.

Assessment is imperfect and needs calibration.

Self and supervisor assessment drifts upward without calibration, and capability, read from evidence of performance under real conditions, is harder to standardise than a binary skill check. The system reduces this by anchoring assessment to observable indicators and to evidence rather than to opinion, but it does not remove the need for calibration and honest moderation. A framework with inflated ratings is a framework nobody trusts.

It describes what humans do. It is not a whole people strategy.

The system is an architecture for capability. It is not a substitute for leadership, for the design of the work itself, for culture, or for fair reward. Those things sit outside it and matter as much. The claim here is bounded: this is the structure that turns strategy into a clear, current, role-based view of human capability, and that informs the rest of the people function. It is not the whole of that function.

This paper is an argument, not a trial.

What is set out here is a case that the architecture is coherent, that its parts are individually credible, and that the assembly produces performance and evidence. It is not an empirical study of this specific assembly in a specific organisation. That proof is the next step, and it is the right thing to be sceptical about until it exists. The honest status of the claim is a well-grounded design awaiting evidence, not a validated result.

Propositions, and how to test them

Because the composite is a proposition and not yet a result, the honest contribution is to state what would have to be true for the system to work, and how each claim could be falsified. These are written so that a negative result is possible, which is the point.

1. P1. Traceability In organisations that build the four-layer system, a higher share of role requirements can be traced to an explicit strategic bet than in matched organisations running disconnected frameworks. Test: a comparative traceability audit across matched organisations.
2. P2. Role clarity and performance Standing up the build raises measured role clarity, and through it engagement and team performance, against a baseline. Test: a pre-and-post comparison with a control, using independent clarity and engagement measures, since the existing evidence is correlational and largely single-provider.
3. P3. The run loop and currency Organisations that operate the run hold a more accurate and current read of capability gaps, checked against an independent assessment, than those that build but never run. Test: the accuracy of the system's read against a blind capability audit.
4. P4. Development matching and transfer Directing development by layer, using the 70-20-10 mix, produces higher transfer to on-the-job performance than development chosen without regard to layer. Test: a controlled learning comparison that measures transfer, not completion.
5. P5. Convergence and defensibility The run-side evidence reduces the time and cost to satisfy competence-evidence, role-clarity control and fair-process documentation, compared with assembling each separately. Test: a time-and-cost comparison, plus audit and review outcomes.
6. P6. The composite claim The assembled system produces a better capability-to-performance outcome than the same components deployed separately. This is the central claim and the hardest to test, and it is the one on which the whole argument should ultimately stand or fall. Test: a design that compares assembled against unassembled deployment on a defined outcome.

None of these is settled here. Stating them this way is what a conceptual paper is for, because it turns an untested system into a set of claims that others can confirm or break. The intention is to pursue them through structured expert critique and case evidence, and the most useful criticism of this paper is the one that sharpens a proposition or shows how to falsify it faster.

Where this goes

The argument of this paper is narrow on purpose. The problem in most organisations was never a shortage of capability material. It was the absence of an architecture that holds the material together and keeps it connected as the work changes.

The People Capability System is that architecture. Four layers, built once from the top and run continuously from the bottom. It drives performance by aiming effort at what the strategy needs, by keeping the state of capability visible, and by matching development to the kind of growth each layer responds to. It produces, as the ordinary output of running it, the evidence that quality, safety and fair-process obligations separately require. And it does all of this from constructs that are individually credible and decades old, which is why the contribution is the assembly rather than any new theory.

The honest next step is proof. A coherent design that rests on good evidence is not the same as a validated result in a specific organisation, and the paper has tried to be clear about that gap rather than paper over it. The work from here is to test the assembly: to put it into organisations, to run it, and to measure whether the performance and the defensibility show up as the architecture predicts. The intention is to pursue that through structured expert critique and case evidence rather than assertion.

That is also why comments are open. The most useful response to this paper is a specific one. If a definition is wrong, name it. If a mechanism does not follow, say where it breaks. If the evidence is thinner than claimed, point to the gap. The argument is stronger for being tested, and the place to test it is here.