The thing nobody tells you about running two projects on the same clock is that the clock is the whole lesson.
For a while now I’ve been building two things at once, on a shared weekly rhythm rather than whenever inspiration strikes. Not because parallel work is inherently smart. Because a single deadline shared by two projects exposes exactly where a system is real and where it’s just good intentions with a deadline attached.
One project alone will forgive almost anything. You can start late, change your mind twice, and still get it out the door by leaning on effort at the end. Two projects sharing the same window will not forgive that. Whatever’s loosest in your process is the thing that breaks first, and it breaks in a very specific, informative way: not by failing outright, but by quietly eating the other project’s time.
The first thing that breaks is the decision you didn’t make in advance
Every open decision costs more than it looks like it costs, because it doesn’t just cost the time to decide. It costs the time to re-decide, every time you come back to it, because you never wrote down why you chose what you chose. Topic picks, formats, priorities: anything you’re deciding fresh each week is a tax you’re choosing to keep paying.
Running two things in parallel makes this visible fast, because the decision doesn’t just cost you time, it costs the other project its share of the same window. The fix isn’t willpower. It’s moving the decision earlier, so the version of you that’s mid-execution never has to make it fresh. A standing order of what gets picked and why beats a smart person improvising twice a week, every single time, once the deadlines start overlapping.
Context switching has a real cost, and it’s not the ten minutes you think it is
The obvious cost of switching between two things is the time it takes to reload context: what state is this in, what did I decide last time, what’s next. That part is real but small. The bigger cost is quieter: the switch resets your judgment to a lower setting for a while. The first decision you make right after switching is worse than the fifth, because you haven’t re-earned the context yet. Do that switch often enough in one sitting and every decision that day is being made at the “first decision after a switch” quality level, without you noticing the drop.
The practical fix is blunter than it sounds: batch by project, not by task type. Do all of one project’s decisions in one sitting, then all of the other’s, rather than pinging between them across the day. It feels less flexible. It produces sharper work, because the sharpest thinking in any session is at the start of it, and batching means you get more starts.
A checklist beats memory, and this is the part I resisted longest
I used to think writing down a process was an admission that the process wasn’t intuitive enough yet. Running two things on one clock corrected that fast. Memory is fine for one project, because one project’s worth of context fits comfortably in your head between sessions. Two projects’ worth doesn’t, and the failure mode isn’t dramatic, it’s a quiet one: you forget a small step you always do, and you don’t notice until the output is missing something you’d have caught on autopilot if you were only tracking one thing.
A written checklist isn’t a crutch for a weak process. It’s what lets a real process survive contact with a second project competing for the same attention. This connects to something I wrote a while back about what running two learning projects first taught me about systems: the lesson keeps refining itself. Back then it was about the value of having a system at all. This time it’s about what specifically breaks inside that system once it has to run on a shared, unforgiving clock, and what the fix looks like in practice rather than in theory.
What “systemised” actually means
Not that it’s automated. Not that it’s fast. It means the process would survive a worse week than usual, because the decisions were already made, the switches were already minimized, and the steps were already written down somewhere other than your memory. A system you only trust on a good week isn’t a system. It’s a good week wearing a system’s clothes.
Frequently asked questions
Is running two things in parallel actually a good idea?
Not for the reason people usually assume (more output). The real value is diagnostic: a shared deadline across two projects exposes weak points in your process much faster than either project would alone, because there’s nowhere for a loose habit to hide.
What’s the single highest-leverage fix?
Moving decisions earlier, so they’re made once instead of re-decided every time you return to a task. That single change reduces both the decision cost and the context-switching cost, since there’s less to reload when the choice is already settled.