This is a practical playbook for beating Parkinson’s Law in software engineering. You’ll see how unconstrained time, scope, and capacity quietly slow teams, and how simple, visible constraints (decision-dated RFCs, PR size caps, WIP limits, six-week “appetites,” async status) turn that drag into speed.
Everything is based on practice and real cases (Google’s large-scale migrations, Basecamp’s Shape Up cycles, and Dropbox’s Virtual First). To make it actionable, you’ll get:
- A manager’s checklist
- The core metrics to watch
- A handful of one-week experiments you can run immediately
- And a short glossary and FAQs to help you roll it out.
TL;DR:
- Parkinson’s Law causes work to expand to fill time, scope, and capacity; leaders address this by designing visible constraints.
- Real cases (Google migrations, Basecamp’s six-week “appetites,” Dropbox’s async culture) show how deadlines, ownership, and timeboxes shrink big work.
- Your playbook: decision-dated RFCs, time-boxed discovery, PR size caps + tiny-PR fast lane, WIP limits, FinOps guardrails, and async status.
- Track outcomes, not opinions: DORA metrics, PR time-to-merge, WIP & rollover, and unit cost.
- Includes a manager’s checklist, one-week experiments, glossary, and FAQs to roll this out immediately.
Table of Contents
Case Studies
Parkinson’s Law says, “work expands to fill the time available.” In 2010, however, Google and a few others proved that the inverse can also be true. You just need to design the right constraints so that even behemoth changes shrink to fit them.
Case Study #1 – Google’s “Impossible” Migrations
In Google’s case, storage SRE leadership set an audacious mandate: migrate everything from the original Google File System (GFS) to its successor, Colossus, by the end of 2011. It was the largest data migration in company history, run like an air-traffic operation with named owners, dashboards, and escalation paths.
Too ambitious?
Not necessarily. You see, by treating the migration as an Infrastructure Change Management (ICM) program, Google contained the sprawl that typically bogs down big rewrites and forced the work to fit the box. To make it happen, they set explicit decision dates, a single source of truth, and “Assign-o-Matic” ownership mapping.
It took about two years end-to-end, but the work shrunk to the constraints: decisions happened on time, stragglers were visible, and coordination load moved from “heroics” to a repeatable cadence.
In case you are unfamiliar with it, Assign-o-Matic is a Google internal tool used by the Infrastructure Change Management (ICM) team to automatically map each production group/service to the best human point-of-contact (owner). It exists because many services don’t clearly list a product or a person, so ICM uses heuristics to identify the right owner quickly. You can only imagine how much of the manual hunt during large migrations and deprecations it saves.
Eight years later, in August 2018, that same playbook kept another tidal shift from expanding endlessly. At that time, Google formally deprecated MapReduce in favor of Flume and instrumented the migration like a product launch.
- By the end of 2018, 50% of 30-day active build targets had moved.
- By September 2019, over 45% of the remaining active targets were off MapReduce.
- >99% of C++/Java pipelines were on Flume.
This progress had been made visible and inevitable only through strict but realistic deadlines, tooling, and programmatic tracking rather than open-ended “we’ll get to it” estimates.
Case Study #2 – Basecamp’s 6-Week Cycles
While Google showcased constraint at hyperscale, product orgs made the same bet in their day-to-day cadence. For instance, Basecamp’s Shape Up (published July 23, 2019) codified six-week fixed cycles and an explicit appetite (“what will we build in six weeks?”). It was a direct antidote to Parkinson’s Law:
- Scope was shaped to fit the timebox, not the other way around.
- Teams shipped meaningful slices without letting “nice-to-haves” swell to fill the calendar.
And where meetings were quietly stealing time, Dropbox attacked the problem culturally.
Case Study #3 – Dropbox’s Culture Shift
In April 2021, Dropbox rolled out Virtual First company-wide with an async-by-default norm (reserving meetings for the “3 D’s”: discussion, debate, decision). It eliminated the automatic one-hour calendar grab and made progress measurable through written updates instead of recurring status calls.
The same is true in a different arena: set hard edges for attention and coordination, and work stops ballooning to fill every slot.
Key Takeaway From These 3 Case Studies
Google’s ICM migrations, Basecamp’s six-week cycles, and Dropbox’s Virtual First show how leaders beat Parkinson’s Law without theatrics. They make constraints visible, make progress understandable, and let the system, not heroics, create speed.
Now, before we give you a practical checklist, you ought to familiarize yourself with the nuances of the subtle mechanisms of Parkinson’s Law that make your job harder if left unattended.
The first thing is to identify it in your daily processes.
Where Does Parkinson’s Law Show Up in Engineering
- Projects & sprints. If a story gets a whole sprint, it’ll often take the whole sprint. Scope quietly grows to match the time budget.
- PR reviews. Large, open-ended pull requests linger; review time expands to the SLA and then some.
- Architecture & RFCs. “We’re still exploring,” continues until a date forces a decision, often after energy has faded.
- Cloud & platforms. Elastic compute/storage makes “temporary” environments permanent and services over-provisioned “just in case.”
- Meetings & rituals. Standups stretch to 30 minutes because the calendar says 30 minutes. Governance forums take the entire hour, whether or not there’s a decision to make.
- Backlogs. Tickets multiply to fill attention; zombie items survive for months and drain context.
Why Tech Amplifies Parkinson’s Law
- Elastic resources remove natural limits. With cloud, backlogs, and calendars, there’s rarely a hard stop.
- Risk management encourages padding. Teams add a buffer to avoid missing dates or denting credibility.
- Ambiguous “done.” Without a crisp definition of done, “nice to have” keeps sneaking in.
- Coordination overhead. More stakeholders → more time to align → more work to keep everyone busy while they wait.
9 Levers That Shrink Work
(Each lever explains why it beats Parkinson’s Law. For exact rules, see the corresponding items in the Checklist [CL].)
- Time-box discovery. Short, fixed windows force early clarity; decisions don’t drift. (See CL #1.)
- Decision-dated RFCs. Deadlines flip inertia: silence defaults to ship. (See CL #2.)
- Definition of Done. Clear finish lines stop “nice-to-have” scope from swelling. (See CL #3.)
- Small batches (PR caps + tiny-PR lane). Smaller changes review faster and fail safer. (See CL #5–6.)
- WIP limits. Less juggling → faster flow; work can’t expand across many plates. (See CL #7.)
- Short-lived branches / trunk-based dev. Tight cycles kill “just one more change” creep. (See CL #8.)
- FinOps guardrails. TTLs, right-sizing, and unit cost visibility remove “infinite resource” slack. (See CL #9–11.)
- Meetings by design / async-first status. Raise the bar for live time so meetings don’t spill over the slot. (See CL #12–13.)
- Backlog hygiene (graveyard + Top-5). Constrain attention; zombies can’t soak up time. (See CL #14–15.)
Use These Metrics To Reveal Bloat
| Metric | How to read it | Action if off-target |
|---|---|---|
| Lead time for changes (DORA) | Rising for 2–3 cycles without quality gains ⇒ batch size or queues are growing. | Enforce PR caps; tighten WIP limits; add a tiny-PR fast lane. |
| Deployment frequency (DORA) | Falling while backlog grows ⇒ work is pooling in review or QA. | Split work into smaller slices; add release trains; remove manual gates where safe. |
| Change failure rate (DORA) | > ~15% on steady teams suggests risky, oversized changes. | Reduce batch size; expand automated tests and progressive delivery (flags, canaries). |
| MTTR (DORA) | > 24h median indicates slow detection/rollback. | Lower WIP caps; reshape work to fixed appetites; strengthen Definition of Done. |
| Median PR time-to-merge | > 24h and trending up ⇒ review queues or PR size creeping up. | Cap PR size (see Checklist); set a same-day SLA for tiny PRs; publish reviewer rota. |
| Time to first review | > 4h during business hours ⇒ context switching and unclear ownership. | Introduce reviewer-of-the-day; Slack bot pings; prioritize tiny PRs. |
| PR size distribution | < 50% of PRs ≤ ~300 LOC ⇒ batches likely too large. | Coach splitting patterns; enforce soft cap in CI; use feature flags for incremental delivery. |
| Rollover ratio | > 20% items spill to next sprint ⇒ scope/WIP too high or estimates padding to timebox. | Lower WIP caps; reshape work to fixed appetites; strengthen the Definition of Done. |
| WIP per engineer/team | > 2–3 concurrent items per engineer ⇒ context switching and invisible queues. | Set visible WIP limits; block new starts until a slot frees. |
| Unit cost (cost per X) | Flat or rising cost-per-request/user/job while volume grows ⇒ idle or over-provisioning. | Right-size autoscaling bounds; enforce TTLs for ephemeral envs; hunt idle hotspots. |
| CPU utilization (p95) — steady services | Chronically < ~20% ⇒ capacity is sitting idle. | Lower requests/limits; adjust autoscaling targets; consolidate workloads. |
| Meeting load | > 10–12 hours/engineer/week or < 70% meetings with agenda/pre-read. | Convert status to async; enforce 25/45-min defaults; kill or redesign poor performers. |
| Backlog age | Growing count of items > 90 days untouched ⇒ attention is unfocused. | Lower WIP caps; reshape work to fixed appetites; strengthen the Definition of Done. |
Treat these as smoke alarms. When one trips, tighten the constraint closest to the signal (e.g., PR cap, WIP limit, environment TTLs).
One-Week Experiments (Pilot)
(Quick experiments that reference the Checklist. Define a start date, owner, and where you’ll post results.)
| Experiment | Action(s) | Success |
|---|---|---|
| Decision-dated RFCs (see CL #2) | Run for one week on all new RFCs. | ≥ 1 hour/engineer/week calendar time reclaimed and ≥ 80% meetings have an agenda + pre-read. |
| PR caps + tiny-PR fast lane (see CL #5–6) | Pilot on one repo. | Median time-to-merge ↓ 30% and % of PRs ≤ 300 LOC ↑ by 20 pp. |
| Time-boxed discovery (see CL #1) | Apply to all new spikes. | ≥ 80% deliver a 1-page brief and a decision by Friday. |
| Meeting diet → async (see CL #12–13) | Convert one recurring status meeting to an async update. | ≥ 1 hour/engineer/week calendar time reclaimed and ≥ 80% meetings have agenda + pre-read. |
| FinOps guardrails on one service (see CL #9–11) | Enable TTLs and right-sizing; publish unit cost-per-X on Friday. | Idle resurfaces drop (e.g., p95 CPU ↑ toward target) and cost-per-X appears in the weekly update with ≤ 24h spike annotations. |
Tip: Measure before/after. Keep what moves a metric; retire what doesn’t.
Quick Glossary For Your Team
- PR – Pull Request: a proposed code change submitted for review/merge.
- RFC – Request for Comments: a design/decision proposal used to gather feedback and drive alignment.
- WIP – Work in Progress: the tasks currently being worked on; limiting WIP reduces context switching and cycle time.
- LOC – Lines of Code: a simple count of code lines; useful for rough sizing but noisy as a productivity metric.
In Conclusion
Parkinson’s Law isn’t a character flaw; it’s a systems property. When time, scope, and resources are unconstrained, work expands. In tech, particularly, this effect is supercharged by elastic cloud resources, infinite backlogs, and calendars that never push back. Left alone, discovery drifts, pull requests bloat, meetings grow to their time slot, and costs creep upward with little to show for it.
None of this is about lazy teams; it’s what happens when systems have slack with no guiding constraints. Your job as a technology leader is to design constraints that focus effort (time, scope, and cost) so teams move faster with less waste.
The antidote is, therefore, purposeful constraints:
- Time boxes
- Decision dates
- DoD
- WIP limits
- PR caps
- Cost guardrails.
Make constraints visible and automate enforcement where possible (branch policies, CI checks, TTLs). Then measure flow so the team sees the payoff in shorter lead times, faster reviews, lower idle cost, and more calm.
Checklist for Engineering Managers (Canonical)
(This is the authoritative list for rules, numbers, and thresholds.)
Download a printable version of the checklist below.
- #1 Time-boxed discovery
- Spikes capped at 3–5 days
- Deliver a 1-page brief (context, options with trade-offs, recommendation, next step)
- #2 Decision-dated RFCs
- Every RFC has a Decision Date
- Default approve the simplest viable option if no blocker by that date.
- #3 Definition of Done (DoD)
- Ship a minimal complete slice
- Move polish/hardening to follow-ups
- #4 Code review standards
- Reviews focus on correctness and risk, not nitpicks
- Comments contain examples and suggested diffs
- #5 PR size cap
- Soft cap ≈300 LOC changed
- CI/bot flags oversize PRs and suggests splitting
- #6 Tiny-PR fast lane
- Same-day (2–4h) SLA for small, low-risk PRs
- Priority review rota published weekly
- #7 WIP limits
- Visible WIP caps per engineer and per team
- Dashboard shows current WIP and rollover ratio
- #8 Branching model
- Trunk-based or short-lived branches
- Median branch age stays low
- Daily merges expected
- #9 Ephemeral environments
- TTL by default for dev/test
- Expirations auto-notify
- Extensions require reason + new TTL
- #10 Right-sizing guardrails
- Define autoscaling min/max and CPU/memory ceilings per service
- Alert on chronic under-utilization (e.g., p95 CPU <20% over 7 days)
- #11 Unit-economics scoreboard
- Publish cost-per-X (per request/user/job) weekly
- Annotate any cost spike within 24h
- #12 Meeting standards
- Default to 25/45-minute slots
- Agenda + pre-read required 24h prior
- End early by design
- #13 Async status by default
- Replace at least one recurring status meeting with a written template (owner, goals, risks, blockers, next decision, links).
- #14 Backlog graveyard policy
- Items untouched for 60–90 days auto-close unless a sponsor revives with date + impact.
- #15 Top-5 in focus
- Team actively schedules no more than five items at once
- Everything else is explicitly “later.”
Pick the two that would most change behavior in your context (often PR caps + Decision Dates), implement them this week, and measure the effect.
Remember, constraints aren’t about saying “no;” they’re how you create the conditions for your team to deliver “yes” faster and with less drama.
FAQ
How do I introduce constraints without slowing the team down?
Start with one or two visible, low-friction constraints and tie them to a metric you already track:
1. Pick a Decision Date policy for RFCs and a PR size cap.
2. Announce the “why,” the rule, the owner, and the metric you’ll watch (e.g., median PR time-to-merge).
3. Run it as a 6-week experiment; keep what moves the metric, retire what doesn’t.
4. Automate enforcement (branch protection, CI checks, templates) so it feels like tooling, not policing.
What’s a good PR size cap, and how do we enforce it?
Aim for ~300 lines changed (soft cap) with a fast lane for tiny PRs:
1. Add a bot/CI check that flags >300 LOC and suggests splitting.
2. Set a same-day (2–4h) SLA for tiny PRs to reward small batches.
3. Track: PR size distribution, time-to-first-review, time-to-merge.
4. Coach patterns that enable small PRs: feature flags, trunk-based dev, scoped commits.
How do we stop discovery from ballooning?
Time-box and require a lightweight artifact:
1. Cap spikes at 3–5 days.
2. Mandate a 1-page brief: context, options (with trade-offs), recommendation, next step.
3. Define exit criteria up front (e.g., “prove X is feasible or recommend Y”).
4. Decide on a schedule (e.g., by Friday noon): ship, defer, or drop.
What should our weekly scoreboard include to know that constraints are working?
Use a short, outcome-focused set so it’s read and acted on:
1. Flow & quality: Lead time for changes, deployment frequency, change failure rate, MTTR (the “four keys”).
2. Code review: Median time-to-merge, time-to-first-review, PR size distribution.
3. Focus: WIP per engineer/team, rollover ratio (>20% is a smell).
4. Cost & capacity: Unit cost (cost per request/user/job), p95 CPU for steady-state services (watch for chronic under-utilization).
5. Meetings: Hours/engineer/week; % with agenda + pre-read.
How do we cut meeting bloat without losing alignment?
Shift status to async and raise the bar for live time:
1. Default to 25/45-minute blocks; end early by design.
2. Require agenda + pre-read; cancel if missing 24h before.
3. Reserve meetings for the 3 D’s: discussion, debate, decision.
4. Move status to a written template (owner, goals, risks, blockers, next decisions) in a shared doc or channel.
5. Review meeting metrics monthly; kill or redesign the worst offenders.
