The Container Rule
a task takes exactly as long as you let it
A task takes exactly as long as you let it.
Hand it 2 hours and it takes 2 hours. Hand it 2 days and it somehow takes 2 days too.
This isn’t news. Parkinson wrote a version of it down in 1955, an essay about a British civil service that somehow always filled whatever hours it was given, no matter what the job actually needed. I read it years after I’d already proved it true on myself, which is usually how it goes with anything worth knowing. Whatever actually changes your life was probably already written down somewhere, waiting for you to need it badly enough to notice.
I believed for years that running invoicing for Optimal Chef Services needed 2 full days a week. 14 to 16 hours, spread across every Monday and Tuesday. Even if i was on holiday, it had to be done. Two full days, disappeared into spreadsheets and numbers that didn’t add up the first time through. I believed it because the task had never once been handed a smaller container to prove it wrong. It was never told to stop. It just filled the space it was given, the way every task does when nothing sets a boundary first.
In 2022 I rebuilt the whole thing around 4 steps. Define what done actually looks like: every invoice sent, every chef paid, the books closed, not 90 percent of the way there. Break that into the goals underneath it: what has to be pulled, what has to be checked, what has to go out the door. Turn the goals into minute-by-minute steps, so there’s never a moment spent deciding what happens next instead of just doing it. Put a timer around the whole thing and refuse to let it run long.
I call it the Container Rule. The container comes first, before the task ever gets touched.
By 2023 the same job took 6 hours. By 2025 the entire procedure took 3. Systems and processes now handle the data entry that used to eat most of the time. I still send every invoice myself and pay every chef personally, because that part is the relationship itself. What’s left now takes 1 hour 50, every Tuesday morning.
Here’s the part that makes it a rule and not just a good week: I allot 2 hours for it. It takes 1 hour 50. If it isn’t done by the time the block ends, it waits until tomorrow. No exceptions. A good reason doesn’t get one either. Let a task borrow 10 minutes from the next block once, and it’ll ask for the same favour every week after that. That’s the same lesson as everything else I’ve had to learn the hard way: the exception you make once becomes the rule you’re stuck defending forever. Structure is the actual mechanism freedom runs on.
There’s a song i use as a trigger to get into flow state. Always the same one. It goes on at 9 every Tuesday morning, and by the second chorus my brain already knows what’s coming. It skips the negotiation and the warm-up lap entirely, straight into the kind of focus that usually takes 45 minutes to find for most people on a normal day. By that point the song is doing the work willpower would otherwise have to do.
Flow doesn’t arrive because you want it to. It arrives because you built the conditions for it and then got out of the way: the container, the cue, the same chair, the same nine o’clock. Remove any one piece and you’re back to negotiating with yourself for the first 45 minutes, which is 45 minutes you don’t get back.
Invoicing is just the test case. The rule works on anything: a task expands to fill the space you give it, and shrinks the moment you stop giving it more.
You’ve got your own version of the two-day invoicing somewhere on your calendar right now. The task that’s technically an hour of real work but somehow eats an entire afternoon, because it was never told to stop. The report. The inbox pass. The thing you keep starting at 9am and still touching at 4.
It’s taking that long because you never built it a container. The difficulty was never the real problem.
Same logic runs under everything else I’ve built. The business that used to take every hour I had now takes 10 hours a week, because I stopped handing it more room than it needed. A tight enough container is what makes room for everything else. That’s the whole trick, and it works on a task exactly the same way it works on a life.
Hit reply and tell me what’s currently allowed to take as long as it wants on your calendar. I want to know which task it is.
Give it less time and watch yourself work your magic.
- Chris
P.S. The song stays private. Find your own. The cue only works if it’s actually yours.




Great article Chris. This got me thinking about how I work when I’m building a product or writing code.
I completely agree that we need limits, otherwise there’s always one more thing to tweak, improve or rethink.
But I think there’s a distinction between giving work a container and allowing focus the time it needs to be fulfilled.
I'd add that the definition of done isn't always fixed. Sometimes the work itself shows you what done should look like. Lock it too early and you might stop just before something valuable emerges.
When I’m deeply focused on building or solving something, I’m not sure I’d want to stop simply because the two hours I gave it are up. Sometimes that’s exactly the point where everything has clicked into place and the most productive work is happening.
Maybe the trick is knowing when a task is expanding because we’ve given it unlimited room, versus when we’re genuinely in a productive state of focus that’s worth protecting.
Perhaps for some kinds of work the best container is time, while for others it’s a clearly defined outcome or scope?
Either way post really landed and made me question how I think about my own working process. Thank you.