Teams
The Backfill Req Is a Task Inventory, Not a Portrait
A backfill req for someone who built every AI workflow on the team starts as a task inventory, not a job description. Spend the notice period listing what they run, what breaks when each one is wrong, who would notice, and what they check before trusting an output. The list is the requirement; their tool choices are not, because a req built from one person's setup rejects people who would do the same work differently.
The takeThe notice period is the last cheap chance to learn what the departing builder's workflows do, and it is easy to spend it writing prose about a person who is already half gone. What that builder holds is rarely a tool list. It is a set of judgments about when an output is wrong, learned from being wrong before, and none of it sits in a document. Get the judgments written down while somebody can still answer a question about them. The job description can wait a week. The person cannot.
Where Olive fits
Open a role and see what the work shows
An inventory keeps circling the same few behaviors: framing a problem before generating, sourcing the claim that matters, keeping the judgment that should not be delegated, testing an output against something outside the conversation. Olive reads those from a real working session rather than from a self-assessment, a person writes or edits each finding, and the candidate gets the same report.
Assess your shortlistWhat has to keep running after their last day?
Everything the team depends on and nobody else can operate. Start there rather than with a job description. Walk the week: the Monday report that arrives already drafted, the pipeline that reclassifies support tickets, the model that writes the first pass of every customer email. Write each one down as a row.
Four columns hold the row: the workflow, what it produces, who reads the output, and what goes wrong when the output is wrong.
The fourth column does the most work. A pipeline that mislabels a support ticket costs an hour; one that mislabels a refund request costs money and a customer. The second can pass unnoticed when nobody downstream reads closely enough to catch it.
Ask who would notice. If the answer is the person leaving and nobody else, the workflow is not a specification for the next hire but a finding about the team.
Run the same pass over the rest of the team, not only over the person leaving. Reading what your team can already do with AI off recent deliverables tells you how much of this work has to be hired for at all.
Most of what makes those workflows run is written down nowhere.
Stanford's Digital Economy Lab, in its 2026 Canaries paper, separates two kinds of knowledge. Codified knowledge is formal documented content taught through education, textbooks or written procedures. Tacit knowledge is acquired through practice, mentorship and repeated exposure to real situations 3.
The paper measures occupations rather than individual people, and its authors call that part of the work descriptive.
The tool is codified; what the person knows about when to distrust its output sits closer to the tacit side. The inventory is how that gets out of one head before the last day.
Ask the four questions before the last day
Book two hours with the person leaving and ask about the work, not about the job. What do you run every week? What would you check before you trusted this output in front of a customer? What have you seen this thing get wrong? What would you not hand to a model at all? The answers are the requirement list.
The third question is the one that pays.
Someone who has run a workflow for two years holds a private list of its failure modes: the month the classifier drifted, the summary that dropped the caveat, the number that looked right and came from the wrong column. None of that is in the tool's documentation and all of it is in the next hire's first quarter.
Write the failures down as cases, one paragraph each, with what went wrong and what caught it. A case is something an interview can use later. A tool name is not.
Reconstructing the inventory from their tool usage logs is tempting and mostly does not work. Seat and prompt counts tell you what got used, not what got decided, and the workflows worth backfilling are often the ones with the fewest logged sessions and the largest consequences.
The fourth question separates the job from the setup.
Whatever the person leaving refused to delegate is a judgment the role carries, and it stays in the role after the subscription is cancelled. Whatever they merely preferred, the model they liked, the prompt library they kept, the plugin they paid for, leaves with them.
Why does a req copied from one person narrow the pool?
Because the exact criteria do the rejecting. Harvard Business School and Accenture's Hidden Workers survey found 88% of employers agreeing that qualified high-skills candidates are vetted out of their process because they do not match the exact criteria in the job description, rising to 94% for middle-skills roles 2. Employers agreeing about their own process is not a measured rate, and it is still the clearest statement of the problem.
A backfill req is the easiest place in hiring to write exact criteria, because a real person is sitting there to copy.
Their model, their orchestration tool, their vector database, their four years at the last employer: each line reads like a description of the work and is in fact a description of one solution to it. Two candidates who solved the same problem with different tools now fail the same screen.
US federal selection rules speak to where a requirement comes from.
In their standards for content validity studies, the Uniform Guidelines on Employee Selection Procedures (29 CFR 1607.14C) say a job analysis should focus on the work behaviors and the tasks associated with them. They also say a requirement for specific prior training or experience based on content validity should be justified on the relationship between the content of that experience and the content of the job 1.
The stack the incumbent chose is not the content of the job, only one arrangement that produced it.
Write the requirement list as work the next person does
Turn each row of the inventory into one sentence about a task and one about the standard it has to meet. The refund classifier line becomes: reviews model-drafted refund decisions and catches the ones that would pay out on a duplicate claim. A requirement in that form is testable, portable across tools, and readable by somebody who has never seen your stack.
Each line still needs somewhere in the loop that can see it. A requirement about judgment under uncertainty with no exercise behind it is one the process never checks, and every requirement needs a stage that tests it.
Then cut the list to what the first six months need.
A backfill req collects everything the departing person ever touched, because everything they touched is now visibly at risk. Most of it is not urgent. The urgent ones are those with a consumer downstream and no second reader.
Deleting the incumbent's tool names does not shorten anything on its own.
Across 33 million job postings from 2017 to 2019, the Burning Glass Institute watched what happened when a credential line came out instead. Employers who cut a credential requirement went on to ask for a wider and deeper set of skills than before, with the biggest increases in stated soft skills such as communication, being detail-oriented and problem solving 4. Vagueness moved rather than left.
Keep the requirements concrete instead. Every line names an artifact the person will produce or check, and any line that could be pasted into a req for a different job comes out.
Published task statements for the occupation are where the wider version of this inventory starts, in finding out what AI actually does in a role before writing the job post. A backfill starts from a person, which is faster and narrower, and those published statements are the correction for the narrowness.
Plan the first month around what nobody documented
Budget the new hire's first month for rebuilding, not for delivering. Whatever the inventory could not explain is now theirs to reconstruct, and reconstruction can run slower than the original build, because the original builder had context nobody wrote down. Name that work in the offer conversation, so it reads as the job rather than as a bad start.
Filling the seat can take longer than the notice period does.
In June 2016, mean US vacancy duration ran 28.3 working days on the DHI-DFH measure, and on the most recent size data, for May, establishments with more than 5,000 employees ran 59.5 6. The monthly series has since been discontinued, so neither number describes today. A filled vacancy is still not a started job.
Some of what the new hire inherits will carry no reason at all. A workflow nobody can explain is the same problem as a codebase the model wrote and nobody remembers why, and in both cases the work starts with reconstructing what the thing was meant to do.
None of this matters if requisition text rarely changes who gets hired.
11,332 roles at large firms dropped a degree requirement, and the Burning Glass Institute and Harvard Business School matched them against roughly 65 million US career histories. Inside those roles the share of hires without a bachelor's degree rose about 3.5 percentage points, while the estimated net effect across all the large-firm roles studied was 0.14 points, because only 3.6% of roles dropped a requirement 5.
Editing a req is not a hiring practice on its own. What the notice period buys is a list of tasks the loop can test, which is the half that moves a hire.
Open the requisition again on the day after their last day.
If it still reads as a description of the person who left, the notice period went into prose. A list of work with a consumer attached to each line will outlive this hire. It also briefs whoever writes the req after it.
Common questions
How long does a task inventory take?
Two hours with the person leaving, plus an hour writing it up, covers most teams. The constraint is calendar rather than effort: it has to happen while they are still employed and still willing to answer a follow-up question. Book the session in the first week of the notice period, not the last, and send the questions ahead so the answers arrive with examples attached. A second short session a week later usually adds the failure cases the first one missed, because those surface when someone has been thinking about the question.
What if the person leaving will not cooperate?
Get what the artifacts hold and stop asking for the rest. Scheduled jobs, shared drives, dashboards, recurring calendar entries and the tickets that reference an automation will reconstruct roughly what runs and who consumes it. What they will not reconstruct is why any of it is trusted, which is the part worth having. Say that plainly in the requisition and in the offer: part of this job is establishing why the outputs can be relied on, because the person who knew is gone. A req that hides the gap gets a hire who discovers it in week three.
Should the backfill req name the AI tools the team uses?
Name them once, under context, and keep them out of the requirements. A candidate deserves to know what stack they would inherit, and telling them costs nothing. Listing the same tools as requirements is a different act: it turns one person's setup into an eligibility rule and rejects people who did the same work in a different tool. Where a requirement rests on content validity, federal selection guidance ties prior experience to the relationship between the content of that experience and the content of the job, not to a match between two toolchains.
Can the workflows be documented after they leave?
Partly, and the part that survives is the cheaper part. What a workflow does, what it produces and who reads it can be recovered from the artifacts by anyone with access. What cannot be recovered is the failure history: which outputs looked right and were not, what tipped the person off, what they stopped trusting and when. That knowledge is held by practice rather than by documents, and it leaves on the last day. Capture the failure history first and let the process documentation wait, because the second one can be written by the next hire.
Should the req ask for the same seniority the person leaving had?
Ask what the tasks need, then check whether the person leaving grew into a level the job never required. Somebody who builds every AI workflow on a team often ends up senior because of what they built, not because the role was written that way. Splitting the inventory helps: the workflows with a consumer downstream and real consequences set the bar, and the rest can go to the team or to a more junior hire. Two hires at the level the tasks need beat one at the level the last person reached.
Is a backfill req the right moment to raise the AI bar for the role?
Only for the tasks a task inventory turns up. Raising a bar the job does not exercise narrows the pool without changing what gets delivered, and a requirement no stage tests is a requirement nobody applies consistently. What that inventory legitimately supports is a harder bar on the specific judgments the departing person exercised: catching a wrong output before it reaches a customer, refusing to automate a decision that needs a person, checking a claim against something outside the model. Write those as requirements and give each one an exercise.
References
- 1. 29 CFR 1607.14, Technical standards for validity studies (content validity, subsections C(2) and C(6)) ✓ govinfo.gov Supports the claim that a requirement is grounded in tasks rather than in the incumbent. Section 14C(2) states: "Any job analysis should focus on the work behavior(s) and the tasks associated with them." Section 14C(6) states that a requirement for specific prior training or experience "should be justified on the basis of the relationship between the content of the training or experience and the content of the job for which the training or experience is to be required or evaluated." Page fetched and read 1 September 2026.
- 2. Hidden Workers: Untapped Talent ✓ hbs.edu Supports the claim that exact job-description criteria filter out qualified people: 88% of employers agreed that qualified high-skills candidates are vetted out because they do not match the exact criteria in the job description, rising to 94% for middle-skills roles. Cited here as employer self-report, not as a measured exclusion rate.
- 3. Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence ✓ digitaleconomy.stanford.edu Supports the codified-versus-tacit vocabulary used to describe what a departing builder holds. The paper defines codified knowledge as formal, standardized, documented content taught through education, textbooks or written procedures, and tacit knowledge as knowledge acquired through practice, mentorship and repeated exposure to real situations. The article states the paper's own limit: the gradients are occupation-level and descriptive, and no individual's knowledge was measured.
- 4. The Emerging Degree Reset: How the Shift to Skills-Based Hiring Holds the Keys to Growing the U.S. Workforce at a Time of Talent Shortage ✓ burningglassinstitute.org Supports the warning that deleting a requirement lengthens rather than shortens a job description: across 33 million postings from 2017 to 2019, employers who cut a credential requirement went on to ask for a wider and deeper set of skills, with the biggest increases in stated soft skills. The named skills are the report's illustrative per-occupation examples, not a ranked national list.
- 5. Skills-Based Hiring: The Long Road from Pronouncements to Practice ✓ static1.squarespace.com Supports the complication that requisition text alone rarely changes who is hired: 11,332 roles at large firms that dropped a degree requirement, matched against roughly 65 million US career histories, showed a 3.5 percentage point rise inside those roles and a 0.14 percentage point net effect, because only 3.6% of roles changed a requirement. Large firms only, education inferred from career histories.
- 6. DHI Hiring Indicators, Report 28: Mean Vacancy Duration Fell to 28.3 Working Days in June ✓ dice.com Supports the claim that the vacancy gap outlasts a notice period: mean US vacancy duration was 28.3 working days in June 2016, and the report gives 59.5 working days for establishments with more than 5,000 employees on the most recent size-category data, which is May. The article states that the monthly series has been discontinued and that these figures do not describe the present.
6 sources, numbered by first appearance. Every one was opened and checked against the claim it carries. How Olive sources claims
General guidance for hiring teams. What works at one company and one volume may not transfer to yours.
Olive assesses how a person works with AI. It does not detect AI-written documents, and it never produces a score, a ranking, or a match percentage for a person. Candidates read the same report the employer reads.