Satisficing Over Maximizing: The Wisdom of Good Enough for Technical Leaders

Satisficing Over Maximizing: The Wisdom of Good Enough for Technical Leaders

The Paradox of Choice in Engineering

You’re choosing a database for your new microservice. PostgreSQL? MySQL? MongoDB? CassandraDB? DynamoDB? You research performance benchmarks, read comparison articles, ask colleagues, build proof-of-concepts. Three weeks later, you’re still deciding.

Meanwhile, your competitor shipped their feature using PostgreSQL because “it’s good enough.”

This is the tyranny of maximizing - the exhausting pursuit of optimal decisions in a world with infinite options. And it’s killing your productivity, your happiness, and your ability to ship.

Satisficing: The Philosophy of “Good Enough”

Herbert Simon, Nobel Prize-winning economist and cognitive psychologist, coined the term “satisficing” (combining “satisfy” and “suffice”) in 1956. His insight was radical for its time and remains underappreciated today: humans can’t actually maximize. We have limited information, limited time, and limited cognitive capacity. Attempting to find the optimal solution is often irrational.

Instead, Simon argued, we should “satisfice” - establish clear criteria for what constitutes “good enough,” then choose the first option that meets those criteria.

Maximizing: “Which database is objectively best for my use case across all possible dimensions?”
Satisficing: “Which database meets my requirements (scalability to 10K QPS, ACID guarantees, strong Go support) and can be deployed this week?”

The satisficer doesn’t seek perfection. They seek sufficiency, then move on.

Why Maximizing Fails for Technical Leaders

1. The Information Trap

As a principal engineer, you have access to enormous information: documentation, benchmarks, blog posts, conference talks, Stack Overflow threads. More information should lead to better decisions, right?

Wrong. Barry Schwartz’s research in “The Paradox of Choice” found that beyond a certain threshold, more options and more information decrease decision quality and satisfaction. You suffer analysis paralysis, constantly second-guessing whether you’ve found the optimal solution.

The satisficer recognizes that perfect information is impossible. They gather sufficient information to make a good decision, then execute.

2. Opportunity Cost of Deliberation

Every hour spent optimizing your technology choice is an hour not spent building. Choosing between 95th percentile and 99th percentile performance takes time that could be spent shipping the feature and discovering whether performance even matters to users.

Jeff Bezos popularized “Type 1” vs “Type 2” decisions:

Maximizers treat Type 2 decisions like Type 1 decisions. Satisficers make Type 2 decisions quickly and adjust later if needed.

3. Diminishing Returns on Perfection

The difference between a “good” solution and an “optimal” solution is often marginal. The difference between no solution and a good solution is enormous.

Consider API design:

The jump from 0% to 90% is relatively fast. The grind from 90% to 97% can take as long as the initial implementation. Maximizers spend weeks on that final 7%. Satisficers ship at 90% and iterate based on actual usage.

4. Regret and Counterfactual Thinking

Maximizers experience more post-decision regret. Because they’ve researched every option, they’re acutely aware of what they didn’t choose. “What if I had picked Cassandra instead of PostgreSQL?” becomes a nagging doubt.

Satisficers experience less regret because their standard is “Does this meet my criteria?” not “Is this the absolute best?” If PostgreSQL works, they don’t waste cognitive energy wondering about alternatives.

Practicing Satisficing as a Principal Engineer

Establish Clear Sufficiency Criteria

Before researching solutions, write down explicit criteria for “good enough”:

Bad (maximizing): “Choose the best database” Good (satisficing): “Choose a database that:

When you find an option meeting all criteria, stop searching. PostgreSQL meets these requirements? Ship it. Don’t spend another week researching whether CockroachDB might be marginally better.

Apply the 70% Rule for Decisions

Amazon has a “disagree and commit” culture, but Bezos also advocates the 70% rule: make decisions when you have 70% of the information you wish you had. Waiting for 90% is too slow, and the extra 20% rarely changes the decision.

For technical decisions:

Use Time Limits for Research

Set explicit timers for decision-making:

When time expires, choose the best option you’ve found that meets sufficiency criteria. If no option meets criteria, extend research time. But don’t extend “to find something better” - only to find “something sufficient.”

Reframe “Settling” as Strategic

Maximizers view satisficing as “settling” - negative connotation implying defeat. Reframe it as strategic resource allocation:

Satisficing isn’t lowering standards. It’s refusing to waste resources on marginal improvements.

Automate Satisficing with Decision Rules

Create reusable decision rules for common choices:

Database selection:

Programming language:

These rules aren’t perfect. But they’re good enough for 80% of situations, letting you skip research entirely. Save deep analysis for the 20% of cases that don’t fit standard patterns.

When to Maximize (Intentionally)

Satisficing isn’t universal. Some decisions warrant maximizing:

Maximize when:

Always satisfice when:

The Life Impact: Beyond Technical Decisions

Satisficing extends beyond engineering decisions to life choices that plague technical leaders:

Career moves: Don’t endlessly optimize for the “perfect” company. Define criteria (compensation, tech stack, team quality, growth opportunity), then take the first offer meeting them.

Learning priorities: Don’t try to learn “the best” new technology. Pick one that’s good enough for your goals (e.g., Go for backend systems), then build deep expertise rather than shallow knowledge of every option.

Work-life balance: Don’t maximize productivity every day. Define “good enough” workdays (shipped 2 PRs, attended key meetings, helped teammate) and stop there. Constant maximizing leads to burnout.

Relationships: Don’t endlessly search for the “optimal” romantic partner or perfect friendships. Define what you need in relationships, then invest in people who meet that standard.

The satisficing mindset reduces anxiety, increases action, and counterintuitively often leads to better outcomes than maximizing because you actually ship and learn from reality.

The Engineering Leader’s Dilemma

As a principal engineer, you’re judged on two dimensions:

  1. Decision quality: Making the “right” technical choices
  2. Velocity: Shipping quickly and unblocking teams

Maximizing optimizes for #1 at the expense of #2. Satisficing balances both. A good decision implemented this week beats a perfect decision implemented next month - especially in fast-moving tech environments where “perfect” today may be obsolete tomorrow.

Your job isn’t finding optimal solutions. It’s finding sufficient solutions that let the team move fast.

Reflection Questions

Conclusion

The engineer’s instinct is optimization. But optimizing every decision is itself suboptimal. Satisficing - the art of defining “good enough” and executing decisively - is a superpower for technical leaders operating in ambiguous, time-constrained environments.

Simon’s insight was profound: rationality isn’t about finding perfect solutions. It’s about finding sufficient solutions with the resources you have. As a principal engineer, your scarcest resource isn’t compute power or network bandwidth - it’s your attention and time.

Spend them wisely. Ship good solutions. Iterate based on reality. Resist the siren call of optimization for its own sake.

Perfect is the enemy of good. And good is often the friend of shipped.

../