Most capability frameworks I see are built backwards.
They start with abstract ideals. Big words. Competency libraries that no one actually reads.
They drop a grid on the organisation and expect people to fit inside it.
But it rarely sticks. Because it’s not anchored in reality.
Here’s what I’ve learnt: if you want a capability framework that actually works — one that helps with hiring, development, performance and workforce planning — you don’t start in theory.
You start with the work.
And most of that work is already sitting there in the PDs.
You just have to mine it properly.
PDs Are the Raw Material — If You Know What to Look For
Every PD contains capability data.
But most people don’t see it.
They see responsibilities. Tasks. A bit of fluff in the skills section.
I see capability signals. Everywhere.
Take a standard line like:
“Prepares and submits monthly financial reports to support departmental budgeting.”
Most people stop there.
I dig in.
That line tells me the role needs:
- Data literacy
- Attention to detail
- Time management
- Stakeholder communication
- Possibly, tool-specific skills like Excel, Xero, or a finance platform
Multiply that across 10 responsibilities, and you’ve got a working picture of what this role actually requires — not in abstract terms, but in practice.
I don’t guess. I tag.
I map each responsibility to one or more capabilities, pulled from a clean, well-defined capability library. I’ve built them in-house. I’ve built them for clients. Doesn’t matter where it comes from — what matters is consistency and clarity.
This is where most organisations get it wrong.
They treat capabilities as bolt-ons. They drop them into a framework without linking them back to real roles. And then they wonder why the framework feels hollow.
If your capability model isn’t rooted in real role delivery — if it’s not grounded in the actual work that people are doing every day — then it’s just another layer of language.
And people can smell it.
What It Unlocks Once You Do It Right
When you do the work — when you go PD by PD and extract the capabilities properly — everything starts to click.
Here’s what you unlock:
1. Role clarity with behavioural depth
Now your PD doesn’t just say what someone is meant to do. It shows how they’re expected to show up.
It gives depth to responsibility. Not just task completion, but capability application.
2. Clean capability pathways
If each PD has clearly mapped capabilities, you can build career progression that makes sense.
You can show someone what it takes to move from Level 3 to Level 4 — not just in output, but in how they operate.
3. Better development conversations
You stop guessing at training needs.
If someone’s doing the work, but missing the mark, you can isolate the missing capability.
It turns vague “areas for improvement” into targeted development plans.
4. Org-wide consistency without losing nuance
You can roll up data across roles. Spot capability gaps. Spot duplication. See where your org is overweight in one skillset and underweight in another.
But you can still preserve the nuance of each role, each team.
This is what WorkLuma builds into every consulting engagement.
It’s not sexy. It’s not instant.
But it’s robust. Scalable. Defensible.
Because it’s built on the actual shape of work — not the imagined shape.
Here’s the kicker:
You don’t need a blank canvas to build a capability framework.
You probably already have what you need.
The PDs. The tasks. The responsibilities.
What’s missing is the lens.
The discipline.
The willingness to pull it apart and reassemble it with structure.
I’ve done this for orgs with 40 roles. I’ve done it for orgs with 1,400.
The size doesn’t matter.
The principle holds: your capabilities are already in the building.
You just have to go get them.