Brooks’ Law
Adding human resources to a late software project makes it later
This classic law reminds us that software development isn’t factory work. You can’t simply throw more people at a problem and expect it to resolve faster. New team members need onboarding, coordination overhead increases, and communication complexity grows exponentially.
Why it happens:
The cost of communication and coordination doesn’t scale linearly; it scales exponentially. The number of communication channels in a team is n(n-1)/2. A team of 5 has 10 channels. A team of 10 has 45. You also have the ramp-up cost; new people are a net negative on productivity for weeks, sometimes months, as they consume the time of your existing team members.
What to do about it:
Instead of adding people to the critical path, find ways to partition the work. Can a new sub-team take on a distinct, parallelizable piece of the project? Can you descale the project’s scope to meet the deadline? Often, the best way to speed up is to remove work, not add people.
Price’s Law
In any group, 50% of the work is done by the square root number of people
This is one of those laws that feels deeply unfair, but once you see it, you can’t unsee it. On a team of 16 engineers, this law predicts that four of them will produce half of the meaningful output. On a team of 25, it’s five. It’s a power-law distribution that shows up everywhere, from academic citations to software commits.
I remember leading a 20-person platform team responsible for a critical set of internal services. We were tracking commits, pull requests, and closed tickets, and on the surface, productivity looked reasonably distributed. But when a major outage hit our authentication service, who was on the emergency call at 2 AM? The same three people who had designed it. When we needed to refactor the data model for our most complex service, who led the design review and wrote the foundational code? The same three people, plus one other senior engineer.
The other 16 people weren’t lazy—they were writing documentation, fixing minor bugs, and attending meetings. They were doing work. But the critical, high-leverage, foundational work that determined the success or failure of the platform was consistently driven by a small, core group—the square root of the team.
Why it happens:
This isn’t about some people working 10x harder. It’s about a combination of talent, experience, and, most importantly, context. The engineers who have been there longer, who have deep knowledge of the system’s quirks, and who understand the “why” behind the architecture can simply operate with more leverage. They can solve in an hour a problem that would take another developer a week of research. Their contributions are multiplicative; they unblock others and create platforms for the rest of the team to work on.
What to do about it:
Your first instinct might be to “fix” this imbalance. Don’t. You’ll never make everyone’s output equal, and trying to do so is a recipe for frustration. Instead, your job as a leader is to manage this reality:
- Identify and Unleash: First, you have to be honest about who these people are. They are not always the loudest or the most visible. They’re the ones people turn to when they’re truly stuck. Once you’ve identified them, your primary job is to protect their time and focus. Shield them from low-value meetings and organizational drag. Point them at the gnarliest, most ambiguous problems—the ones that, if solved, create the most leverage for everyone else.
- Raise the Median: For the rest of the team, the goal isn’t to turn them into that top tier. It’s to raise the overall team average. The best way to do this is to use your high-leverage engineers as multipliers. Have them lead mentorship programs, establish clear engineering patterns, build better tooling, and run tough but fair code reviews. Their job isn’t just to solve the hard problems, but to make it easier for everyone else to solve the medium ones.
- Manage the Risk: This concentration of expertise is also your single biggest risk. If one of those four engineers on my 16-person team left, I didn’t just lose 1/16th of my team; I lost a much bigger chunk of its effective output. They are your biggest flight risks because they know their value. You must actively work to de-risk their departure through aggressive knowledge sharing, pair programming on critical components, and insisting on high-quality documentation for their designs. Your goal is to make their knowledge organizational knowledge, not just individual knowledge.
Ringelmann Effect
Individual members of a group become increasingly less productive as the size of their group increases
Early in my career, I was part of a four-person “tiger team” that built the first version of our company’s mobile API. We were unstoppable. We sat together, made decisions in minutes, deployed multiple times a day, and knew every corner of the codebase. We didn’t need a project manager because we could literally shout across the desk to sync up. The product was a huge success.
So, the company decided to “invest” in our success. Our team of four grew to twelve over the next six months. We were told this would triple our output. Instead, our velocity ground to a halt. Our daily stand-up, once a 5-minute huddle, became a 30-minute status report where everyone tuned out. A simple database schema change that used to be a 10-minute conversation now required a formal design review meeting with twelve people, each with an opinion. We were drowning in process, and the original magic was gone. We learned the hard way that individual productivity is not additive; in fact, it’s often subtractive in large groups.
Why it happens:
This isn’t just about communication overhead, though that’s a big part of it (see Brooks’ Law). The Ringelmann effect points to two deeper psychological factors:
- Loss of Motivation (Social Loafing): In a small group, your individual contribution is highly visible and feels critical. If you don’t do your part, the team fails, and everyone knows it. In a group of twelve, it’s easy to think, “My effort doesn’t matter as much. Someone else will pick up the slack.” Your sense of individual impact becomes diluted, so you unconsciously pull less hard on the proverbial rope.
- Diffusion of Responsibility: In a four-person team, ownership is crystal clear. If the authentication service goes down, everyone knows it’s Sarah’s code. In a twelve-person team, ownership becomes fuzzy. Is it a backend issue? A deployment script problem? Is the new guy supposed to be monitoring that? This ambiguity leads to tasks being dropped and a general lack of accountability.
What to do about it:
As a leader, you must be a bulwark against the Ringelmann Effect. The solution isn’t to work everyone harder; it’s to change the structure of the work itself.
- Honor the “Two-Pizza Rule”: This isn’t just a cute Amazon aphorism; it’s the most effective defense against this effect. Keep your teams small enough that they can be fed by two pizzas—typically 5 to 9 people. This size is the sweet spot that maximizes skill diversity while minimizing coordination overhead and motivation loss.
- Divide and Conquer (Intelligently): When a product’s scope grows to legitimately require more than 9 people, do not create a 15-person “super team.” Instead, split them into two or more smaller, mission-focused teams. The key is to divide them along lines of ownership, not technical layers. Create a “Search & Discovery” team and a “Checkout & Payments” team, not a “Frontend Team” and a “Backend Team.” This re-establishes clear ownership and a strong sense of mission for each smaller group.
- Make Contributions Visible: Actively fight the dilution of individual impact. Ensure that work is clearly attributed and that successes are celebrated publicly, connecting individual efforts to team outcomes. When someone fixes a critical bug or ships a valuable feature, call it out. This reinforces the idea that every person’s contribution is seen and matters.
Cagan’s Law
We need teams of missionaries, not teams of mercenaries
A team of mercenaries is given a specification and paid to build it. Their job is to execute a plan. A team of missionaries is given a problem and empowered to solve it. Their job is to achieve an outcome. Mercenaries build features; missionaries defeat user problems. The latter consistently produces superior results because they operate with a fundamentally different level of ownership and engagement.
Why it happens:
- Ownership of Outcome: Mercenaries are accountable for output (“Did you ship the feature?”). Missionaries are accountable for the outcome (“Did we reduce churn?”). This focus on impact forces a higher level of critical thinking and creativity. The team is empowered to challenge requirements that don’t serve the goal.
- Intrinsic Motivation: Purpose is a powerful motivator. A belief in the mission creates resilience when facing inevitable technical debt, changing requirements, or project setbacks. Mercenary teams get demoralized by obstacles; missionary teams are energized by the challenge of overcoming them to reach the objective.
- Better Solutions: The engineers closest to the code often have the most insight into technical possibilities and constraints. A mercenary culture silences this, demanding adherence to a spec. A missionary culture leverages it, expecting the team to discover the best solution, not just implement the assigned one.
What to do about it:
- Frame Work as Problems, Not Specs: Don’t hand your team a ticket that says, “Build a three-tabbed settings page.” Instead, frame the work as, “Our users are struggling to configure their notification preferences, causing frustration and support tickets. Find the best way to solve this.” Provide the context and the success metric, then let the team own the solution.
- Connect Teams Directly to Users: Nothing builds a sense of mission faster than direct exposure to user pain and success. Have engineers sit in on sales calls, read raw support tickets, and observe user testing sessions. This creates empathy and transforms abstract requirements into tangible human problems that need solving.
- Measure and Reward Outcomes: Shift the definition of “done.” “Done” isn’t when the code is merged; it’s when the business metric has moved. Stop celebrating “velocity” (output) and start celebrating “a 15% reduction in onboarding time” (outcome). Align the team’s definition of success with the user’s and the company’s.
Peter Principle
People in a hierarchy tend to rise to a level of respective incompetence
We promote our best engineer to be a manager, and six months later, she’s miserable, her team is adrift; we’ve lost our best engineer and gained a struggling manager. Sound familiar?
Why it happens:
The skills that make a great individual contributor (deep technical focus, solo problem solving) are often the opposite of what makes a great manager (delegation, communication, empathy, strategic thinking). We reward excellence in one role with a promotion to a completely different role.
What to do about it:
- Dual Career Tracks: Create a viable, prestigious, and well-compensated path for senior ICs (Staff, Principal, Distinguished Engineer). Promotion shouldn’t automatically mean becoming a people manager.
- Try Before You Buy: Let potential managers act as a “tech lead” on a project or mentor an intern. Give them a taste of the role before making the switch permanent.
- Train, Don’t Assume: New managers need rigorous training in coaching, feedback, and project management. Don’t just throw them in the deep end.