Plan for what can go wrong.
Mental models for work and life
Useful Laws & Principles
Twenty memorable ideas for planning better, thinking clearly, and avoiding common mistakes in teams, products, and everyday decisions.
| # | Principle | Meaning | Memorable example |
|---|---|---|---|
| 1 | Murphy's Law | Anything that can go wrong eventually will, so plan for failure. | You have an important presentation tomorrow. The laptop could fail, the internet could go down, or the file could become corrupted. So you keep a local copy and a PDF backup. |
| 2 | Parkinson's Law | Work expands to fill the time available. | You give yourself 2 weeks to make a presentation. You spend the first week tweaking things, adding unnecessary details, and changing slides. Give yourself 2 days and you may produce essentially the same presentation. |
| 3 | Hofstadter's Law | Things take longer than expected—even when you account for that. | You estimate a project will take 2 weeks, so you add a one-week buffer. Unexpected bugs, dependencies and revisions appear, and it takes 4 weeks anyway. |
| 4 | Pareto Principle (80/20) | A small number of causes often produce most of the results. | An e-commerce company discovers that roughly 20% of its products generate most of its sales. Instead of treating every product equally, it focuses attention on those products and customers. |
| 5 | Hick's Law | More choices generally mean more time and effort to make a decision. | A restaurant gives you 6 well-organized choices and ordering is easy. Another gives you 150 dishes with no structure. You spend several minutes just deciding what to order. |
| 6 | Occam's Razor | When several explanations fit the facts, start with the simplest one. | Your phone suddenly won't charge. Before assuming the charging port has failed, you check the cable and discover it was faulty. |
| 7 | Hanlon's Razor | Don't assume bad intentions when a mistake is a sufficient explanation. | Your colleague doesn't reply to an important message. You initially think they're deliberately ignoring you. Later you discover the email went into their spam folder. |
| 8 | Chesterton's Fence | Don't remove something until you understand why it exists. | You find an apparently unnecessary approval step in a company's process and remove it. Later you discover it existed because an earlier project had a serious compliance problem. |
| 9 | Goodhart's Law | When a measurement becomes a target, people may optimize the measurement rather than the real goal. | A support team is judged by how many tickets they close. Soon, agents start closing easy tickets quickly while difficult customer problems remain unresolved. |
| 10 | Cobra Effect | A well-intentioned incentive can make the original problem worse. | The government pays people for dead cobras. People start breeding cobras to collect the rewards. When the program ends, they release the snakes, potentially leaving the city with even more cobras than before. |
| 11 | Kidlin's Law | Clearly defining and writing down a problem can reveal much of the solution. | A team says, “Our checkout is terrible.” They write the problem down and discover: “42% of users abandon checkout because the shipping cost isn't shown until the final step.” Now they have a specific problem to solve. |
| 12 | Peter Principle | People tend to be promoted until they reach a role where their existing skills aren't sufficient. | A developer is excellent at coding, so the company promotes them to engineering manager. But managing people, hiring and resolving conflicts require a completely different skill set. |
| 13 | Brooks's Law | Adding people to a late software project can make it later. | A project is already behind schedule, so management adds five developers. The existing team now has to train them, explain the architecture and coordinate with them. Development slows down further. |
| 14 | Dunning-Kruger Effect | People with limited knowledge can overestimate their ability because they don't yet know what they don't know. | Someone learns basic JavaScript and successfully builds a small website. They conclude they can easily build a large production application—until architecture, security, testing, performance and deployment become problems. |
| 15 | Sunk Cost Fallacy | Money, time or effort already spent shouldn't determine whether you continue. | You've spent ₹10 lakh building an app, but user research shows nobody wants it. You keep investing because “we've already spent ₹10 lakh,” rather than asking whether another ₹10 lakh is worthwhile. |
| 16 | Survivorship Bias | We focus on things that survived or succeeded while ignoring the failures that disappeared. | You study successful entrepreneurs and notice many dropped out of college. You conclude dropping out leads to success—but you haven't studied the thousands of people who dropped out and never became successful entrepreneurs. |
| 17 | Conway's Law | The structure of a product often reflects the structure and communication patterns of the organization that built it. | Four teams work independently on different parts of a product and rarely communicate. The resulting software ends up with four separate components that are difficult to integrate. |
| 18 | Campbell's Law | The more heavily a metric is used to make decisions, the more likely people are to distort their behavior around it. | A company measures salespeople purely by number of calls made. Soon, employees make hundreds of meaningless calls simply to hit the target, while actual sales don't improve. |
| 19 | Regression to the Mean | Extremely unusual results are often followed by results closer to normal. | A football player scores five goals in one match. Everyone expects another extraordinary performance next week, but they return to their usual scoring level. That doesn't necessarily mean they suddenly became worse. |
| 20 | Wirth's Law | Software tends to become more resource-hungry faster than hardware becomes faster. | Your new computer has a much faster processor and more RAM than your old one, yet some modern applications still feel just as slow—or slower—because the software has become much more complex and bloated. |
The short version
A quick way to remember them
Work fills the time you give it.
It'll take longer than you think.
A few causes drive most results.
More choices mean slower decisions.
Prefer the simplest fitting explanation.
Don't assume malice.
Understand the fence before removing it.
A targeted metric loses its value.
Incentives can worsen the problem.
Write the problem clearly.
Promotion can exceed competence.
More people can make a late project later.
Little knowledge can inflate confidence.
Past spending shouldn't decide the future.
Visible winners hide many failures.
Systems mirror team communication.
High-stakes metrics invite manipulation.
Extreme results tend toward average.
Software slows as hardware speeds up.