Why feedback is hard in technical teams
Technical work is easy to criticise in a way that feels personal. A design, a calculation or a piece of code carries hours of someone’s effort, and a comment that is accurate can still land badly. At the same time, silence is costly: a problem noticed late is usually more expensive to fix and more awkward to raise.
Constructive feedback is information given so that the other person, or the work, can improve. The word constructive matters: the aim is to help, not to score points or vent frustration. Done well, it builds trust and makes the next round of review easier for both sides.
Before you speak
Ask yourself a few questions first:
- What exactly is the issue? If you cannot state it in a sentence, you are not ready.
- Is it important? Not every difference of taste needs a comment. Separate problems that affect correctness, safety, maintainability or the schedule from preferences.
- Do I have the full picture? Constraints, earlier decisions and requirements you have not seen may explain what looks like a mistake. Asking can be better than asserting.
- Is this the right time and place? Detailed technical criticism often works better in writing or a one-to-one conversation than in front of a whole meeting. Praise can be public; difficult points usually deserve privacy.
- What do I want to happen? Knowing the outcome you are after keeps the comment focused.
If you are annoyed, wait. Feedback given in irritation tends to be about the person, not the work.
A simple structure
Many people find it helpful to cover four things, in plain words:
- Observation. What you actually saw, without interpretation.
- Impact. Why it matters, in terms of the work, the team or the user.
- Suggestion or question. What could change, or what you would like to understand.
- Next step. What happens now, and who decides.
For example, instead of “This is confusing,” you might write: “In the second section, the term ‘load’ is used for both the applied force and the electrical load. A reader coming to it fresh could misread the calculation. Could we use separate terms and define each at first use?” The observation is concrete, the impact is explained and the suggestion is something the author can act on.
This is an illustration of a structure, not a formula; adapt it to the person and the situation.
Specific beats general
Vague comments are hard to act on, and vague praise is hard to learn from.
| Vague | More useful |
|---|---|
| “The report is messy.” | “The test results appear in three different tables with different units. Using one table and one unit would make them comparable.” |
| “Good job.” | “Your breakdown of the failure cases made it easy for the reviewers to see what was and was not covered.” |
| “This code is bad.” | “This function handles input parsing, validation and storage. Splitting it would make each part easier to test.” |
| “You never listen.” | “In yesterday’s meeting, the supplier question was raised twice before we moved on. Next time, can we note questions and answer them before changing topic?” |
Describe behaviour and work product, not character. “The calculation omits the temperature effect” invites a fix; “you are careless” invites defensiveness and usually is not accurate anyway.
Kind does not mean soft
Being kind means taking the person seriously, not hiding the message. Praise that is a cushion for criticism, followed by “but,” can be hard to trust. A few principles keep honesty and care together:
- Be direct about the issue. Do not bury it.
- Acknowledge what works, when it is true and relevant, and say why it works.
- Assume good intent unless you have evidence otherwise. Most problems come from missing information, time pressure or unclear requirements.
- Use questions where you are unsure. “What made you choose this approach?” can surface a good reason, or help the author spot the problem themselves.
- Offer help. A suggestion, an example or a shared look at the problem shows you want the work to succeed.
Cultural norms about directness differ across countries and teams. Watch how colleagues give and receive comments, and adjust your tone, while keeping the content clear.
Technical feedback in practice
In reviews of designs and code, a few habits help:
- Label the severity: “must fix,” “should consider,” “optional preference.” Authors can then prioritise.
- Comment on the work against agreed criteria such as requirements, standards your team follows or style guides, rather than personal preference.
- Keep a respectful tone in written comments, which are read without the benefit of your tone of voice. Short blunt remarks can come across as harsher than intended.
- Where safety, regulation or ethical concerns are involved, do not soften the message until it disappears. Raise it clearly and use the channels your organisation provides; rules vary by country and industry.
The same ideas apply in a formal code review or in design reviews, though those processes have their own conventions. Good feedback habits also make it easier to be on the other side of the exchange, receiving review feedback without taking it personally.
After the conversation
Check understanding: ask how the person plans to respond, or summarise what you agreed. Follow up later. If the change was made, say so; recognising improvement is part of feedback. If nothing changes, consider whether your message was clear, whether the issue was really within their control, and whether it needs to be raised with someone else, such as a lead.
Be open to disagreement. The author may have information you lack, and the outcome can be that you are the one who changes your mind. Feedback is a conversation, not a verdict.
Common mistakes
- Waiting so long that the problem has become expensive.
- Turning one issue into a list of every flaw.
- Generalising (“always,” “never”).
- Using sarcasm or jokes at the person’s expense.
- Giving feedback you would not accept yourself.
- Leaving out the reason why it matters.
Feedback is a skill that improves with practice. Starting small, with low-stakes comments on routine work, makes the harder conversations easier when they come. Strong team communication and the broader set of soft skills are what give feedback its chance of being heard.