The art of giving and receiving feedback as an engineering leader

Feedback is one of the most powerful tools for growth, yet it is often misused or avoided altogether. In a high-performing engineering team, feedback is not just a formality during performance reviews. It is a continuous process that helps engineers grow, aligns expectations, and prevents small issues from escalating into major problems.

A strong feedback culture fosters trust, improves collaboration, and ensures that both technical and non-technical challenges are addressed openly. On the other hand, when feedback is unclear, inconsistent, or nonexistent, teams stagnate. Engineers feel lost in their growth, tensions build up silently, and mistakes repeat themselves. For engineering leaders, mastering the art of both giving and receiving feedback is essential, not just to improve the team but to improve themselves.

How to give feedback effectively

Giving feedback is a skill, not just an instinct. It is easy to tell someone their code needs improvement or that a meeting did not go well, but if feedback is not clear and constructive, it can do more harm than good.

One of the most effective methods I have found is the SAIL framework. It provides a structured way to ensure feedback is specific, actionable, and supportive rather than vague or discouraging.

• Situation: Describe the context in which the behavior or action happened. Avoid generalizations like “you are always late with estimates” and instead say, “during the last two sprints, your tasks have often been underestimated, leading to scope adjustments.”
• Action: Clearly state what the person did. Stick to observable facts, not interpretations. Saying, “you ignored the team’s input” is not helpful, but “you made a decision about the tech stack without discussing it with the team” is more concrete.
• Impact: Explain the effect of their action on the team, project, or stakeholders. This helps connect feedback to a broader goal rather than making it feel personal.
• Learning: Offer guidance on how to improve or adjust for the future. Feedback should not just point out mistakes but provide a path forward. Try to ask the person their opinion and how they think it can be improved.

For example, instead of saying, “your PRs take too long to review,” using SAIL would sound more like:
“In the last sprint (situation), your pull requests were often reviewed late (action), which caused delays in merging and slowed down deployment (impact). To improve this (learning), we could schedule review time earlier in the sprint or use smaller PRs to make them easier to review. What do you think about it? Do you think of another solution?”

A good feedback culture ensures that feedback is frequent and not just something that happens when something goes wrong. Balancing positive reinforcement with constructive criticism helps people stay motivated while knowing what to improve.

The challenge of receiving feedback as a leader

Engineers are used to giving and receiving feedback about code, but as you grow into leadership, feedback shifts toward team performance, strategy, and decision-making. It can be tough to separate personal feelings from constructive criticism, especially when it comes from executives or peers.

I remember a time when I was asked to speed up development time. At first, I took it as micromanagement and executive pressure to deliver faster. It felt like a push for more output at the expense of quality. But after discussing it more, I realized it was not about just moving faster, it was about accountability and predictability. Product managers needed clearer insight into what was coming next so they could plan our roadmap effectively. They also needed more transparency during the development so they could anticipate eventual delays.

Instead of dismissing the feedback, I worked on addressing the root concern. I built a dashboard showing release-per-week, release-per-month, and release-per-quarter, current bugs (and a few other metrics) to give better visibility into how often we shipped. I made technical debt more transparent so PMs could understand where engineering time was going. I also encouraged developers to be more engaged in estimating their tasks so that forecasts were more reliable, as well as being more vocal on the progress of their task during daily meetings.

At the same time, I made sure to educate product managers about the unpredictability of software development. I explained how shifting focus, trade-offs, and deep collaboration with designers influenced timelines. The result was a much better working relationship between engineering and product. Had I simply dismissed the feedback as executive pressure, I would have missed an opportunity to make meaningful improvements.

What engineering managers can do to create a feedback culture

Feedback does not happen naturally in every team. As an engineering leader, you need to actively shape a culture where feedback is safe, constructive, and expected.

One of the simplest but most powerful things you can do is celebrate wins as a team. Feedback is often associated with criticism, but recognizing good work is just as important. Publicly acknowledging contributions, whether in retrospectives or all-hands meetings, reinforces positive behaviors and keeps morale high.

Regular one-on-one meetings are another key moment for feedback. Instead of waiting for performance review cycles, I always include a small feedback section in every one-on-one. This makes feedback a normal part of conversations rather than something that only happens when there is a problem.

Feedback also needs to go in both directions. As a leader, you cannot just give feedback, you need to actively ask for it from your engineers. Simple questions like “Is there anything I could be doing better to support you?” or “What is something I am not seeing that is affecting the team?” help uncover blind spots. I have found that the more I show I am open to feedback, the more my team is willing to share honest thoughts about what is and is not working.

Encouraging peer feedback also strengthens teams. If feedback only comes from leadership, engineers may hesitate to share their thoughts with each other. Creating spaces for engineers to review each other’s work, discuss approaches openly, and improve together ensures that feedback is embedded in the team’s DNA.

Feedback is a skill, not a one-time conversation

Great teams do not fear feedback. They embrace it as a tool for learning, improvement, and alignment. Whether it is refining a technical approach, improving team processes, or handling interpersonal challenges, feedback is what keeps a team moving forward.

Engineering managers have a responsibility to model the right behaviors, giving clear and constructive feedback, receiving criticism with openness, and fostering an environment where honest conversations are normal.

A team that thrives on feedback is a team that grows together. The question is, do you make space for those conversations, or do you let them happen only when things go wrong?