Starting three things at once
The mobility routine started on a Monday, along with the earlier bedtime, the walk, and the thing about water. Three weeks later none of them are happening and you’d struggle to say which one went first.
That grouping is not a coincidence and it isn’t a shared lack of resolve. Simultaneous behaviour changes fail together for mechanical reasons, and the mechanism is worth knowing because the fix — one at a time — sounds so unambitious that nobody adopts it without an argument.
Why simultaneous starts fail together
They compete for the same slot. New routines gravitate toward the same few parts of the day: the start of the morning, the gap after work, the hour before bed. Those are the places with slack in them, which is exactly why you chose them, and three new behaviours in one slot means the slot is now a queue. Queues get dropped from the back, and each new arrival makes the whole block more expensive to begin.
They compete for the same anchor. If the plan is “with the morning coffee,” then the coffee is carrying three attachments, and an anchor supports about one. The second and third don’t get a trigger at all; they get an intention to remember, which is not the same mechanism and decays quickly.
They share a single stock of attention. In the first fortnight, each new behaviour has to be consciously remembered and consciously begun. That’s the expensive phase for all of them at once, and it lands in the same fortnight.
And they share one failure narrative. This is the underrated one. Three separate routines, if they were separate, would have three separate endings. Started as a package, they’re a single project — “getting into shape,” “sorting myself out” — and one bad week that takes out two of them takes the third too, because the project has visibly failed and the survivor is now a remnant of something that didn’t work. People stop the last one deliberately at that point, which is an odd thing to do and very common.
Why it feels like the wrong advice
Because the appetite to change several things arrives all at once and feels like a resource that should be used while it’s there. That’s a real observation: the appetite is a resource and it doesn’t come back on request.
But spending it on three starts doesn’t produce three routines; it produces three unfinished builds. One at a time, using the same appetite to build one thing properly, produces one routine that still exists — and a routine that still exists is a platform to attach the next thing to, which the failed package isn’t.
The arithmetic is worth stating plainly, even qualitatively. Three simultaneous attempts that all collapse in week three leave you with nothing and one more failed attempt in your history. One attempt that survives leaves you with one routine and an anchor for the next. The slow version is faster within a few months.
THE RULE — one at a time
1. One new behaviour at a time. Not one per category,
not "these two go together." One.
2. It gets promoted only when it has survived a bad week
without conscious effort. Then → next one.
3. Everything else on the list goes in writing, unstarted,
with today's date. It is not abandoned. It is queued.
4. Each new one gets its own anchor, in a different part
of the day from the last.Rule 3 exists because the reason people start three is fear of losing the other two. Writing them down with a date is enough to stop that, and it turns “I’m not doing the walk” from a failure into a position in a queue.
Picking which one goes first
Not the most important one. The one most likely to stick, which is usually the smallest and the one with the most obvious anchor. You’re not optimising for benefit; you’re optimising for producing a routine that exists, because the first success is what makes the next attempt cheaper.
Practical criteria, in order:
Which has an unambiguous daily trigger already available? If one of your candidates has an obvious involuntary event to attach to and the others don’t, start that one.
Which is smallest? Not most valuable. Smallest.
Which have you failed at fewest times? A behaviour with four failed attempts behind it carries expectation of failure and needs a post-mortem before it gets another go. Start with something less loaded.
Which is least dependent on the others? If the movement routine only works when you’re getting up earlier, then the earlier start is really the first item and the routine is the second.
What “survived a bad week” means
Rule 2 needs a definition or it becomes a vibe. Concretely: a week in which something went wrong — a deadline, poor sleep, a disrupted schedule, someone ill — and the routine happened anyway, without you having to think about it much or deliberately protect it.
Note that you can’t schedule this. You wait for a bad week to occur, which it will. Until one has, the routine is untested and adding a second thing means running two untested builds — which is the situation you were trying to avoid.
This is the same criterion as the one for adding to an existing routine, and for the same reason: familiarity is what makes a behaviour cheap, and only a bad week proves it’s cheap enough.
What this costs
The queue is slow, and some things on it will wait months. If two of your candidates are genuinely important, one of them is being deliberately postponed, and that’s a real decision with real consequences rather than a scheduling nicety.
It also spends the fresh-start appetite on one item, and the rest of that appetite is essentially wasted — you can’t bank it. That’s a genuine loss and it’s the strongest argument for the package approach. The counter is that a wasted surplus is cheaper than three failed builds.
What this doesn’t fix
Doing one thing at a time doesn’t make that thing survive. It removes the specific failure mode of mutual interference, which leaves everything else — no cue, too long, no floor — fully intact.
And if two behaviours genuinely are one behaviour, splitting them is artificial. If your routine only happens after a walk because the walk is what gets you off the sofa, that’s one routine with two parts, not two items for the queue.