Summarizer

Silent Resistance in Debates

← Back to Lessons from 14 years at Google

The consensus among commenters is that winning every debate often fosters "silent resistance," suggesting that technical correctness is frequently less important than preserving long-term professional relationships and trust. Many participants emphasize that prioritizing "being right" over collective consensus can lead to a toxic "resentment debt," with some even drawing parallels to Nietzschean "slave morality" or team dysfunctions rooted in a fear of conflict. While most view these insights as essential wisdom for navigating engineering culture, skeptics argue that this approach can inadvertently encourage passive-aggressive sabotage or serve as a hollow platitude that masks deeper issues of leadership hypocrisy.

13 comments tagged with this topic

View on HN · Topics
I am going to file this line > If you win every debate, you’re probably accumulating silent resistance.
View on HN · Topics
Sun Tsu said you have to either give your opponent an out or completely destroy them. I’ve always said that you can only skin a sheep once but can shear them over and over. Or to be more blunt, it’s better to be effective than right. It’s about keeping the bigger/long term goals in mind. That means relationships and being an asshole.
View on HN · Topics
This is one of the Five Dysfunctions of a Team (fear of conflict, caused by absence of trust). Highly recommend the book. https://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Tea...
View on HN · Topics
That one makes me uncomfortable, which is a bad sign...
View on HN · Topics
I'd say it's a good sign – at least now you're aware it might be happening. A worse sign would be thinking you're definitely not that sort of personality; you'd be accruing silent resentment from both being loud _and_ clueless.
View on HN · Topics
Nothing novel, but all true, well expressed, and worth repeating. This should be part of every CS curriculum. #2 and #14 are tough pills to swallow. It's not enough to be right, or even have a long track record of being right. You usually have to convince others that it was their idea all along, but still advocate for yourself at performance review time.
View on HN · Topics
> If you win every debate, you’re probably accumulating silent resistance. This is very true in personal lives as well.
View on HN · Topics
This is actually slave morality: https://en.wikipedia.org/wiki/Master%E2%80%93slave_morality According to Nietzsche, masters create morality; slaves respond to master morality with their slave morality. Unlike master morality, which is sentiment, slave morality is based on ressentiment—devaluing what the master values and what the slave does not have. As master morality originates in the strong, slave morality originates in the weak. Because slave morality is a reaction to oppression, it vilifies its oppressors
View on HN · Topics
Funny that there’s nothing to learn from working for an evil company, other than: keep your head down and don’t ask hard questions :/
View on HN · Topics
Aren't #2 and #14 mostly the same point? And they seem to indicate a rather unhealthy cultural dynamic. Amazon's "Disagree and commit" is a much healthier dynamic than "Pretend to agree and then silently sabotage." I think there's a valid middle ground in finding a path that works well for everybody, but this does not seem to be the right way. I wonder if this is a common thing at Google because I recall another interview (can't find now, I think in the context of WebRTC??) from many years ago where an engineer proudly described how he conspired against a major technical decision because it didn't align with his personal preferences. I was a bit shocked to see someone admit something like that so publicly.
View on HN · Topics
Number 14 really speaks towards the subtle difference between being domineering in conversation and genuinely a sme in an area with little overlap in other people's domain knowledge. I feel like being extremely transparent in explaining the rationale and to a degree teaching really reinforces that boundary. If you get to a point of silent resentment 'debt' in spite of efforts to empathise, consider perspective, and provide clarity, then you have a collaboration problem on the other end. How you choose to address that is dependent on your political capital, and sometimes you need to accept it. Young me naively believed people were like rational automatons who would speak up when appropriate, not take thinga personal, and aspire to the true north that I aspired to as a colleague, and that is no baseline for a healthy collaboration.
View on HN · Topics
What a mediocre article. Its just enough for people to agree and nod and go "wow yeah true!!" while offering almost zero value to people who don't already agree. These are not useful to juniors. Yes, almost all of this is true and well said, but it offers no additional value. It's like a smell test: Show this article to engineers and those who disagree with lots of points should be given a senior mentor. These points are really good, but they often miss context and further info and caveats. I would have liked if the Author just added a little bit more content. Like, for example, the point about "Being right is cheap. Getting to right together is the real work". Yes, it's certainly true that a decision made in agreement is better than one that isn't. However, how do you get there? Does everyone else give up their (weakly held, according to the article) opinions? I would argue it should be acceptable for your opinions to hold, to be factually based, and still to not align with the final decision made. Any respectable engineer should be fine with this. > Your code doesn’t advocate for you. People do. It depends on how much code you output relative to others, for example, and how performance is measured, how much time is actually spent in meetings (and how much of that is wasted or could-have-been-an-email). I've been told at a previous job that the quality and amount of code I output made them reconsider their entire salary- and bonus-structure (and they did restructure it but by the time it went into effect I had gotten a better offer and left). I just had more programming experience than most other developers there (through open source and my own projects), even though I was junior to most of them. Your code can advocate for you, and so can your general output, your contributions, etc. It's not all politics in all companies, though I'm sure the author's point applies at FAANG. Furthermore, I don't know if this point results in actionable advice for juniors, for example. To not bother writing good code? To not bother with doing the best you can? To not honing your skill and instead go to public speaking courses? I'm not sure. Good-ish article, just not enough novel substance IMO, and reads a bit like AI slop. Also choked on this: > Colleagues often remark on Osmani’s humility and generosity despite his fame in the field.
View on HN · Topics
This feels somewhat hypocritical coming from Addy. Addy Osmani plagiarized my code and 'apologized' years later by publishing an article on his website[1] that he has never linked to from his social media accounts. I cannot accept his apology until he actually syndicates it with his followers. Seems relevant to note this behavior in light of points "6. Your code doesn’t advocate for you. People do.", "7. The best code is the code you never had to write.", and "14. If you win every debate, you’re probably accumulating silent resistance." 1. https://addyosmani.com/an-apology-to-eli/