The Job Description Template With a Spine That Actually Hires (Eight Sections, Five Role Variants)

A job description template is the document the hiring manager writes before a single application form goes out, and it is the document that decides who applies, who self-rejects, and how the eventual offer gets calibrated. Most job descriptions fail before the first candidate ever sees them, because they are written as a list of responsibilities copied from the last person who held the role, with no mission, no outcomes, no comp, and a wall of qualifications that the hiring manager could not actually evaluate in an interview.

This guide is the job description template I would hand to a small HR team or a founder writing their first JD. It walks through the eight sections every real job description needs, the four failure modes that make most JDs unread, and five role-type variants (engineer, sales, support, manager, executive) you can copy and adapt. The frame: the JD is the upstream piece of the hiring funnel. It feeds straight into the job application form template candidates fill in, and the way you write it determines the quality of every form that comes back.

What a Job Description Actually Is (and What It Is Not)

A job description is the internal document that defines a role: the work, the success criteria, the qualifications, the comp, and the operating context. It is written by the hiring manager, reviewed by HR and the manager's manager, signed off by finance for the comp band, and stored in the role library so the next person who hires for the same role does not start from a blank page.

A job posting is different. The posting is the public extract of the JD, written for the candidate, omitting confidential context (internal comp logic, strategic positioning, the names of competitors you are hiring against), and tuned for the channel it appears on (LinkedIn, the careers page, an industry job board). The posting can be shorter, more marketing-led, and more compressed than the JD. The JD has to be complete; the posting has to be compelling.

A job specification (the term still used in UK and EU contexts) is functionally the same document as the job description, sometimes split into two artifacts (a "job description" capturing duties and a "person specification" capturing qualifications). Treat them as one document with two sections.

A job ad is the version that appears on a paid channel (Indeed sponsored, LinkedIn promoted). It is the shortest extract: title, two-sentence summary, salary range, location, link to apply.

The build order is JD → posting → ad → application form. Most teams skip the JD and go straight to the posting, which is why their postings are full of vague responsibilities and missing comp bands. Build the JD first.

Why Most Job Descriptions Fail

Four failure modes account for almost every unread JD. Each one is fixable.

Failure 1: Vague responsibilities. "Manages projects." "Owns the customer relationship." "Drives growth." These are not responsibilities; they are headlines for responsibilities. The fix is to add a verb, an object, and a frequency or scale: "manages two to three concurrent client projects of $50k to $150k each, with weekly status reports to the account director."

Failure 2: No scope markers. Candidates need to know how big the role is. Team size, budget authority, geographic remit, customer-base size, codebase scope, deal-size range. A role that says "leads a team" could be three people or thirty. The fix is to add the number every time: "leads a team of four engineers and two designers," "owns a $1.2M annual marketing budget," "covers the EMEA mid-market segment (200-500 employee accounts)."

Failure 3: No compensation. This is no longer just a quality issue; it is a legal one in a growing list of jurisdictions. Colorado started in 2021. By 2026, California, New York, Washington, Hawaii, Illinois, Maryland, Massachusetts, Minnesota, Vermont, DC, New Jersey (Jersey City), and others require salary ranges in any posting visible to applicants in those states. The EU Pay Transparency Directive (effective 2026 for member-state implementation) extends similar rules. Even where it is not legally required, the data is consistent: postings with salary ranges get 30 to 70 percent more applications, and the applications are better calibrated.

Failure 4: Qualifications conflated. A list of fifteen "requirements" that mixes must-have credentials (a CPA license, a US work authorization) with nice-to-have skills (familiarity with Tableau) and aspirational adjectives ("a self-starter") screens out the candidates you wanted and lets through the ones who do not read carefully. The fix is to split the section in two: must-have (3 to 5 items, all of them screen-out questions you would actually ask in a phone screen) and nice-to-have (3 to 5 items, none of which would screen anyone out).

The Eight Sections of a Real Job Description

1. Title and Level

The job title (Senior Software Engineer, Account Executive, Customer Success Manager) and the internal level (L3, IC4, Manager 1). Levels are how the role is calibrated against the rest of the org for comp, scope, and promotion. External candidates do not need the level; internal calibration does.

Avoid title inflation. A "Senior" with two years of experience is a credibility liability the moment the candidate joins and discovers the actual seniors. If the comp band is mid-level, the title should be too.

2. Reports To and Team

Who the role reports to (by title, not name, since the JD outlives any one manager) and which team it sits in. If the role has reports of its own, list them by title and headcount. Candidates use this section to decode the org chart and figure out whether the role is on a growth trajectory or a maintenance one.

3. Mission (One Sentence)

The mission is one sentence that says why the role exists. "The Senior Backend Engineer exists to ship the billing system that lets the company scale revenue without scaling support costs." "The Account Executive exists to convert mid-market inbound demand into closed-won revenue at $25k to $100k ACV."

The mission is the most underused section in most JDs and the most powerful one for self-screening. A candidate who reads the mission and feels nothing is the wrong candidate. A candidate who reads it and wants to talk about it is the right one.

4. Outcomes (90 / 180 / 365 Days)

What success looks like at three milestones after the start date. Three to five outcomes per milestone, written as completed states.

By 90 days: has shipped one production-ready feature end to end, has run a deploy to prod independently, has paired on at least three customer escalations.

By 180 days: owns one of the team's three primary services, leads at least one cross-team architecture discussion, has mentored a more-junior engineer on at least one feature.

By 365 days: has led a major project from design doc to launch, is the team's primary on-call for one service, contributes to hiring as an interviewer.

The outcomes section does the heaviest lifting in the whole JD. It tells serious candidates "this is the bar"; it tells unserious candidates "this is not for you"; and it gives the hiring manager a calibration document to use in interviews and in the first 365 days of the role.

5. Responsibilities

What the person actually does, week to week. Five to ten bullet points, each with a verb, an object, and a frequency or scale. Not "manages projects" but "owns two to four concurrent client projects, runs weekly status meetings, and is the primary point of escalation for project-level risk."

The responsibilities section is the day-to-day texture of the role. If you cannot write a responsibilities section that is specific enough to predict a Tuesday afternoon, the JD is too abstract.

6. Qualifications (Must-Have vs Nice-to-Have)

Split the section in two.

Must-have (3 to 5 items). Things you would screen for in the first phone call. Years of experience in a relevant role, a specific credential or certification, a specific technology where the role cannot productively start without it, a legal requirement (work authorization, security clearance).

Nice-to-have (3 to 5 items). Things that would tip a tied decision but never disqualify. Familiarity with a specific tool, exposure to a specific industry, a second language, a portfolio of relevant work.

Most JDs that fail in hiring do so because the must-have list is twelve items long and the hiring manager would actually only screen on three of them. The candidate sees twelve, assumes they are all required, and self-rejects.

7. Compensation and Benefits

The salary band (or hourly range), the bonus or commission structure, the equity grant, the benefits headline. State the range, do not just say "competitive." Studies on transparent comp consistently find more applications and better-calibrated ones; the legal requirement in growing US and EU jurisdictions is the floor, not the ceiling.

Base salary: $130,000 to $165,000 depending on level and experience. Equity: 0.05% to 0.12% over a four-year vest with a one-year cliff. Bonus: annual target of 10% of base, paid against company and individual performance. Benefits: medical / dental / vision (100% employer-paid for employee, 80% for dependents), 401(k) with 4% match, 25 days PTO plus federal holidays, $2,000 annual learning budget.

8. Logistics

Location (remote, hybrid, in-office, hub city), travel expectations, hours, start date, work authorization requirements. The logistics section is the second most common reason serious candidates self-reject after compensation. If the role is "hybrid 3 days in office in San Francisco" and the candidate is in Phoenix, both sides are better off knowing in section 8 of the JD.

Job Description vs Job Posting (When to Cut)

The JD is internal and complete. The posting is external and compressed. Cuts to make from JD to posting:

• Trim the must-have / nice-to-have list by 30 to 50%. The posting is for the candidate; the JD is for the interviewer.
• Replace internal level codes with the public title.
• Soften the comp range if the JD includes confidential range logic; keep the salary range itself.
• Remove the names of internal projects, customers, or competitors.
• Add one to two paragraphs of company context the JD does not need.
• Keep mission and outcomes intact. They are the differentiating sections.

The posting is shorter; the JD is the source of truth. When the role is filled, archive the JD in the role library so the next hire starts from there, not from a blank doc.

Five Role-Type Templates

The same eight-section spine works for every role. What changes is which sections get pushed hardest in each variant.

Software Engineer (Mid-Level)

The sections that need extra weight: Responsibilities (specific languages, frameworks, services owned, on-call rotation, code-review load), Qualifications (years of experience, system-design depth, specific tech that is non-negotiable). Add a "Stack and scope" subsection: which languages and frameworks the team uses, which services this role would own, the size of the codebase.

Mission: Ship and own the billing service that powers the company's recurring-revenue infrastructure. Outcomes by 365 days: primary owner of two of the four billing services; led one cross-team migration; on-call for one service; reviewed at least 200 PRs. Must-have: 4+ years of backend experience, production experience with one of (Go, Rust, Java, Kotlin), comfort with relational databases at scale, US or UK work authorization. Nice-to-have: Stripe API experience, distributed-systems coursework or equivalent practice, open-source contributions.

Sales Rep (Account Executive / SDR)

The sections that need extra weight: Outcomes (quota attainment, deal velocity, pipeline coverage), Responsibilities (territory definition, account list, ACV range), Compensation (base / variable split, accelerators, on-target earnings, ramp).

Mission: Convert mid-market inbound and outbound demand into closed-won revenue at $25k to $100k ACV. Territory: Northeast US mid-market (250 to 1,000 employee accounts), inbound MQLs plus outbound to a named-account list of 200. Quota: $720k annual quota with $60k / month run rate by month four. Comp: $90k base, $90k variable at OTE, accelerators above 100% attainment, three-month ramp at 50% quota. Outcomes by 90 days: has run 30 first-call meetings, has built a pipeline of 4x quota, has closed at least one deal.

Customer Support / Customer Success

The sections that need extra weight: Responsibilities (ticket volume, response-time SLA, tier ladder), Outcomes (CSAT, time-to-resolution, retention by cohort), Qualifications (industry experience that maps to the customer base).

Mission: Resolve customer issues at speed while building the playbooks that let the team scale beyond manual one-to-one support. Volume: 30 to 50 tickets per day in steady state, with a 2-hour first-response SLA on Pro tier and 30-minute SLA on Enterprise. Outcomes by 180 days: owns the tier-2 escalation queue; has authored at least three help-center articles that reduce inbound volume; has run two customer office hours.

Engineering Manager (First-Line)

The sections that need extra weight: Reports To and Team (span of control, team composition), Responsibilities (one-to-ones, performance reviews, hiring, planning, on-call rotation ownership), Qualifications (management experience separately from IC experience).

Reports to: Director of Engineering. Manages: a team of five to seven engineers spanning backend, infra, and a frontend specialist. Mission: Build and run the team that ships the platform's core services, while developing engineers along the IC and management tracks. Outcomes by 365 days: has hired at least two engineers; has run at least two performance cycles; has shipped the team's annual roadmap with no critical-path slips greater than two weeks; has at least one direct report ready for promotion to senior.

Executive (VP / Director)

The sections that need extra weight: Mission (the strategic bet the role represents), Outcomes (P&L impact, organizational outcomes), Responsibilities (board reporting, cross-functional ownership), Compensation (equity grant logic, severance terms).

Reports to: CEO. Manages: the engineering organization (currently 35, projected to 60 by year-end). Mission: Build the engineering organization the company needs to ship its next product line and scale the platform to 10x current load. Outcomes by 365 days: has hired the three director-level reports; has shipped the new product line; has reduced platform-incident MTTR by 50%; has presented engineering progress to the board four times.

How the Job Description Feeds the Application Form

The JD is upstream. The application form is downstream. The handoff between them is where most hiring funnels lose information.

The application form should screen for the must-have qualifications from section 6 of the JD, ask for evidence of the outcomes in section 4, and not ask for things the JD does not actually require. If the JD says "4+ years of backend experience" as a must-have, the form should have a years-of-experience question. If the JD says nothing about a portfolio, the form should not require one.

A common antipattern: the JD lists three must-have qualifications, but the application form asks for a CV upload, a cover letter, a portfolio link, a GitHub link, and ten optional questions, then the recruiter screens on resume keywords that are not in the JD. The JD-to-form handoff has lost the structure.

The fix is to build the application form from the JD's must-have list. One question per must-have, one optional question per nice-to-have, plus the standard contact and EEO fields. The Good Form job application template does this by default, with the structured questions you can map directly from a JD's qualifications section.

Common Mistakes and Legal Watchouts

A few specific watchouts that recur in JD reviews.

Discriminatory language. Words like "young," "energetic," "digital native," "recent graduate," or "rockstar" can attract age-discrimination claims. "Strong communicator" is fine; "must be a native English speaker" is not (it is national-origin discrimination unless the role genuinely requires it, in which case use "fluent" instead).

Implicit ADA issues. Listing physical requirements that are not actually essential to the job (lifting weights, standing for hours) restricts the candidate pool unnecessarily and creates an ADA risk if challenged. List physical requirements only when they are essential, and frame them as "with or without reasonable accommodation."

Salary range disclosure. As of 2026, posting a role visible in any of California, Colorado, Connecticut, Hawaii, Illinois, Maryland, Massachusetts, Minnesota, Nevada, New Jersey, New York, Rhode Island, Vermont, Washington, or DC requires the salary range. The EU Pay Transparency Directive imposes similar requirements across member states. Default to including the range in every JD; the legal floor is moving in one direction only.

EEO statement. Include a one-paragraph equal employment opportunity statement at the bottom of the public posting. It is not legally required in most jurisdictions, but it is a candidate-experience signal and a reasonable defensive practice if a claim is later made.

Outcomes that read as guarantees. Outcomes are intent, not contract. Phrase them as "by 90 days, has shipped X" rather than "will ship X within 90 days," which can read as a contractual promise. The difference matters in the rare cases where it does.

Use the Template

The eight-section spine works for every role. The five role-type variants give you a starting point for engineering, sales, support, management, and exec roles. The handoff to the application form is the bit most teams skip.

If you want to skip the manual handoff entirely, start with the Good Form job application template, which gives you a structured form that maps to a real JD's qualifications section, screens candidates by the must-have list you defined, and pipes the responses into a hiring workflow you can actually run. The JD defines the role; the form does the screening. Build them as one system, not two.