---
id: I-007
type: intervention
title: "Requirements Drawn From the Team's Own Backlog"
lang: en
registry: 2026.08.2
canonical: https://hoba.work/interventions/I-007
json: https://hoba.work/api/v1/interventions/I-007.json
---

# 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.

> **On the canonical path** — [A real opening, described honestly](https://hoba.work/process#WF-003-real-need)
>
> 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.

## At a glance

- Actor: hiring manager
- Scope: team
- Cost: low
- Evidence: supported

## What it looks like

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*

```
Subject: 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.

## 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.

## 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`

## Related entries

- targets — [M-024](https://hoba.work/mechanisms/M-024) — Inflated Requisition Requirements vs Actual Team Needs
- targets — [B-013](https://hoba.work/barriers/B-013) — Requisition Approval & Public Posting
- targets — [L-003](https://hoba.work/loops/L-003) — Inflated-Requirements Search Saturation Loop

---

hoba — a public, versioned atlas of hiring obstacles. Content CC BY-SA 4.0. This document is generated from the registry; the canonical page is linked above.