A capability framework defines the skills, knowledge and behaviours an organisation needs, at levels of proficiency, mapped to its roles. This paper sets out the four layers of a workable framework, the three ways levelling usually fails, a four-stage build method, why measurement is what turns a framework into infrastructure, and the structural reasons frameworks go unread after launch.
A list is not a framework
A competency list names the things people need to be able to do. A capability framework does three further things: it describes each capability at several levels of proficiency, it maps required levels to actual roles, and it states how the framework will be used.
Those three additions are what turn a list into an instrument. The distinction matters commercially. Organisations frequently commission a framework, receive a well-written taxonomy, and discover a year later that nothing changed — because a taxonomy on its own cannot be applied to a selection panel, a development conversation or a succession review.
The four layers
Frameworks that survive contact with an organisation almost always share the same architecture: capability groups, the capabilities within them, proficiency levels, and role profiles.
Groups are the domains — commonly technical or professional practice, personal effectiveness, working with others, and leadership or stewardship of resources. Capabilities sit inside them, written in the organisation's own language; between twelve and twenty is a workable range, and beyond about thirty, assessment becomes a burden nobody sustains. Proficiency levels, usually four or five, describe what a person at that level can be observed doing. Role profiles set the required level of each capability for a role or role family, so an individual can compare where they are against what the role asks.
Levelling is where frameworks quietly fail
Three failure patterns recur. Adjectival levelling distinguishes levels only by intensifiers — applies, applies effectively, applies expertly — so two assessors reading the same behaviour place it differently and neither can say why. Seniority levelling describes hierarchy rather than capability, restating the org chart and hiding both the senior person with a gap and the junior person ready to progress. Volume levelling distinguishes by how much a person does rather than how they do it, which rewards workload.
What works instead is writing each level as an observable behaviour with a distinct object: what the person acts on, decides, or is accountable for changes as the level rises. If you cannot state what changes between two adjacent levels other than the adverb, the levels are not real.
Read the published frameworks, then write your own
Several substantial frameworks are freely available and worth reading before commissioning anything. The Australian Public Service Commission publishes Work Level Standards and integrated leadership material; the NSW Public Sector Capability Framework is widely used and well documented; SFIA is the international reference for digital and technology roles.
Each is a serious piece of work, and none of them was written for your organisation. Adopting one wholesale usually produces a document staff recognise as imported — and a framework people do not recognise is a framework people do not use. Borrow the architecture; write the content from your own roles, values and work.
Measurement is the difference between a document and infrastructure
A framework can be well written, well levelled and correctly mapped, and still change nothing — because nobody is measured against it. This is the most common state of capability work in large organisations: a well-designed model on an intranet, referenced occasionally in a town hall, absent from every decision it was built to inform.
Two versions of the failure recur. In the first, the framework was never instrumented: the engagement produced the model, the design and the launch communications, but no assessment instrument, so the framework exists as text and never as data. In the second, it was instrumented badly — a one-off self-rating survey, unnormed, never re-run, quietly dropped inside two years.
Three conditions distinguish a measured framework from a published one: every capability has an assessment method a manager or peer can complete about another person; assessment runs on a cadence so movement is visible over time; and decisions visibly reference the results. A useful audit takes three questions per capability — can you name the method that assesses it, can you show movement at team level over the last twelve months, and can you point to one decision in the last year that cited it? The capabilities surviving all three are your real capability infrastructure.
The remedy is rarely a new framework. The work is instrumenting the one you have. Where validated multi-rater measurement is needed for that, we work alongside Perceptn.
Why frameworks fail after launch
The common causes are structural rather than editorial. It was bought rather than built, so nobody owns it. Nothing else changed — position descriptions, selection criteria and performance conversations kept referencing the old criteria, so the framework had no occasion to be used. It is too large to sustain. It has no custodian with authority to update it as roles change. Or assessment carries no consequence, in which case staff correctly conclude the exercise is administrative.
The full paper includes the four-stage build method and a commissioning checklist you can put in front of a prospective provider.
