How to Give Feedback to Developers: A Tech Lead's Playbook

The first time I gave critical feedback to a developer, I handled it terribly. I waited three months, bundled together every issue I had noticed, and delivered it all in a single overwhelming conversation. The developer was blindsided. They felt attacked. It took weeks to rebuild the relationship. I learned that giving feedback is a skill, and like any skill, it requires practice and a framework.

After leading teams for over two decades and mentoring hundreds of developers, I have developed an approach that consistently works. Not because it is soft or avoids hard truths, but because it is designed to be heard. For a structured framework for regular feedback sessions, check out my one-on-one meeting guide.

Why Developers Resist Feedback

Software engineers are problem-solvers by nature. When they receive feedback, their instinct is to debug it: "Is this feedback valid? Is the sample size sufficient? Did they see the full context?" This analytical resistance is not defensiveness in the traditional sense. It is how engineers process information.

Understanding this changes how you deliver feedback. You need to provide enough context and specificity that the developer's analytical brain can validate the feedback rather than dismiss it. Vague feedback like "you need to communicate better" gets rejected immediately. Specific feedback like "in last Tuesday's design review, you interrupted Maria three times. I noticed she stopped contributing after that" gives them something concrete to evaluate.

The SBI Framework

I use a modified Situation-Behavior-Impact (SBI) framework for all feedback, both positive and constructive:

• Situation: When and where did the behavior occur? Be specific.
• Behavior: What exactly did the person do? Observable actions, not interpretations.
• Impact: What was the effect on the team, project, or individuals?

Example: Constructive Feedback

"During yesterday's sprint planning (situation), you estimated the payment feature at two days without asking any clarifying questions about the requirements (behavior). The team is now committed to a timeline that I think is unrealistic, and we may need to renegotiate with product later this week (impact). Can you walk me through your estimate?"

Example: Positive Feedback

"In the code review for the auth refactor (situation), you wrote detailed explanations for each comment and offered to pair with James on the trickier changes (behavior). James told me he learned more from that review than from any documentation. It significantly sped up his onboarding (impact)."

Notice that positive feedback gets the same level of specificity. "Good job" is almost as useless as vague criticism. Specific praise tells people exactly what to repeat.

Timing: The 48-Hour Rule

Give feedback within 48 hours of the event. After that, memories fade and the moment loses its teaching power. If someone handled a production incident poorly on Monday, do not wait until the Friday one-on-one. Pull them aside Tuesday morning.

The exception is when emotions are high. If a deploy went badly and the developer is stressed, give them space. But come back to it within two days. "I wanted to circle back on Tuesday's deploy. Now that the dust has settled, can we talk about what happened?"

Private Criticism, Public Praise

This is an old rule and it remains correct. Constructive feedback should always be delivered privately. No one learns when they are embarrassed in front of peers. Their brain switches to self-protection mode and nothing productive happens.

Positive feedback benefits from a public audience. Recognizing someone's contribution in a team meeting, Slack channel, or sprint retro reinforces the behavior and signals to the team what "good" looks like. But be aware: some people are uncomfortable with public recognition. Ask your team members their preferences.

The Feedback Sandwich Is Dead

The old advice of wrapping criticism between two compliments (the "feedback sandwich") has been widely debunked. Developers see through it immediately. "Nice job on the feature. The code quality was terrible. Great standup update though!" Nobody is fooled.

Be direct. "I need to give you some feedback about code quality on the last PR. Some of the issues were significant enough that I want to discuss them so we can prevent them going forward." No padding. No manipulation. Respect the person enough to be honest.

Navigating Difficult Conversations

The Underperformer

When a developer is consistently underperforming, you need a structured approach. Start with curiosity, not accusations. "I've noticed your velocity has dropped over the past three sprints. Help me understand what's going on." Sometimes the answer is personal issues, burnout, or unclear expectations, things you can help with.

If the issue is skill-related, create a clear development plan with specific, measurable goals. "By the end of next sprint, I'd like to see you completing code reviews within 24 hours and writing unit tests for all new functions." Give them support: pair programming, training resources, or reduced workload while they improve.

If the issue persists after clear expectations and support, escalate to your engineering manager. Document everything. This protects both you and the developer.

The Brilliant Jerk

Every team eventually has someone who writes excellent code but treats colleagues poorly. Do not tolerate this because they are productive. One toxic person can drive away three good developers. The feedback is direct: "Your technical contributions are strong. Your interaction with teammates is not meeting the team's standards. Specifically, [SBI examples]. This needs to change."

The Over-Performer Who Needs Redirection

Sometimes the feedback is not about doing less but doing differently. A developer who goldplates every feature needs to hear: "Your quality bar is high, which I appreciate. But the business needs us to ship faster. I need you to calibrate quality to impact. Not every feature needs your absolute best engineering."

Receiving Feedback as a Tech Lead

Feedback flows both ways. If you never ask your team for feedback on your leadership, you are flying blind. At the end of every one-on-one, I ask: "Is there anything I could do differently to better support you?" The first few times, you will get nothing. Keep asking. Eventually, someone will share something honest. How you react to that first piece of real feedback sets the tone for everything that follows.

If someone tells you your code reviews are too harsh, do not explain or justify. Say "Thank you for telling me that. Can you give me a specific example so I can calibrate?" Model the behavior you want to see from your team.

Building a Feedback Culture

The ultimate goal is a team where feedback flows freely between all members, not just from you. Practical steps to get there:

• Normalize feedback in code reviews. Use the severity prefixes discussed in our code review best practices to make review feedback clear and non-personal.
• Run retrospectives focused on behavior. "What did we do well as a team?" and "What should we do differently?" are feedback questions.
• Celebrate feedback publicly. When someone shares useful feedback, acknowledge it: "Maria made a great point in retro about our deploy process. We are implementing her suggestion."
• Make it safe to fail. If people fear punishment for mistakes, they will hide them. If they see mistakes treated as learning opportunities, they will share openly. This is fundamental to building engineering culture.

Quick Reference: Feedback Scenarios

Giving feedback well is one of the highest-leverage activities you have as a tech lead. A five-minute conversation can redirect someone's career trajectory. Invest the time to do it right.