Laws, Principles and Paradoxes to Back You Up in Discussions (and Debates)

Trigger warning: entry 16 mentions insurgency/terrorism.

I love a law. This is a little set of tools I often rely on to make credible points in a discussion, presentation – and even in an argument.

They are a series of rules, laws, effects and other consistent scientific observations that can help explain behaviours, advise good organisational design and otherwise back up a series of undertakings you might be advocating in an organisation’s Agile transformation journey.

They level the playing field

You could be the most junior intern in a huge organisation, stuck in a dispute with an aggressive, red-personality type executive, but if you are able to whip out a law, theorem or principle laid down by a globally respected academic to enhance your point, you can assert yourself on equal terms with the backing of science (or occasional pseudo-science).

It’s not about your experience, gravitas or personality, it’s about knowing what trends have happened before and what effects are more likely to occur in future circumstances. Whatever point you are trying to make, by using one of these laws, you gain the external backup of some sort of scientist, sociologist, genius developer or other thought leader for enhancing your point.

They are also really good for tackling imposter syndrome. If you, like me, have suffered with this, these bitesized memory tools can help you feel more level and capable of contributing.

They can also help guide you through all sorts of future conundrums, puzzles and difficult conversations.

One point of note: the creator of the modern Kanban framework, David J Anderson, said that any developer worth their salt should know most of these, but also know that they can all, intentionally, be worked around. There are always exceptions, some of them are flippant, but they are still very good and helpful observations for understanding human behaviour, workplace dynamics and organisational design.

Here you go:

1. The Abilene Paradox: this is when a group of people agrees to do something that no-one in the group actually supports because they don’t want to cause a fuss. If you see this sort of thing happening it often denotes a lack of psychological safety so it can be difficult to speak up and call it out, but by citing the Abilene Paradox with an open question, you can at least bring it to the table. Try asking gently “is this an example of the Abilene Paradox happening?” You’re not being accusatory, you are asking people to stop and reflect. Sometimes it’s because everyone is what I call “violently polite” but other times it might be the result of a domineering personality in the room and you’ve just indirectly called it out, potentially encouraging others to speak up more as well.
2. The Anchoring Effect: this is the common human habit of relying on the first piece of information we encounter when making subsequent decisions. Use it to gently provide feedback or challenge other people’s interpretations of things. Even if you don’t suspect it to be at play, it can still be helpful to remind people to approach their own decision-making with rigour.
3. The Asch Effect: this is when individuals in a group conform with what the group is doing even when the group is demonstrably wrong. It can be similar to the Abilene Paradox above. There are obviously historic examples of this happening. Here’s a really fun (but illuminating) psychological study from Princeton University in the 1970s that I think leads in to some of the cases of this sort of thing happening.
4. Ashby’s Law: if a system is to be stable, its internal flexibility / complexity needs to match or exceed the variety of complex situations it will encounter. If you’re designing something that needs to be reliable, give yourself plenty of slack and wiggle room for the unexpected!
5. Brook’s Law: adding more people to help deliver a software project that’s running out of time will only delay its completion. I’ve also heard someone slightly more crassly say “it’s like expecting nine women to make a baby in one month“. It’s usually used in flippant descriptions, but there are loads of reasons why this happens. Adding more people to a team destabilises the dynamics and can add all sorts of additional pressures like onboarding, communication overhead, knowledge transfer requirements and the generally unpredictable dynamics of humans who aren’t used to working together having to figure out how to do exactly that. Additional thumbs down for anyone who does this sort of thing whilst also referring to the people in question as “resources”.
6. The Bystander Effect: an individual is less likely to offer help if other people are present. Comparable to the Ringelmann effect (below)
7. Campbell’s Law: the more a quantitative social indicator is used for decision-making, the more it will be subject to corruption, influence, manipulation etc. It is highly arguable that this applies to all sorts of metrics, like velocity as an extremely common example in Agile teams.
8. Campbell’s Law of Systemic Decay: systems naturally tend to degrade into bureaucratic self-preservation unless they are continually injected with localised, purposeful energy.
9. The Cobra Effect: an incentive that has unintended negative results that exacerbate the problem it was meant to solve. Let’s say you want to improve organisational collaboration in order to get more innovation and higher profits, so you force everyone to work in the office every day rather than working from home. Everyone ends up resenting you while employee morale, collaboration, productivity, and subsequently profits all plummet. Ouch.
10. Confirmation Bias: this is the tendency to search for an interpretation or recall information in a way that confirms pre-existing beliefs. It’s very normal to want to reinforce your own biases, but we really need to be more open minded with data and more rigourous in our own analysis.
11. Conway’s Law: a group of people will design a system, product etc that mirrors their own communication structure. I use this one all the time. Whatever you design in a group of people will probably resemble the structure and patterns of your emails, meetings, file storage systems, records and styles of conversation that you regularly have in your group of people.
12. Cunningham’s Law: if you want to get the right answer on the internet faster than asking a question and waiting for an answer, post the wrong answer and someone will correct you more quickly. Ward Cunningham, the inventor of the concept of a wiki (a big information repository that everyone can edit) is apparently not too happy with this one, but I’m personally very satisfied that so many people correct one another’s mistakes on wikipedia that a German study found that its medical information had an accuracy rate of 99.7%. Well done unhelpful netizens!
13. Dunbar’s Number: humans have a cognitive limit of forming meaningful social relations with about 150 people. This is fascinating and probably stems from tens of thousands of years ago when we evolved as a species to live in adaptive, collaborative groups. The rest is, quite literally, history.
14. The Dunning-Kruger Effect: people with limited knowledge or experience in a field will overestimate their own skills or knowledge in that domain. I think we can all think of a few people like that.
15. Gall’s Law: a complex system that works is invariably found to have evolved from a simple system that worked. Complex systems designed from scratch rarely work. Start simple. If it evolves into something complex, do it gradually, bit by bit, in simple iterations. Look at the Dabbawala system of lunchbox delivery in Mumbai. It’s famously complex, delivering up to 200,000 lunches from homes to workplaces every day with vanishingly few errors. It would’ve been impossible to design such a system from scratch. It started simply, with one person delivering another person’s lunch over 100 years ago, then evolved into the gigantic (and tasty) logistical organism it is today.
16. The Good Regulator Theorem: (trigger warning: this entry mentions insurgency/war content) this is a cybernetics concept whereby the regulator or controller of a system must match or mirror the system it controls. In order to manage something well and responsively, a group must implicitly understand the thing by being like the thing. For an interesting adjacent case study, read the book “Team of Teams” by General Stan McChrystal  about how he had to take the US military from a mentality and logistical structure of standard command-and-control reductionism, into a more fluid, cross-functional force to mirror the insurgency groups they were trying to tackle.
17. Goodhart’s Law: when a measure becomes a target, it ceases to be a good measure. If you start using velocity or lead times or approval ratings, consciously or sub-consciously, people will find themselves trying to massage the figures. It’s much better to use a basket of measures as an indicator, but the target should be a broader outcome.
18. Graham’s Law: bad habits, lazy metrics and poor communications will routinely drive out good working order unless actively resisted by the system. This is why a kaizen mindset is so important. You’re not just looking to continually improve, you’re preventing entropy from seeping into your workplace. Retrospectives are important!
19. Hanlon’s Razor: never attribute to malice that which can be adequately explained by stupidity. I think the majority of people are good, but we are fallible, forgetful, stressed and dealing with our own worlds of complexity. We are all subject to making mistakes! This approach and mentality can help with things like facilitation, creating psychological safety and conversational aikido (good for active listening).
20. Hofstadter’s Law: a task always takes longer than you expect, even when you take the law into account. This is why Agile estimation is so effective. Comparing the effort, complexity and risk of different work items tends to be far more effective for predicting delivery dates over time than just guessing how long it will take us to do something.
21. Hyrum’s Law: with a sufficient number of users of an API, every observable behaviour of the system will eventually be depended upon by someone. Love your users, and love the diverse creativity they will bring to whatever service you are building, because they will end up relying on everything.
22. Hyperbolic Discounting Principle: there is a human tendency to prefer smaller, immediate reward over larger, later rewards, creating a systemic bias against long-term planning. In Agile delivery, breaking things into smaller increments seeks to accept this reality and derive delivery value from it – on a regular basis.
23. Kahneman’s Peak-End Rule: people judge an experience largely based on how they felt at the peak of the experience and how they felt at the end of the experience, rather than the total average of every moment within the experience.
24. The Kingman Formula: the average waiting time in a queue increases exponentially as resource utilisation approaches 100%. The more things in your to-do list, and the busier your team has to be in order to keep up, the more time it takes to get things done.
25. The Law of Diminishing Returns: this is a point in a production system where the allocation of an additional resource results in successively smaller increases in output.
26. The Law of Leaky Abstractions: all non-trivial distractions, to some degree, leak details of the underlying situation they are trying to hide.
27. Linus’s Law: given a large enough number of eyeballs, all software bugs are shallow. The more people you have looking at a piece of code (or a document), the smaller and more manageable the errors. This is another principle that explains the success and reliability of wiki sites like wikipedia. If you involve everyone in looking at something, it becomes much easier to spot and fix any errors.
28. Little’s Law: the long-term average number of items in a stationary queueing system is equal to the long-term average effective arrival rate multiplied by the average processing time.
29. The Ninety-Ninety Rule: this one is a flippant joke, that states that the first 90% of code accounts for the first 90% of development, while the remaining 10% accounts for the other 90% of time. Basically completion and delivery is all smooth sailing until all the unexpected discoveries, recommended tweaks and unforeseen problems derail things towards the end of delivery.
30. Occam’s Razor: when presented with competing hypotheses, choose the one that makes the fewest number of new assumptions.
31. Pareto’s Principle (the 80/20 rule): for many outcomes, roughly 80% of the results come from 20% of the causes/action/effort. This ratio seems to apply to all sorts of scenarios in work, nature and the human condition. It also demonstrates the importance of prioritisation and incremental delivery. If you incrementally delivery the most important 20% of the work first, and gain 80% of the value, you start earning more, faster. You might even decide that this 20% of work is more than enough value for your time and investment, so you can actually stop working right there, theoretically spend the rest of the year on a beach, or, more realistically, move on to your next top priority.
32. Parkinson’s Law: work expands so as to fulfil the time available for its completion. If you have x number of work items and you think you can get them done in a week, but give yourself two weeks to complete things just in case, it might just turn out that it takes two weeks to get things done overall. This might have something to do with Student syndrome (see below). I’m also fairly convinced that this principle applies to meetings. Keep them short in your calendar with intentional agendas or they will fill up your day with chat chat chat.
33. The Peter Principle: members of a hierarchical organisation are routinely promoted until they reach their absolute level of incompetence. This is another flippant one but it partly reveals my belief that we are all humans with different experiences and insights that must be respected regardless of rank. If you’re facing a complex situation you cannot predict which person in your team, group or organisation might have the best idea for making progress. It might be the intern, or the cleaner, or even the barista over the road. Keep your mind open. And don’t let hierarchies get in the way of meaningful innovation and creative problem solving.
34. The Planning Fallacy: this is a systematic tendency for individuals and organisations to display an optimism bias when planning things, underestimating the time, costs and risks of future actions. Being Scottish, I can’t help but recall the line from our national poet: “the best-laid plans o’ mice an’ men gang aft agley” – that is, things generally don’t go to plan, even with the most detailed of preparations. There’s also the other famous quote “no plan survives first contact with the enemy” from the Prussian Field Marshal Helmuth von Moltke the Elder. Planning helps – it really does – but don’t rely on the actual documented plan to be a final, definitive description of how the future will pan out. You don’t know, and you can’t afford to pretend you do.
35. The Red Queen Effect: this one is based on a part of Alice in Wonderland. It relates that a system must continuously adapt, evolve and proliferate merely to maintain its relative fitness against an evolving environment. Exhausting but real.
36. The Ringelmann Effect: this is the tendency for individual members of a group to become increasingly less productive as the size of the group expands. Conversely, if there aren’t many of you in a team, you have to put in the effort to get the results you need.
37. Sayre’s Law: in any dispute, the intensity of feeling is inversely proportional to the value of the issues at stake. This one emerged from academia and implies that when the stakes are so low, people are more willing to take the interpersonal risk of arguing over it, whereas more serious issues are treated with less passion, or perhaps more solemnity.
38. Student Syndrome: people will typically only start to fully apply themselves to a task at the last possible moment before a deadline. Humans are really bad at deadlines and once again, Agile frameworks like Scrum seek to embrace this by setting small and frequent deadlines, such as the Sprint timebox of one month or less.
39. The Sunk-Cost Fallacy: this is when a person or organisation justifies increased investment in a decision based on prior cumulative investments, regardless of the benefits of further investment.
40. Sturgeon’s Law: 90% of everything is crap. Alternatively, in any given field, the majority of the work is mediocre, but a small proportion might be exceptional. This one feels very cynical, but if you can use it to inject some laughter into a bad meeting, the icebreaker alone will likely contribute towards the 10% non-crap element of the interaction.
41. The Texas Sharpshooter Fallacy: this is a bias where differences in data are ignored or similarities are overemphasised, leading to incorrect statistical conclusions. We evolved as a species to spot patterns, but our brains can sometimes try to identify patterns even when the data suggests they do not exist.
42. Wirth’s Law: software is getting slower more rapidly than hardware is getting faster. If it’s easy to create loads of software you can get a complex mess on your hands, whereas hardware is more difficult to create and therefore requires more thoughtful, longer-term design thinking. The goal is balance and this is a really useful concept to think about if you are adopting DevOps principles. How do you make sure your software and hardware people are collaborating effectively to minimise this sort of mismatch from occurring?
43. Zawinski’s Law: every programme will attempt to expand until it can eventually read emails, and those which can’t will eventually be replaced by those which can. Feature-creep is real!

Do you have any questions, comments, experiences or additional laws to add? Please share them in the comments below!