The Law You Already Know But Keep Ignoring
Cyril Northcote Parkinson wrote in 1955 that “work expands so as to fill the time available for its completion.” He was describing British civil servants, but he stumbled onto something that applies with uncomfortable precision to technical work. Give yourself a week to design an API and it will take a week. Give yourself two hours and you’ll have something workable in two hours, probably better than the week-long version.
Most engineers know this. Almost none of them act on it consistently, because acting on it requires making a decision that feels irresponsible: deliberately constraining the time available for something important.
The instinct runs the other way. Important work deserves more time, more space, more room to breathe. So we protect four-hour blocks for architecture decisions. We schedule two-week sprints for features that probably need three days of real thinking and one day of implementation. And then, almost inevitably, the four-hour block fills with tangential reading, the two-week sprint fills with meetings about the sprint, and the actual thinking happens in a compressed panic at the end.
This isn’t a discipline problem. It’s a constraint design problem.
What Happens When You Widen the Container
Think about how memory allocation works. You ask for a chunk of memory and the allocator gives you what you asked for. If you ask for more than you need, the excess doesn’t stay clean and empty, it accumulates overhead, fragmentation, housekeeping. The same thing happens with time. A two-hour block allocated to an architecture decision doesn’t stay focused on the core question for two hours. It expands to include reviewing every adjacent decision, reading three blog posts that seem relevant, opening a document about a vaguely related system you built two years ago.
Expansion isn’t laziness. It’s a natural response to perceived available capacity. Your brain, given an open-ended block, will find ways to fill it with things that feel productive. That’s the insidious part: the filler usually isn’t Netflix. It’s more research, more tangents, more “while I’m at it” work that feels justified by the importance of the task.
Parkinson identified this in administrative contexts, where committees would spend as much time debating a bicycle shed as they would a nuclear reactor (the so-called “bike-shed effect,” later formalized by Poul-Henning Kamp). But the same dynamic runs through engineering planning, design reviews, and technical writing. The work fills the container you build for it.
Constraints Aren’t Restrictions, They’re Specifications
Here’s the reframe that actually changes behavior: a time constraint on important work is a specification, not a restriction. When you tell a function it has 100ms to return a result, you’re not being cruel to the function. You’re forcing it to do the important computation and skip the optional ones. The constraint is the thing that surfaces what actually matters.
This is why your best work often happens in shorter, protected windows rather than sprawling open-ended sessions. The meeting at noon isn’t just an interruption. It’s also, paradoxically, the thing that forces you to actually decide something before it arrives.
Practically, this means you should be deliberately stingy with yourself when allocating time to important tasks. If you think something will take a day, block four hours and see what happens. You will either finish it, which tells you the day estimate was padded, or you’ll finish something that looks like a draft, which is almost always more useful than spending the rest of the day polishing ideas that haven’t been pressure-tested yet.
The key mechanic is commitment before the constraint. You have to decide, before you start, what “done” looks like. “I will have a decision about the database schema” is a completable goal. “I will think deeply about the database schema” is not, and will expand to fill any container you put it in.
The Calendar as a Constraint System
Your calendar is already a constraint system. The problem is most people use it as a recording device rather than a design tool. They add time for things they want to do and then treat whatever’s left as available for more things they want to do. The calendar fills from both directions and what gets squeezed is exactly the work that doesn’t have a specific appointment: the focused thinking, the hard design problem, the document that needs to exist but has no meeting attached.
A better model is to treat your calendar the way you’d treat a CI/CD pipeline configuration. You define the stages, you specify the time budget for each stage, and anything that doesn’t fit in the budget gets flagged rather than silently absorbed. The work hour that matters most is the one that’s hardest to protect, and protecting it means actively constraining it, not just reserving a vague block labeled “deep work.”
Concretely: instead of “3 hours: work on authentication system,” try “90 minutes: decide on token storage strategy, write one paragraph explaining the decision and its tradeoffs.” The second version has a completion criterion. When 90 minutes is up, you either have the paragraph or you don’t. That’s information. The three-hour version just has an end time.
The Uncomfortable Implication
If Parkinson’s Law applies to your important work, then the amount of time you’ve been protecting for that work is probably wrong. Not a little wrong. Significantly wrong.
This isn’t an argument for crunch or for treating focused thinking like a factory output problem. Rest and incubation are real. Some problems genuinely need time to sit. But there’s a difference between giving a problem space to breathe and giving it an open-ended block that your brain will fill with anything that feels vaguely related.
The test is simple: pick one important task this week and cut your time estimate in half. Define a concrete completion criterion before you start. See what happens. Either you’ll finish faster than expected, which should recalibrate your future estimates, or you’ll hit the constraint with something incomplete but concrete, which is almost always better raw material than the diffuse progress you’d have made in the full block.
Important work deserves time. It also deserves a container that fits.
