There’s a lazy way to write a position description.
Most people default to it without realising.
They open up a Word template or HR system.
And start writing out everything the person does in an average week.
Emails. Reports. Meetings. A few bits of admin. Some vague reference to “stakeholder engagement.”
Then they tick the box and move on. PD done. Job sorted.
Except it’s not. Not even close.
I know because I used to write them like that too.
And it wasn’t until I was deep into a project helping a client restructure their entire workforce — roles shifting, teams moving, job families being pulled apart and rebuilt — that I saw just how weak most of these documents really are.
Tasks tell you what someone touches.
But they don’t tell you what that person is responsible for producing, or what the impact of that work is meant to be.
And that’s the crux of it.
A task-based PD doesn’t give clarity.
It just gives you a to-do list.
It doesn’t help with performance conversations.
It doesn’t support legal defensibility.
It doesn’t orient the person in the role around value.
So I stopped writing tasks.
And I started writing outcomes.
Verbs Aren’t the Point — It’s What They Point To
There’s this old HR advice that gets thrown around a lot.
“Use strong action verbs.”
Coordinate. Manage. Deliver. Facilitate.
And yeah — that’s not wrong. But it’s way too simplistic.
Because on their own, verbs are cheap.
“Manages project reporting” sounds official. Looks tidy. Sits neatly in a bullet list.
But what does it mean?
Are they compiling a dashboard?
Chasing team leads for updates?
Creating insights for the exec team?
You’ve got no idea. And neither does the person reading it.
Here’s a better version:
“Develops and maintains weekly project reports that are submitted to the PMO each Monday, providing risk visibility across all active streams.”
Now we’ve got something.
I use a simple pattern now:
Verb + What + For Who + With What Purpose or Outcome
It takes more thought. But it gives the reader (and the person doing the job) an actual target to aim at.
Some examples:
- Coordinates stakeholder workshops to gather system requirements used in the final project design
- Prepares fortnightly financial reconciliations to ensure accurate billing across all active client accounts
- Responds to tier-one support tickets within agreed SLAs, maintaining a resolution rate above 95%
This isn’t wordplay. It’s expectation-setting.
It helps people understand what “good” looks like, and what their job really means in practice — not just what they’re supposed to do, but what they’re supposed to deliver.
If You Can’t Define the Outcome, Don’t List It Yet
The first time I saw a PD used in a formal underperformance case, I felt uncomfortable.
It had all the standard lines.
“Provides admin support.”
“Attends project meetings.”
“Liaises with internal teams.”
The person had technically done all of those things.
But they’d done them badly.
And the PD gave the manager no leverage.
No standard. No benchmark. Nothing specific to point to that would support their claim.
That’s when it hit me — these vague, activity-based lines don’t just weaken the PD, they actively undermine accountability.
So now, when I write responsibilities, I interrogate every line.
Can it be interpreted more than one way?
Is it observable? Is it measurable?
Would it help a new hire understand what success looks like in their first 90 days?
If not, I don’t include it — or I rework it until it’s sharp.
It takes more time, and yes, sometimes you have to push managers or incumbents to be more precise than they’re used to being.
But that process — that discomfort — is where the clarity lives.
And the PD ends up being something you can actually use, not just something you store.
Because I’ve seen what happens when this is done properly.
You get better onboarding.
You get cleaner performance conversations.
You get clearer role boundaries.
And if the worst happens — if you’re in a dispute, a restructure, or an audit — you’ve got something solid in your hands.
Don’t just list what people do.
Define what they’re accountable for.
Describe what they deliver.
And write like someone’s going to use this PD in a serious conversation, not just to fill a folder.
Because if your responsibilities read like filler, the whole thing falls apart.