I’m Roman, CTO at Cambri, and I write High-Impact Engineering, a weekly newsletter for engineering managers, directors, and CTOs. Today we talk about feedback, and why gathering it is the easy part.
A company had an annual employee engagement survey. Typical HR stuff on a high level, nothing specific to software engineering in general.
The survey was run for many years. Each year, after the results are in, team leads organized 4-hour-long workshops with their teams to look at the results. To make this exercise more appealing, team leads ordered pizza and drinks.
Team members went through anonymized results for their team in comparison to the company and needed to come up with action points for each problematic area.
By the way, the worst area was always compensation. The solution was radical: after seeing this for several years, management excluded the question from the annual survey. Problem solved!
But I digress.
Action points were assigned to team members. And that was it. No follow-up, no accountability, and therefore no action.
At least, pizza was usually good.
One of the problems with that company was that it was trying to create artificial harmony. Instead of building transparency and psychological safety, they built a performance improvement theater. When a question became uncomfortable, it was swept under the rug.
What is the lesson here? Are surveys useless? No. A quarterly lightweight survey paired with eNPS (employee net promoter score) can drive positive change and catch problems early.
The real lesson is that for feedback to be useful, it must produce action.
Feedback paired with action is how you and your team get better. Without feedback, you are flying blind. You can only improve by chance.
Feedback can be roughly split into three groups.
Feedback on the work itself: code review, tests, CI, monitoring, incidents, and post-mortems. Fast, and mostly from the system rather than from people. When this is thin, you learn about problems late, usually from a customer.
Feedback from the people around you: one-on-ones, skip-levels, peer and stakeholder input, the occasional 360. When this is thin, you are guessing at how people actually experience the team.
Feedback on how the team runs as a system: retrospectives, delivery metrics such as DORA, and yes, surveys and eNPS. When this is thin, you improve by accident.
Feedback from systems is usually easier to interpret and act upon, whereas feedback from people, and especially larger organizational feedback, requires explicit effort to come up with an action plan and follow through on it.
Act on the feedback
Fast feedback that is acted on creates a virtuous cycle. When the person giving it sees that their input made a difference, they are more willing to give feedback next time.
The reverse is also true: when nothing happens, people read it as a sign that their opinion does not matter. On an individual level, that leads to conflict. On an organizational level, it leads to disengagement and apathy.
Some feedback will not be relevant or high priority. That does not mean it can be ignored. If you cannot or do not want to act on feedback, still acknowledge it and explain why not, or why not now. In most cases, people will understand, and they will keep bringing you feedback. So always close the loop.
Closing the loop on metrics
I wrote a while ago about introducing a developer experience survey at my company.
The team moved perceived CI/CD effectiveness from 18 to 54, documentation from 27 to 69, and focus from 36 to 69. So surveys can be very useful, as long as someone acts on them once the pizza is gone.
We did it by identifying the core areas to improve, acting on them, and closing the loop by running the survey again nine months later.
That points to another lesson: show the before and after to the team. People have short memories and a recency bias. They remember the latest problems, but reflecting on how far the team has come over months and quarters can be revealing. It lifts morale, and it shows people that their input mattered.
Painful or offensive feedback
Some feedback, especially at the individual level, can sound offensive, and in many cases, it partly is. You still need to close the loop.
This is where many make a big mistake. Instead of listening and getting to the core of the problem (why the other person is frustrated, what is behind it, and how it can be solved), they start defending themselves or mount a counterattack. Stop, think, and lead with empathy and curiosity. Often, there is a real problem you can solve. It can be an opportunity to both solve the problem and improve the relationship.
Diagnostics: are you closing the loop?
Look at your last three retrospectives. How many of the action items actually got closed?
Do you always have one person assigned to each action point? Are they held accountable for acting on it?
The last time you got constructive feedback, did you defend yourself or lead with curiosity?
Do you receive constructive feedback from your team? If not, or not often, why do you think that is?
Did you follow up on what happened to the last company-wide initiative you or your team were supposed to act on?
These are self-reflection questions. If you hesitate or do not like the answer, there is something you can do about it.
Actions you can take to close the loop
Respond to the feedback you received, individually or as a team. Even if you do not act on it, say so and explain why. If you did act on it, even better: show what changed.
Always have one responsible person, either you or someone you delegate to. Hold them, or yourself, accountable.
If you have metrics or feedback you are supposed to act on, show them to the team and decide together what to tackle first. Keep it in focus. Later, tell the team what changed.
When feedback stings, do not respond in the moment. Stop, look for the real problem behind it, and lead with curiosity instead of defending yourself.
Conclusion
Your product is a system. Your development infrastructure is a system. Your team is a system too.
Just as unit tests and build status tell a developer whether a change is good to ship, feedback tells you whether the organization is healthy. Ignore the signal and act on nothing, and you are shipping bugs straight into the organization.
So close the loop, and keep your builds green.
If this was useful, subscribe to High-Impact Engineering for a new issue each week. New subscribers get The Manager’s Scoreboard, a free field guide to measure what actually matters as a manager and see where to grow next.
P.S. I also advise founders and engineering leaders on making their teams perform, feedback loops included. If your org collects a lot of signals and changes very little, book an intro call.
the moment they deleted the comp question instead of answering it… dang.... people don't stop trusting when the answer is no. they stop trusting when the question quietly disappears.