The Price of Being Right

Posted on May 4, 2026  •  13 minutes  • 2705 words

Software would be a much nicer place if the only things that clashed were Git branches. But no: egos clash. And when two well-fed egos meet in a daily standup, the merge conflict stops being in the code and starts being in the room.

In theory, software development is engineering: requirements, data, benchmarks, reasoned decisions. In practice, a lot of technical discussions look suspiciously like a bar fight, just with words like “idempotent” and “eventual consistency” instead of “you owe me a beer.”

I know this firsthand, because I’ve been on both sides. I’ve won arguments I had no business winning and lost others where I was right. And more than once I’ve been exactly the obnoxious character I’m about to describe — which gives me some moral standing to write about this, even though it also means owning up to things I’d frankly rather not.

We’re going to talk about why winning the argument matters more to us than solving the problem, about what happens when ego shows up with a title, and about what tactics we can use to survive without ending up hating the job or ourselves.

The factory defect

Programming has a small built-in flaw: you spend your whole day making decisions. Small ones, medium ones, enormous ones. From “what do I name this variable?” to “what architecture is going to define this product’s future for the next five years?”

Day after day, that reinforces a very comfortable idea: my judgment really matters. And it’s not wrong — judgment does matter. The problem starts when your judgment and your identity fuse together until they’re indistinguishable, so that questioning a technical decision feels like questioning the person who made it.

Psychology explains this with more elegance than the thing really deserves — they call it the IKEA effect , which demonstrates that we overvalue things we built ourselves, regardless of their actual quality.

Applied to software: your architecture looks flawless to you partly because it’s yours, not only because it’s good. And your colleague’s looks worse to you partly because it’s theirs. The original experiment used half-assembled IKEA furniture, but your brain reacts the same way when someone criticizes your database schema in a code review.

Add to that the fact that most of us have been through imposter syndrome, fought it by studying, grinding, and shipping things, and we’re surrounded by people who are just as stubborn as we are.

The cocktail is mixed: in many technical conversations, it’s not “two technical options” that clash — it’s “my professional identity” against “yours.”

And underneath the arguments about tabs vs. spaces, monolith vs. microservices, or SQL vs. “let’s spin up a data lake and figure it out as we go,” there’s always the same subtext: if I admit you’re right, what does that say about me?

When the ego in front of you comes with a LinkedIn title

Arguing with a peer is one thing. It’s an entirely different thing when the ego comes with a title: CIO, CTO, CISO, Head of Something, Global Architect, Client Tech Lead, “Head of Technology since 1998 back when this was all COBOL and real men wore ties.”

The scenario is so predictable it practically has its own choreography. Your team shows up with a well-reasoned proposal — you’ve looked at requirements, constraints, budget, you’ve argued among yourselves before presenting it, which is part of the process — and the client’s decision-maker has already decided the right answer is something else “because I saw it at another company / a buddy told me / I caught a talk about it / I like their logo.”

So you present the data. He nods slowly while you talk, with that look people get when they’re waiting for you to finish so they can tell you what they decided before they walked in the room.

And when you’re done: “yeah, but we’ve always done it this way and it’s worked fine for us.” And when you flag specific risks: “that might happen elsewhere, but it doesn’t apply to us.”

The real-time translation of all that is: I’m not changing my mind because I’ve been selling this to the executive committee for months. If he backs down now, he’s not changing his position — he’s admitting he might have been blowing smoke. And in a lot of organizations, that’s worse than being wrong.

Social psychology calls this committed consistency (Influence ): once someone has publicly stated a position, the psychological cost of changing it is enormous, because it changes how others perceive their coherence.

In plain terms: he’s more afraid of looking inconsistent than of being wrong. And rational argument, against that, has about as much chance as a well-documented PR against a “no, I just don’t like it.”

I’ve been in that situation more times than I’d like. And I’ll admit I didn’t always keep my cool. More than once I let frustration take over and turned what should have been a technical conversation into something resembling a low-intensity boxing match, where neither of us gained anything useful and the relationship took a hit.

The anger you feel when you’re right and the other person refuses to hear it is a genuinely hard emotion to manage — and anyone who claims they always handle it well is either lying or hasn’t been in situations intense enough.

The technical ego: when the discussion is about performance but what’s at stake is pride

Setting titles and org charts aside, there’s another kind of ego battle that’s more everyday and, in some ways, more damaging precisely because it’s harder to spot. It’s the fight over “the right way” to do something between peers: two seniors, two architects, two people who’ve been at this for years and have strong, well-grounded opinions.

The pattern is always the same. One person argues their solution is more efficient. The other says the first one is overengineered and theirs is simpler. The first says it’s not overengineering, it’s thinking ahead. The second replies that thinking ahead in this specific context is overcomplicating things just in case they ever grow like Netflix, which probably won’t happen.

Both of them actually sound reasonable. The problem is that neither is willing to say “okay, maybe in this specific context yours wins”, because that would feel like giving up — and giving up, even in the face of a good argument, triggers the same brain circuits as a physical threat.

Amy Arnsten , a Yale neuroscientist, has documented how ego-threat stress reduces blood flow to the prefrontal cortex, the part of our brain that keeps us reasonable. In plain English: when someone challenges something you consider yours, your brain goes into fight-or-flight mode before you can even process whether their argument has merit.

And that matters, because it means most technical discussions that go off the rails don’t fail from lack of intelligence or lack of information — they fail because the participants’ brains have left “problem-solving mode” and entered “win the fight mode.” Which is a colossal waste of technical talent, and also bores everyone watching from the sidelines.

How to survive (and sometimes win) without getting hurt

What follows is a mix of personal experience, quite a few hard lessons, a fair amount of reading (and some YouTube rabbit holes) on applied psychology, and advice from people who navigated these waters better than I did.

This isn’t a foolproof recipe — it’s what’s worked for me most often.

Change the ring

As long as the argument is “your idea” vs. “my idea,” we’re stuck.

The most useful lever is trying to move the conversation from “two people with two positions” to “one team with one problem.”

Phrases like “what risk are we accepting if we go this route?” or “imagine this breaks in production a year from now — which scenario would we rather be managing?” pull people out of gladiator mode and put them in accountability mode.

It doesn’t always work, but when it does, it works well — because the other person no longer has to lose for you to win: you’re both looking in the same direction.

Put data on the table, but do it with care

Data helps, but wielded as a weapon it backfires.

No “see, I told you so”, no presenting a benchmark like it’s a Supreme Court ruling. The temptation is real — and momentarily satisfying, like a contemptuous backhand — but it poisons everything.

The approach that actually works, without turning it into a knife fight, is to run small proof-of-concepts with clear metrics, present results as “here’s what we’re seeing, not what I think,” and give the other person a dignified exit.

“With A we’re taking X time, with B three times that. If performance is a priority, A gives us more headroom. If we want simplicity now, we can go with B knowing what we’re accepting.”

You’re giving the other person the option to change their mind because the data changed the situation, not because “you were smarter.” The difference, in terms of how that gets processed emotionally, is enormous.

The “on the record” move

Sometimes you’re simply not going to win. The person in charge has more power, the client is paying, or the political decision was made before anyone thought to ask you.

In those cases, the healthiest move — for you, for your team, and for your future self when someone asks “who on earth decided this?” — is to lay out your arguments in writing, clearly and without drama: risks, alternatives, foreseeable costs.

Get it on record that your technical recommendation is different, that you’re going along with the decision, and that the risks you’ve identified are what they are.

That’s not passive-aggressive if it’s done with professionalism. It’s simply protecting the project from corporate selective amnesia — a phenomenon just as well-documented as the IKEA effect and considerably more damaging in the long run.

Pick your battles, even when your pride stings

There’s a line you learn the hard way: being right is expensive.

Not every hill is worth dying on.

Before you dig your heels in, it’s worth asking whether this will actually matter six months from now, whether the cost of fighting — time, wear and tear, the relationship — is worth the technical benefit, or whether there’s a solution that’s good enough to live with.

Letting a debatable API or a naming convention you don’t love slide, in exchange for saving your credibility for when it really matters — security, foundational architecture, technical debt that’s going to sink the product — is often the smartest available move.

Not the most satisfying. But the smartest.

Working your own ego: the only one you can actually tune

The least fun part of this whole discussion is that your ego is in the game too. Always. Even when you’re “objectively right.”

You can tell when it costs you a ton to say “I don’t know,” when you get angrier about tone than content, or when you only accept someone else’s idea after a phase where you reframe it in your own words so it feels like yours.

I recognize all of that because it’s happened to me, and it’ll probably keep happening. The difference between now and ten years ago is that I catch it earlier — though not always in time.

People who navigate ego-heavy environments well tend to actually listen, without mentally preparing their rebuttal while the other person is still talking; they can give ground on small things without feeling like they’ve lost standing; and they can draw a line when needed without making it a scene.

Three things that sound simple and, in practice, cost a fortune.

Dealing with the client’s ego: neither a doormat nor a battering ram

When the difficult ego is the client’s — internal or external, it doesn’t matter — money, contract, and a power asymmetry enter the picture, making everything more delicate. A few things tend to work more often than you’d expect.

Never embarrass anyone in public. If you need to push back against someone with a title, do it one-on-one or in a small room where they don’t feel cornered in front of their team. A bruised ego in public is pure gasoline: the person shuts down completely, the rest of the room takes their side out of tribal loyalty, and your technical argument — however solid — gets associated with the awkward moment instead of its actual content.

Social psychology has a name for this: the backfire effect , which describes how people with deeply held beliefs often double down harder when challenged with contrary evidence in a threatening way. Counterintuitive and infuriating, but real.

Get allies among those who bear the consequences. Often there are people inside the client’s own organization who see the same risks you do — ops, support, the security team that’s been saying exactly what you’re proposing for months. If you align your message with theirs, the weight is very different from “the annoying outside consultant who wants to sell more hours.”

And speak the other person’s language: a CIO cares about business risk, compliance, costs that end up in a headline; a CTO cares about technical debt and team velocity; a CMO cares about brand impact. Translating technical arguments into those currencies works far better than talking design patterns to someone who hasn’t written a line of code in twenty years.

And ultimately, if none of that lands, you have to decide whether your role in that relationship is trusted advisor who recommends and documents, or martyr who burns out trying to rescue someone who doesn’t want to be rescued.

Both are legitimate positions. Just make sure you’re actively choosing one, not drifting into no man’s land because you can’t accept that sometimes people would rather be wrong than be helped.

Fewer gladiators, more adults with logs

Software development is already hard enough on its own: shifting requirements, technology in constant motion, bugs that only surface when someone’s watching, estimates everyone knows are fiction but signs off on anyway. If we also turn every technical decision into an ego battle, burning out early shouldn’t come as a surprise.

This isn’t about aspiring to a world without conflict — that doesn’t exist and, honestly, wouldn’t be healthy; constructive tension produces better systems than warm, comfortable consensus.

It’s about arguing hard about ideas without it becoming a war about identities, using data as a compass instead of a weapon, learning to lose small battles to win the larger war, and leaving a record when we see the iceberg coming — not to shout “I told you so” when it hits, but because maybe next time, if the paper trail is there, someone will listen sooner.

In the end, we all want the same thing: for the system to work, for production to not be on fire every Friday, and to go home with the sense that we did decent work.

If that means deflating our own ego a little — and I know from personal experience that we’re not always willing to — and learning to handle someone else’s, maybe that’s a reasonable price to pay.

Though we can always do a mental fork and fantasize about a parallel universe where the biggest fight of the day is whether the README should be in English or Spanish.

And where I, in that universe, always keep my cool.

Sources and references

Not everything in this article comes from personal experience. Here are the people who went to the trouble of proving with data what many of us had already figured out the hard way.

• The “IKEA effect”: When labor leads to love - Norton, Mochon, and Ariely (2012). A study on why we overvalue things we build ourselves.
• Influence: The Psychology of Persuasion - Robert Cialdini. The definitive book on social persuasion and committed consistency.
• Stress signalling pathways that impair prefrontal cortex structure and function - Amy Arnsten (2009). On how stress degrades the prefrontal cortex’s ability to keep us rational.
• When Corrections Fail: The persistence of political misperceptions - Nyhan and Reifler (2010). The study that documented the backfire effect: how contrary evidence can actually reinforce mistaken beliefs.