A lot of engineering teams talk as if quality comes from pull requests and design docs, but sometimes what really shows up there is ego. A PR goes up, or a doc gets shared, and what should have been useful feedback turns into a public display of who can find flaws, raise doubts, or drag things out the longest. Some of that feedback may even be technically correct, but correctness is not the whole job. Feedback is supposed to improve the work and help people move forward. When it starts making people slower, more guarded, and less willing to share unfinished work, something has gone wrong.
When the process breaks down
The clearest sign is volume without care. Someone opens a PR or shares a design, and instead of getting focused input, they get buried under comments that would have been better handled in an actual conversation. A huge wall of feedback does not feel useful. It feels exposed. If the feedback is big enough to take over the thread, that is usually a sign you should talk to them directly, walk through it together, and help them get to something you can actually stand behind.
Design docs can be even worse because they attract a certain kind of vague objection. A reviewer can cover a proposal in open questions, soft doubt, and endless “have you considered” energy while adding very little. That may look thoughtful from a distance, but a lot of the time it just creates churn and uncertainty. If there is a real concern, name it. If there is a better option, propose it. If they did not think it was the right approach, it would not be in the design in the first place. And if someone addresses all the feedback, they should not be rewarded with a fresh batch of concerns that could have been raised earlier. At that point the process stops feeling like feedback and starts feeling like survival. A huge pile of comments does not make the author look bad by itself. A lot of the time it makes the reviewer look worse than they realize.
Limiting the blast radius
Unfortunately, understanding bad feedback culture does not protect anyone from it. Sometimes there really is just one person who turns every PR into a fight, and the practical thing is to reduce the damage as much as possible.
Getting that person involved early often helps, because people are usually easier to deal with in a smaller conversation than in a big thread where every comment becomes a performance. Smaller PRs help too. Huge pull requests are painful even on healthy teams, and on unhealthy ones they give people even more room to tear through someone else’s work. It also helps to find an ally. Not a bodyguard, and not someone who has to jump into every fight, but someone sane who can help sort signal from noise and remind you when a thread has stopped being about the code. You did not necessarily do anything wrong. A lot of the time, you just did not do what that person wanted.
One thing that usually does not work is defending a decision by pointing to the existing codebase. The same people who insist on conventions are often the first ones to tell you that the old code was wrong and you should also fix it. Existing code can give context, but it will not save you. And when a PR turns into a long back and forth, stop trying to settle it in comments. Jump on a call, send a message, or talk directly and sort it out offline. PR wars are horrible. They waste time, harden positions, and make everybody feel worse while accomplishing almost nothing.
What managers need to own
Managers own more of this than they sometimes want to admit. If PRs are constantly churning, if one person seems to block everything, or if people quietly dread sharing work, that is not just a personality issue. It is a team issue, and it will eventually show up in morale, delivery, and retention whether anyone says it out loud or not.
Good environments do not happen by accident. Teams need clear repo standards so humans are not wasting energy arguing about formatting, linting, tests, or broken builds, and newer engineers need guidance instead of surprise public takedowns. It also helps when people know each other a little better. Teams with more trust usually have less appetite for pointless destruction.
Managers also need to actually look at what is happening. That does not mean reading every line of every PR, but it does mean paying enough attention to notice whether work is moving or just churning, and whether someone is giving sharp but fair input or simply grinding people down. And if someone is repeatedly toxic, that has to be dealt with directly. Sometimes the answer is coaching. Sometimes it is stronger action. A manager’s job is not just to notice this stuff. It is to protect the team from it before one toxic person burns out everyone around them.
What better feedback looks like
Good feedback should not just improve the work. It should also improve the team. It should catch real problems, sharpen thinking, and help people grow without turning every draft, design, or pull request into a public stress test. When feedback becomes a power game, people get more cautious, less open, and more focused on self-protection than good work.
Engineering is hard enough already. Teams do not need more ego, more churn, or more people hiding behind process to make each other miserable. They need clearer standards, better support, and less tolerance for the kind of behavior that makes everyone slower while pretending to serve quality.