I’ve sat through enough “radical candor” workshops and HR-approved seminars to know that most corporate advice on how to take feedback you disagree with is absolute nonsense. They tell you to “embrace the growth mindset” or “seek the hidden kernel of truth,” as if you’re a piece of software being patched rather than a person who actually knows how the system works. It’s patronizing. In reality, sometimes the feedback is just wrong—it’s based on a misunderstanding of the legacy code, a misinterpreted metric, or a manager who hasn’t touched a terminal in five years.
I’m not here to give you a lecture on emotional intelligence or how to smile while being told your architecture is flawed. Instead, I want to talk about the mechanical side of this: how to defend your technical decisions without becoming the person no one wants to work with. I’ll share what I’ve learned from years of being on the receiving end of bad post-mortems and how to navigate those conversations so the actual problem gets solved, rather than just your ego.
Table of Contents
Managing Defensive Reactions to Criticism When Youre Right
The instinct to push back is physiological. When a senior architect tells you your implementation is flawed—especially when you’ve already run the benchmarks and know it works—your brain treats it like a physical threat. I’ve spent enough time in incident reviews to know that the hardest part of managing defensive reactions to criticism isn’t the technical debate; it’s the three seconds of heat in your chest before you open your mouth. If you let that heat dictate your response, you’ve already lost the argument, regardless of how correct your code is.
Instead of jumping straight into a defensive rebuttal, I’ve learned to treat the disagreement like a bug report. If someone says your logic is unsound, don’t treat it as a personal attack on your competence. Treat it as an unhandled exception in the communication layer. Ask for the specific edge case they are worried about. This shifts the energy from a battle of egos to a technical investigation. It’s a way of practicing emotional intelligence in professional settings without sounding like a HR manual. You aren’t conceding that you’re wrong; you’re just gathering more telemetry before you defend your position.
Emotional Intelligence in Professional Settings Under Fire
There is a specific kind of physiological spike that happens when you’re halfway through a technical explanation and someone interrupts to tell you that your approach is fundamentally flawed. Your heart rate climbs, your face gets warm, and your brain starts building a legal case to prove them wrong. This is where emotional intelligence in professional settings actually matters—not in the sense of being “nice,” but in the ability to decouple your ego from your implementation. If you let the adrenaline take the wheel, you stop being an engineer and start being a person who is just trying to win an argument.
The goal isn’t to suppress your reaction, but to widen the gap between the critique and your response. I’ve learned that the most effective way to handle this is to treat the feedback as a data point rather than a personal indictment. Instead of immediately pivoting to a defense, I try to ask clarifying questions that force the conversation into the realm of logic. This shifts the energy from a confrontation to a constructive dialogue after disagreement. It’s much harder for a conversation to devolve into a shouting match when you are both looking at the same set of requirements or logs, rather than looking at each other.
Five ways to stop the internal monologue from ruining the meeting
- Separate the signal from the noise. When someone critiques your implementation, your brain immediately treats it as a personal attack on your competence. It isn’t. Try to strip away the tone, the delivery, and the ego, and look only at the technical delta. If they say your approach is “over-engineered,” don’t argue about your intent; look at whether the complexity actually provides a measurable benefit.
- Ask for the “why” behind the “what.” If a reviewer leaves a comment that feels wrong, don’t reply with “I did it this way because…” Instead, ask, “What specific edge case are you worried this pattern misses?” This shifts the conversation from a battle of opinions to a collaborative search for failure modes. It turns a confrontation into a debugging session.
- Document the disagreement, but don’t live in it. If you’ve presented your case and the decision goes the other way, accept it and move on. Write down your reasoning and the counter-arguments in a private doc or a design ticket. If the decision turns out to be the wrong one six months from now, you won’t be “I told you so” person; you’ll be the person who has the data to help fix it.
- Watch out for the “Correctness Trap.” In engineering, we often fall into the trap of thinking there is one mathematically perfect solution to every problem. There isn’t. Usually, there are just different sets of trade-offs. If you disagree with feedback, ask yourself if you are fighting for the “right” way or if you are just fighting for your way.
- Use the “Wait and See” buffer. If the feedback feels particularly stinging or fundamentally incorrect, don’t respond in the PR or the Slack thread immediately. Close the laptop, go for a quick ride, or just grab a coffee. Most of the time, the urge to defend your honor subsides once the initial spike of cortisol passes, and you can actually address the technical merits of the critique.
The Post-Mortem Mindset for Feedback
Separate your ego from the pull request; if someone says your logic is flawed, they aren’t attacking your intelligence, they’re just pointing out a bug in the implementation.
If you disagree with the feedback, don’t argue semantics—ask for the specific failure case they’re worried about so you can both look at the same data.
Treat every piece of friction as a documentation opportunity; if a misunderstanding happened, it usually means the original design or the requirement wasn’t clear enough to begin with.
The Post-Mortem of the Ego
At the end of the day, handling feedback you disagree with isn’t about winning an argument or proving you’re the smartest person in the room. It’s about separating your identity from your code and your decisions. If you can manage that initial spike of defensiveness, keep your cool when the room gets tense, and focus on the underlying technical reality rather than the person delivering the critique, you’ve already won. We’ve covered how to stop the immediate emotional hijack and how to navigate the politics of a professional disagreement, but the goal remains the same: extract the signal from the noise so the system actually gets better.
I’ve spent too many nights staring at logs, realizing that the “obvious” solution I fought so hard for was actually the root cause of a cascading failure. It’s bruising to the ego, sure, but that’s where the real learning happens. Don’t let the desire to be right get in the way of being effective. If you can learn to treat every piece of friction—even the unfair or poorly communicated kind—as a data point to be analyzed rather than a personal attack, you’ll stop fighting the process and start mastering it. Just write it down, fix the gap, and move on to the next ticket.
Frequently Asked Questions
What do I do when the person giving the feedback is technically less experienced than I am but holds more seniority?
This is a classic friction point. I’ve been there—staring at a senior manager’s suggestion that fundamentally ignores how the underlying system actually works.
How do I push back on a feedback item during a performance review without looking like I'm being difficult or uncoachable?
Don’t fight the person; fight the data. If a manager says your velocity is low, don’t just say “I’m busy.” Bring the logs. Show them the three unplanned production incidents you spent Tuesday fixing or the documentation debt you’re cleaning up. Frame it as a resource allocation problem rather than a personal failing. “I hear you on the speed, but here is the technical debt I’m prioritizing to prevent the next outage. How should we balance that?”
Is there a way to document my disagreement formally without it looking like I'm building a legal case against my manager?
The trick is to document the logic, not the person. I don’t write “Manager X ignored my warning about the database migration.” Instead, I create a design doc or an ADR (Architecture Decision Record) that outlines the proposed approach, the identified risks, and the trade-offs. If we go with the other path, the record shows we made an informed choice. It’s not a paper trail for HR; it’s just a technical history of why we chose X over Y.
At what point does "taking feedback" stop being a professional necessity and start being a sign of a toxic engineering culture?
It stops being professional the moment the feedback stops being about the system and starts being about your character. If the “critique” is just a way to move goalposts or punish someone for a design choice that was actually documented and approved, you aren’t in a code review; you’re in a blame game. When the focus shifts from “how do we fix this” to “whose fault is this,” the culture is already broken.
