Execution

The structure centres on five tasks. Not five goals. Not five projects. Five specific outcomes. Ones that, if completed, 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. In practice the list always runs long. It needs to be 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. The categories are client delivery, content, systems, outreach, learning, and internal R&D. The rule is to target eighty to ninety per cent of capacity. Never a full hundred. Something always arrives unplanned. 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. It can't be ticked off. The format is 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 character-level record. One that shows what was actually happening in any given period. It turns out to be more informative than the task log. Look back at a year to see why.

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. Without it the week defaults entirely to output measurement. Whether it changes behaviour in any way I could measure is genuinely unclear. 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. The review gets skipped or abbreviated in the weeks it matters most. Dictating across the categories removes that. The output isn't obviously worse. That's 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. Effort is always visible to you. Outcomes usually aren't until they're named explicitly.

Longer-horizon goals are checked against separately-held tracking. Not reproduced inside the review. That's 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. It's simultaneously too granular and too strategic to work as either.

The wins capture is a data-quality measure. Not a motivational one. That's 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. That happens every time you assess how a period went. 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. Ideas have an asymmetric pull. They feel urgent and important at the moment they arrive. That feeling correlates poorly with their actual value. It has nothing to do with whatever is already in progress. The log captures the idea without committing to anything beyond capture. That's usually all it needed.

The backlog gets reviewed at the start of each week. The output is straightforward. 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. Because they aren't better than what's already being built. That's 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 review was never worth the urgency. It just arrived wearing it.

The failure mode I hit most isn't the skipped log entry. It's the thin prototype built just to see. It produces something half-finished. Then it 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 a complementary function. They surface what could be cut rather than added. The instinct to add is considerably stronger than the instinct to remove. True for me and for 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.