00 — Orientation
Open the hood
You already run on a system: a set of routines, triggers, defaults and recovery cycles that produce your days, whether or not you ever designed them. Most people never open the hood. This guide treats you as a system you can observe, design and debug, using the same logic you would apply to any process that has to run reliably under load.
This is not about motivation
Design beats willpower
Rest is a component, not a reward
01 — The components
Name the parts
Before you can design the system, name its parts. Each is a component you can observe and adjust on its own. Most problems trace back to one of them being overloaded or misconfigured, not to a lack of effort.
1.1
Attention · the processor
Finite, single-threaded and easily fragmented. Everything runs through it, and it does one thing at a time.
1.2
Energy · the power supply
Rises and falls in cycles across the day. It determines what the processor can actually do at any given moment.
1.3
Habits · the automated routines
What runs without conscious input, for better or worse. Cheap to run once built, expensive to change by force.
1.4
Environment · the default config
What your surroundings make easy or hard by default. It quietly decides most behaviour.
1.5
Inputs · what you feed it
Sleep, information, food, and the demands of other people. Bad inputs degrade everything downstream.
1.6
Recovery · the maintenance cycle
When capacity is restored. Skip it and throughput degrades, whatever the effort applied.
Figure 01 — illustrating section 01
The system, whole
Inputs
The system
Outputs
The whole model on one page. Inputs feed a system whose throughput depends on attention and energy; habits and environment decide what runs automatically; outputs generate feedback; recovery restores capacity. When something’s wrong, fix the component with the most leverage, not the symptom at the output.
02 — Map the current system
Observe first
You cannot debug what you haven’t observed. Before changing anything, run the system as it is and log what it actually does, not what you intend it to do. A few days of honest observation beats a month of guessing at the fix.
2.1
Log, don't judge
For a few days, record where attention and time actually go. Observation only. No changes yet, and no verdicts.
2.2
Find the real load
Note when energy drops, where tasks stall, and which transitions cost the most. The expensive moments are rarely the obvious ones.
2.3
Separate signal from noise
Most output comes from a few activities; most drain comes from a few leaks. Identify both, by name.
2.4
Take a baseline
You need a starting reading to know whether a change helped. Measure the system before you touch it.
03 — Inputs: energy & attention
The real budget
The common mistake is budgeting in hours. Hours are uniform; your capacity is not. Energy and attention are the real budget, and they vary across the day in fairly predictable cycles. Schedule against the budget you actually have, not the one the clock implies.
Attention is single-threaded
Energy runs in cycles
Switching has a cost
The supply is finite per cycle
Figure 02 — illustrating section 03
Capacity is not flat
Hours are flat; capacity isn’t. Schedule high-demand work into your peak window and low-demand work into the troughs. Treating every hour as equally productive is the most common budgeting error, and it quietly wastes your best window on email.
04 — Loops: how habits work
A habit is a loop
A habit is a loop, not a decision. A trigger fires, a routine executes, a reward reinforces the path, and over time the loop runs with no conscious input. You don’t break loops with willpower; you edit their components.
4.1
Cue · the trigger
What starts the loop: a time, a place, a preceding action, an internal state. Every habit has one, even if you haven’t spotted it.
4.2
Routine · what runs
The behaviour itself. This is the part everyone tries to change directly, and the hardest to change by force alone.
4.3
Reward · what reinforces
What tells the system to keep the path. No reward, no habit. Weak or delayed rewards make weak loops.
4.4
Reinforcement · repetition
Each run strengthens the path and lowers its cost. The more a loop runs, the more automatic it becomes, in either direction.
Figure 03 — illustrating section 04
The habit loop
Cue, routine, reward, repeat. Change a habit by editing its cheapest component, usually the cue or the environment around it, rather than out-muscling the routine every time it fires. Build by making the cue obvious and the reward immediate; break by removing the cue.
05 — Routines & anchors
Pre-decide it
Routines are pre-decided sequences that run without re-deciding. Their value is that they remove decisions from the system and free the processor. Two routines carry most of the load: the one that starts the day and the one that closes it.
Start-up routine
Shutdown routine
Anchoring
Keystone routines
06 — Blocks: designing the day
Assign the time first
An unstructured day defaults to reacting: whatever pings loudest sets the agenda. Blocking assigns time to work in advance, so the day runs to your design instead of to its incoming load. It is the schedule equivalent of a default configuration.
6.1
Block deep work first
Reserve the peak window for work that needs full attention, before meetings and admin can colonise it. Claim it before the day does.
6.2
Batch the shallow
Group low-demand tasks, messages, admin, errands, into their own blocks so they don’t fragment the deep ones.
6.3
Leave buffer
Unscheduled slack absorbs overruns and the unexpected. A day booked to 100% has no capacity for reality, and reality always arrives.
6.4
Protect the boundaries
A block only works if its edges hold. Treat the start and the end as fixed, not as suggestions to be renegotiated hourly.
Figure 04 — illustrating section 06
The day in blocks
Decide what each part of the day is for before the day decides for you. Deep work goes in the peak window, shallow work is batched, and buffer sits between. The blocks are defaults; reality pushes on them, and the buffer is what absorbs the push without breaking the plan.
07 — Debugging a broken system
Treat it as a fault
A routine that stops running isn’t a moral failure; it’s a fault. Treat it like one. The instinct to scrap everything and start over is the worst possible response, because it destroys the information about what actually broke. Debug instead.
7.1
Isolate the fault
Which specific loop or block failed? Name it precisely. “I’m undisciplined” is not a fault; “the shutdown routine stopped firing on busy days” is.
7.2
Trace the real cause
A missed habit is usually a symptom. Look upstream: the cue disappeared, the environment changed, or capacity was already spent elsewhere.
7.3
Change one variable
Adjust a single component and observe. Change everything at once and you learn nothing about what actually worked.
7.4
Avoid all-or-nothing
One missed run is a data point, not a collapse. Systems that treat a single miss as total failure are brittle by design. Resume on the next cycle.
Figure 05 — illustrating section 07
The debug loop
Not fixed? Change one more variable →
Fail small, recover fast, adjust. Isolate the specific fault, trace it upstream to its real cause, change one variable, and observe. Scrapping the whole system on a single miss throws away exactly the data you need to fix it.
08 — Redundancy & removal
Simplify by subtraction
You simplify a system by removing, not adding. And the only reliable way to know whether a step is necessary is to take it out and watch. If the system keeps running, the step was redundant, and it was quietly costing you. If it breaks, the step was load-bearing: restore it, and now you know why it’s there instead of guessing.
8.1
Remove to test
Pull one step out and run the system without it. This is observation, not demolition. You’re finding out what actually fails when it’s gone.
8.2
Keep what breaks it
A step whose removal breaks the system has earned its place. Restore it, and you’ve learned it’s necessary rather than assumed it.
8.3
Cut what doesn't
A step you can remove with nothing breaking was redundant. Systems accumulate these silently; each one adds cost without adding function.
8.4
Not all redundancy is waste
Deliberate redundancy is different: a backup kept on purpose for a step whose failure is expensive. Remove decorative redundancy; keep protective redundancy, like rest and recovery, on purpose.
Figure — — illustrating section 08
The subtraction test
Load-bearing — restore it, now understood
Redundant — cut it, it was waste
The only way to know a step is necessary is to remove it. If nothing breaks, it was redundant, so cut it. If something breaks, it was load-bearing, so restore it, now understood rather than assumed. Simplify down to what actually holds the system up, and keep protective redundancy on purpose.
09 — Feedback & review
Close the loop
A system with no feedback drifts. A short, regular review is the instrument that tells you whether the design is working, so you iterate on readings rather than on feelings. Keep it light enough that it actually runs.
9.1
Review on a cycle
A brief weekly check is enough for most people. Long enough to see a trend, short enough to act before it hardens.
9.2
Watch few metrics
Track two or three signals that matter, not a dashboard. What reached its target, what stalled, where capacity leaked.
9.3
Iterate deliberately
Change one thing per cycle based on the reading, then measure again. Constant tinkering is its own kind of instability.
9.4
Keep the instrument cheap
A review that takes an hour won’t survive a busy week. Make it small enough to be non-negotiable.
10 — Friction & defaults
Design the slope
The environment is the default configuration, and defaults win. Most behaviour follows the path of least resistance, so the highest-leverage change is rarely more effort. It is rearranging friction, so the good path is the easy one and the bad path is the hard one.
Lower friction for good defaults
Raise friction for bad ones
Design environment, not willpower
Defaults compound
Figure 06 — illustrating section 10
Behaviour flows downhill
Easy path · the default
Hard path · barriers added
Behaviour flows downhill. Lower the friction on the path you want and raise it on the one you don’t, and the default does the work that willpower otherwise would. Design the slope once; don’t fight gravity every day.
11 — Contingency
Plan for the bad day
Every system needs a fallback, because components fail. Not if, but when. And here the mechanical view has to admit what it has kept quiet until now: the system is a person. You get tired and ill, you feel things, and you have a life that doesn’t pause for your routines. A fair contingency isn’t a weakness in the design; it is the design telling the truth about what it runs on.
11.1
Design a reduced mode
A smaller version of the system that still runs when capacity is low. On a bad day you don’t drop to zero; you drop to the minimum that still counts.
11.2
Fair, not brutal
Contingency isn’t lowering the bar out of weakness; it’s engineering for reality. A system that punishes you for using its fallback has designed the fallback wrong.
11.3
Back up the load-bearing parts
The routines whose failure is expensive deserve a planned alternative, so one missed component doesn’t cascade into the rest.
11.4
Bad days are inputs, not faults
Illness, grief, a hard week: these are expected inputs, not defects in you. A system that can’t absorb them was never finished.
Figure — — illustrating section 11
Full mode, reduced mode
Full mode
Reduced mode
the minimum that still counts
Continuity over completeness
A fallback you designed in advance. Full mode runs the whole system; reduced mode keeps only the load-bearing few, so a bad day drops you to the minimum that still counts instead of to nothing. The thread stays unbroken, which is the entire point.
12 — Slack & sustainability
Headroom is a part
A system run at full capacity has no margin, and the first unexpected load breaks it. Slack, recovery and sleep aren’t inefficiencies to optimise away; they’re the headroom that lets the system absorb reality. Over-optimisation is itself a fault.
12.1
Build in headroom
Leave capacity unspent. A system planned to 100% fails on the first bad day; one planned to around 80% keeps running through it.
12.2
Recovery is maintenance
Sleep and rest restore the power supply. Cutting them borrows capacity from tomorrow at a high rate of interest.
12.3
Design for the bad day
The test of a system isn’t the good day; it’s whether it survives the tired, interrupted, low-capacity one. Make the minimum version small enough to run then.
12.4
Don't over-tune
Past a point, more optimisation adds fragility, not output. A slightly loose system that keeps running beats a tight one that seizes.
13 — The A–Z
First actions
If this is a lot, start here. Small, and in order. You’re not redesigning the system today; you’re taking the first readings and changing one thing.
01
Observe for a week
Log where attention and energy actually go. No changes yet, and no judgement.
02
Name your components
Identify the two or three carrying the most load, or leaking the most.
03
Find your peak window
Notice when capacity is highest, and mark it as protected.
04
Block deep work first
Reserve the peak window before anything else can claim it.
05
Build one habit loop
Make its cue obvious, its routine easy, its reward immediate.
06
Anchor it
Attach the new loop to a routine you already run, and borrow its trigger.
07
Change the friction
Lower it on one good default, raise it on one bad one.
08
Add a shutdown routine
Close the work cycle so recovery is protected.
09
Run a weekly review
Two or three metrics, kept deliberately small.
10
Leave headroom
Plan to about 80%, and let the buffer absorb whatever reality sends.
— Appendix
Notes & standing note
This guide applies systems and process language to personal routines. It draws on well-established ideas in habit formation, attention and time design, translated into a mechanical register on purpose.
The ideas behind it
N.1
Habit formation & behavioural design
The cue-routine-reward loop, and the friction-and-defaults principles behind how environments shape behaviour.
N.2
Attention & energy
Single-threading, the reload cost of switching, and working with capacity cycles rather than against them.
N.3
Time & work design
Blocking, the split between deep and shallow work, and buffering for the unexpected.