Execution

The structure centres on five tasks. Not five goals or five projects — five specific outcomes that, if completed, would make the week genuinely productive regardless of what else happened. The entire discipline is in the selection. Choosing five means rejecting everything else that could have been on the list, and in practice the list always runs long until it's forced into a priority stack. Five doesn't suggest that stack; it enforces it.

Each week opens with a capacity tally: available hours mapped against planned work categories — client delivery, content, systems, outreach, learning, internal R&D. The rule is to target eighty to ninety per cent of capacity rather than a hundred, because something always arrives unplanned and an overbooked week reliably produces worse output than an underbooked one. I have consistently overbooked and have not fully solved it. Naming that is more useful than pretending the system runs clean.

One item sits deliberately outside the task list because it can't be ticked off: a single named skill or quality being developed under pressure that week. It's an identity marker rather than a deliverable. Over time these accumulate into a record of what was actually happening at the character level in any given period, which turns out to be more informative than the task log when you look back at a year.

There's also a randomised virtue drawn each week from a fixed list — patience, composure, curiosity, vulnerability and so on. Its function is to force something non-commercial to orient around, because without it the week defaults entirely to output measurement. Whether it changes behaviour in any way I could measure is genuinely unclear, and I keep it anyway.

The template gets filled by voice dump rather than typed field by field. Careful manual note-taking on a blank template creates just enough friction that the review gets skipped or abbreviated in the weeks it matters most. Dictating across the categories removes that, and the output isn't obviously worse — which is the only test that matters for a ritual that has to survive a bad month.

Five tasks. If the five can't be named clearly, the week doesn't have a shape yet.

The review runs a fixed checklist: log any interactions worth recording, a relationship pass covering who to message and who to see, a progress check against annual and quarterly targets, and a wins-and-challenges reflection. The structural rule is that it covers outcomes rather than effort — what moved, what didn't, and what the actual obstacle was. That distinction matters because effort is always visible to you and outcomes usually aren't until they're named explicitly.

Longer-horizon goals are checked against separately-held tracking rather than reproduced inside the review, specifically to stop it becoming a planning session. The weekly review is not where the plan gets rewritten — it's where you confirm the plan is still pointing somewhere sensible. If it isn't, that adjustment happens at the monthly level. Collapsing the two produces a review that's simultaneously too granular and too strategic to work as either.

The wins capture exists as a data-quality measure rather than a motivational one, which is the part people get wrong about it. Wins evaporate from working memory almost immediately. Without an explicit capture step, difficult events get weighted far too heavily when you assess how a period went — and inaccurate assessments feed straight into inaccurate planning. Accurate accounting of what worked is exactly as important as accurate accounting of what didn't.

Diagnostic, not motivational. And not the place to rewrite the plan.

The standing rule is explicit: a new build idea gets a one-line dated entry, not an immediate build. The only override is an explicit decision to build now. It exists because ideas have an asymmetric pull — they feel urgent and important at the moment they arrive, and that feeling correlates poorly with their actual value relative to whatever is already in progress. The log captures the idea without committing to anything beyond capture, which is usually all it needed.

The backlog gets reviewed at the start of each week, producing a straightforward output: which items batch into this week's build slots, and which get pruned. Most ideas are correctly killed at this stage — not because they're bad, but because they aren't better than what's already being built, which is a completely different test and a much harder one to pass. An idea that survives three reviews without being pruned has earned a slot. An idea that doesn't survive the first was never worth the urgency it arrived with.

The failure mode I hit most isn't the skipped log entry. It's the thin prototype built just to see — which consumes as much decision-making overhead as a real build, produces something half-finished, and then sits in the backlog indefinitely radiating obligation. The rule is strict for that reason: sketch in the log, don't prototype until the slot is deliberately scheduled.

Monthly reviews of what already exists serve the complementary function — surfacing what could be cut rather than what could be added. The instinct to add is considerably stronger than the instinct to remove, in me and in most people building systems. The build log counteracts the add instinct on new ideas; the monthly reviews counteract accumulation in existing ones. Neither works alone.

Log, don't build. Urgency isn't a selection filter.