Build Your Team: The Work Comes First

I still sketch complex projects in a notebook.

On September 25, in a conversation about building workflows, I explained why. I need to see the flow. A request like “make a video and publish it” hides a collection of different jobs inside one sentence. Drawing it makes those jobs visible.

Later in that conversation, I was asked which question I find uncomfortable to answer about my work. My answer was: “Why did you do it that way?”

That question belongs before the team diagram. Before assigning a writer, a researcher, an editor, or a model, I want to understand the work each of them is meant to own. What arrives? What leaves? Who needs it next? What would let us accept it?

The team follows that map.

Work first. Team second.

The work contract

Give the work a shape.

Define what arrives, what leaves, who receives it, and how you check it.

Bounded taskProduce narrationRead the approved text.

01InputApproved script02OutputNarration audio03ReceiverTranscript stage04CheckPronunciation listen

Input / Example artefactScript.txt

The harbour opens at dawn.Harbour: HAR-buh

Start from an agreed source.

Approved text and pronunciation notes define what the voice task can use.

Draw The Work Before Naming The Owners

“Make a video” describes an outcome at the wrong resolution for execution. It doesn't tell the next person whether they're writing words, recording speech, aligning captions, building animation, checking the cut, or publishing an approved file.

In our conversation, another participant used a video workflow to make that distinction visible: Script → Voice → Timed Transcript → Animation → Publish. I’m using that sequence here as an illustration. It's one possible workflow, with a specific assumption: the animation follows the recorded voice and its timings. Other productions can have different dependencies.

Even in this small example, the stages do different kinds of work.

These outputs give the stages an identity. “Editor” on its own doesn't. The work could mean correcting language, cutting audio, aligning subtitles, or judging a visual sequence. Until the output is explicit, a role name can conceal several incompatible expectations.

I want the map to survive a change of owner. A person could record the voice. A model could propose it. A script could align a transcript. The required artefact and its acceptance check still need to exist.

Give Each Handoff A Contract

A handoff is where an output becomes somebody else's input. That boundary deserves a contract.

Mine starts with four fields:

• Input: The accepted artefact this stage can rely on, including the revision it belongs to.
• Output: The artefact the stage must produce, with enough structure for its next receiver.
• Receiver: The person or process that needs to use that output.
• Check: The observable evidence that lets the receiver accept it.

Then I add the judgement the stage requires, the dependencies that must already be accepted, and the owner who can make the decision.

For a timed transcript, “a transcript exists” is a weak check. The file might contain every spoken word and still belong to an earlier recording. Its shape can be valid while its relationship to the audio is wrong.

A stronger contract names the accepted audio revision, specifies the time units, requires ordered timestamps within the recording's duration, and includes a sync comparison at meaningful points. Structural checks can reject malformed timestamps. Listening or viewing checks whether the alignment works for the cut. Each check supports a different claim.

A parser accepting a file proves that the parser could read it. It doesn't prove that the words are accurate, the timing belongs to the current recording, or the visual intention survived. Those need their own evidence.

The receiver determines which evidence is useful. Someone recording a voice needs approved words and pronunciation decisions. An animation process needs timings tied to audio. A reviewer needs a playable cut and the intended outcome. Giving each of them the same enormous document makes the interface harder to use.

Enough context means enough to do this job and judge its output. It doesn't mean handing over every conversation that preceded it.

Correct Stages Still Need The Correct Order

A list of sensible stages can describe a broken workflow.

If this animation is timed to the voice, the timings must come from the recording the animation will use. A transcript made before that recording cannot establish its actual timing. If the recording changes, dependent timing and animation need to be checked again.

Try moving the stages below. The lab evaluates the prerequisites of this illustrative workflow. It also propagates an invalid prerequisite: putting Animation after an unusable Timed Transcript doesn't repair the transcript.

Stage order lab

Order follows dependencies

Move a stage. Trace the effect.

Use the arrow controls to change the order.

Reset order

1. 01

   Script

   Approved words

   Starts from the brief

   Ready

   ↑Earlier↓Later
2. 02

   Voice

   Spoken audio

   Requires Script

   Ready

   ↑Earlier↓Later
3. 03

   Timed Transcript

   Words aligned to audio

   Requires Voice

   Ready

   ↑Earlier↓Later
4. 04

   Animation

   Visuals aligned to words

   Requires Timed Transcript

   Ready

   ↑Earlier↓Later
5. 05

   Publish

   Reviewed release

   Requires Animation

   Ready

   ↑Earlier↓Later

All five stages have valid prerequisites.

The underlying structure is a dependency graph. Each stage accepts particular upstream artefacts. An edge means “this job needs that accepted output”, rather than simply “these two boxes are next to each other”.

For this example, the graph is a chain. A larger project might branch: visual research and a script could develop separately, then meet at an agreed direction. Parallel work is useful when those jobs can proceed on their own accepted inputs. A dependency is a reason to wait for acceptance before consuming the result.

There are two different problems to handle:

1. Order: A required input hasn't been accepted yet.
2. Staleness: An input was accepted, but the revision the downstream work used has changed.

Ordering the boxes handles the first. Tracking the relationship between revisions handles the second. A cut can be built in the correct sequence and still use captions from yesterday's voice file.

A practical record can be small: identify the output, the input revision it used, its acceptance state, and the person responsible for accepting it. When an input changes, mark its dependent work for review. Keep the earlier artefact available until the new one is accepted. That gives you a way to understand what changed without pretending the old result remains current.

Assign Ownership Where The Judgement Lives

Once the work is visible, choosing an owner becomes a bounded decision.

Some stages transform accepted inputs according to explicit rules. A script can validate timestamp ranges, move an approved file into a delivery structure, or check whether an expected output exists. Its contract should specify what happens when the input is missing, malformed, or already processed.

Other stages need interpretation: choosing a framing, proposing a line, or assessing whether a cut carries the intended feeling. A model can offer possibilities and make a case for them. A human still has to define the outcome and own the decisions whose consequences she is accepting.

Many stages combine these. A script can check the shape of a transcript while a listener checks its meaning and timing. A model can propose a visual treatment while a human reviews whether the treatment serves the brief. “The model owns this stage” needs more detail about which part it owns.

Use the lab to inspect a responsibility before assigning its owner. Watch how the oversight changes when you choose a human, a script, or a model.

Work owner lab

Responsibility before role

Assign the work, then keep the judgement visible.

ResponsibilityScriptVoiceTimed TranscriptAnimationPublish

Assign the work

HumanScriptModel

Input

Source notes and brief

Output

Approved script

Judgement

Choose the message, structure, and emphasis.

Check

Read for accuracy, omissions, and spoken flow.

Oversight contract

Model owner / Approved script

A model can propose a result within the brief. A human reviews the generated result, including its claims and choices.

Models never grant their own publishing permission.

↳Human release approval remains required before publishing.

An owner needs both responsibility and a boundary. A model asked to propose a cut doesn't acquire permission to publish it. A successful command doesn't acquire authority to accept an editorial decision. The authority to act has to be granted by the application and the person operating it.

That distinction also matters for data access. Saving a brief as Markdown, CSV, or a database record doesn't determine what a model can read. The application decides which material it retrieves, which tools it exposes, and which operations it permits. A file format supplies structure. Access controls supply the boundary.

My useful team diagram therefore includes the acceptance decision. Who can propose? Who can transform? Who can accept? Who can release? Sometimes one person holds several of those responsibilities. Writing them down still helps us see where oversight is required.

Test The Boundary While It Is Still A Boundary

In the September conversation, I said people often don't go through each step and test it. “They just test the end.”

A final review matters. It also arrives after the downstream work has already consumed its inputs. If the voice contains the wrong pronunciation, a reviewer can discover it in the finished cut. A voice-stage listen could have found that same problem before the animation depended on the recording.

The checks below simulate two deliberately simple defects. Choose one, then switch intermediate checks on and off. The result shows the first applicable check in this model. A transcript timing check cannot detect a pronunciation mistake merely because it occurs earlier in the sequence.

Step check lab

Check where a defect becomes visible

Catch it before it travels.

Switch checks off to trace the earliest remaining check that examines this defect.

Defect to traceVoice pronunciationTimed Transcript offset

Local checks

✓

Voice

Voice check

Pronunciation listen

Catches this defect

·

Timed Transcript

Transcript check

Timing against audio

Different defect

·

Animation

Animation preview check

Speech listen and sync preview

Relevant check

Voice pronunciation

Caught at Voice pronunciation listen.

Transcript timing check does not inspect pronunciation.

↳Final human release check always active.

A useful test states the failure it is intended to detect. “Check the output” is too open. “Listen to this pronunciation in the accepted voice file” names a testable boundary. “Compare the caption at this transition against the recording” names another.

Three layers help me keep that precise:

1. Structure: Does the artefact exist, parse, and meet its declared shape?
2. Relationship: Does it use the accepted source and revision its contract requires?
3. Outcome: Does it do the job the next receiver and the brief need it to do?

The layers can overlap. They still answer different questions. A structurally valid subtitle file can reference the wrong audio. A perfectly synchronised cut can miss the intended tone. An expressive cut can be unusable at its delivery size.

The lab is intentionally limited. Its checks catch the defects they are defined to catch. They don't establish that a whole production is correct, and they don't remove final human review. The useful design question is where we can gather evidence while the consequence of changing the input is still bounded.

When a check fails, stop acceptance at that boundary. Keep the failed output available for diagnosis, return a concrete failure to its owner, and rebuild the affected work from the accepted revision. Repeating the whole production without identifying that boundary makes it harder to know what the next run is meant to fix.

Write The Smallest Contract You Can Defend

I don't need a giant orchestration diagram to start. I need one stage described clearly enough that another person could take it over.

The stage and owner worksheet gives you a place to do that. Start with a single outcome. Name the deliverable and the receiver. Then describe one stage, its accepted input, its output, the check, and the decision its owner is allowed to make.

Use the video example or substitute your own work. Keep the ownership question open until you've named the judgement involved. If a rule can perform the transformation, write the rule. If someone has to choose between interpretations, name that decision and its acceptance criteria.

Then follow the output into the next stage. Does its receiver have what it needs? If the input changes, can you identify what has become stale? If the check fails, is there a bounded way back to the right owner? If the stage were done by a different person or model, would the contract still make sense?

That is the question I want the map to help answer. The map should explain the work and make the important decisions visible. It should give the team enough freedom to solve the job, with enough definition to judge what comes back.

Stop prompting. Start defining outcomes.

Define the work. Make the handoffs visible. Build the team around them.