9 Laws Every Manager Should Know (And Most Break Daily)
The unwritten rules of management... finally written down.
Every industry has its unwritten rules. Just like physics has laws, and economics has laws, so does leadership.
The only difference is that nobody bothers to write them down in a management training.
At least, I never had these handed down to me. I learnt them through observation over several years leading teams and driving results. I’m sure you have seen them, too.
In this issue, I’ll share the nine that changed how I lead. I’ve written full deep dives in this newsletter for most of them, linked below if you want to go deeper.
1. Goodhart’s Law
“When a measure becomes a target, it stops being a good measure.”
Elena was an engineering manager at a mid-size fintech startup. Her org started tracking “story points completed per sprint” as the main measure of the team's health. Within a few weeks of this new process, the story point estimates started going up across every team. It was the same work, just larger numbers.
Elena later told me she didn’t notice it happening until she compared velocity numbers across two quarters, and realized that her team wasn’t actually shipping faster. Instead, they had just learned to game the numbers.
That’s Goodhart’s Law in action: the moment you tell people what you’re measuring, you’ve told them exactly where to cut corners.
Key takeaway: Measure outcomes that are hard to game, or a combination of measures that together represent the key goals such as shipped features, customer impact, or retention. Don’t measure proxies or vanity metrics that are easy to game.
Read the full deep-dive on Goodhart’s Law and how to counter it below ⬇️
2. Parkinson’s Law
“Work expands to fill the time available for its completion.”
Marcus ran a platform team at a large tech company. He gave his team three weeks to migrate a legacy service. Three weeks later, it was done… right on schedule, with no surprises.
Then a security issue was reported by a high-profile customer, and it forced the same migration onto a different team, with four days’ notice instead of three weeks.
The team completed the migration and shipped in four days.
Marcus told me that was the moment he stopped trusting his own estimates. The work wasn’t actually three weeks of work. It was more like 3-4 days of work with three weeks of padding built in, because that’s how much time was available.
Key takeaway: Give a task less time and watch how much of the original estimate was actually just slack. Tight deadlines are often just honest, not unreasonable.
Read the full deep-dive on Parkinson’s Law below ⬇️
3. The Pareto Principle
“Roughly 80% of your results come from 20% of your efforts.”
Noor managed a product team at a growth-stage startup and once tracked every meeting on her calendar for a month. Then, she rated each meeting with the actual impact of it on the roadmap. Out of around forty meetings on her list, she counted six that had actually been impactful towards their goals.
The other thirty-four of them, like status updates, quick-syncs, check-ins, etc. felt productive in the moment, but they didn’t really help move the team forward. Most of them could have been done asynchronously on Slack.
That’s the Pareto Principle (or 80/20 rule) in action. After this realization, started asking, before accepting any recurring meeting, whether it was the 20% or the 80%.
Key takeaway: Rank your last ten decisions or projects by actual impact, not effort. You’ll almost always find two or three that mattered enormously and a long list that didn’t.
Read the full deep-dive on the Pareto Principle below ⬇️
💬 Quick favor
If these laws are resonating with you, please hit reply or drop a comment below and tell me which law you’ve seen play out on your own team. I’d love to know!
4. Brooks’s Law
“Adding people to a late software project makes it later.”
Diego was leading a project that had slipped two sprints behind schedule. His director’s instinct was to pull two engineers off another team to help catch up. Diego pushed back, but got overruled, and the two engineers were added to the team to help out.
Two weeks later, the project was further behind than before the new engineers joined. These new engineers needed onboarding, getting accustomed to the new team’s ways of working, and just getting to know everyone. The existing team ended up spending a lot of their time explaining the context and background, and less on writing code. What looked like more hands turned into more meetings.
Diego, in retrospect, later told me that the lesson for him was that more people almost never equals more productivity, especially when added to an already late project.
This is Brooks’ Law in action. More people usually makes the communication problem worse before it makes the capacity problem better.
Key takeaway: Before adding headcount to a late project, ask whether you’re solving a capacity problem or a coordination problem.
5. Conway’s Law
“Organizations design systems that mirror their own communication structure.”
Wei led the backend team at a software company that had just split into two independent teams, one owning checkout, one owning fulfillment. These teams had separate meetings, separate processes, and separate communication channels.
When the product was shipped, customers noticed the checkout flow felt like a different product from the fulfillment tracking, when really the experience should have been seamless and cohesive.
This was Conway’s Law in action - the two teams who were separated in the org chart had shipped a workflow that looked separated to the customers.
Wei fixed it by bringing the two teams together by merging the standups, and integrating the communication channels. He didn’t even touch the architecture - it automatically adapted to the new change.
Key takeaway: Don’t ship your org chart. Organize your teams based on the capability or experience you intend to deliver to your customers, not the other way around.
Read the full deep-dive on Conway’s Law below ⬇️
6. The Peter Principle
“People rise to the level of their incompetence.”
Fatima was the strongest individual contributor on her team. She was the engineer everyone went to with the hardest bugs or issues. For her manager, the natural next step was to promote her into management.
Six months later, after being promoted to manager, she told me she missed writing code and that she wasn’t sure she was actually good at the new job yet.
The mistake was one that most, if not all, managers make: they assume that the only reward for being excellent at one thing is to hand them a different thing.
That’s the Peter Principle - people get promoted based on how good they were at their last job, not how good they'll be at the next one. Eventually, everyone lands in a role that stretches past what actually made them great.
Key takeaway: Promotions should be a bet on a different skill set, not a reward for the old one.
Read the full deep-dive on the Peter Principle below ⬇️
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.”
Owen’s team adopted Claude Code as the AI coding assistant as soon as it launched to the public. From there on, the expectations on what this tool could do were sky-high. In fact, some people on the team thought it would replace half their headcount by the end of the quarter.
A year later, Owen told me that the tool had completely changed how the whole team worked, by changing what junior engineers spent their first six months learning. Nobody was talking about it as a big deal anymore. It just was how the team worked now.
That was Amara’s Law in action - we overestimate what a new technology will do in the short term and underestimate what it'll do over the long term.
Key takeaway: Don’t panic when a new tool falls short of the hype in month one, and don’t get complacent just because it stopped being exciting. The real impact usually shows up later than everyone expects.
Read the full deep-dive on Amara’s Law below ⬇️
8. The Dunning-Kruger Effect
“People with low ability tend to overestimate their competence, while people with high ability tend to underestimate theirs.”
Ravi was about to promote an engineer, Liz, on his team based mostly on how she showed up in meetings (confident, decisive, always ready with an answer). Meanwhile, his strongest coder, Mark, who actually shipped the hardest features, sat in the same room, somewhat reluctant to speak up.
Ravi told me he almost made the call to promote Liz, but he stopped and asked a harder question: was he rewarding the person who sounded most sure (Liz), or the person who was actually best at the job (Mark)?
That’s the Dunning-Kruger Effect in play.
If you don’t know what “great” looks like yet, you assume you’re already there. If you do know what “great” looks like, you see exactly how far you have to go, and it shows up as hesitation, not confidence.
Key takeaway: Don’t promote or reward the loudest voice in the room by default. Confidence is easy to see. Competence is harder to notice, but is actually what you need to look for.
Read the full deep-dive on the Dunning-Kruger Effect below ⬇️
9. The Bannister Effect
“Once one person proves a limit was never real, everyone behind them moves faster.”
Simone managed a cross-functional team where junior engineers never pushed back on senior leads, even when they’d clearly spotted a real problem. It wasn’t a rule or culture code written anywhere. It was just how the team had always worked.
One sprint, a new hire, Tanuja, flagged a flaw in a senior engineer’s rollout plan in front of the whole team. Simone made a point of thanking him publicly, right there in the meeting, and said the team needed more of exactly that kind of thinking.
Simone told me that one moment did something magical in the team. Within a month, two more junior engineers raised concerns they would normally have kept to themselves. Nobody told them to… the mental barrier they previously had was no longer there because they had seen that this was possible in the team.
That’s the Bannister Effect in action. Watching something that was previously hard to imagine actually happen suddenly changes the belief toward it.
Key takeaway: Your team’s beliefs change when they see something happen, not when they hear you ask for it. Go first, do it visibly, and celebrate the next person who follows.
Read the full deep-dive on the Bannister Effect below ⬇️
In Summary
In this article, we discussed the nine laws that have changed how I lead.
Goodhart’s Law: When you turn a measure into a target, people optimize for the measure, not the outcome it was supposed to represent.
Parkinson’s Law: Work expands to fill however much time you give it. Less time doesn’t mean less gets done — it just means less padding.
The Pareto Principle: Most of your results come from a small slice of your effort. The skill is finding which slice is actually doing the work.
Brooks’s Law: Adding people to a late project usually makes it later, not faster, because new people need ramping up before they add any speed.
Conway’s Law: Whatever you build ends up looking like the way your teams talk to each other. Product seams usually trace back to communication seams.
The Peter Principle: People get promoted based on their last job, not their next one, so eventually everyone lands somewhere that stretches past what made them great.
Amara’s Law: We overestimate what new tech will do in the short term and underestimate what it’ll do over the long term. The hype fades before the real impact shows up.
The Dunning-Kruger Effect: People with low ability tend to overestimate themselves, and people with high ability tend to underestimate themselves. Confidence and competence rarely line up.
The Bannister Effect: Once one person breaks a mental barrier and everyone watches it happen, the barrier stops holding anyone else back either.
💬 Let me know in the comments: which of these laws have you seen show up in your team most often?
❤️ Found this helpful?
If you found this post helpful, please like and share it with other managers who can benefit from it, including your boss :) If you have any feedback, please drop your comment below - it helps me keep improving the content. Thank you!
Awesome summary. Thanks for bringing these all together in one place. I have this article saved.