Work Expands to Fill the Time You Give It
So give it less.
U-Flow had grown to 25 employees. We had a specialty product — $5 to make, $100 to sell, solving a $1,000 problem. Good margins. A niche market that wasn't crowded.
What we didn't have was a quality system. Positions had evolved organically. I was the founder and president. My partner did the books. Everyone else ended up doing what they were good at, which was a decent system until it wasn't.
Then a new customer returned an entire shipment. Defective product, all of it. Big dollars lost. Bigger customer lost.
We had a quality control problem and needed to get it fixed fast.
We decided to implement ISO 9001 and get certified. I'd recently hired a crack design engineer who'd immigrated from Yugoslavia — he knew how to design product but not how to run a company. His wife, however, knew everything about quality systems and SOPs. So I hired her too.
We gave ourselves three months.
Three months sounds reasonable. It wasn't. Progress was slow. We were learning, writing SOPs, building workflows — but the actual completion work felt like wading through sand. Things moved, nothing finished.
Two weeks before the audit, my accounting manager came to me and said we needed to reschedule. "Phil, there's no way we can get this done in time."
I said no.
I gathered the entire company. Here's the list of what needs to be done in the next 14 days. Right now, each of you pick items from this list and hold yourself personally accountable for getting them done. Mia — the QC manager — owned the schedule and the Gantt chart. Twice-daily check-ins. Everyone worked twelve-hour days minimum.
Two weeks later, we passed the audit with only a few minor suggestions.
Here's what I understood after the fact: Cyril Northcote Parkinson figured this out in 1955. "Work expands so as to fill the time available for its completion." Give a team three months, and they'll find three months' worth of ways to fill it. Give the same team fourteen days, and they'll find a way to get three months of work done in fourteen days.
That's not a management theory. That's what happened in my shop.
Software engineering teams have built this into a formal system. Karol Wójciszko at Engineering Leader's Playbook adapts it as Critical Chain Project Management: cut task estimates in half, pool the saved time into a shared buffer, and track the buffer-to-progress ratio weekly. His teams finish projects early — not just "on time." The mechanism is the same as what we stumbled into on our shop floor: tight targets create focus. Loose targets create drift.
The obvious objection: twelve-hour days and twice-daily check-ins sounds like burning your team out. And you'd be right if you ran that pace indefinitely.
But there's a distinction. Sprint hard, then celebrate. Set the impossible deadline, hit it, then give the team room to breathe. The exhaustion is temporary. The system you built is permanent.
The mistake most operators make isn't being too hard on their teams. It's being too loose with timelines and calling it compassion. A generous deadline feels kind in the moment. What it actually does is give the work space to get soft.
My CFO came to me two weeks out and said we couldn't make it. That was the reasonable position. And if I'd listened to it, we'd have lost another cycle, another customer, another quarter without a system in place.
After the certification, we finally had real numbers: supplier defect rates, welding defect rates, labeling accuracy. Defects went to near-zero — not because people cared more, but because we had a system to catch them.
https://themarginbuilders.substack.com/publish/post/206856011
Last week I wrote about doing one action at a time. I still stand by that. But there's a precondition: the action has to have a hard deadline, and one person has to personally own it.
Here's what I'd add:
Compress the timeline. Whatever feels reasonable, cut it. Your team will surprise you. They surprised me.
Make ownership visible. Not "the team is responsible." A specific person holds each item and reports on it twice a day. The check-in frequency sounds intense. It's also what keeps things from silently drifting.
Build the measurement system at the same time. The ISO sprint and the quality metrics weren't two separate projects. The deadline drove the system build, and the system build produced the numbers. Run them together.
Don't give up. The CFO's instinct was to delay. That's usually the instinct. The audit was the constraint that made everything real.
The mountain looks unclimbable until someone tells you the rope team leaves in two weeks.
Deadlines aren't cruel. They're the only tool that makes time visible.
One next step: Find one project on your list that's been moving slowly. Pick a deadline that feels too short. Put one person's name on it. Schedule a check-in for this week.
Further reading:
- The Lean Startup — Eric Ries (Crown Business, 2011). The Build-Measure-Learn loop is the sprint model applied to product — the same logic as tight deadlines applied to how fast you find out what's working.
- Extreme Ownership — Jocko Willink & Leif Babin (St. Martin's Press, 2015). The "failure is not an option" posture I took with my team has a name. This book explains why personal accountability — not team accountability — is what actually holds.
- The Score Takes Care of Itself — Bill Walsh (Portfolio, 2009). Walsh never managed by the scoreboard. He managed the process that would eventually produce the result. ISO certification is the same logic: build the system, and the quality numbers follow.