Brooks's Law

"Adding manpower to a late software project makes it later." — Fred Brooks, The Mythical Man-Month, 1975

The counter-intuitive point isn't that people are lazy — it's that the "man-month" itself is a myth: people and time aren't interchangeable. Adding hands slows you down via three hard mechanisms: (1) ramp-up — newcomers produce almost nothing for weeks and drain veterans' time to onboard them; (2) communication overhead grows as n(n-1)/2 — 3 people = 3 channels, 6 people = 15. Work added is linear, but coordination cost explodes quadratically; (3) non-partitionability — some tasks simply can't be split, as in Brooks's line, "nine women can't make a baby in one month."

Non-trivial: (1) it's isomorphic to Amdahl's Law in distributed systems — the small non-parallelizable serial bottleneck caps the speedup from adding cores. Adding people ≈ adding cores; communication ≈ synchronization overhead — the same math. (2) It's a complexity phenomenon: coordination cost balloons superlinearly like a fully-connected graph, so "just hire a few more" is almost always an illusory fix. (3) The real remedy isn't more people but shrinking the communication surface — modularization, clean interfaces, reduced scope (echoing Conway's Law: the org's communication structure gets etched into the code).

3-person team 3 channels 6-person team 15 channels double the people → communication cost ∝ n(n-1)/2, quadratic; work added is only linear
Brooks's Law: adding people adds coordination cost, not capacity
Classic example

Brooks drew the law from running IBM's OS/360 operating system: after the project slipped, they threw people at it, and the training cost plus the exploding communication overhead consumed all the added capacity — progress went backward, not forward. It became software engineering's most expensive lesson: the "add people" button managers love most is exactly the one a late project should never press.

BigCat scenario

The AI era gives the law a new edition: when you stop adding people and start adding agents, does it still hold? It depends on whether those agents must coordinate. If they share context and edit the same artifact → the n² cost returns (the hard part of multi-agent systems is orchestration, not single-unit capability). The "AI super-individual" leverage partly comes from collapsing the communication graph to a single node — one person decides, bypassing the Brooks tax. So the right scaling question isn't "add a few more agents," it's "can I carve the task into independent, non-communicating chunks?"


English Prompt
Our project [describe] is late and we're considering adding [N] people/agents. Stress-test with Brooks's Law: 1. Estimate the new communication channels (n(n-1)/2) and ramp-up cost; judge whether net capacity is positive or negative. 2. Identify the non-partitionable serial bottleneck (the Amdahl segment) that more people can't fix. 3. Propose one "shrink the communication surface" alternative instead of adding people — how to carve the work into independent, non-communicating chunks.

The Peter Principle

"In a hierarchy, every employee tends to rise to their level of incompetence." — Laurence Peter, 1969

The mechanism is brutally simple: promotion rewards performance in the current role, but the new role demands a different skill set. So you keep getting promoted until you land in a job you can't do well — and promotion stops there. Pushed to the limit: every post tends to end up occupied by someone incompetent at it, and the actual work gets done by those who haven't yet reached their level of incompetence.

Non-trivial: (1) it's fundamentally an optimization using the wrong proxy — treating "past performance" as a proxy for "fitness for the next role." It's the organizational version of Goodhart's Law: once "current performance" becomes the promotion target, it stops being a reliable signal of ability. (2) The root sickness is conflating doing the work with managing the work — a top engineer ≠ a top engineering manager; two different skill sets. (3) The fix isn't to stop promoting but to change the selection function: dual ladders (technical track / management track each capped separately), promote on "ability already demonstrated at the next level" rather than "results at the current one," and trial-in-role before confirming. (4) A curious corollary is "creative incompetence" — deliberately appearing slightly bad at irrelevant things to dodge a promotion that would push you past your ceiling.

Classic example

The most common script: promote the company's #1 salesperson to sales manager. The organization loses twice — it forfeits a top closer and gains a poor manager, because "closing your own deals" and "teaching a team to close, forecast, and manage morale" are entirely different skills. Armies, hospitals, and universities run this script everywhere: the best doctor is pushed into being a dean, and from then on neither sees patients nor runs the hospital well.

BigCat scenario

(1) Personal growth: a senior technologist moving toward "super-individual" hits their own Peter ceiling — going from writing code to orchestrating a swarm of AI agents and making architectural trade-offs demands product judgment and systems design, not faster typing. The tell: your strongest old skill is becoming the lowest-marginal-utility one in the new role. (2) Parenting is isomorphic: a child excelling at one stage (say, rote memory in early grades) is no reason to "promote" expectations to the next stage — which may demand abstract reasoning or self-regulation, a different skill set. Predicting fitness for the next level from results at the last is the Peter Principle inside the family.


English Prompt
I'm considering [promoting someone / taking on a new role myself]. Current role: [describe]. Target role: [describe]. Apply the Peter Principle: 1. List the core skills each role truly requires; flag which ones don't overlap — the non-overlap is the risk zone. 2. Assess how poorly "excelling now" actually predicts "competence in the new role." 3. Propose one design that lowers the failure odds (trial-in-role, dual ladder, or a different evaluation axis).

Pournelle's Iron Law of Bureaucracy

"In any bureaucracy, the people devoted to the bureaucracy itself end up in control, and those dedicated to its goals have less and less influence." — Jerry Pournelle

Every organization holds two kinds of people: the mission people (there for the goal the org exists to achieve) and the organization people (loyal to the institution itself). The law says: over time, the organization people win control. Why? Because internal power is decided by internal games, not external goals — the organization people optimize exactly what confers internal power (budget, headcount, process compliance, managing upward), while the mission people optimize external outcomes. Two tracks; only the first leads straight to the center of power.

Non-trivial: (1) it's a pure selection-pressure argument — the org is a fitness landscape, and any trait that wins internal power gets selected and amplified; "mission orientation" simply isn't the trait that wins the internal game. Same family as evolution and the principal-agent problem (the org becomes its own principal). (2) It's an organizational entropy: without continuous energy injected (external competition, founder tension, accountability), the system drifts toward "self-preservation," its lowest-energy state — process for process's sake, meetings for meetings' sake. (3) Every countermeasure points to re-introducing external pressure: stay small, bind to real market/competition feedback, keep founder-grade mission intensity, and periodically tear down and rebuild. (4) Key diagnostic: when "good for the org" conflicts with "good for the mission," which does your organization default to? The answer is the dial showing how far the law has already run.

Classic example

Universities and public schools are textbook cases: the count, pay, and clout of administrative and compliance staff grow, over the long run, far faster than those of the teachers who actually educate — the people who run the school gradually outweigh the people who teach. Any institution old enough, large enough, and short on external competitive pressure shows the same trajectory: a department built for a mission slowly becomes an entity that runs mainly to sustain its own existence.

BigCat scenario

(1) Inside a company: the platform/infra team founded to "enable product teams" quietly evolves into a gate that exists to weigh its own process — it starts protecting its approval authority rather than the delivery speed it once promised. The tell: the number of processes rises while the outcome metric it's meant to serve doesn't move. (2) Super-individual angle: a solo operator's biggest structural advantage is zero bureaucratic density — no organization person can seize power from you. But beware a subtle version: even your own tools and systems can "go organization-people" — you start maintaining the note system for the note system's sake, building process for process's sake, not for output. Ask regularly: "Is this step serving the outcome, or serving the system itself?"


English Prompt
My organization is [describe]. Run a "drift checkup" using the Iron Law of Bureaucracy: 1. Separate which current behaviors/units serve the mission from which serve the institution itself. 2. Identify 2 processes that are "good for the org but not clearly good for the mission," and gauge how far the drift has gone. 3. Propose one concrete move that re-injects external pressure and pulls power back toward the mission people.

Parkinson's Law of Triviality

"The time spent on any item is in inverse proportion to the money involved." — C. Northcote Parkinson, 1957 (a.k.a. "bikeshedding")

Parkinson's classic parable: a committee approves a multi-million-dollar nuclear reactor in two minutes (no one truly understands it), then argues 45 minutes over the few-hundred-dollar bike shed (everyone has an opinion), and debates the coffee budget longest of all. The law in one line: discussion time is inversely proportional to an item's importance. The driver isn't laziness but accessibility: trivial things are comprehensible to all and carry almost no risk of "being wrong" exposing your ignorance; major decisions are the opposite — challenging the reactor design would reveal you don't understand it, so everyone wisely stays quiet.

Non-trivial: (1) it's attention misallocation hijacked by comprehensibility rather than importance — same root as availability bias: the brain mistakes "easy to process" for "worth processing." (2) Software calls it bikeshedding: an hour spent on variable naming and indentation style in a PR, while a risky concurrency change sails through. (3) The deep cost is that the organization's cognitive bandwidth gets eaten by cheap opinions — everyone wants to leave an "I participated" mark, and the trivial item is the safest place to leave one. (4) Defenses are all structural: allocate agenda time inversely to stakes (the bigger the call, the more it's timeboxed to a small expert group; the smaller, the more it's delegated or defaulted), kill the debate with tooling (let a linter/formatter make style "non-discussable"), and raise the cost of cheap opinions. (5) Echoing energy management: trivial decisions drain decision-making the most, so automating or defaulting them frees scarce attention for the real reactor.

Classic example

It's the reactor-vs-bike-shed committee parable itself — so precise that "bikeshedding" became global engineering slang. The biggest, costliest, most irreversible decision (the reactor) gets waved through because no one can follow it; the smallest, cheapest, most universally comprehensible one (what color to paint the bike shed) absorbs the whole meeting's energy. The livelier the debate, the more it often signals the item is irrelevant.

BigCat scenario

(1) Engineering: rather than relitigating tabs vs spaces in code review, add a linter/formatter to make that entire class of debate non-discussable — structurally eliminate bikeshedding and reserve review firepower for architecture and concurrency safety. (2) AI workflow: spending an afternoon repeatedly tweaking a prompt's wording (trivial, controllable, and satisfying) while dodging the hard question "is this agent architecture even right?" is textbook self-soothing bikeshedding. Set a rule: no editing prompt copy until the architecture question is settled. (3) Home: the energy a family burns on "which restaurant tonight" should go to real reactors like "which school" or "what family values." Defaulting or rotating trivial decisions frees attention for the major ones.


English Prompt
Here's the agenda and time breakdown of our last [meeting/review/decision]: [describe]. Diagnose with Parkinson's Law of Triviality: 1. Flag items where "discussion time ÷ real importance" is badly skewed (the bikeshedding targets). 2. Explain why exactly these trivial items captured the attention (accessibility / desire to leave a mark / risk of exposing ignorance). 3. Propose a structural fix: which debates to kill outright with tooling/defaults, and which to timebox and hand to a small expert group.