Skip to main content
How to Write a Job Description That Gets Results
TMThomas McClean· Engineering Manager· 7 min read
  • Hiring
  • Recruitment
  • Team management

How to Write a Job Description That Gets Results

A badly written job description attracts the wrong people and puts off the right ones. Here is how to write one that sets your hire up for success from day one.

Most managers write job descriptions the same way: copy last time's version, add a few new requirements, swap out the team name, and post it. The result is a document that reads like a committee wrote it by committee, lists fourteen "essential" skills that no single human possesses, and tells candidates almost nothing about the actual role. Then comes the frustration when the applications are not quite right, or the right person never applied at all.

A job description is often the first thing a candidate reads about your team. It shapes who applies, who self-selects out, and how your new hire understands their role for the first few months. Getting it right is not about writing well for its own sake. It is about setting the hire up to succeed before they have even sent an application. Read our broader guide on how to hire an employee for the full end-to-end picture.

A job description is not a wishlist. It is a promise. Write it as if you will be held to every word, because your new hire will read it again on their first day.

Define the problem before you describe the person

Before you write a single bullet point, answer this question: what problem will this person solve? Not what tasks they will do, but what the team cannot currently achieve without them. If you cannot answer that clearly, the JD will be vague because the thinking behind it is vague.

Start by writing down three things: what the person will deliver in their first six months, what success looks like at the end of their first year, and what they will own that nobody currently owns well. These three answers are the backbone of a good job description. Everything else should connect back to them.

Task-led (weak)

-Attend weekly team meetings
-Respond to customer queries
-Manage the Jira backlog
-Write documentation
-Support the team with ad hoc tasks

Tells candidates what they will do. Says nothing about why it matters.

Outcome-led (strong)

Own onboarding end-to-end and cut time-to-value by 30%
Reduce customer churn by improving self-serve support
Build a backlog process the team actually trusts
Create documentation that halves the support volume

Tells candidates what success means. Attracts people motivated by impact.

  • Start with outcomesWrite what the role needs to achieve, not a list of daily activities. Candidates who are motivated by impact will respond to outcome-led descriptions. Those who just want a task list may not be the hire you need.
  • Name the problemBe direct about what is currently not working. If onboarding is broken, say so. If the team lacks a specialist skill, name it. Honest JDs attract candidates who want to solve problems, which is exactly who you need.
  • Set a success benchmarkInclude what success looks like at six and twelve months. This tells candidates what they will be measured against and gives you a ready-made 30-60-90 day framework once they start.

Be ruthlessly selective with requirements

The requirements section is where most job descriptions fall apart. Managers add everything they could possibly want in a candidate, the result is a list of twelve essentials that eliminates nearly everyone. Research consistently shows that long requirements lists deter underrepresented candidates disproportionately, particularly women, who are more likely to only apply when they meet every criterion listed.

A practical rule: limit genuine must-haves to five. If you cannot hold the list to five, you are either describing two roles or you have not thought hard enough about what actually matters. Every requirement you add is a filter. Make sure you are filtering for the right things.

Splitting requirements honestly

Must-have (max 5)

Experience owning a customer-facing product area
Strong written communication
Comfortable with data analysis
Experience in a cross-functional team
Background in B2B SaaS

Nice-to-have

+Experience with Figma
+Knowledge of SQL
+Startup experience
+Relevant degree or qualification

Shorter must-have lists attract more applications and fairer shortlists.

  • Five or fewerCap essential requirements at five. Ask yourself: would you reject an otherwise excellent candidate for lacking this skill? If not, it is not essential. Move it to the nice-to-have section, or cut it entirely.
  • Separate the two listsLabel them clearly: essential and desirable. This signals to candidates that you have thought carefully about the role. It also reduces the self-selection problem where strong candidates rule themselves out over a skill they could learn in a month.
  • Question years of experience"5 years of experience in X" is rarely what you actually need. What you need is evidence of a specific skill or outcome. Write the evidence you want to see, not an arbitrary number of years.
  • Include salaryIf you have a budget, publish it. Candidates who discover the range is wrong after three interview rounds will not come back. Publishing the range also signals confidence and transparency, which reflects well on you as a manager.

Write like a human, not a corporate template

Job descriptions written in corporate language attract candidates who are comfortable with corporate language. If that is your team, fine. But if you want curious, direct, self-aware people, write that way. Nobody is inspired by "a dynamic, fast-paced environment with a passion for excellence." It says nothing specific and signals that nobody thought hard about how to describe the team honestly.

Describe the team as it actually is. If it is small and still figuring things out, say so. If there is a lot of autonomy but not much structure, name both sides. Candidates who join based on an honest description are far more likely to stay. Those who join based on a polished version of reality will leave when reality sets in. For the interview process to complement this, read our guide on how to perform a great interview.

Before and after

Before (jargon)

"We are looking for a dynamic self-starter who thrives in a fast-paced environment and can leverage synergies across cross-functional teams to drive impactful outcomes."

After (plain language)

"You will work closely with engineering and design to ship product improvements. The team is small and direct - decisions get made quickly, which means your opinion will carry real weight from day one."

  • Be honest about challengesIf the role involves a lot of ambiguity, say so. If there is technical debt to manage, mention it. Candidates who join knowing the challenges are prepared for them. Those who discover them later feel misled.
  • Describe the teamA sentence about how the team works, how decisions get made, and what the working day actually looks like is worth more than five bullets about perks. People join teams, not organisations.
  • Cut the buzzwords"Passionate", "ninja", "rockstar", "synergy" - none of these mean anything. Replace each buzzword with something specific. What does passion look like in this role? What does working at pace actually mean here?
  • Mention the working arrangementRemote, hybrid, office - people need to know before they apply. Include the expected hours, location, and any travel requirements. These are decision-making factors, not afterthoughts.

Turn your JD into a working document

A job description should not be filed away once the hire is made. The best JDs become the foundation for the new joiner's first ninety days. The outcomes you described in the role become their early Targets. The challenges you named in the description become the first topics for your career conversations. The success benchmarks become the measures for their first performance review.

In Manager Toolkit, you can set Targets for your new hire based directly on the outcomes you wrote into the job description. This closes the loop between recruitment and management. The person who joined to solve a specific problem has that problem tracked from day one, not discovered months later when expectations have already drifted.

From JD to onboarding Targets

1

JD outcome

"Reduce onboarding time from 8 weeks to 5 weeks within 6 months"

2

30-day Target

Audit current onboarding and identify top 3 friction points

3

90-day Target

Ship revised onboarding flow and measure completion rate

6-month review

Onboarding time measured against the benchmark set in the JD

When you use the Targets featureto track these goals in Manager Toolkit, they appear alongside the new hire's profile and show up in your dashboard. You can see at a glance whether they are progressing against what they were hired to achieve, which makes your early catchups sharper and your first performance review far less speculative. The goal you wrote in the JD becomes the goal you manage against. Nothing gets lost in translation.

This is the real payoff of a well-written job description. It does not just attract the right person. It gives you and your new hire a shared language for success from the very first conversation. That alignment is rare, and it is worth a few extra hours at the outset.

Frequently asked questions

Track your hiring with Actions

Capture interview feedback, follow-ups, and hiring decisions in one place. Free to start.