How To Write a Job Description for a Startup

So many hiring processes go wrong before anyone applies, right at the start, when someone opens a Google Doc and starts writing a job description.

After 15 years in recruitment, we can tell you: most of them are not very good. And it is getting worse, not better.

The old version of a bad JD was at least honest in its chaos. Two fonts, inconsistent formatting, paragraphs clearly lifted from three different companies. You knew exactly what you were dealing with.

The new version is more insidious. AI has given teams the ability to generate something that looks like a job description in about 45 seconds. What you get is a document that hits all the expected sections, uses all the right language, but tells you almost nothing about the role, the team, or what success looks like. It’s longer than it needs to be, more generic than it should be and often not read in full even by the people who wrote it.

That last part is not a joke. It happens more than you would think.

The startup hiring wish list problem 

The most common failure mode is the wish list. Ten years of experience. Deep technical knowledge. Strong commercial instincts. Comfortable being hands-on. Experienced managing a big team. Sector knowledge.  Really strategic. Thrives in ambiguity.

This is not a job description. It is a description of a person who does not exist.

And when the brief is that vague, you either compromise on everything or spend months interviewing people with no framework for deciding whether they are actually right for the role.

Too many cooks on a job description

There is a specific way a JD becomes unmanageable, and it usually happens with senior roles. You start with a clear brief, someone adds a comment, someone else adds a paragraph, a third person says they need to get their hands dirty too. Nothing gets removed. Nobody decides what matters most.

What this usually masks is a misalignment that nobody wants to name. Rather than resolve it, people accommodate competing views by adding more requirements. The role becomes impossible to hire against.

If you are writing a JD by committee, stop and have the alignment conversation first. It is uncomfortable. It is significantly less uncomfortable than hiring the wrong person.

Start with the outcome, not the role 

Before writing a single requirement, ask what you actually need this person to achieve. Not their responsibilities. Their outcomes.

Get clear on that, and the rest of the document tends to write itself more honestly. You also end up with something more useful than a JD: a rough version of their first 90-day review. If you know what success looks like at 90 and 180 days, you know what you are hiring for.

It also forces a harder question. Are you hiring for what you need right now, or what you imagine needing in a year? At seed stage, you almost certainly need someone who can generate revenue or solve a specific operational problem. You probably do not need someone designing an international expansion strategy. Trying to hire for both in one person is how you end up with a mediocre version of each.

How to write a job description for the right people

A job description has an audience: the candidate. Not the board, not the hiring team. The person you want to read it and think “this is exactly the right role for me”.

That means telling them clearly what your company does, what the role involves, what they will be accountable for, and why it is worth getting excited about. 

It also means getting specific about the team they are joining. What is the current gap? Are there junior people who would benefit from someone with mentoring experience? Say that. You can find people who have it, but only if you ask for it.

A quick sense check

Before you post anything, ask yourself three questions. 

1. Can you read it in under three minutes? 

2. Would the right candidate recognise themselves in it? 

3. Can everyone on the hiring team say, without looking at the document, what the one or two most important outcomes for this hire are in the first six months?

   
   

If the answer to any of those is no, the brief is not ready. The time spent getting it right is a fraction of the time you will spend managing a hire that was never clearly defined.