Performance Reviews & Feedback

Performance reviews terrify people. On both sides of the table. The person being reviewed worries about being judged. The person giving the review worries about saying the wrong thing. So what happens? Everyone plays it safe. Reviews become a bureaucratic checkbox. Ratings get inflated. Real problems go unaddressed. Good people leave because nobody told them what they needed to hear — or told them too late.

This is one of the most consequential things you will do as a leader. Get it right and you accelerate careers, retain your best people, and build a team that trusts you. Get it wrong and you lose talent, breed resentment, and create a culture where nobody knows where they stand.

Let's get it right.

1. Feedback Is a Daily Habit, Not a Quarterly Event

Here is the single most important principle in this entire guide: if someone is surprised by anything in their performance review, you have failed as a leader.

Read that again. Let it sink in.

The review itself should be the most boring meeting of the quarter. Everything in it — every strength you acknowledge, every area for improvement you raise, every goal you discuss — should be something you have already talked about. Multiple times. In your 1:1s, in the moment after a meeting, in a quick Slack message, walking back from lunch.

This is what continuous feedback means. It doesn't mean you need to schedule formal feedback sessions every week. It means you pay attention, and when you see something worth commenting on, you comment on it. Right then. Not three months later when you're staring at a review template trying to remember what happened in January.

The benefits of this approach are enormous:

Trust increases. People trust leaders who tell them the truth consistently, not leaders who save it up and dump it on them twice a year. When you give feedback in the moment, it feels like coaching. When you save it for a review, it feels like judgment.

Behavior changes faster. If someone has a habit that's hurting them — interrupting in meetings, writing unclear design docs, missing edge cases in code — they need to hear about it the first or second time it happens, not after it's become an entrenched pattern. Early feedback is a nudge. Late feedback is a confrontation.

Reviews become easy to write. If you've been giving feedback all along, your review is just a summary of conversations you've already had. You pull up your 1:1 notes, look at the themes, and write it up. Thirty minutes, done. If you haven't been giving feedback, you're staring at a blank document the night before the deadline, trying to reconstruct six months of work from memory and Jira tickets.

Defensiveness drops. When someone hears something for the first time in a review, their brain immediately goes into defense mode. "That's not fair. Why didn't you tell me? I would have fixed it." And they're right. When they've heard it before, the review is just confirmation. "Yeah, we talked about this. I've been working on it. Here's my progress."

Here is a practical habit to build: after every meaningful interaction — a code review, a presentation, a design discussion, a 1:1 — ask yourself, "Is there feedback I should give?" If yes, give it within 24 hours. If you can give it in the moment, even better.

You will not always do this perfectly. Nobody does. But aiming for it will transform the quality of your reviews and the trust your team has in you.

2. Types of Feedback

Not all feedback is the same, and using the wrong type at the wrong time is a common mistake. There are three fundamental types, and each has its place.

Praise

Praise is recognizing something someone did well. It sounds simple, but most leaders are terrible at it. They either don't give enough of it, or they give it in a way that doesn't land.

Good praise is specific. "Great job" is not praise. It's noise. It tells the person nothing about what they did that was great or why it mattered. Compare that to: "The way you broke down that migration plan into phases, with rollback strategies for each phase, made the entire team confident we could ship it safely. That's exactly the kind of thinking that makes you invaluable on complex projects."

That second version tells the person exactly what behavior to repeat and why it matters. It's also more credible — it shows you were actually paying attention, not just handing out generic compliments.

Good praise is often public. When someone does something great, say it in front of others. In standup, in a team channel, in a retro. Public praise reinforces the behavior for the whole team, not just the individual. It also signals what "good" looks like, which is one of the most powerful culture-shaping tools you have.

Exceptions: some people are uncomfortable with public praise. Pay attention. If someone shrinks when you call them out in a meeting, switch to private praise with them and find other ways to give them visibility.

Constructive Feedback

Constructive feedback is telling someone that something they did — or a pattern in their behavior — needs to change. This is where most leaders struggle the hardest.

Good constructive feedback is specific. Just like praise. "You need to communicate better" is useless. The person doesn't know what that means. "In the last three sprint reviews, stakeholders have asked questions about your work that you couldn't answer on the spot, which made them lose confidence in the project. I'd like us to figure out how to prepare you better for those conversations" — that's actionable.

Constructive feedback is almost always private. Never give someone constructive feedback in front of their peers. It's humiliating, and they won't hear a word you say because they'll be too busy managing their embarrassment. Pull them aside. Do it in your next 1:1. If it's urgent, schedule a quick chat.

Coaching

Coaching is different from praise and constructive feedback because you're not telling the person anything. You're asking questions that guide them to figure it out themselves.

This is the most powerful form of feedback for senior people and high performers, because it respects their intelligence and develops their judgment rather than just correcting their behavior.

Instead of: "You should have involved the platform team earlier in your design."

Try: "Looking back at this project, at what point do you think bringing in the platform team would have been most helpful? What would have changed if you'd done that?"

The person arrives at the same conclusion, but they own it. It becomes their insight, not your instruction. That's far more likely to stick.

When to use each:

3. The SBI Framework

When you give constructive feedback, you need structure. Without it, feedback tends to drift into vague generalizations ("you need to be more proactive") or character attacks ("you're unreliable"). Both are useless and the second one is actively destructive.

SBI stands for Situation, Behavior, Impact. It forces you to be specific and objective, which makes your feedback dramatically more effective.

Here's how it works:

Situation. Set the scene. When and where did this happen? Be specific enough that the person knows exactly what moment you're talking about.

Behavior. Describe what you observed. Not what you think they were feeling or intending — what they actually did or said. Stick to observable facts.

Impact. Explain the effect of that behavior. What happened as a result? How did it affect the team, the project, the stakeholder, or the person themselves?

Example 1: Interrupting a teammate

Bad: "You're rude in meetings. You need to let other people talk."

Good: "In yesterday's standup (S), when you interrupted Sarah twice while she was explaining the API issue (B), she stopped sharing her concerns and just said 'never mind, it's fine' (I). I think we missed important context because of that."

Notice the difference. The bad version attacks the person's character. It invites defensiveness. "I'm not rude! When did I ever..." The good version describes a specific moment, a specific action, and a specific consequence. It's hard to argue with because it's factual. And it gives the person something concrete to change.

Example 2: Missing documentation

Bad: "Your documentation is always lacking."

Good: "When you shipped the payment service last week (S), the on-call engineer couldn't find any runbook or troubleshooting guide (B), which meant it took three hours to diagnose what turned out to be a simple config issue during Saturday's incident (I)."

Example 3: Positive feedback using SBI

SBI works for praise too, and it makes your praise much more credible.

"In the architecture review on Tuesday (S), the way you walked through the trade-offs of each approach and explicitly called out the risks (B) gave the team enough information to make a confident decision in a single meeting instead of the usual three rounds of back-and-forth (I)."

Making SBI a habit

The first few times you use SBI, it will feel mechanical. That's fine. Write it out before the conversation if you need to. After a few weeks, it becomes natural. You'll start thinking in Situation-Behavior-Impact automatically, and your feedback — both positive and constructive — will be noticeably better.

One pitfall to watch for: don't let the "I" in SBI become about your feelings. "It made me feel disrespected" turns the conversation into a debate about whether your feelings are valid. Focus on observable impact: what happened to the project, the team, the outcome.

4. Setting Goals

Performance goals are the foundation of performance reviews. Without clear goals, a review is just a vibes check — "I feel like you did well" or "I feel like you could do more." That's not useful for anyone.

There are two major frameworks for goal-setting in engineering organizations, and you need to understand both.

OKRs (Objectives and Key Results)

OKRs separate the what from the how much. The Objective is qualitative — it describes what you want to achieve in plain language. The Key Results are quantitative — they define how you know you achieved it.

Example:

• Objective: Make our deployment process reliable and fast.
• KR1: Reduce deployment failure rate from 15% to under 3%.
• KR2: Reduce average deployment time from 45 minutes to under 10 minutes.
• KR3: Achieve zero rollbacks caused by missing automated checks.

OKRs work well at the team and company level. They're good at aligning everyone around outcomes rather than activities. They're less useful for individual performance goals because individual KRs can feel artificial or gameable.

SMART Goals

SMART goals are Specific, Measurable, Achievable, Relevant, and Time-bound. They're more straightforward than OKRs and often work better for individual contributors.

Bad goals vs. good goals:

Aligning goals

Every individual goal should connect to a team goal, and every team goal should connect to a company or org-level goal. If you can't draw that line, the goal is probably not worth setting.

This doesn't mean every individual goal needs to be about shipping features. Goals around mentorship, technical quality, operational excellence, and personal development are all valid — as long as you can articulate why they matter for the team and the business.

When setting goals with your report, don't hand them a list. Co-create the goals. Ask them what they want to work on, what they want to grow in, what they think the team needs. Then shape it together. Goals that people help create are goals people actually care about.

Check in on goals regularly. Monthly at minimum. If a goal becomes irrelevant because priorities shifted, update it. Don't wait until the review to discover that someone spent the whole quarter on a goal that stopped mattering in month two.

5. Running a Performance Review

A good performance review has five phases. Skip any of them and the review suffers.

Phase 1: Preparation (you, 1-2 weeks before)

Start gathering information well before the review. You should be looking at:

• Your 1:1 notes from the entire review period.
• The goals you set together at the beginning of the period. Where did they land?
• Peer feedback (if your organization does 360s or you've collected informal input).
• Concrete examples of strong work, growth areas, and impact.
• Any feedback you gave throughout the period and whether behavior changed.

Do not rely on your memory. Memory is biased toward recent events and dramatic events. If you didn't keep notes, you'll write a review that's mostly about the last three weeks. That's not fair to anyone.

Phase 2: Self-assessment (them, 1 week before)

Ask your report to write a self-assessment before the review. This serves multiple purposes:

• It tells you how they see their own performance, which is crucial data. If their self-assessment is wildly different from yours, that gap is itself a topic for the conversation.
• It ensures they come to the review engaged and reflective, not passive.
• It surfaces accomplishments you might have missed. You don't see everything. They might have done excellent work that wasn't visible to you.

Give them a simple framework: What were your key accomplishments? Where did you fall short of your own expectations? What do you want to focus on next?

Phase 3: Your assessment (you, before the meeting)

Write your review. Be honest. Be specific. Use examples. For every statement you make — positive or constructive — you should be able to point to a concrete moment, deliverable, or pattern.

If you find yourself writing "needs to improve communication" without a specific example, stop. Go find the example. If you can't find one, reconsider whether the feedback is real or whether it's a vague impression that doesn't hold up to scrutiny.

Read your assessment through their eyes before the meeting. Is there anything that would feel unfair? Is there anything that would be a surprise? If yes, you need to either address it in advance or reconsider it.

Phase 4: The conversation

This is the part that matters most, and it's the part most leaders handle poorly. Some guidelines:

Don't read the review to them. They can read. Share the written review before or at the start of the meeting, then use the conversation to discuss it, not narrate it.

Start with their self-assessment. "How do you feel about the last quarter/half/year?" This grounds the conversation in their perspective and gives you information about where your views align and diverge.

Spend more time on growth areas than on ratings. The rating is a data point. The conversation about what's working, what's not, and what comes next — that's what actually changes performance.

Listen more than you talk. Ask questions. "Does this feedback resonate with you?" "What do you think is behind that pattern?" "What support would help you with this?" A review where you do 80% of the talking is a lecture, not a conversation.

Be direct. If someone is underperforming, say so clearly. Don't hide it in a wall of praise. Don't soften it so much that the message gets lost. You can be direct and compassionate at the same time. More on this in the next section.

End with clear next steps. What are we going to work on? What does success look like? When will we check in on progress?

Phase 5: Follow-up

The review is not over when the meeting ends. Within a week:

• Share a written summary if you haven't already.
• Set or update goals for the next period.
• Add the key themes to your 1:1 agenda so you can track progress.
• If you discussed a development plan or stretch opportunity, start making it happen now. Not next month.

The follow-through is what separates leaders who develop people from leaders who just evaluate them.

6. Difficult Conversations

At some point — probably sooner than you'd like — you will need to tell someone that they are not meeting expectations. This is the conversation that new leaders dread most, and it's the one they most often avoid or botch.

Here's the thing: avoiding this conversation is not kind. It's cruel. If someone is struggling and you don't tell them, you are robbing them of the chance to fix it. You are letting them continue down a path that ends in a PIP or a termination, and when that happens, they will look back and say, "Why didn't anyone tell me?"

How to have this conversation

Be direct from the start. Don't spend 20 minutes on pleasantries and praise before dropping the bomb. The person will feel ambushed and will retroactively distrust everything positive you said. Open with the topic: "I want to talk about your performance over the last few months. I have some concerns I want to share honestly."

Be specific. "You're not meeting expectations" is a starting point, not the whole message. You need to explain exactly what expectations are not being met, with examples.

"Over the last quarter, three of the five features you led were delivered more than two weeks late. In each case, the delays weren't surfaced until the sprint review. And the code quality issues — we've had four production incidents traced back to missing error handling in your services. These are the patterns I'm concerned about."

That's specific. That's factual. That gives the person something to respond to and something to change.

Be compassionate. Direct doesn't mean cold. You can acknowledge that this is hard to hear. You can ask about context you might be missing. You can express genuine confidence in their ability to improve — if you believe it.

"I know this is hard to hear, and I want to be clear that I'm telling you this because I believe you can turn it around. I've seen what you're capable of. Let's figure out together what's getting in the way."

Have a plan. Don't just identify the problem — outline what improvement looks like. "Here's what I need to see over the next 60 days. Let's meet weekly to check in on progress. Here are the specific things I'll be looking for."

Document everything. After the conversation, send a written summary of what was discussed, what the expectations are, and what the timeline is. This protects both of you. It ensures there's no ambiguity about what was said, and it creates a record in case the situation escalates.

What not to do

• Don't blindside them. If this is the first time they're hearing there's a problem, you skipped several steps.
• Don't do it in a group setting. Ever.
• Don't compare them to teammates. "Sarah ships things on time, why can't you?" is toxic.
• Don't apologize for giving the feedback. You're doing your job. "I'm sorry, but..." undermines your message.
• Don't promise outcomes you can't control. "If you improve, you'll get promoted." You might not have that authority.

7. Avoiding Bias

Every leader has biases. You are not the exception. The goal is not to eliminate bias — that's not possible. The goal is to recognize it and build systems that counteract it.

Here are the biases most likely to corrupt your performance reviews:

Recency Bias

What it is: Overweighting recent events and underweighting everything before the last few weeks.

How it shows up: Someone had a phenomenal Q1 and a mediocre Q2, and their review reads like they had a mediocre year. Or someone screwed up last week and it colors your entire assessment of six months of solid work.

How to counteract it: Keep running notes throughout the review period. After every 1:1, jot down what you discussed. When you see notable work — good or bad — write it down. When review time comes, you'll have a complete picture instead of relying on your decaying memory.

Halo Effect

What it is: Letting one positive quality dominate your perception of a person's entire performance.

How it shows up: "They're so smart" becomes a halo that makes you overlook missed deadlines, poor collaboration, or mediocre code. Being impressive in design reviews doesn't automatically mean they're performing well across the board.

How to counteract it: Evaluate each dimension of performance separately. Write your assessment of their technical work before you assess their collaboration. Rate each area independently, then look at the full picture. If every dimension is "exceeds expectations," ask yourself if that's really true or if the halo is talking.

Similarity Bias

What it is: Rating people who are similar to you — in communication style, background, personality, approach to problems — more favorably.

How it shows up: The person who thinks the way you do, who communicates the way you do, who would have made the same technical decisions you would — that person "just gets it." Meanwhile, someone with a different style but equally good results gets rated lower because their approach doesn't match your mental model of what "good" looks like.

How to counteract it: Focus on outcomes, not style. Ask yourself: "If someone I found personally harder to relate to had delivered the same results, would I rate them the same?" If the answer is no, you have a bias problem.

Squeaky Wheel Bias

What it is: Giving more attention and higher ratings to people who are vocal about their work, while underrating quiet contributors.

How it shows up: The engineer who presents at every all-hands and writes long update emails gets glowing reviews. The engineer who quietly maintains the system that everything runs on, who nobody thinks about because it never goes down, gets a "meets expectations" because their work is invisible.

How to counteract it: Actively look for invisible work. Who maintained the systems that didn't break? Who onboarded the new person? Who answered questions in Slack every day? Who reviewed the most pull requests? The data is there if you look for it. Don't let visibility be a proxy for impact.

Other biases to watch for

• Leniency bias: Rating everyone high to avoid difficult conversations. If everyone on your team "exceeds expectations," either you have the greatest team ever assembled or your standards need calibration.
• Central tendency bias: Rating everyone in the middle because it feels safe. This underrates your stars and overrates your underperformers.
• Attribution bias: Crediting successes to individual talent and blaming failures on circumstances, or vice versa, depending on whether you like the person.

The single best defense against all of these biases is data. Specific examples. Concrete outcomes. Measurable results. The more you anchor your reviews to facts rather than feelings, the fairer they'll be.

8. Giving Feedback to Senior Engineers

This deserves its own section because it's genuinely different from giving feedback to junior or mid-level engineers, and most new leaders get it wrong.

Here's the situation: you just became a team leader. You have a senior engineer on your team who has been writing software for 15 years. They have more technical experience than you. They've seen more systems fail and succeed. They might have been considered for the leadership role you're now in.

And you need to give them feedback on their performance.

If you walk in with the same approach you'd use with a junior engineer — "here's what I noticed, here's what you should do differently" — you're going to get resistance. Not because senior engineers can't take feedback, but because the delivery implies a level of authority over their craft that you haven't earned.

What works

Lead with curiosity, not authority. Instead of "I think you should involve the team earlier in your design decisions," try "I've noticed the team sometimes feels blindsided by design directions. What's your take on how design decisions are getting communicated?" This opens a dialogue instead of issuing a directive.

Anchor feedback to impact, not technique. Don't tell a senior engineer how to write code or architect a system. Tell them about the impact of their choices on the team, the project, or the organization. "Your design for the caching layer is technically sound. The concern I have is that nobody else on the team can maintain it, and that creates a bus factor of one." That's about impact. It respects their technical ability while raising a legitimate concern.

Acknowledge their expertise genuinely. Not as a preamble to criticism, but as a real part of the conversation. "You have more context on this system than anyone. That's exactly why I want your perspective on this problem." When people feel respected, they're far more receptive to feedback.

Frame it as a partnership. "I need your help with something. The junior engineers are hesitant to push back on your code reviews because your comments can come across as dismissive. I know that's not your intent. Can we talk about what's happening and how we can fix it?" You're not above them. You're working with them.

Focus on the leadership dimension. Senior engineers are expected to lead, not just code. Their influence on the team — through mentorship, design decisions, code reviews, and culture — is as important as their individual output. This is often where the most impactful feedback lies, and it's the area where they might have the biggest blind spots.

What doesn't work

• Telling them how to do their technical work (unless it's truly wrong).
• Being indirect or hinting. Senior people respect directness.
• Pulling rank. "I'm the lead, so..." kills the conversation instantly.
• Giving feedback on things you don't understand deeply enough to discuss.

9. Receiving Feedback as a Leader

You're now in a position of authority, and that authority creates a barrier. People will be less likely to tell you the truth. They'll nod in meetings even when they disagree. They'll say "everything's fine" when it's not. They'll vent to each other instead of to you.

This is not because they don't trust you personally. It's because you control things that matter to them — their assignments, their reviews, their career trajectory. That power dynamic is real, and pretending it doesn't exist doesn't make it go away.

Your job is to make it as easy as possible for people to tell you the truth.

How to actively seek feedback

Ask specific questions. "Do you have any feedback for me?" is too broad and too easy to deflect. "What's one thing I could do differently in our 1:1s that would make them more useful for you?" — that's specific enough to get a real answer.

Ask regularly. Make it part of your 1:1s. Not every time — that gets annoying — but once a month or so, ask. "What's one thing I've been doing well lately, and one thing I could improve?" The frequency normalizes it.

React well when you get it. This is the crucial part. The first time someone gives you honest feedback, they're testing the water. If you get defensive, explain yourself, or — worst of all — seem hurt, that's the last time they'll ever be honest with you. The correct response is: "Thank you. That's really helpful. Can you tell me more about what you observed?" Then actually change your behavior.

Share what you're working on. "Based on feedback I've received, I'm going to be more intentional about sharing context behind decisions instead of just announcing them. If you see me falling back into old habits, please call it out." This is powerful. It shows vulnerability, models the behavior you want from your team, and gives people explicit permission to hold you accountable.

Use anonymous channels. Some people will never give you honest feedback face-to-face. Team retrospectives with anonymous input, engagement surveys, or even a simple anonymous form can surface things that would never come up in a 1:1.

What you're modeling

When you seek and accept feedback gracefully, you're sending a message to your entire team: feedback is normal here. It's not threatening. It's how we get better. This sets the tone for a feedback culture, which is far more valuable than any single piece of feedback you receive.

When you resist or ignore feedback, you send the opposite message: feedback goes one way in this team. That's toxic, and your best people will leave for a team where they feel heard.

10. Real-World Scenarios

Theory is great. Let's look at what this actually looks like in practice.

Scenario 1: The review that motivated growth

Context: You have a mid-level engineer, Marcus, who has been solid but plateauing. He ships consistently, his code is good, but he's been doing the same kind of work for two years. He's capable of more.

Throughout the quarter: In your 1:1s, you've been asking Marcus about his career goals. He says he wants to reach senior level. You've been pointing out opportunities to stretch — "This cross-team project would be a great chance to practice technical leadership" — and he's been taking some of them, with mixed results. You've been giving real-time feedback after each one: what went well, what could be better.

In the review: You walk through the quarter together. You acknowledge his reliable delivery — it matters, and he should know you see it. Then you focus on the growth trajectory. "You took on the data pipeline coordination with the platform team. The technical work was strong. Where I think you have room to grow is in how you drove the project. You did most of the work yourself instead of delegating parts to the team, and when the scope changed, you absorbed it silently instead of escalating. At the senior level, leading the work is as important as doing the work."

You set goals together for next quarter: lead a project where at least 50% of the work is done by others, practice early escalation of scope changes, and present the technical design to the broader team. You commit to meeting bi-weekly on these goals specifically.

What happened: Marcus stepped up. Having clear, specific growth areas — not "be more senior" but "delegate, escalate, present" — gave him a concrete path. Two quarters later, he was promoted. He later told a new hire that the review was a turning point.

Why it worked: No surprises. Continuous feedback throughout the quarter. Specific, actionable goals. Follow-up commitment.

Scenario 2: The review that caused someone to quit

Context: You have a strong engineer, Priya, who has been on the team for three years. She's technically excellent, well-liked, and has been expecting a promotion to staff engineer.

What went wrong: Throughout the two quarters leading up to the review, you never discussed the promotion timeline with Priya. You assumed she knew it wasn't happening yet because the staff bar is high and there weren't enough opportunities for her to demonstrate staff-level impact. You never had that conversation. You were busy. It was uncomfortable. You figured you'd address it in the review.

In the review: You rate Priya as "meets expectations" — which, in your company's framework, means solid performance but not promotion-ready. You spend most of the review talking about areas for growth at the staff level. You think you're being helpful and forward-looking.

What Priya hears: "After three years of busting my ass, I'm just 'meeting expectations.' Nobody told me I wasn't on track for promotion. I've been working toward this for over a year and apparently everyone knew it wasn't happening except me."

What happened: Priya was crushed. Not by the rating itself, but by the surprise. She felt blindsided, disrespected, and invisible. She smiled through the rest of the review, said the right things, and started interviewing the next week. She was gone within a month, taking institutional knowledge with her that took the team six months to recover from.

What should have happened: The conversation about promotion readiness should have started six months earlier. "I know staff engineer is your goal. Let me be honest about where I think you are relative to that bar, and let's build a plan to close the gap." That conversation might have been hard, but it would have given Priya agency. She could have adjusted her work, sought out the right projects, or decided to leave on her own terms. Instead, she left feeling betrayed.

The lesson: Avoiding uncomfortable conversations doesn't prevent pain. It delays it, multiplies it, and destroys trust in the process.

Scenario 3: The feedback conversation that turned around a struggling engineer

Context: You have an engineer, David, whose work has declined noticeably over the last two months. Deadlines are slipping. Code quality has dropped. He's disengaged in meetings. A few teammates have come to you privately with concerns.

Your first instinct: David used to be great. Maybe he's just going through a rough patch. Give it time. Don't make a big deal out of it.

What you actually do (because you've read this guide): You bring it up in your next 1:1, using SBI. "Over the last few sprints (S), I've noticed that two of your features shipped after the deadline and your last three PRs needed significantly more revision cycles than usual (B). The team is starting to feel the impact — other people's work is getting blocked, and the project timeline is slipping (I)."

Then you ask: "This doesn't match what I've seen from you before. What's going on?"

David pauses. And then tells you he's been dealing with a family health crisis. He hasn't been sleeping. He's been distracted and he knows his work is suffering but he didn't know how to bring it up.

What you do next: You don't give him a pass. You don't pretend the performance issues don't exist. But you adjust your response completely. You work with him to redistribute his workload temporarily. You connect him with whatever support your company offers. You set up weekly check-ins focused on making sure he's not drowning. You make it clear that his job is not in jeopardy and that you'll work through this together.

What happened: David took two weeks of reduced responsibility, stabilized, and came back stronger. The vulnerability of that conversation actually deepened his trust in you and his commitment to the team. He became one of your most reliable engineers over the following year.

The lesson: Feedback is not just about correcting performance. It's about opening a door. Sometimes the conversation you think is about work turns out to be about something else entirely. But you'll never find out if you don't have the conversation.

11. Common Mistakes

Let's go through the mistakes that new leaders make most often. If you can avoid these, you're already ahead of the majority.

Only giving feedback in reviews

This is mistake number one because it leads to every other mistake. If you're saving feedback for the review, you're not leading — you're filing a report after the fact. Feedback should flow continuously. The review should contain nothing new.

Vague feedback

"You need to be more proactive." "Your communication could improve." "You should show more ownership."

What do any of these mean? The person walks away with no idea what to change. Every piece of feedback needs a specific example and a specific behavior to adjust. If you can't provide both, the feedback is not ready to be delivered.

The feedback sandwich

You've probably heard this one: start with something positive, deliver the criticism, end with something positive. Positive-negative-positive. The sandwich.

It doesn't work. Here's why: everyone knows what the sandwich is. The moment you start with a compliment, the person braces for the "but." They don't hear the positive feedback because they're waiting for the real message. And the closing positive feels hollow because it's clearly a palate cleanser, not genuine recognition.

Worse, over time, the sandwich erodes your positive feedback. When you give someone genuine praise, they'll start wondering, "OK, what's the bad part?" You've Pavlov'd them into distrusting your compliments.

What works instead: separate your feedback. If you have praise, give it. Fully, on its own. If you have constructive feedback, give that directly, on its own. Don't mix them in a single conversation just to make yourself more comfortable delivering criticism. The discomfort is yours to manage, not theirs.

Avoiding hard feedback

You know someone is underperforming. You know it. Your team knows it. The person probably suspects it. But you don't say anything because the conversation will be uncomfortable, or you like the person, or you're hoping it resolves itself.

It won't resolve itself. It almost never does. And every week you wait, the problem gets harder to fix, the team gets more frustrated, and the eventual conversation gets more painful.

Having the hard conversation early is an act of respect. It says: "I take your career seriously enough to tell you the truth."

Comparing people

"Why can't you ship as fast as Sarah?" "Marcus handles scope changes much better."

Never compare team members. It breeds resentment, creates competition instead of collaboration, and tells the person nothing useful about how to improve. Focus on the individual. What are their specific gaps? What does improvement look like for them? They're not Sarah. They're not Marcus. Help them be a better version of themselves.

Business Value: Why This Matters to the Organization

If the human argument doesn't convince you — though it should — here's the business argument.

Retention

The number one reason people leave their jobs is their relationship with their manager. Not compensation, not the work itself, not the company strategy. Their manager. And the quality of feedback and performance management is one of the biggest factors in that relationship.

When people get clear, fair, continuous feedback, they know where they stand. They feel seen. They feel invested in. Even when the feedback is tough, the fact that you cared enough to give it builds loyalty.

When people get vague, infrequent, or dishonest feedback, they feel invisible, confused, and insecure. They start looking for a team or a company where someone will actually help them grow.

The cost of turnover

Losing an engineer costs far more than you think. Industry estimates range from 50% to 200% of annual salary when you factor in:

• Recruiting costs (sourcing, interviewing, offer negotiation).
• Onboarding time (three to six months before new hires reach full productivity).
• Knowledge loss (the institutional knowledge that walked out the door).
• Team disruption (redistributed workload, broken relationships, morale impact).
• Opportunity cost (the projects that slip or don't happen while the seat is empty).

For a senior engineer earning $200,000, losing them could cost the company$100,000 to $400,000. If you lose two senior engineers a year because of poor feedback practices, that's up to$800,000 in preventable cost. That's before you account for the damage to team morale and culture that triggers further attrition.

Good feedback practices are not a "nice to have." They are one of the highest-ROI activities a leader can engage in.

Performance improvement

Feedback isn't just about retention. It's about getting better output from the people you already have. A team where feedback flows freely improves faster. People correct course sooner. They develop new skills faster. They make fewer repeated mistakes.

The difference between a team with strong feedback culture and one without is not marginal. It's dramatic. One team compounds their improvements quarter over quarter. The other keeps making the same mistakes, wondering why velocity isn't improving, and blaming it on "hiring needs."

Building a feedback culture

When you do this well, it spreads. Engineers who receive great feedback learn how to give great feedback. They start doing it in code reviews, in design discussions, in peer interactions. The entire team's bar goes up, not because of a policy or a training session, but because they experienced what good feedback feels like and they want to pay it forward.

This is how high-performing engineering cultures are built — one honest, specific, well-delivered piece of feedback at a time.

Wrapping Up

Performance reviews and feedback are not bureaucratic overhead. They are the mechanism through which you develop your people, retain your best talent, and build a team that continuously improves.

The core principles are simple:

• Give feedback continuously. Never save it for the review.
• Be specific. Always have examples.
• Be direct. Softening the message helps you, not them.
• Use SBI to structure constructive feedback.
• Set clear, measurable goals and follow up on them.
• Run reviews as conversations, not lectures.
• Have difficult conversations early. Avoidance is not kindness.
• Watch for biases. Build systems to counteract them.
• Adapt your approach for senior engineers.
• Model the behavior you want by actively seeking feedback yourself.

None of this is easy. All of it is learnable. And the leaders who master it build teams that people never want to leave.

Common Pitfalls

• Saving all feedback for the quarterly or annual review. If someone is surprised by anything in their performance review, you have failed as a leader. Feedback should flow continuously so that the review is merely a summary of conversations already had.
• Giving vague feedback without specific examples. "You need to communicate better" tells the person nothing actionable. Every piece of feedback needs a concrete example and a specific behavior to adjust, or it is not ready to be delivered.
• Using the feedback sandwich. Wrapping criticism between compliments trains people to distrust your praise and makes the real message easy to miss. Deliver positive and constructive feedback separately, each on its own terms.
• Avoiding difficult performance conversations. Waiting months to address underperformance because the conversation is uncomfortable robs the person of the chance to improve and lets small problems become big ones.
• Allowing bias to distort assessments. Recency bias, halo effects, similarity bias, and squeaky wheel bias all corrupt reviews when unchecked. Anchor your assessments to specific examples, concrete outcomes, and data gathered throughout the review period rather than relying on memory and impressions.
• Comparing team members to each other. Telling someone "Why can't you ship as fast as Sarah?" breeds resentment and tells the person nothing useful. Focus on the individual's specific gaps and what improvement looks like for them.

Key Takeaways

• If someone is surprised by anything in their performance review, you have failed as a leader. Continuous, timely feedback throughout the period makes reviews straightforward summaries rather than ambushes.
• Use the SBI framework (Situation, Behavior, Impact) to structure constructive feedback. It forces specificity and objectivity, making feedback dramatically more effective and less likely to trigger defensiveness.
• Praise should be specific and often public; constructive feedback should be specific and always private. Coaching through questions rather than directives is most effective for developing senior engineers' judgment.
• Set clear, measurable goals collaboratively using frameworks like OKRs or SMART goals, and check in on them monthly. Every individual goal should connect to a team goal.
• Run performance reviews as conversations, not lectures. Start with their self-assessment, listen more than you talk, and end with clear next steps and a follow-up plan.
• The single best defense against bias in reviews is data: specific examples, concrete outcomes, and measurable results gathered throughout the review period via running notes.
• Actively seek feedback on your own leadership. React well when you receive it, share what you are working on, and model the feedback culture you want your team to adopt.