How to give and receive technical feedback — a guide for engineering teams

Strong technical teams are built on how they exchange feedback, not just what they build. Whether in code reviews, architecture debates, or day-to-day collaboration, the goal is the same: improve the work while maintaining trust.

What Good Feedback Looks Like

Effective technical feedback is specific, actionable, and grounded in shared goals.

• Focus on the work, not the person. Say “This function is hard to test because it mixes concerns,” not “You wrote this poorly.”
• Tie feedback to outcomes. Explain why it matters: performance, readability, maintainability, security, or user impact.
• Be concrete. Vague comments like “this feels off” don’t help. Point to exact lines, behaviors, or trade-offs.
• Offer a path forward. Suggest alternatives or ask guiding questions instead of just pointing out problems.

Example (code review)

Instead of:

“This is confusing.”

Say:

“This method handles validation, transformation, and persistence in one place. Splitting it into smaller functions would make it easier to test and reason about. For example, a separate validateInput() step could isolate edge cases.”

Writing Constructive Feedback

Structure your feedback so it is easy to receive and act on.

A simple pattern: Observation → Impact → Suggestion

• Observation: What you see, without judgment
• Impact: Why it matters
• Suggestion: A concrete improvement

Example (architecture discussion)

• Observation: “This design relies on synchronous calls between services.”
• Impact: “That could increase latency and create cascading failures under load.”
• Suggestion: “Have you considered an event-driven approach for non-critical updates to decouple the services?”

This structure reduces ambiguity and keeps the conversation productive.

Framing Feedback for Impact

How you say something determines whether it gets used or ignored.

• Use neutral, precise language. Avoid exaggerations like “always” or “never.”
• Ask questions to invite collaboration: “What do you think about extracting this into a shared module?”
• Prioritize feedback. Don’t overwhelm with minor issues; highlight what matters most.
• Separate preferences from standards. Make it clear when something is subjective versus required by team conventions.

Example (style vs substance)

“This naming doesn’t follow our conventions (team standard), and it also makes the intent unclear (impact). Renaming it to calculateInvoiceTotal would align both.”

Receiving Feedback Without Defensiveness

Receiving feedback well is just as important as giving it.

• Assume positive intent. Most feedback is meant to improve the work, not attack you.
• Listen fully before responding. Avoid interrupting or immediately justifying.
• Ask clarifying questions. “Can you point to a case where this breaks?” is more useful than “It works on my machine.”
• Acknowledge valid points. Even partial agreement builds trust.
• Take time if needed. It is fine to say, “I’ll think about this and follow up.”

Example (non-defensive response)

Instead of:

“I had to do it this way because of the deadline.”

Say:

“That’s a fair point about the coupling. I optimized for speed given the deadline, but I can refactor this into separate components now.”

Separating Personal from Technical

Conflicts often arise when technical critique feels personal.

• Use shared goals as the anchor: performance targets, reliability, user experience.
• Avoid identity language: not “your design,” but “this design.”
• Normalize disagreement. Different approaches are expected in complex systems.
• Escalate to principles, not opinions. Refer to documented standards, benchmarks, or prior decisions.

Example (heated discussion reframed)

“This approach is wrong” →

“This approach introduces a single point of failure. Our reliability target is 99.9%, so we need redundancy here.”

Feedback in Different Contexts

Code Reviews

• Keep comments small and scoped to changes.
• Use inline suggestions where possible.
• Distinguish between blocking issues and optional improvements.

Architecture Discussions

• Compare trade-offs explicitly: scalability, complexity, cost, time.
• Use diagrams or examples to clarify thinking.
• Capture decisions and rationale for future reference.

Team Settings (standups, retros, planning)

• Give feedback on processes, not just code.
• In retros, frame issues as system problems, not individual failures.
• Encourage quieter voices to contribute. ### Creating a Feedback-Positive Culture

A healthy team makes feedback routine, safe, and expected.

• Model the behavior. Senior engineers should both give and receive feedback openly.
• Normalize early feedback. It is easier to adjust a design doc than rewrite a system.
• Reward improvement, not ego. Celebrate when feedback leads to better outcomes.
• Keep loops short. Frequent, lightweight feedback beats infrequent, heavy critique.
• Document standards. Reduce friction by aligning on conventions and expectations.

Example (team norm)

“All pull requests should include at least one suggestion and one acknowledgment.”

This ensures feedback is balanced and consistent.

Real-World Before and After

Before (ineffective)

“This API design is bad. It won’t scale.”

After (effective)

“The API requires clients to make three sequential calls to render a page. Under high traffic, that could increase latency and error rates. We could reduce this by aggregating the data server-side into a single endpoint.”

Quick Checklist

• Is it about the work, not the person?
• Is it specific and actionable?
• Did you explain why it matters?
• Did you suggest a next step or alternative?
• If receiving: did you fully understand before responding? Teams that treat feedback as a shared tool-not a personal judgment-move faster, build better systems, and enjoy working together more. Would you like this adapted into a shorter checklist for your team or a template you can paste into pull requests?

---

Rizwan Saleem — https://rizwansaleem.co