Requirements Teardown Sheet

A blank sheet for one requisition. You bring the current requirements list and the task list behind it; the sheet takes them apart in four passes and hands back a list where every surviving line names the stage that tests it and the rule that acts on the result.

It is not a posting template and it writes nothing for you. What it produces is the requirements section, not the posting around it.

Before the first pass

Two inputs, and the second is the one people skip.

• Pull the published task statements for the occupation code closest to this role, and mark every task a model can already draft ^{1 2}.
• Spend twenty minutes each with three people doing this job now, one of them from outside your company. Ask what they hand to a model and what they keep.

The published statements tell you what the occupation contains. The three conversations tell you what has already moved, which no published list is current enough to say ³.

Pass one: sort every task three ways

One row per task, before a word of the posting is written.

Only the tasks in the middle band become requirements. Those are what the hire is paid for and the only lines a loop can check. The first band describes work the role still contains and no longer selects anybody.

Pass two: three deletions and one sharpening

Delete, in this order:

• The production verbs where an assistant now writes the first pass: drafts, formats, compiles, transcribes, summarizes.
• The software-proficiency lines the assistant absorbed.
• The years-of-experience line, wherever the experience it stood for was volume practice at those same tasks.

Then sharpen what is left. The verbs that still sort somebody are accountability verbs: decides, verifies, refuses, escalates. Rewrite each surviving line so it carries one.

Pass three: a stage, a rule and an owner for every line

Three rules govern this table, and the third is the one that shortens the list.

• A line with an empty stage column gets a stage or comes off the list. There is no third option.
• A requirement is a must-have when a named stage tests it and a decision rule acts on a candidate who fails. Everything else is a preference and belongs in the body of the posting or nowhere.
• The bullet count is not the test. A five-line list nobody checks is worse than a nine-line list where every line has an owner and a rule.

A requirement you use to make a decision is a selection procedure, and the burden that attaches to one is stated here rather than paraphrased: Once a complaining party shows a particular practice causes disparate impact, demonstrate that it is job related for the position in question and consistent with business necessity. 42 U.S.C. 2000e-2(k), effective November 21, 1991. ^{4 5}. That is the reason the middle column is not optional. It is also why an attribute has to be rewritten as a behaviour or an artifact before it can be tested: you have to be able to name what a person would do or show that satisfies it.

Pass four: the lines about working with a model

Each of these lines has three parts. Write all three or drop the line.

• The occupational task. The work this role does, in that occupation's own language.
• The override point. The place in that task where a person has to overrule the model.
• The proving step. The stage in your process where a candidate shows it.

Four rules for writing them:

• Name the behaviour, not the product. A product name is a keyword, applicants mirror keywords back, and the products listed in a requirements block come back on nearly every application while reporting nothing about who uses them. Name a product only where it is genuinely not substitutable.
• Write the question first and the posting line second. If you cannot say what a passing answer contains, the line does not belong in the posting.
• Ask for recency and evidence, not years. Years of experience reports something only once a tool has been stable long enough for exposure to accumulate. Ask instead whether the candidate has used an assistant on work of this kind in the last six months and can walk through one instance.
• Required means required. Required means you would turn down a strong candidate on day one for lacking it. That is rarely true of a general assistant, which a new hire can be taught inside a normal ramp. Most of these lines belong in the preferred block or nowhere.

The preferred block

Delete it, or replace it with one line naming what would make somebody unusual in this role and what evidence would show it. A preferred block was only ever a self-selection device and it does little selecting now.

Exit checks

Run these before the requisition goes out. A no on any line sends you back a pass.

A refreshed requisition that got longer had nothing subtracted from it, whatever else changed.

What this sheet does not do

• It does not write the posting. It produces the requirements section and stops there.
• It does not tell you whether a requirement is lawful where you hire. It applies no law to your facts, and the burden it names above is the general standard rather than advice about your requisition.
• It does not evaluate a candidate. Nothing here produces a number, and no output of this sheet describes a person.
• It carries no benchmark for how many requirements a role should have. The passes shorten the list by removing what nothing tests, which is not the same as a target.