What is a Capability Framework? And why do they matter?

Most leaders don't arrive at a conversation asking for a capability framework. They arrive describing symptoms: managers holding their teams to visibly different standards, promotion decisions that look arbitrary from the outside, two employees behaving in almost exactly the same way with one praised for showing initiative and the other pulled aside for overstepping.

These look like performance problems. More often they are expectation problems, and the two call for very different responses. A performance problem sits with an individual. An expectation problem sits with the organisation, and coaching one manager at a time will not resolve it.

That gap is what a capability framework exists to close.

What a capability framework actually is

A capability framework sets out the skills, behaviours and attributes people need to succeed in their roles. It describes what good work looks like across the organisation, covering technical ability alongside how people communicate, make decisions, solve problems, lead others and contribute beyond their own patch.

The difference from a position description is worth being specific about. A position description lists what a person is accountable for. A capability framework describes how the work is done well, and what growing into the next level actually requires of someone.

AHRI takes a similar approach with its own Australian HR Capability Framework, which it describes as defining the "capabilities, skills, knowledge and behaviours required to deliver a great employee experience and drive strong organisations". The framing holds well beyond HR: capability sits at the intersection of what someone knows, what they can do, and how they go about it.

Built properly, the framework becomes the language running underneath recruitment, performance conversations, development planning and career progression, which is what moves it out of the HR folder and into how the organisation talks about work day to day.

Why capability frameworks matter

Inconsistency scales with growth. Every new manager brings their own instincts about what strong performance looks like. Every new team develops its own norms. In a business of fifteen people, leaders can hold the standard in their heads and mostly stay aligned. At fifty, that stops being possible, and the differences show up in who gets promoted, who gets stretched, and who disengages without ever saying so.

Without a shared reference point, a performance rating reflects the reviewer as much as the person being reviewed. Progression starts to look like a matter of visibility rather than contribution, and that perception does damage long before anyone raises it formally.

The CIPD's guidance on competence and competency frameworks, last updated in August 2024, puts the case plainly: applied well, frameworks "can increase clarity around performance expectations and establish a clear link between individual and organisational performance".

That link is the practical payoff. When the standard is written down and actually used, difficult conversations become more objective and promotion decisions become easier to explain to the people who didn't get promoted. It also answers a question employees ask themselves constantly and rarely out loud: what would I need to be doing differently to move forward here?

Where organisations commonly struggle

Few organisations set out to build a bad capability framework. The failure points are consistent enough to name.

Building it in isolation. A framework written entirely inside HR, without leaders or employees in the room, tends to describe an idealised version of the organisation rather than the real one. People feel the difference immediately, and it never quite earns their trust.

Overengineering it. This is the most common trap. CIPD's guidance cautions that "care needs to be taken to balance detail with flexibility and avoid an overly prescriptive and non-inclusive approach". Frameworks with nine capability domains, six proficiency levels and several hundred behavioural indicators are technically thorough and practically unusable. They get read once at launch and never again.

Borrowing someone else's. Generic frameworks lifted from another organisation carry that organisation's priorities, not the one adopting them. They describe capabilities that sound reasonable and mean very little in context.

Writing it in language nobody uses. If the behavioural descriptors don't sound like the way people in the business actually speak, they won't get quoted in a performance conversation.

Launching it and stopping there. If recruitment, performance reviews, development plans and progression decisions carry on exactly as they did before, the framework is a document rather than a working part of the business.

Waiting to be large enough. The organisations that benefit most tend to be the ones growing, appointing first-time leaders, redesigning roles or noticing their teams operating in visibly different ways.

The HMNKND approach

Our starting point is that a capability framework should describe how work genuinely gets done well in a specific organisation, not how work gets done in theory.

HR should lead the design. Capability sits across performance, development and culture, and it needs someone holding the whole picture rather than each function shaping its own version. The design should not happen inside HR alone.

The strongest frameworks are built alongside leaders and employees. We spend time working out what high performance already looks like in the business, where expectations diverge between teams, and which behaviours leaders find themselves coaching over and over. Those conversations produce the raw material. The framework then names what is already true and sets the standard for what should be.

That process also gives leaders and employees a stake in the outcome, so by launch the language is already familiar to the people who have to use it, which removes most of the resistance a new framework usually meets.

We keep frameworks deliberately lean. Fewer capabilities, described in plain and observable terms, applied consistently, will outperform an exhaustive model every time. If a leader cannot hold the shape of it in their head, it will not shape their decisions.

We also build the connections before launch rather than after. That means mapping the framework into interview questions, performance review templates, development conversations and progression criteria, so it arrives already doing work. Before it goes live, we test it against decisions the organisation has recently made. If the framework wouldn't have led to the same conclusion, either the framework needs adjusting or the decision does. Both are useful findings.

What this looks like in practice

Consider a scenario we come across often. A Melbourne engineering consultancy of about 70 people had grown from 30 in four years, mostly by promoting strong technical people into team leader roles. Their managing director came to us with a specific irritation: two engineers at the same level, on the same money, with completely different reputations depending on which team leader they reported to.

The business had no agreed definition of a senior engineer beyond years of experience and billable hours. Asked separately, three team leaders described it three different ways: one valued technical depth almost exclusively, one promoted the people who brought in work, one weighted client management above both. All three were defensible, and none had ever been written down or reconciled.

We ran workshops with the team leaders and a cross-section of engineers, then built a framework with five capabilities across four levels. Technical judgement, client relationships, commercial awareness, developing others, and how people handled work going wrong, which turned out to be the behaviour that most separated their best people from the rest.

The build took about ten weeks, and we mapped it into their interview guides, review template and promotion criteria before it launched. In the following review cycle, two promotions that had previously stalled went through, and a third didn't, with a specific development plan attached instead of a vague conversation.

Where to start

A capability framework build is a defined piece of work with a start and an end, which is why it sits inside People Projects. The scope covers the framework itself along with the connections into recruitment, performance reviews and progression criteria, since building the framework and building those connections is one project rather than two.

The frameworks that get used are the practical ones. Short enough to remember, specific enough to quote in a performance conversation, and connected to the decisions they are meant to inform. That is a lower bar than most organisations set for themselves, and a considerably more useful one.

If expectations are drifting between teams, get in touch and we can work through what a framework would need to cover in your organisation.