Monday morning, October 13th. Watching someone implement a complex architectural solution to avoid doing the obvious thing that would have worked, and realizing we've made simplicity socially unacceptable.

The Intelligence Tax

Here's the problem: obvious solutions don't make you look smart. They make you look like you didn't think hard enough.

Someone proposes a straightforward fix to a problem. The room goes quiet. Everyone's thinking: "That's too simple. What are we missing? Surely the problem requires a more sophisticated approach. Otherwise, why are we all here?"

So you dismiss the obvious solution and search for something more impressive. You add layers. You introduce abstractions. You architect a solution that demonstrates you've really thought about this. You build something complex enough to justify everyone's time and expertise.

Then it doesn't work as well as the simple thing would have. Or it works but requires 10x the maintenance. Or it works initially but becomes unmaintainable. So eventually, after the complex solution causes enough problems, someone quietly implements the obvious fix. And it works. Of course it works. It was obvious.

The Complexity Credential

We've turned complexity into a credential. The more complicated your solution, the smarter you must be. The more moving parts, the more sophisticated your thinking. The harder it is to understand, the more expert knowledge it must contain.

This is completely backward. Complexity is usually evidence of unclear thinking, not deep thinking. The person who needs eight layers of abstraction to solve a problem hasn't thought more deeply—they've thought more confusedly. The person who sees the direct path isn't missing nuance—they're seeing clearly.

But simple solutions don't signal intelligence. Anyone could have thought of the obvious approach. If you want to demonstrate expertise, you need to do something non-obvious. Something that requires specialized knowledge. Something that makes other people nod and say "I wouldn't have thought of that."

So we optimize for impressiveness instead of effectiveness. We choose solutions that showcase our intelligence over solutions that solve the problem. We add complexity as a credential, then spend years maintaining it.

Why Obvious Solutions Get Dismissed

The obvious solution gets dismissed because it threatens everyone's self-image. If the problem really was that simple, why did you need experts? Why did you have all those meetings? Why did you spend weeks analyzing it?

Accepting a simple solution means admitting the problem didn't require the level of sophistication you brought to it. It means your expertise was overkill. It means someone without your credentials could have solved it. This is uncomfortable, so you find reasons why the simple solution won't work.

"It's not scalable." (But you don't need it to scale.) "It's not elegant." (But it works.) "It's not maintainable." (But it has fewer moving parts than your complex version.) "It's not future-proof." (But the future is uncertain and this solves the present problem.) "It's not best practice." (But best practices are context-dependent and this is the right practice for this context.)

You generate objections until you've justified rejecting the obvious in favor of something that lets you demonstrate your skills. Then you build the complex thing. Then it causes problems. Then someone implements the obvious fix anyway. The revenge of the obvious is that it works, eventually, after you've exhausted the alternatives.

The Expert's Blind Spot

Experts are especially vulnerable to this. They've accumulated sophisticated tools and frameworks. They've learned to see complexity that novices miss. They've developed taste for elegant abstractions. All of this makes them better at solving genuinely complex problems.

But it also makes them worse at recognizing when a problem isn't complex. The expert sees every problem through their sophisticated toolkit. They pattern-match to scenarios where complexity was necessary. They can't see the simple solution because their expertise trained them to look past it toward the interesting complications.

The novice doesn't have this problem. They don't know enough to see the subtle complications, so they see the obvious approach clearly. Sometimes they're wrong—the problem really is complex and they're missing important constraints. But often they're right, and the expert has overcomplicated it.

This is why "naive questions" from outsiders sometimes reveal that the emperor has no clothes. The outsider asks "why don't you just do X?" and the room full of experts has to admit they rejected X not because it wouldn't work, but because it wasn't interesting enough to apply their expertise to.

The Maintenance Revenge

The revenge of the obvious isn't immediate. Initially, the complex solution seems to work. It does what it's supposed to. It showcases the team's sophistication. Everyone feels good about the impressive thing they built.

Then you have to maintain it. The person who built it moves on. New people join. They look at the complex architecture and ask "why is it built this way?" and the answer is "because we needed to handle X edge case" except that edge case never actually happens. Or "because we wanted it to scale to Y" except you never reached that scale. Or "because we were following Z best practice" except that practice doesn't fit your actual constraints.

The complex solution was optimized for impressiveness at design time, not for maintainability over its lifetime. And maintainability is where the obvious solution gets its revenge. The simple approach is easy to understand, easy to modify, easy to debug. The complex approach requires deep context, careful modification, and sophisticated debugging.

Over time, the maintenance cost of the complex solution exceeds the total cost of implementing the simple solution, breaking it when assumptions change, and implementing a different simple solution for the new context. But you already committed to the complex approach, so you're stuck with it.

How to Stop Fearing the Obvious

First: Optimize for effectiveness, not impressiveness. Your job is to solve the problem, not to showcase your intelligence. The solution that works with the least machinery is usually better than the solution that demonstrates sophisticated thinking.

Second: Try the obvious thing first. Even if you think it won't work, try it. You might be wrong about its limitations. And if it does work, you just saved yourself from building something more complex than necessary.

Third: Make simplicity respectable. When someone proposes an obvious solution, your instinct might be "that's too simple." Reframe it as "that's elegantly simple." Simplicity isn't evidence of shallow thinking—it's often evidence of clear thinking.

Fourth: Question your objections. When you find yourself dismissing a simple solution, audit your objections. Are they real constraints, or are they intellectual insecurity? Are you rejecting it because it won't work, or because it won't showcase your expertise?

Fifth: Remember the maintenance burden. That clever, complex solution you're excited to build will eventually become someone else's maintenance nightmare. Possibly yours, six months from now when you've forgotten why you made it complicated. Simple solutions are gifts to your future self.

The Monday Lesson

The obvious solution usually works. We reject it not because it's wrong, but because it's embarrassing. It's embarrassing that the problem wasn't complex enough to require our sophistication. It's embarrassing that we spent so much time on something that had a straightforward answer. It's embarrassing that someone without our credentials could have solved it.

So we complicate it. We add layers, abstractions, edge case handling, future-proofing, architectural elegance. We build something impressive. Then we maintain it forever, wondering why the simple systems are so much easier to work with.

The revenge of the obvious is that it works, reliably, with minimal maintenance, while your sophisticated solution requires constant attention. The obvious solution doesn't signal intelligence, but it solves the problem. And solving the problem was supposed to be the point.

Stop optimizing for impressiveness. Start optimizing for effectiveness. Try the obvious thing first. Make simplicity respectable. Question objections that protect your ego instead of preventing problems.

The simplest solution that could possibly work probably does work. And when it works, no one will remember that it was obvious—they'll just remember that it worked. That's the real revenge: obvious solutions become invisible, while complex solutions become maintenance burdens.

Choose obvious. Choose simple. Choose what works. Let the complexity signaling be someone else's problem.

We reject obvious solutions because they don't signal intelligence. If the problem has a straightforward answer, why did we need experts, meetings, and analysis? So we add complexity as a credential—layers, abstractions, architectures that showcase sophisticated thinking. Then we maintain that complexity forever while wondering why simple systems work better. Experts are especially vulnerable because their toolkit trains them to look past simple solutions toward interesting complications. The maintenance revenge comes later: the complex solution optimized for impressiveness at design time becomes a burden over its lifetime. The obvious approach is easy to understand, modify, and debug. Simple solutions are gifts to your future self. The obvious solution doesn't signal intelligence, but it solves the problem—and solving the problem was supposed to be the point. Try the obvious thing first. Make simplicity respectable. Question objections that protect ego instead of preventing problems. The simplest solution that could possibly work probably does work.