HAMMURABI

If

The brain instinctively treats all failures as threats to survival, demanding excessive caution for reversible decisions (Two-way doors). This causes "Analysis Paralysis."

Then

“If a decision is easily reversible (two-way door), ship within 24 hours to gain data. Only spend days/weeks on "one-way doors" (e.g., core database schema, security protocols).”

Unless

The "One-Way Door" Filter

If

When a minor rule is broken (e.g., skipping a test) and no immediate disaster occurs, the brain re-classifies this "deviance" as "normal." This is how catastrophic failures begin.

Then

“If you see a "hack" or a bypassed alert, do not say "it worked before." Either fix it immediately or document it as high-priority technical debt.”

Unless

Broken Windows Theory

If

We view legacy code/processes as "clutter" because we lack the context of their origin. The ego jumps to "simplify" by deleting what it doesn't understand.

Then

“You are forbidden from removing a "fence" (code/rule) until you can explain why it was put there — but put a deadline on the search. When it expires, take the fence down behind a flag, with a rollback ready, and watch what complains.”

Unless

Time-Boxed Archaeology — taken absolutely the rule removes nothing ever, because the reason is sometimes gone with the person who had it

If

In the face of a true anomaly, the brain defaults to the most "frequent" explanation to save energy. "It's probably just a transient network error," we say as the database corrupts.

Then

“When an error occurs, ask: "If this were the start of a total system collapse, what would the next 10 minutes look like?" If that scares you, investigate now.”

Unless

Pre-mortem / Red Teaming

If

People provide more feedback on simple things (naming variables) than complex things (distributed consensus) because everyone understands the simple things, creating a false sense of value.

Then

“If a PR review spends 80% of comments on style/naming, approve immediately and move the discussion to an automated linter config.”

Unless

Core Value Focus

If

We believe we can "architect" a complex system from scratch. We can't. Complex systems are too chaotic to be designed top-down.

Then

“A complex system that works is invariably found to have evolved from a simple system that worked. Start with a working "Hello World" and evolve.”

Unless

The MVP (Minimum Viable Product)

If

The software architecture is a map of the organizational chart. If two teams don't talk, their services won't integrate smoothly.

Then

“If you want a modular architecture, create modular, independent teams first. Do not fight the org chart with code.”

Unless

Inverse Conway Maneuver

If

With a sufficient number of users, every observable behavior of your system (even bugs) will be depended on by someone.

Then

“"Internal" doesn't exist once you have users. Version and feature-flag what you promise; deliberately vary what you do not, so nobody can build on it in the first place.”

Unless

Deliberate Variance — if every observable behaviour were sacred nothing could ever change, so vary what you never promised — randomised iteration order, planned outages — and the dependency never forms

If

Adding people to a late project increases communication overhead quadratically (n(n-1)/2 communication channels for n people). New people take more time from veterans than they contribute.

Then

“If a project is late, do not add people. Remove features or push the date.”

Unless

Scope Cutting

If

A user/engineer gets stuck on a solution (Y) and asks for help with it, forgetting that the original problem (X) might have a much simpler solution.

Then

“When someone asks "How do I do Y?", always reply "What are you trying to achieve with Y?"”

Unless

Five Whys

If

In a distributed system, assuming everyone follows the spec perfectly leads to brittle failures.

Then

“Be conservative in what you send (strict compliance) and liberal in what you accept (handle messy inputs gracefully).”

Unless

Fail-Fast (Internal only)

If

We take bugs/delays personally, assuming "malice" or "sabotage" when it's usually just lack of sleep or missing context.

Then

“Never attribute to malice that which is adequately explained by stupidity or lack of context. Focus on the system, not the person.”

Unless

Psychological Safety

If

"It always takes longer than you expect, even when you take into account Hofstadter's Law." The brain cannot visualize unknown unknowns.

Then

“Double your most conservative estimate, then add 20%. And expect to be wrong.”

Unless

Evidence-Based Scheduling

If

When a measure becomes a target, it ceases to be a good measure. If you reward "number of commits," people will make tiny, useless commits.

Then

“Never use a single metric to judge performance. Observe the system's output, not its proxies.”

Unless

Balanced Scorecards

If

For non-perishable things like ideas or software, the longer they have survived, the longer they are likely to survive.

Then

“If you need a stable system for 10 years, choose a technology that has already been around for 10 years (e.g., PostgreSQL over a new NoSQL).”

Unless

Hype Cycle Analysis

If

We continue investing in a failing tech stack/project because "we've already spent so much on it." The brain hates admitting a loss.

Then

“Ask: "If we started today with zero investment, would we choose this path?" If no, kill it.”

Unless

Zero-Based Budgeting

If

Copying the practices of successful companies (e.g., "The Spotify Model") without understanding why they worked there, hoping for the same results.

Then

“Do not adopt a tool/process because Google uses it. Adopt it because you have the exact problem Google had at that scale.”

Unless

First Principles Thinking

If

Optimizing a small part of a system has no impact if the bottleneck is elsewhere.

Then

“Find the 1% of the code that takes 90% of the time. Only optimize that. Ignore the rest.”

Unless

Theory of Constraints

If

All non-trivial abstractions, to some degree, leak. You can't use SQL without understanding how indexes work eventually.

Then

“Use abstractions to move fast, but ensure at least one person on the team understands the layer beneath it.”

Unless

T-Shaped Skills

If

80% of bugs come from 20% of the code. 80% of value comes from 20% of the features.

Then

“Identify the "Critical 20%" and give it 100% of your quality focus.”

Unless

Ruthless Prioritization

If

We study only the successes that survived and draw conclusions from them, ignoring the silent graveyard of failures that used the same strategy. The data we see is fundamentally skewed.

Then

“Before adopting a strategy because "Company X succeeded with it," research how many companies failed using the same approach. The dead don't write blog posts.”

Unless

Failure Studies / Post-mortem Culture

If

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

Then

“Code "cleverness" is a liability, not an asset. Write code that your future self, sleep-deprived at 3 AM, can still understand in 6 months.”

Unless

KISS (Keep It Simple, Stupid)

If

A solution designed to fix a problem creates a worse problem. In colonial India, a bounty on cobras led people to breed cobras for the reward. When the bounty was cancelled, breeders released their stock, making the problem worse.

Then

“For every incentive you create, ask: "If someone wanted to game this, how would they?" If you can find a way, the design is wrong.”

Unless

Second-Order Effects Analysis / System Dynamics

If

Humans can maintain approximately 150 stable social relationships. Dunbar's result is about neocortex size and group size across primates — it is not about work teams. What engineering extrapolates from it is a separate argument: communication channels grow as n(n-1)/2, so past the size where everyone can still hold everyone else's context, added people go into coordination rather than output.

Then

“When a team exceeds 7±2 people, split it. If "information-sharing meetings" start multiplying, that's the symptom of exceeding the cognitive limit.”

Unless

Two-Pizza Rule / Team Topologies

If

A simpler, "inferior" design that is easy to implement and adopt will beat a theoretically "correct" but complex design in the real world. Unix beat Lisp. HTTP beat CORBA.

Then

“A solution that is 80% correct and ships today will outperform a 100% correct solution that ships next year. Optimize for adoption, not elegance.”

Unless

The Right Thing / Perfectionism

If

"The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer." People are more motivated to correct mistakes than to answer questions.

Then

“When documentation is missing, post your best guess of how something works. The person who knows the truth will appear to correct you far faster than if you had asked directly.”

Unless

Socratic Method

If

In an emergency, the more people who are present, the less likely any single person is to take action. "Someone else will handle it." In engineering, a page sent to a group channel often means nobody responds.

Then

“Never say "Can someone look at this?" Instead, say "@name, you are investigating this." Assign a single, named owner for every incident.”

Unless

Explicit Role Assignment / Incident Commander

If

"Anything that can go wrong, will go wrong." Given enough time, traffic, or unexpected input, every latent failure mode eventually fires. Engineers who design only for the happy path build systems that are one network blip away from collapse.

Then

“Treat every external dependency, retry, and timeout as something that will fail in production. Build the failure path before the success path.”

Unless

Defensive Design / Chaos Engineering

If

Codebases decay because cleanup is always "someone else's job." Each engineer absorbs the entropy hit but defers the fix to a future refactor that never lands. The graph trends down.

Then

“Always leave the code cleaner than you found it, and keep the cleanup small enough to read inside the same diff — a one-line rename, a clearer comment, a deleted dead branch. Anything bigger gets its own commit.”

Unless

One Reason Per Diff — cleanup riding along with a behaviour change hides the change, and a pull request that also renames forty things is one nobody reviews

If

Every system has an irreducible amount of complexity that cannot be removed — only relocated. Hide it from the user and it lands on the developer. Hide it from the developer and it lands on the operator. Hide it from the operator and it lands on the customer at 3 AM.

Then

“When a "simple API" feels too clean, ask: who absorbed the complexity I just removed? If you can't name them, you didn't simplify — you displaced.”

Unless

Honest Layering / Explicit Tradeoffs

If

Lacking expertise in a domain also means lacking the meta-skill required to recognize one's own incompetence. In the original study the bottom quartile scored around the 12th percentile and placed themselves near the 60th. Top performers under-rated themselves, because they assumed others found the task as easy as they did.

Then

“When someone declares a hard problem "easy," check their domain history before trusting the estimate. During scoping, pair confident newcomers with quiet veterans and weight the quiet voice.”

Unless

Calibrated Confidence — the effect is contested — much of the classic pattern is reproduced by regression to the mean in noisy self-assessment, so treat overconfidence as a prompt to check the record rather than as a diagnosis

If

Once you know a thing, you cannot easily imagine not knowing it. Engineers write docs, error messages, and APIs that are obvious to themselves and opaque to the next person who has to use them.

Then

“Before shipping documentation or a public API, have someone who has never touched the system attempt the task while you watch silently. Their confusion points exactly at the assumptions you forgot to spell out.”

Unless

User Testing / Onboarding Buddies / Documentation Reviewers Outside the Author's Team

If

Every protective layer (review, test, alert, runbook, rollback) has holes. Accidents happen when holes across multiple independent layers happen to align. No single layer can ever be perfect, so resilience comes from layers that fail in independent ways.

Then

“During an incident review, do not stop at "the one thing that failed." Enumerate every layer that should have caught the failure and ask why each hole was open at exactly that moment. The fix is rarely a single layer; it's plugging the cheapest two.”

Unless

Defense in Depth / Independent Controls / Hole-Audit at Post-Mortem

If

"Premature optimization is the root of all evil." Optimizing code before measurement proves it matters wastes engineering hours, adds complexity, and obstructs the eventual real optimization by entangling hot and cold paths.

Then

“Write the obvious code first. Only optimize hot paths that a profiler proves are bottlenecks. Leave the other 97% of the code simple — that's where the next maintainer will live.”

Unless

Profile First / Make It Work, Make It Right, Make It Fast (in that order)

If

"Given enough eyeballs, all bugs are shallow." A defect that looks impossible to one person often becomes trivial when many independent perspectives are applied to it — provided the code is actually visible to those perspectives.

Then

“If the same class of bug keeps slipping through, the fix is not more careful review by the same people — it is exposing the code to more, differently-shaped eyes. Rotate reviewers, open up internal libraries, run bug bounties.”

Unless

Open Source / Rotated Reviewers / Bug Bounties / Internal Code Discoverability

If

A networked data store cannot simultaneously guarantee Consistency, Availability, and Partition tolerance. Because network partitions are not optional in the real world, the live choice is really between consistency and availability at the moment a partition happens.

Then

“Decide before an outage whether each operation prefers consistency or availability. The partition will happen; the only question is what your system does when it does.”

Unless

PACELC / Tunable Consistency

If

In any stable system, the average number of items in the system (L) equals the average arrival rate (λ) times the average time each item spends in it (W): L = λW. It holds regardless of arrival distribution or service discipline.

Then

“To cut latency (W) without adding capacity, cut work-in-progress (L). Cap concurrent requests — a shorter queue is faster than a faster server.”

Unless

Backpressure / Admission Control

If

Two parties communicating over an unreliable channel can never be certain they have reached agreement — every message needs an acknowledgment, which itself needs an acknowledgment, forever. No fixed number of messages yields common knowledge.

Then

“Never assume "I sent it, so they got it." Make every cross-network action safely retryable and idempotent, and reconcile state instead of trusting a single round-trip.”

Unless

Idempotency / Eventual Consistency / Acknowledged Retries

If

In a hierarchy, people are promoted on performance in their current role, not the one above. So everyone tends to rise until they reach a role they are bad at — and there they stay. Competence is promoted away; incompetence accumulates.

Then

“Do not promote your best engineer into management as a reward — it removes a great engineer and risks creating a poor manager. Offer a technical ladder, and evaluate candidates for the role above, not the one they already mastered.”

Unless

Dual Career Ladders / Role-Specific Evaluation

If

"Work expands so as to fill the time available for its completion." Give a task a week and it takes a week; the same task with a two-day deadline ships in two days. Slack is consumed, not banked.

Then

“Set deliberately short timeboxes for open-ended work and review at the deadline. A tight box forces the scoping decisions an open one defers forever.”

Unless

Timeboxing

If

"Software is getting slower more rapidly than hardware is becoming faster." Each hardware gain is absorbed by added abstraction layers, features, and carelessness, so user-perceived speed stays flat or worsens.

Then

“Treat the speed a faster machine buys you as a budget to protect, not a license to spend. Set a performance budget and fail the build when a release regresses against it.”

Unless

Performance Budgets / Lean Software

If

"The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time." The visible work hides a second, equally large body of integration, edge cases, and polish.

Then

“When something looks "almost done," assume an entire second project remains: the last-10% of hardening, edge cases, and integration. Schedule it explicitly instead of treating it as a rounding error.”

Unless

Demo on Real Data / Hard Definition of Done

If

"Any code of your own that you haven't looked at for six months might as well have been written by someone else." Your mental model of the code evaporates far faster than the code does; context is not stored in the source.

Then

“Write code and commit messages for the stranger you will become in six months. If a decision is not obvious from the code, record the why in a comment or an ADR — not just in your head.”

Unless

ADRs / Self-Explaining Code / Code Comments on the "Why"

If

The time to make a decision grows logarithmically with the number of choices: T = b·log₂(n+1). More options do not just add visual clutter — they measurably slow every user down.

Then

“Cut the number of choices on any screen or API surface to the few that matter; push the rest behind defaults and progressive disclosure. Fewer doors, faster decisions.”

Unless

Progressive Disclosure / Sensible Defaults

If

The time to move to a target depends on its distance and size: distant, small targets are slow and error-prone; near, large targets are fast. Pointing is a physical act with a measurable cost.

Then

“Make frequent or destructive actions big and easy to hit; make rare or dangerous ones small and far. Screen edges and corners are effectively infinite targets — put primary actions there.”

Unless

Edges & Corners / Sizing by Frequency

If

"The Magical Number Seven, Plus or Minus Two" — human working memory holds only about seven chunks at once. Cross that limit and recall collapses; the brain drops items rather than slowing down.

Then

“Group related items into a handful of named chunks — phone-number style — wherever a person must hold state in their head: function arguments, form fields, menu groups, on-call steps.”

Unless

Chunking / Information Hiding

If

Newcomers to distributed systems silently assume the network is reliable, latency is zero, bandwidth is infinite, the network is secure, topology is stable, there is one administrator, transport cost is zero, and the network is homogeneous. Every one of these eight assumptions fails in production.

Then

“Before shipping any cross-process call, name which of the eight assumptions you are relying on and add an explicit timeout, retry, and failure path for each.”

Unless

Design for Failure — without gold-plating against impossible modes

If

Automating the routine parts of a task leaves the human only the rarest, hardest exceptions — while their manual skill and situational awareness atrophy from disuse, precisely at the moment a failing automated system hands control back to them.

Then

“Keep operators sharp with regular game-days and hands-on drills, and design handoffs so a human takes over with context, not cold.”

Unless

Human-in-the-Loop Drills — better teaming, not less automation

If

Every component granted more authority than it strictly needs enlarges the blast radius of any bug, compromise, or accident, and multiplies the interactions an auditor must reason about.

Then

“Default every process, service account, and token to deny, then add only the minimal scopes the job provably needs; re-audit the grants whenever the job changes.”

Unless

Psychological Acceptability — over-restriction that users route around defeats itself

If

A cryptosystem should remain secure even if everything about it except the key is public. Secrecy of the algorithm is brittle: mechanisms leak, get reverse-engineered, and get reused across systems.

Then

“Assume the attacker has your source and design. Put all of the secret in rotatable keys, and never rely on a hidden algorithm to protect anything.”

Unless

Defense in Depth — obscurity may be one thin extra layer, never the foundation

If

For a fixed time budget, a larger machine lets you solve a proportionally larger problem, so the serial fraction shrinks with scale and speedup grows near-linearly — the optimistic counterpart to Amdahl's fixed-workload pessimism.

Then

“Before justifying more cores, ask whether the problem size grows with the hardware. If the workload is fixed, reason with Amdahl; if it scales, Gustafson applies.”

Unless

Amdahl's Law — for a fixed-size workload, the serial fraction still hard-caps speedup

If

In a service that fans out to many components, rare per-node slowness (GC pauses, contention, a failing disk) is near-certain to hit some node on every request. So tail latency (p99, p99.9) governs the user experience even when medians look healthy.

Then

“Set SLOs on p99/p99.9, not the mean, and deploy tail-tolerance — hedged requests, micro-partitioning — instead of trying to make every node uniformly fast.”

Unless

Redundancy Has a Price — hedged and tied requests add load; don't chase the tail where the median is what users feel

If

A controller can regulate a system only if it can match the variety of states that system can produce. Under-powered control simply cannot cope with a sufficiently rich environment.

Then

“When incidents keep escaping your alerts and runbooks, either add matching response capability or deliberately shrink the system's state space: fewer configurations, stricter inputs.”

Unless

Constrain the Environment — excess control variety is itself cost and complexity

If

An object that reaches through other objects' internals (`a.getB().getC().doThing()`) couples itself to the entire dependency chain, so a change anywhere along that chain ripples back and breaks it.

Then

“Only call methods on your direct collaborators, your arguments, objects you create, and your own fields. If you are chaining getters, add a method to the object that owns the data.”

Unless

Pragmatism over Dogma — strict application breeds forwarding and wrapper bloat

If

Making a resource cheaper to use per unit lowers its effective price and can raise total consumption instead of lowering it — the efficiency gain is spent on more usage rather than banked as savings.

Then

“When you make something cheaper — compute, storage, an internal API — expect demand to balloon; provision and budget for the rebound instead of assuming a net reduction.”

Unless

Cap the Rebound — pair efficiency with a quota, cap, or price signal to actually capture the savings

If

In systems that are both interactively complex and tightly coupled, small independent failures interact in ways no designer anticipated and propagate faster than operators can intervene — so accidents become a property of the structure, not bad luck.

Then

“Reduce coupling — add buffers, timeouts, bulkheads, and circuit breakers — and cut complexity before adding more safety interlocks, which themselves add interactions.”

Unless

High-Reliability Organizations — culture, slack, and decoupling measurably beat fatalism

If

An unrepaired broken window signals that nobody is watching, which lowers the cost of the next violation. In a codebase, one tolerated hack, one skipped test and one permanently silenced alert together announce that the standard is optional.

Then

“Repair the first visible defect in a file you are already touching, and give every tolerated exception an owner and a date. Do not open a refactor for a window you are not standing next to.”

Unless

Repair Is Not Free — attention spent on paint is attention not spent on the foundation, and the criminological evidence for the original claim is contested

If

Speculative generality is paid for three times: writing the abstraction, carrying it while it is unused, and unpicking it when the anticipated requirement finally arrives in a different shape. Predictions about future requirements are usually wrong in exactly the details the abstraction fixed.

Then

“Implement the case you actually have. When you feel the pull to generalise, name the second concrete case first — if you cannot, you do not have a pattern, you have a guess.”

Unless

Chesterton's Fence — YAGNI licenses you not to build something; it never licenses you to delete something whose purpose you have not established

If

"Keep it simple, stupid" came out of aircraft design, where the requirement was that a jet be repairable by an average mechanic in a field with basic tools. The test was never elegance — it was whether an ordinary person could fix it in the worst circumstances the thing would actually meet.

Then

“Judge a design by who can repair it at 3 AM, not by how it reads in review. If the on-call engineer needs the author on the call, it is not simple — it is familiar to one person.”

Unless

Ashby's Law of Requisite Variety — a system simpler than the problem it has to regulate cannot cope with it, and simplicity below that floor is displaced complexity rather than less of it

If

Duplicated knowledge drifts, because nothing forces the copies to change together. The cost is not the extra characters — it is that some future editor fixes one copy and ships a system that now quietly contradicts itself.

Then

“Deduplicate knowledge, not text. Before merging two similar blocks, ask whether they change for the same reason and at the request of the same person; if not, leave them apart.”

Unless

Duplication Is Cheaper Than the Wrong Abstraction — two blocks that merely look alike today will fight each other the moment they need to diverge

If

Every chain has one weakest link. Improvement anywhere else raises local efficiency while total throughput stays flat — and often makes things worse, because the faster upstream stage simply piles more work in front of the real bottleneck.

Then

“Find the constraint, exploit it fully before you buy capacity, and subordinate every other stage to it. Then measure again — you have just created a different bottleneck somewhere else.”

Unless

The Constraint Moves — relieve one and another takes its place, so a process permanently optimised around yesterday's bottleneck starves at the new one

If

Under incident pressure the mind reaches for the interesting hypothesis — a kernel bug, a bad disk, an attacker. The explanation requiring the fewest unverified assumptions is almost always the deploy that went out twenty minutes ago.

Then

“Rank your hypotheses by how many unverified assumptions each needs, and test the cheapest first. Ask "what changed?" before "what is broken?"”

Unless

Hickam's Dictum — a system can carry several independent faults at once, and the simplest story that fits the symptoms is not automatically the true one

If

When one module serves two audiences, their change requests arrive on different schedules and collide in the same file. Coupling is not really about calls between modules — it is about who is entitled to force you to edit them.

Then

“Define responsibility by who asks for the change, not by what the code does. If two different people can each demand an edit to the same module, split it along that line and nowhere else.”

Unless

Premature Decomposition — splitting by imagined responsibilities produces a scatter of one-method classes and moves all the complexity into the wiring between them

If

Users arrive with a model assembled from every similar thing they have used. A behaviour that is defensible but surprising costs more than a behaviour that is slightly worse but predicted, because the surprise is paid again by every user, every time, forever.

Then

“When two designs are close, take the one that matches the convention your users already know — the flag name, the exit code, the sort order. Spend deliberate surprise only where you can afford to announce it.”

Unless

Astonishment Is Relative — designing only for today's expectations freezes bad conventions in place; sometimes the right move is to surprise everyone once, loudly, with a migration path

If

The first system is built cautiously, by someone unsure of the ground. Its success converts that caution into confidence, and every idea deferred the first time is loaded into the rewrite at once. The result is over-general, late, and frequently never ships at all.

Then

“When rewriting, carry forward the constraints and not just the wish list. Cut the deferred features to the two that actually blocked users, and replace the original one piece at a time.”

Unless

Gall's Law — the answer is not to freeze the first system but to grow it — a rewrite that ships in slices is not a second system

If

Moore's observation was economic rather than physical: the component count giving the lowest cost per component doubles about every two years. It held for half a century and quietly underwrote every plan that assumed hardware would rescue it — but single-thread performance stopped following it once Dennard scaling ended around 2005.

Then

“Do not budget for the hardware bailing out a design. If the workload is single-threaded and latency-bound, next year's machine will not save it — you have to parallelise it or do less work.”

Unless

Wirth's Law — the gains get spent rather than banked, and clock speed stopped rising long before transistor counts did

If

A new technology is judged on a demo, which flatters it, and then adopted against an installed base, which resists it — so the first two years disappoint. The same compounding that made the early forecast wrong then runs for a decade in the other direction, and the ten-year forecast turns out to be wrong too, this time low.

Then

“Discount two-year forecasts about a new technology and take ten-year ones seriously — but plan around the version that actually ships, not the one in the demo.”

Unless

Some Things Simply Do Not Arrive — survivorship makes the law look inevitable, because the technologies that never got a long run are not the ones quoted back at us

If

Across seven decades of AI research the approaches that won were search and learning scaled with available computation, not the ones that encoded human insight about the domain. Built-in knowledge helps in the short run and becomes the ceiling in the long run, because unlike computation it does not get cheaper every year.

Then

“When choosing between encoding what you know and building something that learns from more data or more compute, ask which one improves on its own when the budget doubles. Bet on that one for anything with a multi-year horizon.”

Unless

Compute Is Not Free — inside a fixed budget domain knowledge is often the only lever you have, and the lesson describes the trajectory of a field rather than the right move this quarter

If

A network of n nodes has n(n−1)/2 possible connections, so its value was claimed to scale with n². The exponent is disputed — n log n fits real networks better — but the shape holds: each new node adds value to every existing node, which is why networks tip rather than grow smoothly.

Then

“For a product whose value comes from other users, spend early effort on the smallest network that is already useful to its own members, not on features. For a team, do the opposite and cut connections.”

Unless

The Same Quadratic Is a Cost — connections are an asset between users and a liability between colleagues; Brooks' Law is Metcalfe's Law with the sign flipped

If

Ringelmann had men pull a rope alone and in teams, and measured the force. Each additional person contributed less than they had alone — partly coordination loss, partly reduced individual effort once the contribution stopped being separable. It shows up wherever output is pooled and nobody can see who produced which part.

Then

“Give every workstream one named owner and a visible output. If you cannot say who produced which part of a result, expect the group to produce less than the sum of its members.”

Unless

Separable Contribution — the effect is a property of how the work is measured rather than of the people; make the individual contribution legible and most of it disappears

If

An organisation built to solve a problem draws its budget, headcount and status from that problem persisting. Nobody has to be cynical for this to work: the incentives simply never point at making the team unnecessary, so over time the solution quietly becomes an argument for the problem.

Then

“For any team or tool created to fix something, write down what "fixed" looks like and when you will check. A platform team that cannot describe its own obsolescence is optimising for its own survival.”

Unless

Some Problems Are Permanent — treating every long-lived team as self-serving destroys the ones doing necessary maintenance, which is invisible precisely when it is working