TL;DR:
Describe what the person will achieve in the first months, not a list of duties.
Keep must-haves short and honest, and label the rest as nice-to-haves.
Say what you can say plainly: pay range if you can, hours, how to apply and what happens next.
A job post is the first thing a stranger reads about your team. If it is a wall of duties and a wish list, the people who are right for the work often assume it is not for them, and the people who send fifty identical applications are the ones who apply.
You can fix most of that in a plain document in a word processor or notes app. This article walks through the steps, using a post for a support specialist as the example.
Decide what the job is for
Before you type a word of the post, answer one question in a sentence: what will be better because this person is here? A job exists to produce a result, and the post should lead with it.
Talk to whoever does the work now, or to the person who will manage the new hire. Ask what a great first three months looks like, what is hard about the work and what usually goes wrong. Their answers are better source material than an old post.
Write the outline before the sentences
Title: the plain name people would search for, not an invented one.
One paragraph on the team and why the role exists.
What the person will do and achieve, in outcomes.
Must-haves, then nice-to-haves.
What you offer: pay range, hours, location or remote, and anything else true.
How to apply and what happens after.
Write outcomes, not a list of duties
"Answer customer emails" says what the days look like. "Answer customer emails so that most people hear back within a working day and feel understood" says what good looks like. Outcomes let a candidate picture themselves doing well, and they let you judge applications later.
Aim for three to five outcomes. Use verbs and specifics. Only write a target if you will really hold the new hire to it.
Must-haves versus nice-to-haves
Split the requirements into two lists, and be strict about the first. A must-have is something you would turn down an otherwise strong candidate for lacking. If you would train for it in a month, it is a nice-to-have.
Long must-have lists tend to discourage people who could do the job well, so keep the list short enough that every item is truly needed. Never list a requirement that is a stand-in for something else, such as a degree when you actually care whether someone can write clearly.
Worked example: a post for a support specialist
Here is a draft for a small software team, written in a plain document. The company and details are made up for this example.
Support specialist
About the team
We are a team of six that makes scheduling software for dentists' offices. You would be the second person on support.
What you will do
- Reply to customer questions so people hear back within a working day and feel understood.
- Spot problems that come up again and again, and write them up so the product team can fix the cause.
- Keep our help articles accurate as the product changes.
Must-haves
- Clear, friendly writing. We will ask you to write a sample reply.
- You stay calm and kind when someone is upset.
- Comfortable learning a new tool quickly.
Nice-to-haves
- Earlier experience answering customers.
- Familiarity with help-desk tools.
What we offer
- Pay range: [fill in the real range]
- Hours: Monday to Friday, with flexibility around school pickups
- Remote within [your time zones]
How to apply
Send a short note on a time you helped someone solve a problem, plus your resume. We reply to everyone, usually within a week, and the process has a short writing task and two conversations.Read it once as a candidate. Do you know what you would do, whether you qualify, what it pays and what happens next? If any answer is no, add a line.
Pay range and other honest details
Include the pay range if you can. Some places require it by law, and rules vary by location, so check yours. Even where it is optional, a range saves both sides time. If you cannot share it, say when in the process you will.
Say what the process looks like and roughly how long it takes, but only promise what you will do.
Mistakes to avoid
Wild titles that nobody searches for.
"Rockstar", "ninja" and other filler that tells nobody anything.
A must-have list that quietly includes the nice-to-haves.
Wording that points at one kind of person, such as "digital native". Describe the work instead.
Forgetting to say how to apply.
Test the post before it goes live
Give the draft to two people: someone who does the job today and someone outside the team. Ask the first whether it describes the work truthfully. Ask the second to tell you, in their own words, what the job is and whether they would apply. Where they stumble, the post is unclear.
Also check the length of the application ask. A short writing sample or a few questions tell you more about a candidate than a long form, and they tell the candidate what the job will be like. Keep the effort you ask for in proportion to the role.
Last, decide who will read the replies and by when. A good post that sits unanswered for weeks loses the people you wanted most, so put the first review on your calendar before you publish.
Doing it faster
Keep your best past post as a template, and reuse the structure rather than the sentences. Reading the draft aloud helps; DuckyHelper, which runs on Mac, Windows and Linux, can look at the document on your screen and answer questions about it out loud while you edit. The wording and the decisions stay yours.
Frequently asked questions
How long should the post be?
Long enough to answer a candidate's main questions and no longer. For most roles that is a few short sections, not a full page of duties.
Should I mention salary if I am not sure?
Decide it before you post. A range you can honor beats a guess, so settle it with whoever approves the budget first.
Get started
