TL;DR The default in tech leadership is addition: more features, more tools, more process, more people. But the teams that move fastest got there by removing things. Freedom to execute isn't having every option available. It's having removed enough that the remaining ones are obvious. Subtraction is the most underleveraged leadership skill in engineering.
Every new CTO inherits a pile. Legacy services nobody touches. Dashboards nobody reads. Workflows that exist because someone important requested them three years ago. The instinct is to add on top: new observability, new CI checks, new architecture layered over the old one. Addition feels productive. It generates PRs, Slack announcements, roadmap line items. It looks like leadership.
Subtraction looks like nothing happened. That's the problem.
The addition bias is structural, not personal
Organizations reward visible work. A new feature ships: there's a launch email, metrics, a demo. Removing a feature generates a support ticket, maybe a churned customer, definitely an argument. The incentive gradient points one direction. So everything accumulates.
This isn't laziness. It's a rational response to how most companies measure contribution. Product managers get promoted for launching things. Nobody gets promoted for killing a feature that was confusing 40% of users but generating $200K in ARR. The removal was worth more than the revenue. But the person who championed it has nothing to put on their performance review.
The same pattern runs through engineering. Adding a linter rule is a five-minute PR. Removing one requires proving a negative: that the rule wasn't preventing bugs. Adding a microservice is a design doc and a sprint. Collapsing two services into one is a migration plan, a rollback strategy, a month of careful work. The second project is almost always more valuable. It is also harder to justify. Harder to get staffed.
Fewer features, faster product
Basecamp is the canonical example. 37signals has been removing features from Basecamp for twenty years. They killed time tracking, Gantt charts, resource allocation. Competitors kept adding them. Basecamp is still profitable with a team under 100. The competitors who added everything either sold, folded, or became enterprise bloatware that requires a consultant to configure.
The mechanism isn't mysterious. Every feature you ship creates a maintenance surface: tests, documentation, edge-case handling, customer support scripts, onboarding flows. A product with 50 features doesn't cost 50 units of maintenance. It costs 50 times the interaction effects between those features. The complexity is combinatorial.
Stripe understood this early. Their API surface stayed deliberately small for years while competitors rushed to cover every payment method and workflow. Stripe's constraint forced clarity: if you can only expose ten endpoints, they'd better be the right ten. That discipline created an integration experience so clean it became a moat.
The lesson isn't "build less". It's that every addition has a compounding cost paid in the future. Most teams never account for it at decision time.
Process subtracts freedom by pretending to add safety
Process accumulation follows the same curve. A production incident happens. The postmortem recommends a new approval step. Nobody objects because opposing safety is a losing argument. Eighteen months later, deploying a config change requires four approvals across three time zones. The original incident that triggered the process was a one-time human error that would have been caught by a unit test.
The fix isn't fewer postmortems. It's treating process like code: if it hasn't been exercised in 90 days, it's probably dead. Delete it. If an approval step has never actually blocked a bad deploy, it's not providing safety. It's providing the feeling of safety while taxing every deploy with latency.
Google's SRE team got this right with error budgets. Instead of accumulating safety process, they set an acceptable failure rate. As long as you're within budget, you move fast. When you burn through it, you slow down. The constraint is explicit and measurable. It replaces seventeen implicit rules with one clear one.
One clear rule beats a dozen half-followed ones every time. The dozen rules create an environment where nobody's sure which ones actually matter, so compliance becomes performative. That's the opposite of safety.
Subtraction as a leadership signal
The hardest part of subtraction is that it requires conviction. Adding something is low-risk: if it doesn't work, it just sits there. Removing something means you're betting that you understand the system well enough to know what's load-bearing and what's dead weight. That's a public bet. If you're wrong, the failure is visible and attributable.
This is why subtraction is a leadership signal. It tells the team that someone has done the work to understand what matters and is willing to make a call. The leader who says "we're cutting this feature" or "we're removing this process" is demonstrating judgment in a way that "we're adding this" never does. Anyone can add. Subtraction requires a point of view.
Jeff Bezos got at this with his two-pizza teams, but the deeper principle in Amazon's operating model was the single-threaded leader: one person, one problem, no shared dependencies. The structure itself was subtractive. Remove the coordination. Remove the joint planning. What's left is a team that can move without permission.
Where subtraction becomes its own trap
The obvious failure mode is removing something load-bearing. Chesterton's fence exists for a reason: if you don't understand why a thing is there, removing it is just ignorance with confidence. The fix is simple in theory (understand before you cut) and hard in practice because understanding legacy systems takes time that feels unproductive.
There's also a cultural risk. Teams that over-index on subtraction can develop a reflexive hostility toward new ideas. "We don't add things" becomes an identity rather than a discipline. The goal isn't minimalism as an aesthetic. It's keeping your freedom to act. Sometimes acting means adding something. The test is whether the addition increases or decreases your future optionality.
Subtraction also requires ongoing maintenance. Entropy runs in one direction. Things accumulate naturally: features, process, technical debt, meetings. Subtraction is an active practice, not a one-time cleanup. The leader who does a big "simplification initiative" once a year and lets things pile up between cycles hasn't internalized the principle. They've just added another process.
What to do with this
Audit your product surface quarterly. For each feature, ask: if we hadn't built this, would we build it today? If the answer is no, start the deprecation conversation. You won't remove all of them. But the conversation itself forces the team to articulate what's actually core.
Apply the same audit to process. List every approval, every required meeting, every gate in your deployment pipeline. For each one, find the last time it actually caught a problem. If you can't find one, run a 30-day experiment without it.
When you're about to add something, state the removal it replaces. New monitoring tool? Which old one dies? New weekly meeting? Which existing sync does it replace? If the answer is "nothing, this is additive", that's useful information. It might still be worth doing. But you should feel the weight of it.