If you ask any engineering manager whether feedback is important, they’ll immediately say “yes.” But if you ask engineers how they feel about the feedback they get, you’ll often hear hesitation. In too many teams, feedback comes too late, feels one-sided, or is only trotted out during performance review season. Feedback is no longer a way to grow; instead, it is something to be afraid of.
This disconnect creates a paradox: managers give feedback because they want their teams to get better, but the way they do it often makes engineers ignore it or not trust it. The whole team's progress suffers when valuable feedback is lost and chances to learn are missed.
It doesn't just happen that people in engineering trust feedback. It takes work to make sure that feedback is timely, safe, and focused on growth.
In this article, we'll talk about how to create a culture of feedback that engineers can really trust. We'll talk about why traditional ways of giving feedback don't always work for engineering teams, and then we'll talk about some practical ways to make feedback a normal, positive part of everyday work. Feedback can become a good habit instead of something you dread, from pull request reviews to retrospectives and one-on-ones. Let’s start by understanding the common pitfalls that cause feedback to fail—so we can avoid them.
Why Feedback Often Fails in Engineering Teams
Before we talk about solutions, it helps to recognize why feedback in many engineering orgs isn’t working. Here are some of the most common complaints engineers have about the feedback they receive:
It’s too infrequent
When feedback only happens during annual or semi-annual reviews, that’s far too late to course-correct. An issue noticed in March shouldn’t wait until December to be addressed. Unfortunately, many developers only get formal feedback once or twice a year, which means small problems quietly snowball into big ones. No wonder it feels overwhelming or off-base by the time it arrives.
It feels like a judgment, not help
In some teams, “feedback” is basically a code word for criticism. If engineers only hear something from their manager when they’ve done something wrong, feedback will always carry a negative connotation. It starts to feel less like coaching and more like being graded or scolded. This kind of feedback is demoralizing—silence is assumed to mean “all good,” and any comment means “you messed up.” That’s not exactly motivating!
It’s one-directional
Often, feedback flows only from the top down. Managers give it; engineers take it. There’s no real dialogue, and certainly no safe way to give upward feedback in return. In such a hierarchy, engineers can feel like they’re being lectured by people who might not even have the full story. Plus, when peers hesitate to give each other feedback, everything gets bottled up for the manager’s ears, or not said at all. It’s a recipe for distrust on all sides.
It’s not geared toward growth
When feedback is solely tied to performance ratings, promotions, or raises, it starts feeling transactional. Engineers might start to ask, “Is this feedback genuinely to help me improve, or just to justify my performance score?” If every piece of input is linked to a report card, people naturally become defensive. They focus on the rating, not the message. And managers, under pressure to rank their reports, might avoid giving honest feedback until review time—missing chances to guide day-to-day growth.
It's not clear or vague
It's very frustrating to get feedback that doesn't tell you what to do next. Comments like "Be more proactive" or "Show more leadership" are vague and open to interpretation. Such feedback is hard to act on without specific examples or advice. Engineers are left guessing what “being proactive” looks like or why their manager thinks they lack leadership. Vague feedback doesn’t build trust; it breeds confusion.
It’s no surprise that under these conditions, many engineers view feedback as something unreliable or even risky. In fact, a lack of regular, useful feedback directly hurts engagement: one survey found 98% of employees become disengaged when managers give little to no feedback (codeclimate.com).
Conversely, when feedback is done right, it can dramatically improve confidence and alignment on a team. A study by an engineering organization even noted that the strongest indicator of solid team trust was having an open and honest feedback culture (getyourguide.careers).
So how do we get there? Let’s look at five key principles that can transform feedback from a source of anxiety into a source of growth. These principles are drawn from real engineering team practices and are aimed at managers and team leads (though individual engineers can apply many of these ideas too). Each principle builds on the previous, and together they create a holistic approach to feedback that engineers can truly trust.
Principle 1: Make Feedback Continuous and Timely
Problem: Infrequent feedback is ineffective feedback. If an engineer only hears about an issue months after it first appeared, the context is gone and the chance to improve feels lost. Sadly, a lot of teams still use formal reviews that don't happen very often as their main way to get feedback.
What to do instead: Make getting feedback a normal part of work, not something special. This means making feedback a regular part of engineering life every day and every week.
Here are some useful ways to do this:
- Pull requests and code reviews: These are great times to give feedback in context. Don't just say yes to a PR; leave comments that help the author learn something. If a PR doesn't have tests, for instance, don't wait until the quarterly review to say something. You could say, "I see that this feature doesn't have any unit tests yet. Let's add a few things together before we merge. It will help us find bugs sooner." This quick, specific input makes a code review feel like a mini feedback session. The engineer can do something right away, and the feedback is meant to help the work, not to criticize the person.
- Team check-ins and stand-ups: Daily stand-up meetings aren't usually for giving detailed feedback, but they can help people get used to talking to each other. It's fine to briefly mention something that happened yesterday that went well or badly. For instance, a tech lead might say in stand-up, “Yesterday’s deployment was rough. Let’s do a quick huddle after this to see what we can improve.” That’s feedback on a process, delivered the very next day. It shows the team that feedback isn’t a rare event; it’s part of how we operate continuously.
- Sprint demos and retrospectives: Agile rituals provide built-in opportunities for feedback. In sprint reviews or demos, team members can give immediate praise or pointers after seeing a feature in action (“The new UI looks great! One suggestion: maybe we can refactor the API calls for efficiency.”). In retrospectives, make it routine for the team to discuss what each person or the team as a whole can improve, and what went well. Retros aren’t just about venting—they’re about learning. When everyone expects that each sprint will involve reflecting on feedback (good and bad), it normalizes continuous improvement.
- One-on-one meetings: Regular 1:1s between managers and engineers are gold for ongoing feedback. Rather than waiting for a formal review, managers can use a monthly or bi-weekly 1:1 to share observations while they’re fresh. “Hey, I noticed in last week’s client meeting you were quieter than usual. Everything okay? I want to make sure you have room to contribute your ideas,” is feedback that’s both timely and supportive. Frequent check-ins also give engineers a chance to ask for feedback when they feel they need it, creating a two-way street.
The goal with continuous feedback is to make sure nothing stays bottled up for too long. When feedback is frequent and low-key, it becomes less scary. Engineers won’t be blindsided by “that thing you did 6 months ago” because it was already discussed back then. Over time, this builds trust: people learn that feedback is just a normal part of how we collaborate, not a portent of doom.
Real-world example: At one software startup, the engineering manager made it a habit to give quick feedback during code reviews rather than saving it for later. Instead of waiting until the annual review to say “you need better testing practices,” he’d comment right on the pull request, in the moment: “Looks like we didn’t include unit tests for this function. Let’s add those before we merge — I can pair with you if you want.” The engineer started writing tests more proactively in future work, and because the input was given kindly and immediately, it felt helpful, not punitive. This kind of timely feedback loop became a normal part of their team culture.
Principle 2: Balance Positive and Negative Feedback
Problem: Many engineers secretly (or not so secretly) equate “feedback” with “criticism.” If every feedback conversation is about something that went wrong, people will start to dread it or distrust it. Nobody wants to constantly feel attacked or unappreciated. In a culture where feedback is always bad news, even a simple "Can I give you some feedback?" can make an engineer's stomach drop.
It's important to balance constructive criticism with praise in order to build trust. It's not about being nice or "babying" anyone; it's about being fair and seeing the whole picture. Engineers do a lot of things well and a lot of things that need to be better, and they should be told about both.
What to do instead: Make sure to praise good work and successes as much as you point out problems. When it's real, positive feedback encourages behaviors you want to see more of and makes people feel better about themselves. The person getting the feedback knows you're not just focusing on the bad things, which makes it easier to take.
Continue / Stop / Start framework
- Continue: Point out something the person is doing well and tell them to keep doing it.
"Your code refactoring in that module really sped up our load times." Keep up the good work with that kind of optimization. - Stop: Talk about a behavior or pattern that is bad or not helpful and needs to stop.
"I've seen you combine PRs without looking at them first. We need to stop doing that because it's causing problems with production. Let's make sure that every PR gets at least one person to look at it." - Start: Suggest a new task or behavior for the person to take on in order to grow.
"I think you're ready to start leading our talks about architecture. How about you lead the next design review? I'll help you."
By framing feedback in these three categories, you inherently balance the positive (continue) with the corrective (stop) and the developmental (start).
Public vs private feedback
- Public praise: Give someone recognition when they do something great. Example: in a team Slack channel or at the daily stand-up:
"I want to shout out Jamal for writing an amazing integration test suite for this feature. Before it even came out, it caught two bugs!" - Private critique: Talk to the person one-on-one about any bad feedback, not in front of the whole team. This shows respect and prevents embarrassment.
Positive feedback isn't about gold stars. It's about recognizing real contributions. Engineers want to know their work matters. When managers only mention problems, it gives a distorted view. Balanced feedback shows fairness and builds trust.
Principle 3: Give Feedback Based on Facts and Things You Can See, Not on What You Think
Have you ever gotten feedback that felt like a personal attack or just plain wrong? This happens a lot when feedback is given as a vague opinion or an accusation instead of an objective observation. To create a culture of trust, feedback needs to be as clear and based on facts as possible.
Example
- Vague or based on opinion: "You don't pay enough attention to how good your code is." → broad, subjective, and personal.
- Based on facts and specifics: "The team found big bugs in the last two PRs you sent, which meant they had to do some extra work. Let's find out what the problem is. We could try to make your testing process better or do paired reviews for a while to find problems sooner."
The second approach is factual and collaborative. It’s about fixing processes, not blaming identity.
Tips for fact-based feedback
- Use the SBI model (Situation, Behavior, Impact):
"You interrupted John twice while he was speaking at the planning meeting yesterday (Situation). This made him angry, and the conversation went off track (Impact)." - Cite data or examples: Engineers respond well to metrics. Example:
“We estimated those features would take 3 days each, but they each took over a week. Let’s figure out why and adjust.” - Avoid absolute language: Words like “always” or “never” usually aren’t true and trigger defensiveness.
- Mind your tone: Especially in written comments. Example:
- Harsh: “This code is confusing; you need to write clearer logic.”
- Constructive: “I had trouble following this function—could we simplify or add comments? I want to make sure everyone can understand it.”
When feedback is rooted in facts, engineers view it as credible and actionable. It shifts from personal criticism to professional assessment.
Principle 4: Create Safe, Two-Way Communication Channels
Trust in feedback flourishes only when people feel safe — safe to speak honestly, safe to make mistakes, and safe to voice concerns without fear of backlash.
How to build safety
- Encourage upward feedback: Ask in 1:1s: “Is there anything I could be doing better to support you?”
- Use anonymous channels: Retrospective boards, surveys, or forms to surface sensitive issues.
- Practice blameless post-mortems: Focus on what went wrong in the system, not who to blame.
- Demonstrate empathy: Thank people for feedback, share your own mistakes, and avoid defensiveness.
A two-way feedback culture means feedback isn’t a lecture, it’s a conversation. Managers who admit their flaws humanize themselves and set the tone.
Principle 5: Don't Just Use Feedback to Evaluate, But Also to Help People Grow
One big reason engineers don't trust feedback is that it's often only used for judging performance, like ratings, promotions, and pay raises. Evaluations are important, but feedback that is only given in that context can feel like a dreaded report card.
Feedback that helps people grow is much more motivating and useful.
How to do this
- Include feedback in growth plans: Tie feedback to Individual Development Plans or career goals.
Example: "One thing you can do to get closer to that tech lead role is to start having an effect on the work of others. Would you like to be in charge of the next code review? I'll let you know how it goes." - Offer clear next steps: “Maybe we can send you to a technical writing workshop,” or “Pair with Alice—she’s great at documentation.”
- Decouple feedback from compensation (in the moment): Make clear when feedback is developmental, not evaluative.
- Highlight progress over time: Acknowledge growth:
“Three months ago we talked about presentations. Your last tech talk was smoother and more confident. Great job.”
When feedback is tied to growth and mentorship, trust skyrockets. Engineers start to seek feedback rather than avoid it.
Building a Systemic Feedback Culture
We’ve talked a lot about what individual managers can do, but truly trustworthy feedback cultures are reinforced at the system and team level.
Broader practices
- Normalize peer feedback: Encourage it in PRs, design sessions, pair programming. Run a workshop to teach constructive peer feedback.
- Rituals that strengthen feedback: Weekly shout-outs, monthly improvement days, regular retros with action items.
- Education and training: Workshops on SBI, role-play, active listening, empathy.
- Leadership and HR support: Reviews should include growth plans, not just scores. Leaders should model feedback openness in AMAs or skip-levels.
- Tools for safe feedback: Anonymous forms, retro boards, suggestion boxes—use whatever makes people feel safe.
When feedback is systemic, new hires quickly see: “This is how we do things here.”
Case Study: A Team Transformation Through Feedback
The situation:
A mid-sized SaaS team of 20 engineers had poor feedback culture. Feedback happened only in annual reviews, focused on mistakes and raises. Trust was low, and good engineers left saying they “never knew where they stood.”
The intervention (by new manager Julia):
- Monthly one-on-ones with Continue/Stop/Start both ways.
- Biweekly retros with anonymous notes and concrete action items.
- Training on SBI and effective peer praise.
- Commitment: “No new feedback should appear first in a performance review.”
The results:
- Engagement scores for “I receive timely and helpful feedback” rose 27%.
- Engineers proactively asked for feedback.
- Collaboration and morale improved.
- Instead of attrition, the team promoted from within.
One senior engineer summed it up: “I used to be afraid of feedback, but now I see it as an opportunity to get better. It’s exciting to see my own progress.”
Conclusion: Trust, Feedback, and Growth
It takes time, consistency, and real commitment to build a culture of feedback that engineers can really trust.
But the benefits are huge:
- Engineers stop fearing feedback and start embracing it.
- Teams improve faster and work better together.
- Innovation speeds up because people can share ideas without fear.
Key takeaways
- Make feedback continuous, not annual.
- Balance positive and negative.
- Base feedback on facts, not opinions.
- Create safe, two-way communication.
- Tie feedback to growth, not just ratings.
The challenge for managers is to live these principles daily. That means being a coach, not just a judge. For engineers, it means engaging in respectful peer and upward feedback.
In the end, respect and a desire to get better are what make a feedback culture work. It’s about replacing the fear of “feedback” with curiosity: “What can I learn today?”
When engineers truly trust feedback, they can focus on what matters: learning, growing, and making great software together.
Keep in mind: the trust you build in your team may be just as important as the systems you build. Start small, stay consistent, and over time feedback becomes not just practice—but culture.
