I’ve lost count of how many times I’ve asked to see a PD, only to get a blank stare.
Sometimes people don’t know where it is.
Sometimes they didn’t even realise they had one.
Sometimes they say the quiet part out loud — “We have them, but no one really uses them.”
That’s the problem.
A PD isn’t useful unless it’s being used.
If it’s not shaping how someone gets onboarded, how their performance is reviewed, how decisions are made during restructures, or how work gets divided when the team’s under pressure — then what’s the point?
You’ve just written a brochure.
A well-structured PD should be a tool. Not just for HR. For the person in the role. For their manager. For leadership. For anyone who needs to understand how the role works, what it owns, and how it fits into the broader system.
And if your PD structure doesn’t support that? You’ll feel it. Sooner or later. When a dispute happens. Or a role changes. Or a team burns out and no one knows who was meant to be doing what.
Most PDs Are Built for Storage, Not Use
There’s a reason most PDs die in SharePoint.
They’re not designed to be used day-to-day. They’re designed to look complete. Neat. Official.
Lots of big paragraphs. Abstract language. A couple of token responsibilities. Maybe some capability jargon at the end. If you’re lucky, a line about WHS or compliance.
And then they get saved, sent, and filed away.
Out of sight. Out of mind. Out of date within six months.
But here’s what I’ve learnt: people will use a PD if it helps them make a decision.
That’s the bar.
Does it help me delegate?
Does it help me performance manage?
Does it help me onboard?
Does it help me restructure?
If the answer is no, then something about the structure is off.
So now, when I build a PD, I don’t start with the form. I start with the use case.
Who’s going to use this? When? Why?
And what would make it easier for them to do that?
That’s how I landed on the structure I use today.
The Structure I Use Now — and Why It Works
Here’s how I structure every PD now. Clean. Practical. Built to be used, not stored.
1. Role Purpose
A short, clear paragraph explaining why this role exists and what it enables. No fluff. Just the core purpose.
This keeps everyone aligned. Hiring managers. Incumbents. Execs.
If you can’t explain why a role exists in three sentences, you shouldn’t be hiring for it.
2. Key Responsibilities
6–10 bullet points. Each one describes a delivered outcome, not a task.
These should be testable. Observable. Something I can measure or see.
Not “supports team initiatives” — that’s filler.
More like “delivers weekly team reporting to identify delivery risks across all projects.”
This section is what gets used in onboarding, in 1:1s, in performance plans.
3. Key Relationships
Who the role reports to. Who reports to them. Key internal and external stakeholders.
This section cuts through the noise when responsibilities overlap — it makes sure everyone knows who’s connected to who, and how.
4. Capabilities & Skills
This is where I include core behavioural or functional capabilities — ideally mapped to a capability framework if the business has one.
But I keep it lean. Not a laundry list. Just the real drivers of success in the role.
You can’t develop someone against 14 generic traits. Pick what matters.
5. Knowledge & Experience
Split into Essential and Desirable.
Keeps hiring decisions focused.
It also creates a base to plan development from.
6. Qualifications & Compliance Requirements
Licences. Legal obligations. System access requirements. Anything that links to risk or compliance.
Too many PDs forget this section — and then panic when someone without the right credentials is put forward.
7. Conditions / Classification Info
Title. Band or level. Award info if needed. Status (FT/PT). Location or remote eligibility.
This section keeps your HR and IR house in order.
That’s the core structure.
Then, across the top or bottom — depending on the format — I flag two things:
- Date of last review
- Next scheduled review
Because a PD isn’t a one-off. It’s a living tool.
And if you don’t treat it like that, it dies.
Here’s what I’ve learnt:
The more usable the PD, the more likely people are to trust it.
The more trusted it is, the more likely it is to be used in the hard moments.
And in those moments — whether you’re hiring, realigning, managing risk or performance — having a structured, clear, and accurate PD is one of the best tools you can have.
It’s not admin.
It’s infrastructure.
You can feel when it’s there. And you can really feel it when it’s not.