"Work expands so as to fill the time available for its completion." This single sentence, written by Cyril Northcote Parkinson in 1955, explains why your two-week sprint becomes a two-month project, why startups slow down as they grow, and why that "quick update" to your app takes six months. It's called Parkinson's Law, and once you see it, you can't unsee it.

The Law in Action

When Instagram launched in 2010, they built the entire app in 8 weeks. Two guys, one app, 8 weeks. They had no choice—they were burning through savings and needed to ship something.

Compare that to any feature update at Meta today. A simple change to the like button would involve months of meetings, design reviews, A/B testing frameworks, accessibility reviews, internationalization considerations, and stakeholder approvals. The same company, infinitely more resources, but somehow everything takes longer.

This isn't incompetence. It's Parkinson's Law. When you have 8 weeks and no money, you build only what matters. When you have 8 months and unlimited budget, you build everything you can think of—and then some.

The MVP That Wasn't

Every startup founder knows this story. You decide to build an MVP—a true minimum viable product. "It'll take two weeks," you say. "Just the core features."

Week one: You add user authentication. But wait, you should probably add social login too. And password recovery. And two-factor authentication for security.

Week two: The core feature works, but it could be better. Let's add some animations. And a dark mode. And keyboard shortcuts for power users.

Week three: You realize you need analytics to understand user behavior. And error tracking. And performance monitoring.

Week eight: You're still not launched. The "minimum" viable product has become a maximum viable product. Why? Because you had time to fill, and work expanded to fill it.

The Slack Story

When Slack was first built, it was an internal tool for a gaming company called Tiny Speck. They built the first version in a few weeks because they needed it to communicate while building their game. It was rough, basic, and solved exactly one problem: their team needed to talk to each other.

If they had started with a two-year roadmap and a team of 50, Slack would have launched with video calls, AI assistants, workflow automation, and fifteen other features that nobody asked for. It probably would have failed.

Instead, they shipped fast, learned what people actually wanted, and then built that. The constraint of time forced focus.

The Series A Slowdown

Watch what happens to a startup after they raise their Series A:

Before funding: Ship weekly. Everyone codes. Decisions happen in minutes. The entire product roadmap fits on a napkin.

After funding: Ship quarterly. Half the team is in meetings. Decisions require "alignment sessions." The product roadmap is a 47-page document that nobody reads.

They didn't get worse at building. They got more time. And with more time came more process, more features, more complexity. Parkinson's Law kicked in.

Stripe famously fought this by maintaining "founder mode" long after their Series A. They kept shipping like they were still two brothers in a apartment. They gave themselves artificial deadlines. They refused to let work expand to fill the available time.

The Two-Pizza Rule

Amazon's Jeff Bezos had a rule: no team should be larger than what two pizzas can feed. This wasn't about saving money on food. It was about fighting Parkinson's Law.

A two-pizza team doesn't have time for bloat. They can't afford to let work expand because there aren't enough people to do the expanded work. They're forced to focus on what matters.

When Amazon wanted to build AWS, they didn't create a 200-person division with a three-year plan. They started with a small team and an aggressive deadline. EC2 launched with basically one feature: virtual servers. That's it. No fancy orchestration, no managed services, no AI integration. Just servers you could rent by the hour.

If they had given themselves five years and 500 people, AWS would probably still be in beta.

WhatsApp: 55 Engineers, 900 Million Users

WhatsApp served 900 million users with just 55 engineers. How? They had no time for anything except keeping the service running and fast.

No stories feature (at first). No voice calls (for years). No business accounts. No payments. No marketplace. No dating features. No algorithm. Just messaging that worked.

Meanwhile, Google had thousands of engineers working on messaging apps. They built Hangouts, Allo, Duo, Messages, Chat, Meet, and probably five others I'm forgetting. Each project had years of runway and massive teams. None of them won.

WhatsApp won because they didn't have time to overthink it. Parkinson's Law never had a chance to kick in.

Fighting the Law

You can't eliminate Parkinson's Law, but you can fight it:

Set artificial deadlines. When Shopify builds new features, they often use "hack days"—ship something in 24 hours. Not perfect, just shipped. These artificial constraints prevent work from expanding.

Stay small on purpose. Linear, the project management startup, has stayed intentionally small despite massive growth. Fewer people means less time for work to expand into.

Ship before you're ready. GitHub's philosophy was "ship to learn." They'd rather ship something 70% done today than 100% done next month. You can always iterate, but you can't recover lost time.

Kill features aggressively. Basecamp regularly removes features that aren't pulling their weight. Less surface area means less work expansion.

Time-box everything. When Figma was starting out, they gave themselves one week sprints. Not two weeks, not a month. One week. If it couldn't ship in a week, it was too big.

What Nobody Talks About

Most of the work we do is Parkinson's Law in action. The six-month project that could have been done in six weeks. The two-hour meeting that could have been a five-minute conversation. The 100-person team doing what 10 people could do better.

We tell ourselves we're being thorough. We're considering edge cases. We're building for scale. But really, we're just filling time. We have a month, so we take a month. We have a budget for 50 people, so we hire 50 people.

Why Startups Beat Giants

Understanding Parkinson's Law explains why small startups can compete with huge companies. While your competitor is on month six of their "two-month project," you can ship in two weeks. While they're having meetings about meetings, you're talking to customers. While they're building features nobody wants, you're learning what people actually need.

This is why startups can beat giants. Not because they're smarter or work harder, but because they don't have time for Parkinson's Law. They have to ship or die.

Making It Work

Next time you're planning a project, cut the timeline in half. Then cut it in half again. You'll be amazed at what becomes "not essential" when you don't have time for it.

Next time you're hiring, ask: "What if we couldn't hire anyone?" You'll be surprised how often the answer is "we'd figure it out."

Next time you're in a meeting planning another meeting, remember: work expands to fill the time available. The question is, how much time are you going to make available?

The startups that win aren't the ones with the most time or the most resources. They're the ones that don't let work expand to fill them.

Ship faster. Stay smaller. Give yourself less time.

Parkinson's Law is undefeated, but you don't have to play its game.