This post first appeared on my personal blog, The Human Side of Tech.
Great engineering leadership isn’t measured by output squeezed from teams, but by value unlocked through the right conditions. After years guiding engineering teams through challenges, I’ve come to re-evaluate some classic management principles through a modern engineering lens.
One concept I frequently encounter in discussions about productivity is Parkinson’s Law. This seemingly simple principle has profound implications for how we lead engineering teams—but not necessarily in the way many think.
In this article, I revisit Parkinson’s Law, unpack its misapplications, and offer a leadership playbook for navigating what I call the “perfection-pressure spectrum.”
What I've discovered might surprise you: the real challenge is giving engineers permission to stop instead of getting them to work harder.
As we’ll see, in engineering contexts, work expands not through bureaucratic inefficiency or laziness, but through unchecked perfectionism—a commitment to craft that, paradoxically, can work against delivering value. And it explains why this traditional “productivity hacks” backfire: they solve for idleness when the real challenge is excellence run wild.
I first encountered Parkinson’s Law while reading Tom DeMarco and Timothy Lister's influential book Peopleware.1 The law, coined by historian Cyril Northcote Parkinson in 1955, states that “work expands to fill the time available for its completion.”2
It's like making a sandwich. Give yourself 2 minutes, and it's bread-meat-cheese-done. Give yourself 30 minutes, and suddenly you're cutting the tomatoes into perfect circles, toasting the bread just right, and arranging everything in layers. Same hunger, same basic sandwich, just a lot more time spent on it.
Parkinson observed this, not in the kitchen, but in administrative contexts, particularly noting how British Civil Service bureaucracy grew regardless of the actual workload. He wasn't speaking about knowledge workers solving complex problems—he was describing bureaucratic inefficiency.
As DeMarco and Lister point out in Peopleware, this context matters:
“Parkinson’s Law almost certainly doesn’t apply to your people.”
Their skepticism makes sense. Parkinson based his observations on administrative tasks with clear endpoints. It’s not the complex, creative problem-solving that characterises modern software engineering. And yet, something about the law still rings true in our world.
The research around time estimates in engineering projects tells an interesting story. The 2013 edition of Peopleware references a particularly compelling 1985 study by Lawrence & Jeffery from the University of New South Wales that examined how different scheduling approaches affect team productivity.3
The study showed that teams without deadlines achieved productivity significantly higher—on the order of 40-50% better—than even the best of the deadline-bound groups. This wasn’t just slightly better; it was dramatically better.
As DeMarco and Lister quote metrics expert Capers Jones: “When the schedule for a project is totally unreasonable and no amount of overtime can allow it to be met, the project team becomes angry and frustrated... morale drops to the bottom.”
This data seems to suggest Parkinson’s Law has little place in software engineering. If anything, it appears counterproductive when interpreted as justification for imposing tight deadlines.
Yet the real world introduces complexity. Engineering teams operate within broader systems—stakeholders, product roadmaps, cross-functional dependencies, and budgets. At some point, milestones must be set.
While some argue that estimates should be abandoned entirely, I find that view often overlooks how businesses actually operate. Software exists to serve users and align with broader strategy and not just to ship tickets. The real insight is that realistic time estimates aren't restricting—they're valuable tools that balance engineering freedom with organizational needs. The key is ensuring these estimates come from thoughtful team input rather than arbitrary deadlines.
While research challenges the traditional application of Parkinson’s Law in creative knowledge work, I've observed that work expansion still occurs in engineering teams—just through a different mechanism than Parkinson originally described.
Engineers have a natural tendency toward perfectionism and completionism, rather than laziness or unengagement. Without clear constraints, many engineers will:
It’s the opposite of laziness. It’s a commitment to quality that, paradoxically, can work against delivering value efficiently.
While engineers often expand work through perfectionism and craft, there is also the classic manifestation of Parkinson’s Law when intrinsic motivation is absent. I’ve seen skilled developers who had mastered tasks but no longer found them challenging—work stretched not through careful craftsmanship, but through reduced engagement. This is the intrinsic motivation problem: without autonomy, mastery challenges, or purpose connection, work becomes something merely to complete rather than excel at. In these cases, tighter timeframes might temporarily increase output, but the sustainable solution is reconnecting engineers to what drives them internally.
What appears to be Parkinson’s Law in action is often what I call the “perfection trap.” Engineers aren’t filling time with busywork—they're pursuing a 100% solution when an 80% solution would deliver the needed business value.
During a time-sensitive release, one teammate spent two weeks perfecting an integration test already covered by unit tests. In hindsight, we should have offered clearer leadership and clarified priorities earlier. Even with that, the teammate was especially insistent on implementing certain refactorings, leading to extended debates on class structure rather than shipping urgently needed features. While their drive for quality was admirable, this “perfection trap” delayed real business value.
A widely known example of the perfection trap is Google’s Gmail, which famously remained in ‘beta’ for over five years.4 While continual refinement improved features, this unchecked perfectionism delayed broader business adoption, particularly in enterprise settings where “beta” signaled instability. Google engineers weren’t delaying due to laziness—they were continuously perfecting the product beyond what users actually needed, illustrating how Parkinson’s Law in engineering manifests through craft, not complacency.
The perfection trap stems from several psychological factors:
These instincts come from good places: commitment to craft, attention to detail, and professional pride. But when left unchecked, they can prevent timely delivery of value and create unpredictability in your engineering process.
As Steve McConnell argues in Software Quality at Top Speed, pushing for ultra-high defect removal rates—above 95%—can actually slow delivery, offering marginal benefit outside of life-critical systems. This illustrates how chasing “perfection” in software quality can quickly become counterproductive.5
At my current employer, we once had a product principle that captured this tradeoff well: “Don’t cover all the cases.” It was a deliberate cultural stance. It encouraged teams to move quickly, ship value fast, and address edge cases iteratively. It worked well in that stage of our growth, when speed of learning and delivery mattered more than polish.
This explains why Parkinson’s Law manifests in engineering: work expands through misallocated craftsmanship, not laziness.
“So if Parkinson’s Law doesn’t fully apply as traditionally understood, how should engineering leaders approach time management?”
While the temptation might be to impose arbitrary deadlines, effective engineering leadership calls for:
Instead of pressuring engineers to work faster, the objective is to guide them in recognizing the ideal moment to stop refining and ship. This approach channels perfectionist tendencies into delivering tangible business value.
Finding the right balance is crucial. As I’ve observed in my teams:
The sweet spot is what I call “informed constraints”—timeframes based on a genuine understanding of the work and the team, with enough pressure to maintain focus but not so much that quality suffers.
Reframed this way, Parkinson’s Law becomes a useful tool for engineering leaders. It reminds us that:
The law isn’t about making people work harder or faster—it’s about recognizing our natural tendency to expand work and setting appropriate boundaries. And crucially, it's about understanding when to apply that pressure, and when not to.
The Perfection-Pressure Spectrum is a leadership tool I developed to help navigate the balance between quality-driven perfectionism and deadline-driven pressure, guiding teams toward delivering meaningful value through informed constraints
The Perfection-Pressure Spectrum— A leadership compass to diagnose why work expands in engineering teams, and how to guide it back toward value through informed constraints.
Over the years, I've found these approaches particularly effective in managing the “Perfection-Pressure spectrum” while maintaining quality:
Watch for these warning signs:
While the healthy constraints outlined earlier provide the overarching strategy for a supportive and realistic time management approach at leadership level, these informed constraints outline specific and actionable practices that implement the strategy.
The right balance on this spectrum shifts based on context—medical software justifiably demands higher perfection than a marketing site, startups benefit from quick 70% solutions while enterprises may need more polish, and early products require rapid iteration while mature ones warrant deeper refinement. Effective leaders adjust constraints based on these factors rather than applying one-size-fits-all thresholds.
One practical approach I've used successfully: When a team member proposes adding scope or performing additional refactoring, ask them to quantify the user impact: “How many users will notice this improvement? What business metrics will change as a result?”
This bases engineering effort in user outcomes and business value—not just technical curiosity or craftsmanship.
Use this checklist as a quick gut-check when leading your next project:
These questions help steer effort toward value—not just effort for effort’s sake.
Parkinson’s Law wasn’t written for engineering. But the core pattern—work expanding to fill available time—still plays out, just through a different lens: craft-driven overcommitment rather than bureaucratic inefficiency.
Modern engineering work rarely suffers from idleness. Software Engineering has never been so accessible before and is thriving from a vibrant community full of motivated and passionate problem-solvers.
The challenge is knowing when to stop refining and start delivering. That’s where leadership comes in—not to impose pressure, but to create guidance and clarity.
Clarity around priorities. Around scope. Around “done.”
When engineering leaders provide informed constraints, celebrate meaningful delivery, and keep value in focus, Parkinson’s Law becomes a helpful lens—not a hammer.
That’s the work. And it’s where great leadership shows up.
Thanks for making it to the end. I hope you like the content.
Loving what you've read? Subscribe to The Human Side of Tech, completely for free. My posts appear there first.
Facing challenges navigating change in your engineering career? I offer one-on-one mentoring to help you develop personalized strategies for thriving amid uncertainty. Connect with me on MentorCruise to learn more.
Find out if MentorCruise is a good fit for you – fast, free, and no pressure.
Tell us about your goals
See how mentorship compares to other options
Preview your first month
