Across eight experiments published in Nature in 2021, people asked to improve an object, a plan, or an idea reliably reached for addition and overlooked subtraction, even when removing something was the better fix and sometimes the only right answer. The finding is inconvenient because subtraction is usually cheaper, faster, and safer than the feature, process, or headcount we instinctively add instead.

A single hot pink brick being lifted away from a black tower, illustrating subtraction as improvement — Improvement by subtraction: taking one piece away often stabilizes the whole structure.

I study behavioral psychology because these defaults run quietly under almost every business decision. This one is worth naming, because it shapes product roadmaps, operating processes, org charts, and codebases in the same predictable direction: bigger. Understanding the bias is the first step to running a leaner system on purpose.

What the Nature study actually found

Gabrielle Adams, Benjamin Converse, Andrew Hales, and Leidy Klotz ran a set of studies, from Lego structures to written essays to digital grids, testing whether people consider subtractive changes as readily as additive ones. They do not. Participants defaulted to adding components even when subtraction produced a cleaner, cheaper result, and the pattern held across contexts.

The clearest demonstration used a small structure that had to hold a heavy block on a raised platform supported by a single pillar. As the University of Virginia research team reported, most people stabilized it by adding blocks at the corners, paying a small cost per block, rather than simply removing the one block that let the platform rest flat on the base. Removing was free. Adding was not. People added anyway.

The researchers were careful about the mechanism. People were not weighing subtraction and rejecting it. They were failing to generate the subtractive option at all. As Klotz put it, we do this "to our detriment, even when the only right answer is to subtract. Even with financial incentive, we still don't think to take away."

Why does the brain reach for "add" first?

The explanation is cognitive economy. "Additive ideas come to mind quickly and easily, but subtractive ideas require more cognitive effort," Converse explained in the study coverage. Because we move fast and act on the first workable idea, addition wins by default, not by merit.

Worse, the habit compounds. Adams noted that the more we rely on additive strategies, the more cognitively accessible they become, so over time the pull toward adding gets stronger. A team that has always solved problems by adding a tool, a step, or a meeting will keep doing it, and each addition makes the next one feel normal.

This is a close cousin of the other defaults I write about. It sits beside the ones covered in the bias you don't see making your technology decisions, and it is reinforced by ownership effects like the endowment effect in the self-hosting decision. Once something exists, we overvalue it, which makes removal feel like loss rather than improvement.

Where addition quietly accumulates in a business

The bias is easiest to see in software. The Standish Group's often-cited usage data found that roughly 64 percent of features in a typical application are rarely or never used, a figure repeated so widely that it is worth treating as directional rather than exact, as one analysis of its origins points out. Even discounted, the direction is clear: most of what teams build sees little use, yet almost none of it gets removed.

The same accumulation shows up as technical debt. In a McKinsey survey of CIOs, respondents estimated that technical debt amounts to 20 to 40 percent of the value of their entire technology estate before depreciation, and that 10 to 20 percent of the new-product technology budget gets diverted to servicing it. Debt is what unremoved additions cost later.

It is not only code. It is the standing meeting nobody cancels, the approval step added after one bad incident, the fourth analytics tool bought because the first three were never consolidated. Each was a reasonable addition in the moment. The sum is a system heavier than the work requires, and that weight is exactly the drag behind the real cost of context switching.

The reason this accumulates so quietly is that additions are individually defensible and collectively invisible. No single feature, form field, or checklist item feels like the problem, so no one is ever assigned to remove it. Removal has no natural owner, while addition has a champion for every item. That asymmetry, not laziness, is why systems only grow.

The subtraction that improves the system

Subtraction is not austerity. It is choosing the smaller set that does the job, then defending it. In a product, that means cutting the features nobody uses so the ones that matter get faster and clearer. Fewer options also lowers the load on the person deciding, which is the mechanism behind why cognitive load quietly kills conversion.

In content and search, more is often less. Publishing thinner pages to cover more keywords tends to dilute the pages that already rank, which is the whole argument in why more content loses in answer engine optimization. Consolidating and pruning usually beats adding.

In engineering, the discipline is starting small and resisting the urge to pre-build. That is the case for starting with a monolith: a smaller architecture you can actually reason about beats a distributed one you added complexity to before you needed it. Removing premature structure is subtraction applied to design.

And in operations, subtraction sometimes means not building at all. Knowing which work should stay manual is its own skill, which is the point of the tasks you should never automate. Not every gap needs a system bolted over it.

What connects these cases is that the win comes from removing constraint, not from removing capability. A pruned product still does the important jobs, a smaller architecture still ships, a manual step still runs. What goes away is the drag: the surface to maintain, the choices to make, the paths to test. Subtraction that removes value is a mistake. Subtraction that removes weight is the whole point, and telling the two apart is the actual judgment involved.

How do you make subtraction the default?

The most useful takeaway from the research is practical: subtractive ideas rise sharply the moment you cue them. When people are simply reminded that removing is an option, they find subtractive solutions they otherwise miss. So the fix is to build the reminder into how you make decisions.

The first move is to ask the subtractive question out loud in every review. Not only "what should we add," but "what could we remove, and what would break if we did." Making removal an explicit agenda item counters the bias before it acts, because the problem is generation, not judgment.

The second is a subtraction budget. For every quarter of additions, schedule a deliberate removal pass: dead features, unused integrations, dashboards nobody reads, approvals that no longer map to a real risk. This is close, recurring work, not a one-time purge. Systems drift toward more unless someone is paid to trim them.

A useful ritual is to make removal the first draft of any improvement. Before anyone proposes what to add, spend the first few minutes listing what could come out. Because subtractive ideas are the ones that do not arrive on their own, giving them the opening slot forces them into the room while the additive ones are still forming. It costs almost nothing and consistently surfaces options a normal brainstorm would skip, and it trains the team to treat removal as a real move rather than an afterthought.

The third is to protect the smaller set once you have it. When teams reach for a new tool, the honest first question is whether an existing one already does the job, a restraint I described in how the sunk cost fallacy runs your technology stack. Adding a fourth tool because the first three feel half-used is the bias in action.

When removing is the wrong move

Subtraction is a default worth building, not a rule to apply blindly. The point of the research is that removal is systematically underweighted, so the correction is to consider it, not to always choose it. A follow-up study across age, culture, and task found that the additive bias is not as universal as the original framing implied, and that context changes how strongly it shows up. Subtraction is an option people miss, not an answer that is always right.

The real danger is removing something whose purpose you do not understand. A rule, a legacy process, or an odd piece of code often exists for a reason that is not visible from where you stand. The discipline is to learn why a thing is there before you cut it, then remove it deliberately if the reason is gone. Thoughtful subtraction and reckless deletion are not the same act.

Good engineering tends to converge on the smallest system that satisfies the requirement, because smaller systems have less surface to fail and less to defend. At Kief Studio we treat that restraint as part of building well, not as a separate cleanup phase. We share more of that thinking on the Kief Studio blog and in the free tools and write-ups at kief.dev. The goal is the same in both: a system you can hold in your head, because you kept it that way on purpose.

Frequently Asked Questions

What is subtraction bias?

Subtraction bias, sometimes called additive bias, is the tendency to improve things by adding components rather than removing them. The 2021 Nature study by Adams and colleagues showed that people systematically overlook subtractive changes, defaulting to addition even when removing something would be cheaper and better.

Why do people prefer adding over removing?

Additive ideas require less cognitive effort and come to mind first, so people acting quickly tend to accept them without ever generating the subtractive alternative. The habit also compounds: the more you solve problems by adding, the more automatic adding becomes.

How do I apply subtraction to my business?

Build the subtractive question into every review by asking what you could remove, not only what you could add. Schedule a recurring removal pass for unused features, tools, meetings, and approvals, and check whether an existing system already does a job before you add a new one.

Is subtraction always better than addition?

No. The research shows subtraction is underconsidered, not that it is always correct, and later studies found the bias varies by context. The correction is to weigh removal fairly, and to understand why something exists before you take it away.

What is the difference between subtraction and technical debt cleanup?

Technical debt cleanup is one form of subtraction applied to code and systems. Subtraction is the broader habit of removing features, steps, and complexity across the whole business, of which paying down accumulated debt is a specific and measurable case.

Product

Subtraction: Why Removing Beats Adding (and Why We Never Do It)