The art of giving and receiving feedback as an engineering leader

An executive once told me I needed to speed up development time. My first instinct was to bristle. It felt like micromanagement dressed up as strategy, a push for output at the expense of quality.

I was wrong about what the feedback meant.

After sitting with it and having a real conversation, I understood the actual concern. Product managers couldn’t plan effectively because they didn’t know what was coming or when. They couldn’t anticipate delays because we weren’t surfacing them early. The feedback wasn’t “go faster.” It was “we can’t see what’s happening and we don’t trust the forecasts.”

That changed what I needed to do. I built a dashboard with release-per-week, release-per-month, and release-per-quarter metrics, plus current bug counts. I made technical debt more visible so PMs could understand where engineering time was going. I worked with developers to make estimates more reliable and encouraged them to be more vocal in dailies when things shifted. I also explained to the product team why software timelines move: how shifting priorities, design collaboration, and unknowns compound.

The working relationship between engineering and product improved significantly. If I’d dismissed the original feedback as executive pressure, that improvement wouldn’t have happened.

What makes feedback land versus miss

The difference between feedback that helps and feedback that lands wrong is usually specificity. Vague feedback, like “your PRs take too long” or “you need to communicate better,” doesn’t give someone a path forward. It gives them something to feel bad about.

A framework I’ve used is SAIL: Situation, Action, Impact, Learning. The structure forces specificity at each step.

Instead of “your PRs take too long to review,” SAIL produces something like: “In the last sprint, your pull requests were opened late in the week, which pushed review and merge into the following sprint and blocked deployment. Going forward, it would help to open PRs earlier in the cycle, or break larger changes into smaller pieces that are easier to review incrementally. What’s your take, is there something making that hard right now?”

The last question matters. Good feedback isn’t a verdict. It’s the start of a conversation, and the person receiving it often has context you don’t have about why things happened as they did.

Specificity also separates the person from the pattern. Feedback about a recurring behavior in a specific context is easier to act on than feedback that reads as a character assessment. “You made a decision about the tech stack without discussing it with the team” is a conversation. “You always ignore input” is an argument.

Building a team where feedback happens regularly

Most teams give feedback in two moments: performance reviews and when something goes wrong. Both are too late for feedback to be most useful.

I include a feedback exchange in every 1:1, not a formal review, just a standing practice. “Is there anything I’m doing or not doing that’s making your work harder?” and some version of “here’s something I’ve noticed that I’d like to talk about.” This makes feedback a normal part of how we talk rather than a special occasion with stakes attached.

It also has to flow upward. When I show I’m genuinely open to feedback, by asking for it, acting on it visibly, and not getting defensive, engineers become more willing to give it to me and to each other. A team where feedback only comes from management is a team where only management sees clearly. The people doing the work see things the manager doesn’t.

Celebrate what’s working explicitly. Feedback gets associated with criticism, but recognizing specific contributions publicly is equally important. “The way you handled the stakeholder escalation in Tuesday’s call was exactly right” does more than a quarterly “good job this period.” Specific positive feedback reinforces the behavior and makes developmental feedback less threatening when it comes.

Peer feedback builds resilience in the team too. If engineers only hear from me, I become a bottleneck for their growth. When teams build the habit of reviewing each other’s work and talking about it openly, in retros, in code reviews, in ad-hoc conversations, feedback becomes part of how the team operates rather than something that happens to engineers when a manager decides to give it.