Computational Kindness — Why "I'm Flexible" Is the Cruelest Thing You Can Say

The Goa Problem

You've lived this conversation.

"Hey guys, let's go to Goa."

"Totally, sure."

"Cool."

"I'm in."

"When should we go?"

"Whenever you want."

"… Okay."

Three weeks later: "Hey, what happened to the Goa plan?"

Nothing happened. That's the point. The plan died the moment someone said "whenever you want" — because they handed the entire cognitive load to someone else and walked away. It felt polite. It felt easygoing. It was, in fact, the least kind thing they could have done.

This is the idea behind computational kindness — a concept drawn from Brian Christian and Tom Griffiths' book Algorithms to Live By. The core insight is deceptively simple: the less the brain has to work, the more willing it is to act. When you create situations where people don't have to think too hard, you're being computationally kind. When you dump an open-ended problem on someone and call it "being flexible," you're being computationally cruel.

The Cognitive Buck

Every interaction involves a cognitive buck — the mental effort required to process, decide, and respond. The question is always: who's holding it?

In different contexts, the answer changes:

In an interview, pass the cognitive buck. You want the other person to think deeply. Ask open-ended questions that can't be answered in one word.

In a conversation, share the cognitive buck. Pass it when you're genuinely interested in the answer. "How was London?" opens a door. "Did you try the churros at the Christmas market?" closes it to a yes or no.

In planning, do not pass the cognitive buck. This is where most people get it wrong. Plans that dump the entire cognitive load onto the group rarely survive. "Where does everyone want to eat?" is a search problem — you're asking someone to mentally scan every restaurant in the city. "Does Nandos on the corner work for everyone?" is a verification problem — all they have to do is say yes or no.

The gap between search and verification is enormous. As Brian Christian puts it, it's "about as wide as the gap between knowing a good song when you hear it and writing one on the spot."

The Dark Side of "I'm Flexible"

Here's where social etiquette betrays us. Saying "Oh, I'm flexible" or "Whatever you want" feels generous. It has the veneer of kindness. But it does two deeply problematic things.

First, it passes the cognitive buck entirely: "Here's a problem, you handle it."

Second — and this is the subtle one — by not stating your preferences, you force everyone else to simulate them. They have to guess what you might want, what you might object to, what might make you quietly resentful later. The simulation of other minds is one of the hardest computational problems that exists. Even Hari Seldon, the greatest fictional mathematician of the far future, could only manage to predict the behavior of very large groups — never individuals.

When you withhold your preferences in a group, you're not being easygoing. You're asking everyone else to run a mind-simulation algorithm on your behalf. And in groups, this problem compounds. Five people all saying "I'm flexible" creates a deadlock where everyone is waiting for someone else to go first, everyone is simulating everyone else's preferences, and nothing gets decided.

The fix is almost embarrassingly simple: state your preferences before passing the cognitive buck. "I'd love Thai food, but I'm open to other ideas" is infinitely more useful than "Whatever works."

Computational Kindness in Design

This principle extends far beyond dinner plans. It's a design philosophy.

Think about the last mall you hated going to. Chances are, the parking was a nightmare. You drove in circles, stressed out, hunting for a spot. That's computationally unkind design — it forces you to solve a search problem every time you visit.

Now think about a well-designed parking structure. You pull in, see a green light above the first available spot, and park. The spot is, by design, the closest one to the elevator. You didn't have to think. That's computational kindness.

The mall with the kind parking gets more of your money. Not because the stores are better, but because the experience of getting there doesn't drain your cognitive battery before you even walk in.

Amazon understood this when they invented one-click ordering. The entire checkout flow — shipping address, payment method, confirmation — collapsed into a single button. They didn't just remove steps. They removed decisions. That's computational kindness at scale, and it's worth billions.

If you're an architect, a software engineer, or a writer, the lesson is the same: be mindful of the cognitive buck you're passing to your users. Every form field, every ambiguous menu, every "please select from the following 47 options" is a computational burden. The best designs don't just look clean — they think clean. They've already done the hard work so the user doesn't have to.

The Deeper Point

Subtle changes in how you frame a problem can radically shift the cognitive load on the person receiving it. Architects choose how to structure the computational problems we solve when we navigate buildings. Urban planners choose whether cycling is easier than driving. Product designers choose whether signing up takes one click or twelve.

And in your daily life, you choose whether to say "Where should we meet?" or "Does the coffee shop on 5th work at 3pm?"

The first is a search problem. The second is a yes-or-no.

A Rule of Thumb

Here's the simplest version of this idea, borrowed from Neil Kakkar's excellent write-up on the concept:

When you care enough about something happening — take the cognitive load yourself. Don't ask "Where does everyone want to meet?" and then follow up with "Oh, where else? Think." Instead, stop being the robot that keeps replying with a question, and suggest something concrete.

Propose a place. Propose a time. Propose a plan. Make it easy for people to say yes.

After all, you wouldn't want to pass the cognitive buck to them.

The concept of computational kindness comes from Algorithms to Live By by Brian Christian and Tom Griffiths. Neil Kakkar's blog post is an excellent, accessible exploration of the idea.