Muhammad Rizki

Writing · Architecture

The bias that almost picked our database

By · · 2 min read

We almost picked a database within ten minutes, because someone liked it at their last job.

Hand drawn sketch for "The bias that almost picked our database", with a stick figure saying "it worked at my last job!"
Sketch by me. The stick figure says: "it worked at my last job!"

A few years ago a team I worked with needed a new data store for a high traffic service. Within ten minutes of the first meeting, someone said, "We should use the same one we used at my last company. It handled everything."

From that moment, every discussion quietly orbited that one option. We compared others, technically. But the comparisons felt like a formality.

We nearly signed off. Then someone asked a slightly awkward question, and the whole thing unravelled. Nostalgia is a terrible architect.

Anchoring

My strategic leadership course had a session on cognitive bias, and I recognised that meeting immediately. Anchoring is when the first piece of information you hear shapes all your later judgments. The first option suggested becomes the reference point. Everything else is measured against it, usually unfairly.

In tech this happens constantly. The first estimate sets the timeline. The first architecture diagram becomes "the design." The first vendor demo becomes the benchmark.

Confirmation bias

The second trap is confirmation bias. Once we lean toward an option, we look for evidence that supports it and ignore evidence that does not. In our case, people shared benchmark posts that praised the database. Nobody went looking for posts about its failure modes.

The awkward question that saved us was simple. "What workloads does this database handle badly?" It turned out our access pattern was one of them.

Why smart people fall for it

It is tempting to think bias is for less experienced teams. In my experience, it is the opposite. Experienced people have more stories, and stories are powerful anchors. "It worked at my last job" carries weight precisely because the person is credible.

Experience is valuable. It is just not the same as evidence for this situation.

Habits that help

Over time I have collected a few cheap habits.

  1. Write down the decision criteria before discussing options. Agree on what matters first, then compare.
  2. Ask for at least three real options. Two options often means one favourite and one strawman.
  3. Assign someone to argue against the leading option. Rotate the role so it is not personal.
  4. Ask "what would have to be true for this to fail?" It surfaces risks people were too polite to mention.
  5. Sleep on big decisions. Bias loves urgency.

AI agents can help, carefully

I sometimes ask an AI agent to make the strongest case against my preferred option. It is surprisingly good at this, because it has no ego in the outcome. But agents have their own biases, often toward whatever is most popular online. Treat their arguments as prompts for thinking, not as verdicts.

What happened next

We ran a small proof of concept with the actual access pattern. The favourite option struggled. A less fashionable choice handled it calmly. The person who first suggested the favourite was the first to say, "Good, glad we checked." That is the kind of team you want.

The funny part is that the favourite option was a fine product. It just did not fit us, which is a much less exciting thing to say in a meeting.