Your team has the AI tools. The pilots worked, the demos were real, and a year later the roadmap moves at roughly the speed it always did. Before you buy more seats or schedule another training, look at a date instead of a tool. Parkinson’s Law says work expands so as to fill the time available for its completion, and that sentence is most of the explanation. AI collapsed how long the work takes. It did not touch how long you gave it. Until the second number moves, the first one never shows up anywhere a CFO can see.
I will put the stance up front so you can argue with it early. The bottleneck in most of your projects was never the work. It was the deadline you set, and AI just exposed how much of every timeline was padding. A tool that makes execution nearly free does not make an organization faster on its own. Without a real date and someone to answer to, the weeks you save turn into spin: another revision, another alignment meeting, a third option nobody asked for. So set the aggressive deadline anyway, run people at about 80 percent so there is room to absorb the work, and spend what comes back on more reps and better judgment rather than more comfort.
Parkinson wrote it as a joke, and the joke is about organizations
The line gets passed around as productivity advice, which is funny, because C. Northcote Parkinson published it as satire in The Economist in November 1955 (opens in new tab). His opening sentence is the entire law: "It is a commonplace observation that work expands so as to fill the time available for its completion." Then he gives the example that makes it stick. An elderly lady of leisure spends a full day writing and posting one postcard. An hour finding the card, another hunting for her spectacles, half an hour on the address, an hour and a quarter composing it, twenty minutes deciding about an umbrella. His summary: "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."
Read the rest and it stops being about one lady. The essay is about institutions. Parkinson’s second factor is that officials make work for each other, and his claim is that the number of people and the amount of work to be done are not related to each other at all. Work grows to match the room you gave it, and then the room looks justified. Seventy years later you can watch the same thing happen on a sprint board. A two-day task scheduled across two weeks takes two weeks, and every person involved can show you exactly where the time went.
What four weeks of padding actually was
I have written that execution is cheap now and ideas are expensive, and the concrete version of it is that work which used to take about four weeks now takes under an hour to get to something real enough to react to. I am not going to re-argue that piece here. What matters for this one is the uncomfortable half of it. If the thing that took four weeks now takes forty minutes, the four weeks were never a measurement of the work. They were a measurement of the calendar around the work.
Take one of those old estimates apart and most of it is queue. Two days of making. A week waiting on a review. Four days for a feedback round that arrives as three comments. A handoff that sits because the person who owns it is at a planning offsite. Then the part Parkinson would recognize: the gaps get filled, because a person with ten days to produce a thing that takes two will produce a more elaborate thing. Not a better thing. A more elaborate one, with a longer deck in front of it.
If the work that took four weeks now takes forty minutes, the four weeks were never a measurement of the work.
AI shrank the making, which was the smallest slice. It did not shrink the queue. So the saved time lands in a calendar still built around waiting and quietly dissolves there. That is how a team gets genuinely faster at every individual task and ships at exactly the same rate as last year. The cycle time you report to a board is made of dates, not keystrokes.
Without a real deadline, the time you saved becomes spin
This is a deadline problem rather than a willpower problem, and there is good experimental evidence for that. Dan Ariely and Klaus Wertenbroch published Procrastination, Deadlines, and Performance (opens in new tab) in Psychological Science in 2002. In one study, 99 professionals in an executive-education course each had to write three papers. One section was given fixed, evenly spaced deadlines. The other section chose its own. The imposed-deadline section scored higher on the papers, 88.76 against 85.67, and on the final project, which was due the same day for everyone, the gap was wider: 86 against 77.
They ran a cleaner version too. Sixty people were paid ten cents per error found, proofreading three ten-page texts with 100 planted mistakes in each, with a dollar-a-day penalty for being late. Three conditions: evenly spaced deadlines, self-chosen deadlines, or everything due at the end of three weeks. Evenly spaced external deadlines produced the most errors caught, the least delay and the highest earnings. Self-chosen came second. Everything due at the end finished last on all three measures.
The finding that should change how you plan is near the bottom of that paper. They asked participants how they felt about the task, and the ratings ran exactly opposite to the results. The evenly spaced group, the one that did the best work, liked it the least, 22.1 on a 100-point scale. The end-deadline group, the one that performed worst, liked it the most at 37.9. The arrangement that produces the best work feels the worst from inside it, and the one that feels most generous produces the least. Every leader who has ever said let us give the team some breathing room on this has just run the third condition.
Under-promise and over-deliver is half of a good idea
Here is where I part with advice most people treat as settled. Under-promise and over-deliver has two halves and only one of them holds up. Over-deliver, absolutely. Ship past the scope, catch the thing nobody asked you to catch, hand back something better than what was agreed. Under-promise is the other thing entirely. It is Parkinson’s Law written into a commitment on purpose, and it is the most common place padding gets institutionalized, because it gets rewarded. You quote six weeks for three weeks of work, deliver in five, and get thanked for it.
What you bought with that thank-you is a team that now believes three-week work takes six weeks, a roadmap built on the inflated number, and a date that carries no information. Do it twice and the padding becomes the planning baseline. Nobody can find it afterward, including you, because it is not a line item anywhere. It is distributed into every estimate as the ordinary way things get sized.
My version is simpler. Promise the aggressive date, say it out loud to someone who will notice if you miss, and put the buffer somewhere you can see it. Buffer belongs at the capacity level, as unassigned hours, not hidden inside each estimate. One is a reserve you can point to, defend and spend deliberately. The other is a number that compounds into a culture.
The best work I have shipped had a date I could not move. At Enverus I designed a Deal Finder for NAPE, the largest show in oil and gas, and led the agency that built it. A buyer entered their budget and what they were after, it matched them to the vendors on that floor selling exactly that, then mapped where to find them. It surfaced millions in deals on the show floor. The show opened on a day printed on a sign months in advance. There was no version of that project where we took another two weeks, and the absence of that option is the reason it got built the way it did. Every scope argument lasted about four minutes, because the date settled it.
Eighty percent all the time beats 100 percent for 20 percent of the time
Aggressive dates and open capacity sound like opposites. They are the same move. A tight date only holds if there is somewhere for the surprise to go. I run this as arithmetic on a seven-person design team at a multi-billion-dollar apparel platform, a team I built from one designer over two years. About 32 of each person’s 40 hours get planned for project work. The other eight absorb meetings, the ask that arrives Tuesday and is needed Thursday, and the hours it takes to learn a tool that did not exist last quarter. A dashboard flags anyone running over. I made the full case for that in planning a design team at 80 percent on purpose, so here I will only add the part that belongs to this argument.
Book people to the last hour and your aggressive date becomes an aspirational one the first time a review slips, because there is no room left in the week to absorb it. The reserve is what makes a tight date credible instead of theatrical. Cut the timeline and the capacity at the same time and you have not been disciplined, you have just moved the overrun onto someone’s evening.
The framing I would put in front of any executive deciding how hard to run a team: 80 percent capacity all the time beats 100 percent for 20 percent of the time. A team planned at 80 percent hits its dates every quarter. A team planned to the last hour produces something spectacular twice a year and misses in between, and organizations remember the misses with far more precision than they remember the brilliance. Reliability is what buys you the right to be pointed at the hard problems.
Spend what you get back on reps, not on comfort
The reason this is urgent rather than theoretical is that people are terrible at judging whether AI sped them up. METR ran a randomized controlled trial in early 2025 with 16 experienced open-source developers working 246 real issues in repositories they had maintained for years. Beforehand, the developers forecast that AI tools would cut their completion time by 24 percent. With the tools they took 19 percent longer (opens in new tab). Afterward, having lived through the slowdown, they still estimated that AI had sped them up by 20 percent.
I want to be careful about what that result does and does not cover. Sixteen developers on mature codebases they know intimately is close to the hardest case for a model, and it is not the same as a designer building a landing page or a team standing up something new. The number I would not wave away is the second one. A 19 percent slowdown that feels like a 20 percent speedup is the entire subject of this essay. Speed nobody measures is a feeling, and the feeling runs wrong in the flattering direction.
Speed that nobody measures is a feeling, and the feeling runs wrong in the flattering direction.
So measure it against a date, and then spend the recovered hours on reps instead of slack. A research vendor once quoted us a per-seat yearly fee for the one feature we needed, bundled with a dozen we did not, which across a platform with more than a hundred people came to a six-figure bill every year. I built and tested that one feature the same afternoon the proposal arrived. That afternoon only existed because it was planned to exist, and it only got used because there was a date on the proposal. Open time with no deadline attached to it is not leverage, it is just a lighter week.
Reps are also the only way to stay useful while the ground moves. On my team everyone uses AI in their work and everyone shows that work every week, finished or not. The value in this field moved off producing the artifact and onto knowing which artifact was worth producing, which I argued in the gap between good and great is not skill anymore. Judgment is built by shipping things and watching what happens, so an hour you save is only worth something if it turns into another attempt.
Who each path is for
If you run the team, do not announce a philosophy. Pick the next project on the board, cut its timeline close to in half, name the new date in front of people who will notice, protect the 20 percent, and watch one full cycle. You will learn more in six weeks than any tooling audit will tell you, and the thing you are testing is not whether the team can work faster. It is whether the old number was ever real.
If you are the executive writing the checks, change the question you ask in review. Stop asking whether the team is using AI, because the answer is always yes and it means nothing. Ask what shipped, by what date, against the same quarter last year, and ask for planned hours against calendar hours. If adoption is high and cycle time is flat, you do not have a tooling problem. You have a planning problem wearing a tooling problem’s clothes, and buying more licenses makes it worse by giving everyone a reason to believe it is being handled.
And if the real gap is that nobody in the building owns how work gets scoped, dated and staffed, no purchase fixes that and neither will another pilot. That is an operating model, and it is cheaper to borrow one than to build one from scratch. It is the work I do as a fractional head of design: setting the dates, putting the capacity reserve in writing, and being the person on the hook when a date is missed. Someone has to answer for the calendar, and a tool will never volunteer.
When a long timeline is still the right call
There are real cases where compressing the date is the wrong move, and I would rather name them than pretend the rule is universal. The first is when being wrong is expensive. Hardware, regulated work, anything where a bad release costs more than a late one. Compress the loop before the commitment, not the commitment itself. Prototype in an afternoon, then take the time you need on the thing that ships.
The second is discovery that runs on calendar time instead of work time. Some of the research threads my team carries run twelve to eighteen months before a customer sees anything, because you are waiting on a season, a budget cycle, or enough real usage to mean something. No tool makes a quarter pass faster. Compressing those dates just produces a confident answer built on two weeks of data.
The third is a team already planned at 125 percent. Tightening dates on an overloaded team is not discipline, it is attrition with a project plan attached. Fix the capacity first, run a clean cycle, then get aggressive. And the fourth is a team with no track record yet. A new group should hit a conservative date first and earn the right to promise a hard one, because an aggressive date from someone who has never hit one is not a commitment, it is a wish said loudly.
Here is the test to run in your next planning meeting. It takes about four minutes. Pick the next milestone on the board and ask the person who owns it one question: if this had to ship in half the time, what would come out? Not could you, what would come out. If the answer is a list of real tradeoffs, the estimate is sound and you should leave it alone. If the answer is nothing, it would just be tighter, you have found your padding, and no tool you buy this year is going to find it for you. The four weeks already became forty minutes. The only number left to change is the one you wrote on the calendar.