Pipeline de repurposing
de contenu

Six months after a hire, a manager I know said: "She's great. Just not quite right for where we're going." The candidate had passed every interview. Checked every box. Strong references. So what went wrong? The job description was written from memory — a reconstruction of what the previous person had done, what the team had liked about them, what they'd wished for in hindsight. It was a portrait of the past. And they hired someone to fit it perfectly. The role had moved on. The JD hadn't. This is the hiring mistake that never shows up in post-mortems. It doesn't look like a mistake until six months later, when alignment slowly unravels. The job description is a forecast. If it reads like a museum exhibit, you're not recruiting — you're cloning.

We spend weeks refining interview scorecards. We A/B test job titles for click-through rate. We debate whether to include salary bands. And then we copy-paste a job description from 18 months ago, update two bullet points, and call it done. The sourcing, the process, the candidate experience — none of it matters if the role itself is defined wrong. A misaligned hire costs more than a slow hire. But we optimise for speed and scoring consistency, not for whether the role we're filling is actually the role we need. The most expensive part of hiring is almost never the recruiting budget. It's the six months before anyone admits the fit was off.

One question that changed how I think about writing job descriptions: "If the person we hire is wildly successful in this role two years from now, what did they actually do?" Not which tools did they know. Not which processes did they manage. What did they achieve — and for whom? Start there, and work backwards to requirements. You'll likely find: → Half the "required" skills become irrelevant → The seniority level shifts (up or down) → The title might be wrong entirely Job descriptions written from outcomes attract people who want to build something. Job descriptions written from tasks attract people who want to maintain something. Those are different candidates. Which one do you actually need?

This week I want to talk about a hiring mistake that's almost invisible until it isn't. It doesn't show up on a scorecard. It doesn't get flagged in an exit interview. It happens before the first candidate ever applies — in the thirty minutes someone spends writing a job description by pulling up the last one. The result is a role defined by the past: what the previous person did, what the team wished they'd done better, what skills felt important at a moment that no longer exists. Round by round, those descriptions accrete requirements. Nothing gets removed. And the company ends up recruiting for a version of itself that it has already moved beyond. In this issue, we look at what it means to write a job description as a forecast rather than a historical record — and why that single reframe tends to surface more strategic clarity than any amount of interview optimisation. Let's get into it.

Run this quick audit on your next open role. Open the job description and ask: when was this last written from scratch — not updated, written from scratch? If the answer is "the last time we hired for this role," you have a copy-paste JD. It describes a past version of the position, not the current one. The tell: requirements that feel oddly specific, or bullet points that contradict each other because they were added in different hiring rounds. Rewrite it from the outcome, not the task list. It takes one meeting. It saves months.

Before your next intake meeting with a hiring manager, drop this question into the agenda: "If this hire is extremely successful, what's different about the team in 18 months?" Most managers haven't been asked this. They'll default to describing the role's responsibilities. Push past that. You want the outcome, not the job description they already have in mind. The answer tells you whether you're filling a functional gap or a strategic one — and those two openings require completely different candidates, timelines, and sourcing approaches.

Think of the job description as a contract with the future, not a report on the past. Every requirement you list is a prediction: this skill will matter in this context. Every qualification threshold is a bet: candidates below this line probably won't succeed here. If those predictions were written 18 months ago for a team that's since doubled, a strategy that's since pivoted, or a market that's since shifted — you're hiring for a company that no longer exists. The JD doesn't need a polish. It needs a rewrite. Start with the question: what does success actually look like here, now?