When you hire a backfill, the old job description is usually the wrong document. It describes the role as someone designed it years ago, not the role the person leaving actually ran. Write it from the work instead, and every requirement becomes something you can point to.
Why does a template job description fail for a backfill?
Because a role drifts. Over a few years it picks up a vendor relationship, an integration, a compliance duty, and drops things nobody does anymore. A template job description hires for the role on paper, and the successor finds out what the real job is in their first month.
| Template job description | Job description from the work | |
|---|---|---|
| Starts from | A title and a generic list of duties | What the role does today, from its record |
| Requirements | Skills the role might need | Skills the work demonstrably needs, each with its evidence |
| Systems | Often missing or out of date | The systems the role actually touches |
| Who you'll work with | Rarely mentioned | Every recurring counterpart, by role, inside and outside the team |
| Risk | Hiring for a job that no longer exists | The evidence is only as good as the record behind it |
What is the evidence rule?
Every responsibility and requirement names the real work that needs it. "Vendor and commercial negotiation" is a claim; "vendor negotiation, evidenced by the logistics contract renewal" is a fact you can verify and a candidate can be asked about. Anything you cannot evidence comes out.
Should a job description name people?
No. A role record is full of names and internal systems, and a handover should name people, since the successor needs them. A job description goes to strangers and outlives the current team, so it uses roles instead: "an executive sponsor", "a systems integrator's solution architect". One-off events get generalized into standing duties, and internal hostnames come out entirely.
Example: a job description written from the work, annotated
This example comes from the fictional company in our live demo, written in the exact format Understudy produces from a role record. Compare it with the handover documents for the same role: same work, but the job description names no one.
Delivery Lead, Enterprise Applications
Mission
Lead delivery across the enterprise application landscape — currently an S/4HANA migration, a major vendor contract renewal, a customer data platform build, support capacity planning, and PCI remediation — keeping sponsors ahead of risk and vendors honest.
What you'll own
- End-to-end delivery of the S/4HANA migration: cutover planning, go/no-go, rollback strategy, sponsor communication (evidenced by: Project Atlas — runbook, checklist, board visibility).
- Vendor & contract management: commercial negotiation, redlines, renewal strategy (evidenced by: Apex Logistics renewal — uplift counter, liability-cap position).
- Data platform governance: schema decisions, privacy gates, build sequencing (evidenced by: Customer Data Platform — DPIA-gated build, consent model).
- Capacity & operations planning (evidenced by: Support backlog — ticket-type analysis, seasonal-hire decision).
- Compliance remediation ownership (evidenced by: PCI-DSS — four findings driven to evidence).
- Integration ownership: a live Workday → S/4 HR integration — 8 iFlows on SAP Integration Suite and the S/4 RAP data model behind them (evidenced by: the grounded systems record — package WorkdayToS4, transport MRDK900412).
Systems & tools you'll work in
SAP S/4HANA (RAP data models, transports) · SAP Integration Suite (iFlows, OData) · Workday (HR data source) · the retail POS estate · ticketing/support tooling.
Who you'll work with
An executive sponsor (VP), internal engineering and data leads, finance, security & compliance, HR — and externally a systems-integrator (account exec + solution architect) and a logistics vendor's commercial team.
What success looks like
A clean, on-schedule ERP cutover with a defensible rollback story; a renewal signed at defensible commercials; a data platform built without privacy debt; peak season absorbed without an SLA breach; audit findings closed on evidence, not promises.
Requirements
- Enterprise ERP delivery leadership, ideally an S/4HANA migration (evidenced by: Atlas).
- Vendor/commercial negotiation at contract level (evidenced by: Apex renewal).
- Working fluency in SAP integration — Integration Suite, OData, transports (evidenced by: the Workday→S/4 integration this role owns).
- Privacy/compliance literacy — DPIA, PCI-DSS (evidenced by: CDP gate, PCI remediation).
- Sponsor management and board-level communication (evidenced by: Atlas go/no-go cadence).
- Data-driven operations planning (evidenced by: the ticket-type breakdown approach).
Nice to have
Retail domain experience · HR data models (Workday) · post-merger or replatforming history.
This description reflects the role as actually performed today, generated from its role record — not a template.
How do you turn the requirements into interview questions?
Each evidenced requirement already contains its best interview question: ask the candidate about the situation the evidence describes.
| Requirement, as evidenced | Interview question |
|---|---|
| ERP delivery leadership (the S/4HANA migration) | Tell me about a cutover where a data risk threatened the go-live date. What did you recommend, and why? |
| Contract-level negotiation (the logistics renewal) | A vendor opens a renewal well above your budget and holds firm on liability. What do you trade, and what do you never trade? |
| SAP integration fluency (the HR integration) | Walk me through how you would find out what an inherited integration actually does, before anyone who built it is available. |
| Privacy and compliance literacy (the data platform gate) | A privacy review blocks your build for a week. How do you keep the project moving without working around the gate? |
| Sponsor management (the go/no-go cadence) | How do you tell an executive sponsor that a date is going to slip? |
| Data-driven operations planning (the support backlog) | Your team asks for a temporary hire. What would you want to know before you agree? |
How was this produced?
Understudy reconstructs a role from the work itself, the mail threads, calendar and systems of record, into a living role record. The job description is generated from the same record as the handover documents, with the people taken out and the evidence kept in. The record belongs to the person whose role it is, and it maps the work, not the worker. For the questions to answer before someone leaves, see the 100 handover questions.
How the record behind all of this is built: knowledge transfer from the work itself.