Why does work expand?

Ever heard that “work expands to fill the time available”? Let's dig into why that’s only half the story — and what Parkinson’s Law gets wrong about how real work (and real people) actually operate.

“It is a commonplace observation that work expands so as to fill the time available for its completion.” That is the first sentence of a C. Northcote Parkinson’s essay published in the Economist in 1957. It is a seriocomic attempt to derive a formula that describes the rate of increase of a bureaucracy, complete with fake statistical proofs. No surprise then that people only remember the first sentence, which has (erroneously) been dubbed “Parkinson’s Law.”

Parkinson, a Naval Historian, says work grows in a bureaucracy because bureaucrats can only delegate work to subordinates. Asking for less work puts their careers at risk. Attempting to share the work with peers risks their status, and thus subordinates must be hired to share that work.

So is that the whole answer? Parkinson, a Naval historian, thought so. He used the growth of personnel of the British Navy on land during a time when the Navy at sea was shrinking to establish his formula. Obviously you can poke a lot of holes in the methodology here, but — as with so much of conservative humor — it’s “just a joke.”

Who’s laughing?

I’ve heard this line from businesspeople, project managers, scrum trainers, and small-government advocates. Most of these folks don’t know it’s called “Parkinson’s Law.” I’d bet money they haven’t read the essay.

It’s true that work both expands or contracts to fit available time and budget, within certain limits, of course. To illustrate how more time is simply wasted, Parkinson compares two people mailing a postcard:

An elderly lady of leisure can spend the entire day in writing and despatching a postcard to her niece at Bognor Regis. An hour will be spent in finding the postcard, another in hunting for spectacles, half-an-hour in a search for the address, an hour and a quarter in composition, and twenty minutes in deciding whether or not to take an umbrella when going to the pillar-box in the next street. The total effort which would occupy a busy man for three minutes all told may in this fashion leave another person prostrate after a day of doubt, anxiety and toil.

It’s the same task, but the “elderly lady of leisure” — with no demands on her time — takes hours to do what a “busy man” in less time that it takes to boil a kettle.

But is it the same work? What happens when work expands? What happens when it contracts? Parkinson assumes that extra time is frittered away, but if we want to make sure we really have to take a closer look.

Understanding the work

Honestly, there’s no point nitpicking Parkinson’s example. It is “just a joke,” right? And joke arguments don’t have to make sense — they just have to have that “true” vibe. But maybe the busy man doesn’t care what his niece at Bognor Regis thinks of him. And perhaps Auntie and the niece had a serious fight over the niece’s new boyfriend, and Auntie is anxious to patch things up. You can probably imagine a bunch of different stories here, too.

And that’s where things get complex. We can assume it’s the same work, but once we take a good hard look at what’s going on the difference in time investment might become apparent.

Few people have jobs mailing postcards, and it’s a trivial task anyway. Instead, let’s consider something that’s more complex and likely to have a much more broad range of possible timelines: launching website contact form feature.

The first form is built by Liam. Liam is 13 and will do it for a pizza in about an hour.

The second contact form is built by the firm JTH, LLC. JTH is Junius, a UX designer; Tricia, a developer; and Harper, a graphic designer. Building the form takes JTH two months, and they bill $3,000. What’s the difference?

When you starve a project for resources, some things have to go out of the window. If we, citing Parkinson’s Law, choose to give JTH one month instead of two, what do we lose? What do we keep? It seems self-evident, and yet everyone with an income under seven figures has probably had to deal with someone with unreasonable expectations. Hard decisions have to be made.

Frederick Brooks saw this problem with AI in programming several decades ago. Speaking specifically of AI, he said:

The hard thing about building software is deciding what one wants to say, not saying it. No facilitation of expression can give more than marginal gains.

The promise of AI in coding is you can just say what you want “in natural language” and the AI can give it to you. But if people were capable of clearly explaining what they want in a non-trivial bit of software, I’d have spent less time in meetings. And arguing.

So much arguing.

Here’s where I mention vibe coding

I have seen so many demos at this point where someone feeds an LLM a screenshot of a website interface and a website comes out. Maybe it has a little code to make that form functional! But vibe coding has so much more in common with little Liam than it does professional work.

How much does the speed increase of vibe coding come from just not doing work? Production-quality software goes much further than the basic set of instructions that fulfills a specific task. This is why JTH’s work is so much more expensive than little Liam’s; Liam has done the barest minimum.

Frederick Brooks, again:

The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

… For the truth is, the client does not know what he wants. The client usually does not know what questions must be answered, and he has almost never thought of the problem in the detail necessary for specification. Even the simple answer “Make the new software system work like our old manual information-processing system” is in fact too simple. One never wants exactly that.

Programming is tough, but honestly saying what you want in natural language is the hardest part. Non-programming vibe coders run up against this all the time once they move beyond the trivial. They just don’t realize that the problem is not the AI agent. The problem is they don’t know what they want or what questions are necessary.

I’ll admit it: I’ve started to enjoy having AI assistance in coding. But what I enjoy is the reduction in typing I have to do. I am still having to do all the thinking. The thinking is still taking the bulk of the time.

It may feel like we’ve drifted away from Parkinson’s Law, but the big hope of AI assistance in general — and in its extreme form, vibe coding — is that we can compress the time it takes to do something. We want to stop being Auntie looking for her specticals on the way to the pillar-box. We want to be on the right side of Parkinson’s Law, doing the most amount of work possible in the least amount of time. But instead we’re just skipping a lot of work.

Maybe putting the squeeze on the timeline causes people to work more efficiently. But when you try to squeeze too much, something is going to leak out.