Requirements Drawn From the Team's Own Backlog

Draft the requisition's requirement list from the last two quarters of the team's actual work: every requirement the screen reads names a task it is required for, and anything without one is published in a separate section that is not screened on.

Intervention I-007 Actor: hiring manager Scope: team Cost: low Evidence: supported

On the canonical path

A real opening, described honestly — The requisition describes work that exists now, at a level the team actually needs, inside a band the budget already covers. Nothing here is aspirational: the list of requirements is what the job uses, not what the last four candidates happened to have.

This entry is one of the things that holds that commitment up.

What it looks like when this intervention is in place

Composite excerpts, written to be typical rather than copied. No particular message, company or person is quoted here.

The requisition, with the list split reconstruction

Title: Backend Engineer · Billing — requirements

Screened on — Go, three years or more: billing endpoints and the report export, 40 of last quarter's 52 merged changes.

Screened on — SQL schema changes under load: the two migrations scheduled this quarter.

Not screened on, useful — Kubernetes, Terraform, Rust: no task in the last two quarters; the cluster is owned by the platform team.

Level: L4. The list was written from the backlog rather than carried over from the L5 search for this team.

What to notice: The same manager, the same worry about the ceiling. What changed is that a requirement now has to name a task, and the ones that cannot are still published — in the list nobody is screened against.

What this targets

Expected effects

M-024 is split into two published lists: the screened list carries only requirements that name a task, and the wish sits in the section that is not screened on
B-013 fixes a bar that states what each part of it is for: the requirement list is checkable against the team's own backlog rather than against the level in the grid
L-003's entry point becomes an edit with a date — raising a requirement mid-search means adding a line with no task behind it

What to measure

screened_requirement_count
mid_search_requirement_edits
screen_to_onsite_rate

From each side

The same entry from inside each position that meets it: what reaches them, what it means from there, and what happens next given what they control.

Hiring manager

What reaches them: The requisition draft next to the last two quarters of merged work, and the requirements carried over from the previous search that now have to be matched to a task or moved.
What it means from there: The ceiling can still be written down, but it is written in a section the screen does not read; what is screened on is what the backlog can account for.
What happens next: Moves each unmatched line into the second section, and carries the risk that a requirement not screened on brings someone who has to learn it on the job.

Recruiter

What reaches them: Two lists in the requisition instead of one, and only the first is the screening standard.
What it means from there: What is movable is written down before the pipeline thins, rather than found by going back to the manager in week six.
What happens next: Screens against the first list, and passes the second one to candidates as a description of the work rather than as a bar.

Candidate

What reaches them: A posting where each screened requirement names the work it is for, and a separate list marked as not screened on.
What it means from there: The bar is stated as the work rather than as a stack, so which lines the assessment runs against is readable before applying.
What happens next: Applies against the screened list, and reads the second section as description rather than as a threshold to clear.

Share card png This page as markdown json