Most position descriptions are useless.
That’s not an exaggeration. It’s not even a hot take. It’s just the truth in most organisations I’ve worked with. Whether I’m helping HR teams restructure their workforce, or reviewing job documentation for legal compliance, the pattern is always the same.
Bloated. Generic. Disconnected from reality.
They’re written once, then left to rot in a SharePoint folder. Or copied from a template that never really fit in the first place.
I used to write PDs like that too. I thought I was doing a good job. Until the first time one got challenged — formally — in a workplace investigation. That was the wake-up call. I realised the stakes were higher than just admin. And that most of the ways we’re taught to write PDs… are fundamentally flawed.
Vague Descriptions Create Real Harm
Here’s what happens when PDs don’t reflect reality:
A team member underperforms, but the manager can’t point to the PD to show what was expected.
A restructure needs to happen, but the documents don’t back up the rationale.
A psychosocial hazard claim gets raised, and “role ambiguity” is suddenly in the spotlight.
In every case, an imprecise PD becomes a liability.
And not just legally. It creates stress. Confusion. Resentment.
People want to know what’s expected of them. What they’re accountable for. Where their role starts and ends.
If you get that wrong, you don’t just risk non-compliance.
You create a workplace that runs on assumption and guesswork.
That’s why I stopped describing “tasks” in PDs.
And started describing outcomes.
Instead of:
“Attends project meetings and takes notes”
I now write:
“Captures key actions and decisions from project meetings and ensures distribution to relevant stakeholders within 24 hours.”
Same activity. Different clarity.
It signals what success looks like. What “done well” actually means.
You Can’t Fix What You Don’t Define
Most people think PDs are just for hiring. I think that’s backwards.
You should be able to use a PD to:
- Set role expectations
- Clarify how the role contributes to team goals
- Identify capability gaps
- Defend decisions in a restructure or dispute
- Connect the role to your WHS risk controls
That’s the minimum bar. And yet, I’d say 8 out of 10 PDs I see wouldn’t pass that test.
Why?
Because they’re built to tick a box, not solve a problem.
They use filler language. Or worse — they rely on HRIS-generated templates that sound polished but say nothing.
Here’s what changed the game for me:
I started treating each PD as a design problem. Not a form to fill in.
I ask:
- What pain does this role reduce?
- What value does it create?
- What happens if this role is done badly?
- What does good look like in 6–12 months?
Then I write the PD with that lens.
It’s slower at first. But it scales better. And it means when we’re doing capability reviews, org redesigns, or AI task mapping — we’ve got something real to build on.
Because a PD should never be a static document. It should be a live representation of the role’s value in context.
I’ll leave you with this:
A good PD won’t fix your team’s problems.
But a bad one will definitely make them worse.
So next time you’re handed a template, or tempted to CTRL+C from another department — stop. Ask: is this something I’d stand behind if it was challenged?
Because one day, it might be.
And the difference between a well-written PD and a vague one… is the difference between clarity and chaos.