When to Satisfice (And When Not To)

This is a followup to my earlier post on How to Make Fewer Decisions. You may want to read that one first, although it’s not strictly necessary.

In economics, satisficing is a decision-making strategy that tries to find a “good enough” solution to a problem. It can be contrasted with maximizing, which tries to find the best (or at least close to optimal) solution. It’s quite common to see search problems in all areas of the world ranging from the personal (which flavor of jam or which car should I buy?) to the business (which product should we invest in? which technology should we use to build it?). And the strategy we use to perform this search can have a big effect on how happy we are with the results.

Psychology research has found evidence that, rather than depending on the situation, people tend to fall into one or the other of these styles in most or all of their decisions, i.e. everyone is either a “satisficer” or a “maximizer”. They’ve also found that satisficers tend to be happier with their decisions and more pleased with their life outcomes, even when those outcomes are worse. For example, job search maximizers found jobs with, on average, 20% higher salaries, but still said they were less satisfied with those jobs than satisficers. 

There have been several explanations proposed for why this is the case. For example, some have suggested that maximizers tend to regret the choices they missed out on more, or that they are more likely to focus on the obvious features of each choice (such as salary for a job) while ignoring factors that can be just as important but are harder to compare, or that maximizing is associated with poor decision making skill in general. It’s probably some combination of all of these factors.

Yet when dealing with situations beyond the merely personal, there is a strong bias in favor of maximizing. Companies will spend significant time and money figuring out the right product, the right strategy, and the right people to work on it. With things that seem to be ‘higher stakes’ than merely which flavor of jam to buy it can seem like there is more payoff to maximizing compared to satisficing. Yet I think the research on individual decisions should give us pause. Finding a good job is very important for an individual and even with a decision of that magnitude satisficing performed well. In the rest of this post I’ll discuss why I think satisficing is a good approach to take initially, and when you might want to move away from it to avoid being stuck in a local minimum. 

Satisfice in the Short Run

Let’s say you are starting on a new, greenfield software project. You aren’t tied to any pre-existing technology or codebase. You don’t have to deal with any legacy code, or fix any long standing bugs. Amazing, right? Well, maybe. At least until you realize that you need to make many decisions, such as which technologies to use, how to set up your codebase, how to organize your teams, and so on. Even if you are working with some rough constraints there are many decisions of this type that might matter quite a bit (have you ever had to pick a JS framework?).

You might think that since this type of decision is critically important, you should spend a lot of time getting it right–i.e. maximizing. It can be very paralyzing to keep searching for an optimal choice (for example, the book Dreaming in Code explores some of the problems that result from this with one large-scale open source project). This can significantly delay the start of your project. Yet who can argue with wanting to make the right choice? 

On the other hand, new projects are when we have the most uncertainty. Perhaps the product you are building is actually useless and you’ll have to abandon it or change it significantly. Perhaps once users start trying it out you’ll realize you need to focus on totally different use cases (no plan survives first contact with customers). Or perhaps the technology you thought was a perfect fit actually turns out to have issues with the specific usage patterns you now have, different from what you could have expected. Just as startups aim to “build an MVP”, and “pivot quickly”, anytime you are doing something new you can’t expect to get it right the first time. Spending too much time early on maximizing is wasteful when the inputs are likely to change.

Consider a different situation. You are working on a large company maintaining their CRUD apps. Now there’s a business need to build yet another one. Should you spend time investigating alternative tech or just use the same thing the other apps are using? Especially if you’re new to the project, there’s always a temptation to consider whether you can do things better. But this needs to be tempered. If 100 CRUD apps are working fine one way then why make the 101st different? You’re just setting yourself (or, more likely, the next person in the job) up for a maintenance headache. 

As I wrote in my earlier post, planning is for doing. We should make sure that the amount of planning we put in is commensurate with what we need to accomplish our goals. In the early stages of a new endeavor this generally means we should strive to satisfice and not maximize.

Maximize in the Long Run

After all that satisficing it can be easy to fall into the opposite trap. You make a quick decision and it seems to be working well for a time. You built that 101st CRUD app the same as the others and it works “ok” just like the rest of them do. Your users are happy (kind of). Sure, it has all of the bugs and issues from the old framework you’re using, but you figure it’s good enough. 

Or, you launched that MVP of your product using the tech from your last company. It works ok, even though this isn’t really the same type of thing, and the backend you’re using wasn’t meant for this kind of workload. But initially you have very few users so it doesn’t matter. Now your product is picking up traction and there’s some slowdowns so you need to introduce rate limiting. But people are still excited to use it so you don’t spend too much time worrying about it.

There often comes a time to change your mindset into that of the maximizer. It’s rarely the case that the solution you came up with early on is still going great, and even if it is, there is always room for small improvements. When things are going well you can take some time to reconsider whether aspects of your solution could be done differently or better. For example, perhaps now that you understand your data access patterns much more you can optimize your backend differently. Or maybe now that you know what types of bugs tend to crop up, you can implement a more thorough testing strategy. Any time there is a major issue it is worthwhile to consider whether it’s an isolated case or part of a larger trend that needs a larger-scale solution.

When you make such a big change it can be common to feel regret. Is it going to be much more work than if you had set things up this way originally? Yes, certainly. It’s always tricky to perform migrations of this type while minimizing downtime. But this is purely hindsight bias. You didn’t have the right information in the past to make this decision so it’s pointless to consider whether you could have. Instead focus on how you can improve things now. Remember what they say about premature optimization. 

In the beginning of this post I wrote that individuals tend to be either satisficers or maximizers. How can we accomplish this change of mindset given that? I think there are two things to consider. First, psychology is always far less fixed than psychologists would want us to believe. It’s in their interest to study “personality” as if it’s immutable, but there’s quite a bit of uncertainty as to how much of that is really the case. Even if it is so, when we’re dealing with projects we rarely have a single person working on them. It can make sense to have the satisficers work on projects in the early stages, and then add maximizers to them later on. 

If you know which group you fit into then you can also look for work that matches those strengths. As a maximizer don’t look for greenfield, 0->1 projects, but instead go for those that are more established but facing some sort of challenge. Conversely as a satisficer you can focus on new things that need to be built out quickly. Or, if you’re more flexible and can adapt to the situation, simply be introspective as to what makes sense for whatever stage what you’re working on is in.