What to write in a job description when you can't fully describe the job
Publish the problem and the first six months, not a list of adjectives. You'll attract people who are good at undefined work.
By Macro Merge · · 4 min read
The short version
- 1Adjectives like “ownership mindset” tell candidates nothing. A picture of the first six months tells them everything.
- 2Say why the role exists now. The trigger is the most useful line in the post.
- 3Your job post is public. Your brief is private, and holds what you'd never publish: the budget ceiling, the trade-offs, why the last person left.
Most startup job descriptions are written in about ten minutes, usually by copying one from a bigger company and changing the name. You can tell. They ask for five years of experience and a set of frameworks, then add adjectives: “self-starter”, “ownership mindset”, “thrives in a fast-paced environment”.
The people you most want to hire are good at reading between the lines, and these lines say nothing. Worse, for an early role you often can't describe the job in detail yet, because it will change within six months. So you write something vague, and you attract people who are comfortable with vague.
There's a better way: publish the problem and the first six months, not a list of requirements.
Why the usual job description fails
- It describes a person, not a job. “Strong communicator, analytical, proactive.” Every candidate believes that describes them.
- It borrows a big company's context. Requirements that make sense at a 2,000-person company, like deep specialism or experience with mature processes, can screen out exactly the people who'd do well at your stage.
- It hides the trade-offs. Every early role has hard parts. Leaving them out attracts people who'll be surprised later.
- It doesn't say why now. The most important fact about an early hire is the reason the role exists today. It's usually missing.
Publish the problem, not a list of adjectives.
A template that works
- The company, in one plain line. What you sell, to whom, and who pays. “We make inventory software for mid-sized pharmacies in western India” beats any sentence about transforming an industry.
- Why this role exists now. The trigger. “We've raised a seed round and need our first engineer to take over from the agency that built our product.” This line does more work than everything else in the post.
- What the first six months look like. Three to five outcomes, not tasks. “Customers stop reporting outages.” “We release every week.”
- The decisions they'll own. What they decide alone, what they decide with you, and what they don't decide.
- What's hard about it. Be specific. “You'll be on call. There's nobody to review your code for the first few months.”
- Must-haves, four at most. Each should be something you'd actually turn a candidate down for. Then a short list of things that would be nice.
- The practical details. Location or remote, a salary range if you can share one, equity, and the notice period you can wait for.
- How the process works. The steps, who they'll meet and how long it takes. Good candidates have options, and a clear process is a reason to apply.
Before and after
The first version attracts machine learning specialists who'd be frustrated within a month. The second attracts people who enjoy building foundations. Same budget, same title. Different hire.
Words to cut
Some phrases appear in so many job descriptions that they no longer mean anything. Each one is a missed chance to say something specific.
| Instead of | Say what you mean |
|---|---|
| “Ownership mindset” | What, specifically, will they own in six months? |
| “Fast-paced environment” | How often do you release? How often do priorities change? |
| “Wear many hats” | Which hats? Name the two or three things outside the core job. |
| “Rockstar”, “ninja” | Nothing. Cut them. |
| “5+ years of experience” | Experience doing what, at what kind of company? |
| “Competitive salary” | A range, if you can share one. |
Should you publish the salary?
Many Indian startups still don't publish salary ranges. There are reasons to be careful: you may not want your existing team comparing numbers, and ranges for early roles can be wide.
But weigh the cost of leaving it out. Strong candidates who are already well paid often won't apply to a role with no range, because they can't tell whether it's worth their time. And you'll spend interview hours with people whose expectations you could never meet. Even a broad range helps, or a line like “we pay in the top half of the market for this role”, if that's true.
Your job post is not your brief
A job description is public. It's a pitch as much as a description, and it has to make the right people want to apply.
A brief is private. It's the working document that you, and anyone helping you hire, use to make decisions. It holds things you'd never publish:
- the real budget ceiling, and how flexible it is;
- the trade-offs you've agreed: what you'll give up to get what matters;
- why the last person in the role left, if there was one;
- who else needs to be convinced, and of what;
- the backup plan if the search takes longer than you'd like.
Write the brief first. The job description is then much easier, because it's the public, honest version of the same thinking.
If you really can't describe the job yet
Sometimes you genuinely don't know. “Something isn't working, and we think we need a senior hire.” That's fine, but it's a signal to do more thinking before you post, not less.
Start with the problem. What's going wrong, and what would be true if it were fixed? Then ask whether the answer is an engineer, a product manager, a lead, or not a hire at all. Sometimes it's a change to how the team works, or a contractor for three months. Posting a vague role to find out is expensive, because every interview becomes a guess.