Team Lead Mindset
Laws and Biases Every Lead Should Know
Conway, Brooks, Goodhart, Gall, Hyrum, Chesterton and more, each in one sentence with a lead's use, plus common thinking biases.
On this page
In one line: a handful of well-known rules of thumb explain many team problems: why architecture copies the org chart, why adding people to a late project makes it later, why a measure stops working once it is a target, and why meetings spend an hour on button colour. Know them by name, use them as questions, and never treat them as proven laws.
Leads are often asked "why does this keep happening?" The famous rules of thumb in software give you words for patterns that many people have seen again and again. Naming a pattern helps the team talk about it calmly, without blaming a person.
This lesson takes the laws and biases most useful for a lead, explains each in one sentence, and shows how you would use it. Read Lesson 0 first for the answer shape.
Everything here is common practice and opinion. The "laws" are mostly observations, not scientific laws. Use them as questions to ask, not as proof.
What I checked. I read directly the README of dwmkerr/hacker-laws (about 27k stars in an April 2026 snapshot; I read the first 100,000 of about 117,000 characters). The one-sentence definitions below follow that page. The "what a lead does" column is my own opinion and is not from the page. For biases I use the "Biases" section of charlax/engineering-management, which lists Daniel Kahneman's Thinking, Fast and Slow, a cognitive-bias cheat sheet and a "backfire effect" comic; I did not open them. One more caution: star counts on GitHub can be partly inflated by fake stars (a 2025 research paper estimated this), so stars show interest, not truth.
Words used in this lesson
- A rule of thumb is a useful pattern that is often true but not always.
- A bias is a habit of thinking that pushes you to a wrong judgement in a predictable way.
- A metric is a number you track, such as bugs closed per week.
- A target is a number someone is told to reach.
- Bikeshedding is spending a lot of time on a small, easy topic while a big, hard one gets little attention.
Laws about teams and work
| Law | In one sentence | What a lead can do with it (opinion) |
|---|---|---|
| Conway's Law | A system's structure tends to mirror the communication structure of the organisation that builds it | Before you design services, look at your teams. If two teams must change one module, expect friction. Change the team shape or the design on purpose. |
| Brooks's Law | Adding people to a late project tends to make it later (ramp-up time and more communication) | When a deadline slips, first cut scope or move the date. Add people early, not late, and for separable work. |
| Hofstadter's Law | Things take longer than you expect, even when you allow for Hofstadter's Law | Give ranges and add a buffer for the unknown. See Lesson 3. |
| Parkinson's Law | Work expands to fill the time available | Use small, time-boxed tasks, and a clear "done" definition. |
| Goodhart's Law | When a measure becomes a target, it stops being a good measure | Do not reward "most commits" or "most tickets". See the warning in Lesson 4. |
| Law of Triviality (bikeshedding) | Groups spend too much time on small, easy issues and too little on big, hard ones | Automate small things (formatting, lint), and start the meeting with the hard decision. |
| Dunbar's Number | People can keep only a limited number of stable relationships (often cited as about 150) | A big team needs structure, not just good will. Keep teams small (see the Two Pizza Rule: a team small enough to be fed by two pizzas). |
| Peter Principle | People tend to be promoted until they reach a level where they are not competent | Do not promote only because someone is the best coder. Check that they want and can do the new work, and train them. |
| Dunning-Kruger effect | People with low skill in an area tend to overestimate it, since judging good work needs the same skills as doing it | Ask for evidence, not confidence, and give juniors safe ways to test their ideas. |
Laws about code and design
| Law | In one sentence | What a lead can do with it (opinion) |
|---|---|---|
| Gall's Law | Complex working systems grow from simpler working systems; a complex system designed from scratch tends not to work | Start small and working, then grow. Be careful with big-bang rewrites (Lesson 6). |
| Hyrum's Law | With enough users, every observable behaviour of your API will be depended on by someone, whatever the contract says | Treat "small" changes to public behaviour as breaking. Version, announce and give time. |
| Kernighan's Law | Debugging is harder than writing code, so code written as cleverly as possible is too hard to debug | In review, prefer clear code to clever code. |
| YAGNI | Build a feature when you actually need it, not when you think you might | Ask "who needs this now?" before building a general solution. |
| KISS | Keep designs simple and avoid needless complexity | When two designs work, choose the one that is easier to explain. |
| Scout Rule | Leave the code cleaner than you found it | Encourage small clean-ups inside normal work. |
| Chesterton's Fence | Do not remove or change something until you know why it exists | Before deleting "useless" code or a process, find its history. |
| Premature optimization | Optimizing before there is evidence you need to wastes effort and adds complexity | Measure first. Ask "what is the number, and what is the target?". |
| Postel's Law | Send only well-formed data, but accept imperfect input when you can understand its intent | A good rule for being kind to callers. Remember Hyrum's Law: accepting odd input also creates users who depend on it. |
| Pareto Principle | About 80% of effects often come from 20% of causes | Find the few bugs, endpoints or customers that cause most of the pain, and start there. |
These are not laws of nature. Each one fits some situations and fails in others. A good habit is to name the law and then check it against facts: "This looks like Conway's Law. Do the module owners really sit in different teams?"
Biases that hurt technical decisions
The reading list for engineering managers has a short "Biases" section. It points to Daniel Kahneman's Thinking, Fast and Slow (a tour of how human judgement goes wrong), a cognitive-bias cheat sheet, and a comic about the backfire effect (showing someone evidence against their belief can make them hold it more strongly). I did not read those, so here are the simple ideas in my own words, as habits to check:
- Sunk cost. "We already spent six months, so we must continue." Past cost is gone; ask what is best from today. (This is a well-known idea; it is not in the hacker-laws text I read.)
- Confirmation. You look for facts that agree with your choice. Ask one person to argue the other side.
- The loudest voice wins. Write the options down and compare facts, not volume.
- Backfire. If someone pushes back harder when you show data, stop arguing. Ask what evidence would change their mind.
- Familiarity. You prefer the tool you know. Test it by asking: "Would I still choose it if I did not know it?"
Interview questions
What is Conway's Law, and how does it affect your work? (Senior signal)
It says a system's design tends to copy the communication structure of the organisation. If three teams build a product, you often get three parts with sharp borders between them. In practice, I look at team boundaries before I design services: a module that two teams must change together will cause friction. I can either change the design to fit the teams, or change the teams to fit the design. I choose on purpose, instead of letting it happen by accident.
A project is late. Should we add more people? (Trap)
Usually not as a first move. Brooks's Law says adding people to a late project tends to make it later, because new people need time to learn and everyone needs more communication. I first look at scope (what can we cut or ship in a smaller first version?) and the date. If I add people, I add them for work that can be separated and well documented, and I accept that the first weeks will be slower. Adding people early is much better than adding them late.
How do you measure your team's performance without gaming? (Senior signal)
I remember Goodhart's Law: when a measure becomes a target, it stops being a good measure. So I use a few measures of the process, such as how long a change takes to reach users and how often releases fail, to find problems, and I talk to the team about what they show. I do not use one number to rank people, and I do not set a target for a single metric alone. If a number improves but the work feels worse, I trust the work and look again.
How do you stop meetings from wasting time on small things? (Must know)
The Law of Triviality says groups spend most time on easy topics. I automate the small decisions (a formatter and lint rules for style, a template for naming), put the hard decision first in the agenda, and give each topic a time limit. If a small topic still takes over, I say "let's park this and decide it in a comment", and I make sure someone owns it. Bikeshedding in reviews is a signal that the tooling is missing.
Why are you careful about changing "small" public behaviour? (Senior signal)
Hyrum's Law: with enough users, every observable behaviour of an API will be depended on by someone, even if the documentation never promised it. So a "small" fix to the order of results, an error message or a timing can break callers. For a public API or shared library I version changes, announce them early, keep the old behaviour for a clear period when I can, and look at real usage before I remove anything.
Someone proposes deleting a strange piece of code or process. What do you do? (Senior signal)
I think of Chesterton's Fence: do not remove it until you understand why it was put there. I look at the history (blame, old tickets, past incidents), ask the people who were there, and write what I learn. If the reason is gone, we remove it with a way back (a flag, or a revert-friendly pull request). If I cannot find a reason, I add a test or a metric first, then remove it in a small step and watch.
You notice you are defending a choice mostly because you already spent a lot on it. What do you do? (Trap)
That is the sunk-cost trap. I write down what is true now: the cost to continue, the cost to stop, the expected benefit. I ask, "If we were starting today with this knowledge, would we choose this?" and I invite a colleague to argue the opposite. If the answer is no, I say so openly, and use what we learned. Changing your mind in the open makes it easier for the team to do the same.
Key takeaways
- Known rules of thumb give the team shared words for patterns. They are observations, not laws of nature.
- Conway: design follows team structure. Brooks: adding people to a late project delays it. Goodhart: a target ruins a measure. Gall: grow from a simple working system. Hyrum: every visible behaviour gets depended on. Chesterton: understand before you remove.
- Use a law as a question and check it against facts.
- Know common biases (sunk cost, confirmation, loudest voice, familiarity, backfire) and build habits against them: write the options, argue the other side, ask what would change your mind.
- Stars on a GitHub list show interest, not truth.
- This is common practice and opinion. Adapt it to your team.
What's next
Next: 1:1s, feedback, delegation and conflict, Lesson 8. Practise: pick one law above and find one real example from your own project in the last year. Write two sentences on what you would do differently.
Published by Jainik · Last updated · How these lessons are made
Keep learning
Part of the study guide
Related series