Season 1 · Episode 11

Run Several Projects Without Losing the Plot

Delegation, durable memory, and background work.

This lesson drops soon — check back here for the video and voiceover.

Chris runs mining research, a vineyard production, music slates, apps, and businesses — sometimes in the same week. This lesson is the orchestration layer: how to classify work, give every track a deliverable and a return condition, parallelize what’s independent, preserve state in project records, and tell the difference between “started” and “finished.”

The problem this lesson solves

M

u

l

t

i

p

l

e

p

r

o

j

e

c

t

s

i

n

o

n

e

c

h

a

t

b

e

c

o

m

e

o

n

e

c

o

n

f

u

s

e

d

p

r

o

j

e

c

t

.

D

e

l

e

g

a

t

e

d

w

o

r

k

v

a

n

i

s

h

e

s

i

n

t

o

t

h

e

v

o

i

d

.

A

b

a

t

c

h

j

o

b

“

r

a

n

”

b

u

t

n

o

b

o

d

y

k

n

o

w

s

i

f

i

t

f

i

n

i

s

h

e

d

.

N

o

t

i

f

i

c

a

t

i

o

n

s

p

i

l

e

u

p

u

n

t

i

l

t

h

e

r

e

a

l

b

l

o

c

k

e

r

s

a

r

e

i

n

v

i

s

i

b

l

e

.

T

h

e

p

r

o

b

l

e

m

t

h

i

s

l

e

s

s

o

n

s

o

l

v

e

s

i

s

r

u

n

n

i

n

g

m

a

n

y

t

r

a

c

k

s

a

t

o

n

c

e

w

i

t

h

t

h

e

s

a

m

e

r

i

g

o

r

y

o

u

’

d

g

i

v

e

o

n

e

—

e

v

e

r

y

t

r

a

c

k

o

b

s

e

r

v

a

b

l

e

,

e

v

e

r

y

o

u

t

c

o

m

e

v

e

r

i

f

i

e

d

,

e

v

e

r

y

f

a

i

l

u

r

e

s

u

r

f

a

c

e

d

.

The lesson, step by step

Classify the work

Immediate conversation, delegated research, build task, monitored event, scheduled recurrence. Different classes get different handling — you don’t babysit a recurrence like a conversation, and you don’t fire-and-forget a build task.

Give every track a contract

Concrete deliverable, boundary, evidence requirement, return condition. “Research X” is not a track; “research X, deliver a ranked table with sources, return when the table reconciles” is.

Parallelize the independent, sequence the shared

Independent tracks run in parallel. Tracks that share data, credentials, or judgment gates run in sequence. Parallelism is a scheduling decision, not a hope.

Pilot before you batch

One successful pilot before launching a large batch. The pilot proves the method on real data; the batch scales what the pilot proved.

Preserve state in a project record

Last completed step, artifact location, unresolved issue, next action. Every run resumes where the last one stopped — this is Episode 2’s project map, grown up into operations.

Distinguish “started” from “finished”

Queued, running, and deployed are not the same as verified. Work is done when the evidence says so — the completion report template (Completed, Evidence, Changed, Not completed, Decision needed, Next action) is the receipts for orchestration.

Surface failures immediately — with the consequence and the next move

No silent failures, ever. What failed, what it affects, what completed work is preserved, and the safest next step. Bad news early is cheap; bad news late is expensive.

Kill notification sludge

Notify on completions, blockers, genuine risk, or decisions — not every heartbeat. A notification system that cries wolf trains you to ignore the wolf.

Worked example

A nine-city data rebuild. The pilot: one city, end to end — collection through audit — with counts reconciled against the source. It works. Then the batch: remaining cities run as parallel tracks, each with its own project record (last completed step, artifact location, open issues). One city’s track fails on a timeout — the failure surfaces immediately with the consequence (“city 4 incomplete, others unaffected”) and the next move (reconcile counts, resume that track only). No re-running the world.

Your takeaway

• Classify work, then handle each class appropriately — don’t babysit recurrences or fire-and-forget builds.
• Every track gets a deliverable, a boundary, an evidence requirement, and a return condition.
• Pilot once, then batch; keep a project record so every run resumes cleanly.
• “Started” is not “finished” — queued, running, and deployed are not verified.
• Surface failures fast with consequence + next move; notify only on what needs a human.

The BRAVE lens

Every episode runs through the BRAVE method: brief the outcome, reveal relevant context, authorize the next action, verify the evidence, and evolve the system.