The Cost of Knowing: Why the solution you already know stops you from seeing the better one

I remember the confidence of walking into the room already knowing what, and how we should build. I couldn't resist speaking first, sharing with everyone the direction we need to go. Isn't that what I was being paid for? Why waste time on meetings while the decision is obvious, at least for myself?

The behaviour appears to be rational when we consider the efficiency criteria. Coming prepared, sharing the experience, and following proven paths are all good practices. Choosing already known direction is a safe bet and might be perceived as an act of pragmatism. But is it really the optimal solution to the problem? Or more importantly, does it solve the right problem?

I've been noticing a similar pattern in the behaviour of other senior colleagues in multiple contexts. They set a tone for the whole conversation, and less experienced colleagues feel obligated to follow the direction. The more right they are, the less room there is to find out when they're not. Eventually, they end up solving the wrong problem. The one they already know how to solve.

This pattern has a name. The Einstellung effect has been studied for decades¹, and my favourite illustration on this comes from chess. When there’s a familiar position on a board for a player, their attention is directed away from the better move towards the one they feel confident with. They’re convinced they considered alternative moves, but the eye-tracking machine doesn't register a player really has seen the move, they rather focus on what they’re used to seeing².

This sheds new light on the seniority problem. Whenever a problem is formulated, our natural instinct pushes us to solve it using tools we already know and trust. This makes perfect sense in terms of saving cognitive effort, but reduces our ability to make unbiased judgements. Now, since experienced people have naturally more influence in their teams, this effect creates a broader blast radius, which further explains why well-balanced teams in seniority are generally healthier³. Consequently, when a principal engineer with 15 years of experience in microservices is prone to see them as a solution for most of the problems, it doesn't mean that they are narrow-minded. It means they should be more aware of the bias happening in each conversation. Yet, awareness alone isn’t enough from the larger organisational point of view.

We might expect this bias to be purely human as a cognitive safeguard. It turns out it happens for large language models too. In a medical environment, LLMs caused clinical misdiagnosis following the statistical shortcuts, despite high accuracy on medical benchmarks, and ignored patient specific evidence in atypical cases⁴. The same thing happens in software engineering, where the first solution a model suggests anchors the engineer's thinking even when better alternatives exist⁵.

Given that, LLMs inherit the same mechanism, and when you ask them with your bias already in place, they will respond with higher confidence, reinforcing the bias rather than questioning it. This is a widely known behaviour, LLMs amplifying both the strengths and the blind spots of whoever is asking.

Context management is a real challenge given the human tendency to share thinking process upfront. It’s tempting to leave it to the individual, but it doesn’t solve the problem at the organisational level, and remains an unnecessary risk for everyone else.

What helps is (1) organisation-wide awareness that such a problem exists⁶, (2) the presence of a devil’s advocate somewhere in the process to challenge assumptions, and provide different, uncomfortable perspective⁷. Not as the optional step, but rather as a part of the culture.

After a few years of holding back my first answer, I feel much less confident with my proposals, which might be a good thing, and still need to remind myself of the importance of defining the right problem rather than having a solution in my pocket. Yet, it remains alluring.

---

1. The Einstellung Effect (Luchins, A.S., 1942): original study introducing the concept, showing how prior experience with a method blocks access to simpler solutions. ↩

2. Einstellung in chess (Bilalić, M., McLeod, P. & Gobet, F., 2008): eye-tracking study showing experts' attention is actively directed toward familiar patterns even when a better move exists. Extended by Sheridan, H. & Reingold, E.M. (2013): the effect is strongest when the first pattern is good enough, not when it's clearly wrong. ↩

3. Expertise diversity in teams (Li, Q., She, Z. & Yang, B., 2018): varied expertise translates into innovative performance only when leadership actively creates conditions for perspective exchange. ↩

4. Einstellung in medical LLMs (MedEinst, 2025): LLMs caused clinical misdiagnosis by following statistical shortcuts despite high benchmark accuracy. ↩

5. Einstellung in software engineering (Cognitive Biases in LLM-Assisted Software Development, 2025): anchoring bias in developer-LLM interactions shows that the first solution a model suggests influences subsequent decisions even when better alternatives exist. ↩

6. Naming as intervention (Lane, D.M. & Jensen, D.G., 1993): participants who received an explanation of the Einstellung mechanism were three times more likely to overcome it than the control group. ↩

7. Devil's advocate in decision making (Cosier, R.A., 1978): groups using devil's advocacy achieve higher decision quality than groups under free discussion. Schweiger, D.M., Sandberg, W.R. & Cosier, R.A. (1989): devil's advocate reduces confirmation bias and overconfidence by balancing information seeking. ↩