Lesson 5.65.6 Adapt the brief to the task type

In everyday life. Asking friends for vacation ideas is different from booking the flight you chose.

At work. Asking for ways to avoid late fees needs a loose brief, but pulling the fields out of invoices needs the tightest one.

The four parts never change. What changes is how tightly you set them. A tight brief fixes exactly what the answer must look like. A loose one leaves room for the worker's own ideas. Either way, give the worker the context and constraints the task needs, every time. Only the shape of the answer gets tighter or looser.

Two more rules go with the table. For research and analysis, never present the conclusion you hope for as already true, because a worker that sees it tends to find it. If you have a hypothesis, a guess of your own, state it as something to test, and ask for evidence for and against.¹ For extraction, tell the worker to leave a field blank and flag it instead of guessing. A guessed invoice number looks exactly like a real one. Technical tasks follow the same rows. Turning invoices into JSON records that a system checks is extraction at its tightest. JSON is a file format that programs read.² Name the schema (the fields the system expects and the type of each), and what to return when a value is missing.

At Brightline. Maria needs two things in the same week. The first is ideas for avoiding late fees. That is brainstorming, so her brief stays loose. It names the problem, the team and what to avoid, and leaves the shape open: "Suggest five different ways a small AP team that pays weekly could avoid late fees. Avoid anything that needs new software." The second is this week's invoices as JSON records for the accounting system's import check. That is extraction, so every part is tight:

Outcome:     One JSON record for each invoice in this week's batch,
             ready for the accounting system's import check.
Context:     Only the invoice PDFs in this week's batch folder.
Format:      The fields vendor, invoice number, invoice date as
             YYYY-MM-DD, total in USD with two decimals, and currency.
             Nothing else in the file.
Constraints: When an invoice does not show a field, leave it empty and
             list the invoice and the field at the end. Never guess a
             value.

The brainstorm brings back ideas Maria had not thought of. The extraction brings back clean records and two flagged invoices, each without a date. Swap the two styles and both fail. A tight brainstorm returns five rewordings of one idea, and a loose extraction returns dates that look real but are not.

A note to a supplier. Drafting sits between the two. The facts and the promises must be tight, and the wording can stay loose. Maria's note to Lakeshore Janitorial (5.5) ends up like this:

Outcome:     Draft a note to Lakeshore Janitorial saying that invoice
             5131 is overdue and under review. Done when a saved
             draft says it is overdue and under review.
Context:     For Lakeshore's billing contact. Dave approves it before
             it goes out. Payment terms come from the vendor record,
             not the terms printed on the invoice.
Format:      An email draft.
Constraints: Under 150 words, polite and plain. Quote the invoice
             number and amount exactly as recorded. Say it is under
             review, without a payment date. Leave out the terms
             question until Dave confirms it. Save it as a draft and
             send nothing.

Its content rules are tight, and the words between them are the worker's to choose.

How big the brief should be. A job needs a full brief when it runs while you are away, runs on a schedule, or would cost a lot to redo (5.1). Maria's brainstorm is an ask: she reads the ideas at once and can ask again. The JSON records are read by a system, not a person, and a guessed value looks exactly like a real one, so they need a full brief.