Let me be blunt: most HR systems are better at storing documents than defining work.
They’ll give you templates. Drop-downs. Auto-generated wording that looks official, sounds polished, and means almost nothing.
They’ll help you file the PD.
But they won’t help you write a good one.
They won’t help you clarify accountability, manage performance, or reduce risk.
Because that’s not what they were built for.
They were built to standardise. To control. To keep everything neat.
Which sounds good. Until you realise that neat isn’t the same as useful.
Clean Templates Don’t Equal Good PDs
I’ve worked inside some of the world’s biggest HRIS platforms — and I’ve seen how they shape behaviour.
You get given a structure. It looks tidy:
- Role summary
- Key responsibilities
- Competencies
- Reporting lines
- Approval flow
Seems fine. Until you try to customise it.
You go to rewrite a responsibility in plain English, and the system suggests something generic instead.
You try to add capability context, and it forces you to pick from a pre-loaded list.
You want to show how the role contributes to WHS risk controls, or explain where AI supports a workflow — but there’s no place for it. No field. No logic.
So what do people do?
They stop thinking.
They start filling.
Responsibility: ✓
Skills: ✓
Other duties as directed: ✓
Then they hit Save. Send it to HR. And move on.
The result?
A PD that ticks the box but doesn’t reflect the role.
A document that’s easy to find, but impossible to use in any meaningful way.
And a system full of beautifully formatted, strategically useless content.
It’s a quiet failure.
And it compounds over time.
I Work Outside the System First, Then Bring It Back In
Here’s how I fix it.
I write the PDs outside the HR system.
In Word. In Google Docs. In Notion. In Miro.
Anywhere I can actually think, not just fill fields.
I follow my structure. The one I trust. The one that’s built on clarity, not compliance theatre.
I write:
- Real outcomes, not activities
- Actual responsibilities, not legal hedges
- Human language, not corporate filler
- Capabilities and tools that reflect the work, not just the system defaults
Only once the PD is right — only once I’d stand behind it in a performance case or a restructure meeting — do I map it back into the HR system.
That might mean adjusting how it’s entered.
Splitting responsibilities across fields.
Adding links to supporting docs.
Using rich-text workarounds if the platform allows it.
Or storing the source PD outside the system entirely, and only referencing it inside.
Because here’s the thing: the HRIS is just a tool.
It should serve the role, not define it.
And if the system can’t handle the truth of the work? Then the system gets workarounds.
I don’t wait for perfect tech. I design for clarity.
And I make sure the clarity survives integration.
So here’s my advice:
If your PDs are starting to sound the same…
If they read like they were written by the software, not a human…
If you’re struggling to explain what someone actually does, even with the PD in front of you…
Your system might be the problem.
Or more accurately — your dependence on the system is.
Write like it matters.
Design outside the box your platform gives you.
Then bring it back in on your terms.
Because a system can file your work.
But it can’t think for you.
That part’s still yours.