1. Parkinson’s Law: Work expands so as to fill the time available for its completion.
2. Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
3. Gates’ Law: Most people overestimate what they can do in one year and underestimate what they can do in ten years.
4. Goodhart’s Law: When a measure becomes a target, it ceases to be a good measure.
5. Hanlon’s Razor: Never attribute to malice that which is adequately explained by stupidity (or, don’t invoke conspiracy when ignorance and incompetence will suffice, as conspiracy implies intelligence).
6. Acton’s Dictum: Power tends to corrupt, and absolute power corrupts absolutely.
7. Amara’s Law: We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.
8. Benford’s Law: In a diverse collection of unrelated statistics, a given statistic has roughly a 30% chance of starting with the digit 1.
9. Betteridge’s Law: Any headline which ends in a question mark can be answered by the word ‘no’.
10. Brooks’ Law: Adding manpower to a late software project makes it later.
11. Chesterton’s Fence: Reforms should not be made until the reasoning behind the existing state of affairs is understood.
12. Claasen’s Law: Usefulness = log(technology).
13. Clarke’s First Law: When a distinguished elderly scientist states that something is possible, they are almost certainly right, but when they state something is impossible, they are probably wrong.
14. Cromwell’s Rule: Nothing but logical impossibilities have a prior probability of 0 or 1.
15. Cunningham’s Law: The best way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer.
16. Doctorow’s Law: When someone puts a lock on a thing you own, against your wishes, and doesn’t give you the key, they’re not doing it for your benefit.
17. Dunbar’s Number: Most people can’t maintain stable social relationships with more than 150 people.
18. Eroom’s Law: Drug discovery is becoming slower and more expensive over time, despite improvements in technology.
19. Gell-Mann Amnesia Effect: You’ll believe articles outside your area of expertise, even after acknowledging that neighboring articles in your area of expertise are completely wrong.
20. Gibson’s Law (or the Expert Witness Law): For each PhD (to use as an expert witness for one side) there’s an equal and opposite PhD.
21. Godwin’s Law: As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one.
22. Morley-Souter’s Law (Rule 34): There is porn of it (no exceptions).
23. Greenspun’s Tenth Rule: Any sufficiently complicated C program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp.
24. Hebb’s Law: Neurons that fire together wire together.
25. Hubble’s Law: Galaxies recede from an observer at a rate proportional to their distance to that observer.
26. Hume’s Guillotine (Is-Ought Problem): Normative statements (about what’s moral/immoral/right/wrong) cannot be deduced exclusively from descriptive statements.
27. Humphrey’s Law: Conscious attention to a task normally performed automatically can impair its performance.
28. Kranzberg’s Law: Technology is neither good nor bad; nor is it neutral.
29. Lamarck’s Principle (or “Use it or Lose it”): Use it or lose it (evolutionarily speaking, but also in the brain).
30. Lewis’s Law: The comments you’ll inevitably find on any article about feminism justify feminism.
31. Littlewood’s Law: Individuals can expect miracles to happen to them, at the rate of about one per month.
32. Maes–Garreau Law: Favorable predictions about future technology will fall at the latest possible date they can come true and still remain in the lifetime of the predictor.
33. Metcalfe’s Law: The value of a system grows as approximately the square of the number of users of the system.
34. Miller’s Law: To understand what another person is saying, you must assume that it is true and try to imagine what it could be true of.
35. Moore’s Law: Computation per dollar grows exponentially (or: number of transistors per circuit doubles roughly every 24 months).
36. Murphy’s Law: Anything that can go wrong will go wrong.
37. Alder’s Law: What cannot be settled by experiment is not worth debating.
38. O’Sullivan’s Law: All organizations that are not actually right-wing will over time become left-wing.
39. Pareto’s Principle (80/20 Rule): For many phenomena 80% of consequences stem from 20% of the causes.
40. Peter’s Principle: In a hierarchy, every employee tends to rise to his level of incompetence.
41. Poisson’s Law (or Law of Large Numbers): For independent random variables with a common distribution, the average tends to the mean as sample size increases.
42. Pournelle’s Iron Law of Bureaucracy: In bureaucracy, those devoted to the bureaucracy get control, those devoted to what it’s supposed to achieve lose influence.
43. Putt’s Law: Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand.
44. Rosenthal Effect (Pygmalion Effect): High expectations lead to an increase in performance, low expectations to a decrease in performance.
45. Schneier’s Law: Any person can invent a security system so clever that she or he can’t think of how to break it.
46. Shermer’s Law: Any sufficiently advanced extraterrestrial intelligence is indistinguishable from God.
47. Zipf’s Law: The frequency of use of the nth-most-frequently-used word in any natural language is approximately inversely proportional to n (few words are used often, most are used rarely).
48. Wirth’s Law: Software gets slower more quickly than hardware gets faster.
49. Sturgeon’s Law: Ninety percent of everything is crud.
50. Stigler’s Law: No discovery is named after its original discoverer, including this one.

This piece was first written on July 6, 2020, and first appeared on my website on May 30, 2026.

With that definition in mind, there are many reasons a work team may have low productivity. To make a team more productive, I suggest first trying to pinpoint the predominant causes of inefficiency, since different failure points typically have different solutions. The key is to identify and then focus on just the 1-3 of these causes that seem to be the biggest recurring blockers of team productivity.

Once these biggest blockers are identified, an analysis needs to be made of why they are occurring (e.g., using a method like the “5 whys”, where you try to uncover the root cause of the issue). Then, strategies need to be developed to try to resolve the blockers, and one or two strategies that have sufficient team buy-in need to be selected for implementation. Finally, re-evaluation needs to occur to make sure the problems are actually improved by those strategies.

Below is a list of these potential failure points or blockers.

There are four main facets of team productivity (Planning, Effectiveness, Resources, and Communication), which break down further into specific reasons for low productivity. You can use this list by considering each potential reason and scoring the degree to which you think it’s a problematic factor on your team (or having all team members anonymously score each potential reason for how big a problem it is, and then aggregating the responses to find the few most important seeming issues).

—

Reasons For Low Team Productivity:

—

(A) Planning

(1) Wrong Goal – the work is focused on achieving a goal that is not actually particularly valuable.

      e.g., the team is building a new feature that customers don’t want

(2) Poor prioritization – rather than focusing on the very most important things, the team focuses on things of secondary importance.

      e.g., the team lead keeps pushing team members to make tiny improvements to existing features, even though there are really major features where implementation hasn’t even begun.

(3) Slow Path – the planned route for achieving the team’s goal is not as efficient as other routes to achieving the same goal.

      e.g., the team could use a well-tested plugin to help them solve their problem, but the team lead insists they build their own alternative to this plugin.

(4) Incompletion – there is no pressure to finish projects, or team members work on far too many projects at once, so work doesn’t get completed, or takes much longer than it should.

      e.g., when a crisis comes up, the projects already in progress are abandoned, and rarely are they picked up again.

(5) Feature Creep – the project takes a really long time to be released because its scope or feature set keeps unnecessarily increasing, repeatedly delaying the launch.

      e.g., the client keeps making more and more requests about what to include in the next version.

(6) Missing Buy-in – team members don’t actually care about achieving the team’s goals (i.e., they don’t view the goal as valuable, and don’t feel like a genuine team, such that they care about the team’s success).

      e.g., Bill doesn’t think the product they are building is worthwhile, Sally doesn’t feel invested in the success of her team members or the team overall.

(7) Incentive Misalignment – some team members have incentives that cut against the project going well, or are focused on optimizing for personal goals at the expense of project goals.

      e.g., team members know that if they succeed at the goal, then someone else will take all the credit, and if they fail at it, there will be no negative consequences, and Bob actually wants the project to fail because then he’ll get to move on to a different project he likes more.

(8) Missing Skills – certain skills are needed to accomplish the goals, but no one on the team has these skills, and there are no external consultants that can be called on.

      e.g., no one on the team has a good eye for design, so the interface you’re building has the right features but looks bad.

(9) Reactivity – the team is constantly reacting to crises or imminent deadlines, which means there isn’t time to focus on achieving the long-term goals.

      e.g., every month or two, there is a major system failure, followed by weeks of scrambling simply to get things back to normal.

(10) Groupthink – team members do not feel comfortable sharing their unique ideas, or challenging the team lead, or getting their ideas heard above the most vocal person, or contradicting the group consensus, so the best ideas don’t filter to the top.

      e.g., the first proposed solution to a problem was accepted because no one wanted to challenge the person who proposed it, and since no one spoke up, everyone assumed the other group members must be in consensus.

(11) Guessing – the team doesn’t have enough data or information to solve the problems they are working on, but rather than gathering this data or information, they guess at solutions that aren’t very likely to work.

      e.g., the team has the goal of reducing customer churn, but they haven’t conducted customer interviews or carefully analyzed the churn data, so they are merely guessing at why churn is occurring and developing inadequate solutions based on those guesses.

—

(B) Effectiveness

(12) Insufficient Time – people not working enough hours.

      e.g., a culture of showing up at 10 am and leaving at 4 pm.

(13) Waste – spending time engaged in unnecessary processes or pointless meetings.

      e.g., a culture of constant meetings where you have little time to get your actual work done, or a requirement to tediously document all your work.

(14) Distraction – people may not be able to get “in the zone” on their work because of frequent distractions, or an environment where it is hard to focus.

      e.g., a noisy office environment where colleagues continuously interrupt you to ask you questions.

(15) Burnout – people may feel stressed, depressed, disinterested, bored, or exhausted, and find it is psychologically difficult to get their work done.

      e.g., a culture where bosses regularly yell at, blame, and fire employees for things that are not their fault.

(16) Bad Foundations – the work may be building on other work that was not well made, slowing down additional progress.

      e.g., programmers inherit a massive, buggy, and poorly written spaghetti codebase (i.e., high levels of technical debt).

(17) Disempowerment – team members are not allowed to do certain things (or make certain decisions) that would move the project forward, or they are required to follow a bureaucratic or standardized process that is not an efficient or effective process.

      e.g., a user experience researcher is not allowed to pay customers for doing interviews, but customers won’t do the interviews for free.

(18) Intrinsic Difficulty – the work may genuinely be intrinsically difficult, with progress speed inherently limited.

      e.g., work involving proving new theorems that others have failed to prove.

—

(C) Resources

(19) Slow Platforms – the systems or platforms on which the work is performed make progress more difficult, slower, or more complex than it needs to be.

      e.g., teams are forced to work on Windows 98 and experience regular computer crashes, or teams are forced to work using old and out-of-date software.

(20) Lacking Tools – the team members don’t have the best tools to do their work.

      e.g., a construction team is forced to use a saw that is inappropriate for the job because they don’t have access to the right kind of saw.

(21) No Training – there is a lot of relevant information about how to do the job well that team members are not told, and have to laboriously figure out on their own, or struggle to get by without.

      e.g., programmers are expected to figure out how the undocumented API works on their own via trial and error.

(22) Insufficient Assistance – when team members are stuck, they have no one knowledgeable they can go to (or that they feel comfortable going to) for help.

      e.g., a machine learning researcher can’t get her neural network model training properly and has no one she can ask for advice.

(23) Insufficient Skill – team members are not sufficiently skilled at the tasks they are trying to do.

      e.g., the team members responsible for writing documentation are not skilled at clear communication.

—

(D) Communication

(24) Blocking – team members are waiting on each other to do things before they can get their own work done.

      e.g., Sam needs approval from Sally to move forward, but Sally requires approval from Samantha in order to give Sam permission.

(25) Conflict – team members dislike each other, don’t trust each other, or have clashing personalities.

      e.g., Bill refuses to work with Sam, Jill thinks that Jenny is trying to undermine her, Tim and Tammy get into heated arguments.

(26) Discordant Goals – different team members are working towards different long-term goals, because they are not on the same page about what the purpose, mission, or primary goal of the team is.

      e.g., the product manager is trying to add features, whereas the engineering team is trying to do a feature freeze so they can focus on stability and efficiency.

(27) Ambiguity – the goals are not clear enough, leading to confusion, false starts, and stops, or circling around problems without directly solving them.

      e.g., there is agreement that the user interface needs to be “easier to use,” but little clarity on what that means.

(28) Duplication – team members end up repeating work that has already been done (or that is in the process of being done) by others, either because they don’t know that other work exists or because they don’t trust the quality of it.

      e.g., the new lead engineer doesn’t trust the code developed by the prior lead engineer and so decides to rewrite it from scratch.

(29) Unassigned work – it is not clear who is supposed to tackle certain work (e.g., it is not in any particular person’s job description or current assignments), so some important work just doesn’t get done by anybody.

      e.g., nobody has been assigned the responsibility of bug testing, so bug testing simply doesn’t get done, and therefore, the product is highly buggy.

(30) Siloed Information – team members need information from each other to do their work well, but this information is not transmitted reliably.

      e.g., the team member doing customer interviews isn’t reliably communicating what they learn to the team member planning UX changes.

A big shoutout goes to Eddie Liu, who helped develop this framework.

This piece was first written on July 3, 2019, and first appeared on my website on January 22, 2026.