Some of these laws are well-known, while others are more niche. All of them, however, are incredibly valuable for engineers and managers.
Curious to see how many of these are new to you?
- 1. Parkinson’s law
- 2. Hofstadter’s law
- 3. Brooks’ law
- 4. Conway’s law
- 5. Cunningham’s Law
- 6. Sturgeon’s Law
- 7. Zawinski’s Law
- 8. Hyrum’s Law
- 9. Price’s Law
- 10. Ringelmann Effect
- 11. Goodhart’s Law
- 12. Gilb’s Law
- 13. Murphy’s Law
For each, I’ll share:
The law itself A relevant comic (if I found one).Why it matters for engineering managers. Let’s dive in:
1. Parkinson’s law
Work expands to fill the available time.
This well-known principle often justifies setting artificial (and sometimes unreasonable) deadlines.
Why it matters
This law is discussed in depth in James Stanier’s excellent guest post. Setting deadlines can help drive results by leveraging the "Iron Triangle" of scope, resources, and time.
However, as with any law, this one can be misapplied. Hofstadter’s law, for example, serves as an excellent counterbalance.
2. Hofstadter’s law
It always takes longer than you expect, even when you take into account Hofstadter’s law.
Software projects are notorious for being late—often even when buffer time is added. Misusing Parkinson’s law to justify overly short deadlines can result in:
- Burning out your team
- Consistently delivering late
Why it matters
Together, these two laws highlight the complexities of estimation in software development. Excessively long buffers waste time; overly short buffers lead to missed deadlines.
There’s no easy fix—only relentless practice, clear communication, and flexible scope management can make a difference.
3. Brooks’ law
Adding manpower to a late software project makes it later.
The classic illustration of this principle is: “Nine women can’t make a baby in a month.”
Every EM under pressure has been there: a higher-up declares, “This is absolutely critical—pull resources from other teams if you need to!” Sure thing… Or maybe just let us focus and get it done 🙃.
Why it matters
Every engineering manager has experienced this scenario: an urgent project, and someone suggests pulling in extra people from other teams to help. Unfortunately, this often backfires.
While it may feel like adding two senior engineers to a late project will boost productivity by at least 5-10%, the reality is that productivity can actually decrease. This is due to the added coordination overhead and onboarding effort required.
Of course, like every law, its impact depends on specific circumstances and variables.
4. Conway’s law
Organizations produce designs that mirror their communication structures.
For example: In a SaaS company with separate frontend and backend teams, their independent operations can result in mismatched expectations. This leads to inefficiencies and additional layers of glue code to bridge the gap.
Why it matters
You can leverage the Inverse Conway’s law to your advantage. A compelling case is what Flo did:
Faced with three-week mobile app release cycles, they restructured teams to include one iOS engineer, one Android engineer, and 2-4 backend engineers in each team. By offloading more functionality to the backend, they were able to deploy 20-30 times per day instead of every few weeks.
5. Cunningham’s Law
The best way to get the right answer on the internet is not to ask a question, but to post the wrong answer.
People love correcting others, and that can work to your advantage.
Why it matters
In the article 6 Secrets for Never Being Blocked Again, this principle was applied to help you get unstuck:
Instead of waiting for the DevOps team to prioritize your request and eventually complete it, open a Pull Request and take a shot yourself—even if you're unsure about what you're doing. Examine previously merged PRs, find one that's similar to what you need, and try your best.
This approach accomplishes several things:
The DevOps team will review your PR and quickly point out issues.
You'll gain valuable insights for next time.
Over time, the team will streamline the process with automation and policies, making future tasks smoother.
6. Sturgeon’s Law
90% of everything is crap.
This is like the Pareto Principle (80/20), but with a harsher reality. Most code, ideas, and features end up being suboptimal.
Why it matters
A majority of the features you release will have little impact, while only a select few will define your company’s core value. The legendary “10x engineer” isn’t someone who produces 10x more code but rather 10x more value.
Blindly following the roadmap handed down by your PM risks focusing on the 90% of features that won’t move the needle. That’s why working strategically and questioning priorities is essential.
7. Zawinski’s Law
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones that can.
In the age of AI, this law rings truer than ever. Adding features (like chatbots) to everything may seem appealing but risks turning your product into an unwieldy monstrosity.
Why it matters
Feature creep can dilute your product’s value. New users struggle to navigate overly complicated systems, while loyal ones may grow frustrated by the clutter. Avoid this trap by prioritizing simplicity and acknowledging that customers might still rely on external tools like spreadsheets.
8. Hyrum’s Law
With a sufficient number of users of an API, all observable behaviors of your system will be relied upon by someone, regardless of the contract.
Why it matters
This law highlights the unpredictable nature of API (and feature) dependencies. Even if 90% of your work is subpar, you'll still spend significant time maintaining the full range of features because someone will depend on them. Removing outdated elements often leads to complaints from customers—and pressure from stakeholders to retain them.
9. Price’s Law
In any group, 50% of the work is done by the square root of the number of people.
For instance:
Out of 10 engineers, 3 contribute 50% of the output.
In a team of 100, just 10 produce as much as the remaining 90.
Why it matters
This law underscores the inefficiency of scaling teams. To double your output, you’ll likely need to hire quadruple the staff. One explanation for this phenomenon is the Ringelmann Effect, which states that individual productivity decreases as team size grows.
10. Ringelmann Effect
Individuals in larger groups tend to contribute less effort.
A 1913 study revealed this in a rope-pulling competition—effort per person decreased as the group size grew.
Why it matters
The Ringelmann Effect isn't just about physical tasks; it applies to engineering teams as well. Smaller groups with clear ownership of tasks are often far more effective than larger ones. For startups especially, don’t shy away from breaking into smaller, agile teams.
11. Goodhart’s Law
When a measure becomes a target, it ceases to be a good measure.
Every KPI can be gamed:
- Revenue? Offer steep discounts.
- Churn? Make cancellations difficult.
- Support ticket resolution? Close tickets prematurely.
Why it matters
Metrics often become unreliable when they're directly tied to performance incentives. Instead of discarding measurement entirely, apply Gilb’s Law for balance.
12. Gilb’s Law
Anything you need to quantify can be measured in some way that is superior to not measuring it at all.
Basically saying that it might be hard to measure, and the measurements might not be 100% accurate, but any measurement is better than nothing.
Why it matters
While perfect metrics are impossible, even imperfect ones are better than none. By refining and iterating on your measurements, you’ll uncover valuable insights over time—especially in areas like developer productivity.
13. Murphy’s Law
Anything that can go wrong will go wrong.
No list of laws is complete without this classic.
Why it matters
Murphy’s Law serves as a reminder to account for edge cases, even those that seem highly unlikely. Cutting corners often leads to production failures—and valuable lessons learned the hard way.
