The Feedback Loop

Here's a weird thing that happens in engineering careers.

Two engineers join the same team on the same day. Same college, same GPA, roughly the same technical ability. Five years later, one of them is a Staff Engineer. The other is still a Senior, wondering why the system feels rigged.

From the outside, the difference looks like luck. Or politics. Or favoritism.

It's almost never any of those things.

The difference is almost always this: one of them got good at collecting, processing, and acting on feedback. The other didn't.

The first engineer treated feedback like compound interest — small deposits, made consistently, that grow exponentially over time. The second engineer treated feedback like a tax — something uncomfortable to be minimized or avoided.

After five years, the gap is enormous. And it's nearly impossible to close.

This chapter is about building that compounding machine.

What Feedback Actually Is

Most engineers think of feedback as criticism. Someone telling you what you did wrong. Something to survive intact and move on from.

That framing is completely backwards. And it costs you enormously.

Here's the correct framing: feedback is data about the gap between your self-model and reality.

Every person operates from a mental model of themselves. How good they are. How they come across. What they're strong at. Where they're weak. The problem is that your self-model is always wrong. Not slightly wrong. Often wildly wrong.

You think your design doc was clear. Three people on the team were confused by it and said nothing. You think you come across as confident in meetings. You actually come across as dismissive. You think your pull request reviews are thorough and helpful. Half the junior engineers on your team are afraid to ask you for a review.

You don't know any of this. Because nobody told you.

The engineers who grow fastest are not the most talented. They are the most calibrated. They have the most accurate self-model. Which means they know exactly where to focus their energy. They don't waste years getting better at things they're already great at. They find the real gaps and close them.

Calibration comes from feedback. Full stop.

Why Most Engineers Are Terrible at Getting Feedback

If feedback is so valuable, why do most engineers avoid it?

The answer has two parts.

First: feedback feels like a threat. Humans are wired to protect their self-image. We are social animals and our sense of status matters to us at a deep, almost physical level. When someone tells you that your communication is unclear or your code reviews are too harsh, it doesn't just feel like information. It feels like an attack on your identity. Your brain treats it the same way it treats a lion in the tall grass. Fight, flight, or freeze.

Most engineers fight (get defensive), flee (change the subject), or freeze (nod and do nothing). Almost none of them actually process the feedback and use it.

Second: most engineers ask terrible questions.

"Any feedback for me?"

That question is a trap. It sounds humble. It feels like you're being open. But watch what happens when you ask it. The other person smiles uncomfortably and says something like "No, I think you're doing great!" And you both go back to your laptops feeling like the check-in was productive.

It wasn't. You got nothing. Because you asked for nothing.

Here's why that question fails: it's too open, too vague, and too easy to dodge. It puts all the work on the other person. They have to decide what's worth saying, whether you can handle it, whether the relationship can withstand it, and how to phrase it carefully enough to not cause a problem. That's a lot of work. Most people will choose the path of least resistance: "You're doing great."

Bad feedback questions create a comfortable silence that feels like approval but is actually ignorance.

How to Actually Get Useful Feedback

Getting good feedback is a skill. It can be learned. Here's how.

Rule 1: Make it specific and small

Don't ask about your overall performance. Ask about one thing that just happened. The smaller and more recent, the better. Your brain can evaluate specific behavior. It cannot easily summarize a person's entire pattern of existence.

See the difference? The specific question gives the other person something to react to. It lowers the cost of honesty. It tells them exactly what you want to know. And it makes it easy to give you a real answer instead of a diplomatic non-answer.

Rule 2: Give them explicit permission to be direct

Most people soften feedback because they're afraid of your reaction. They don't know if you're the kind of person who can hear hard things. So they hedge. They wrap the truth in so much softening language that it disappears.

Your job is to make directness feel safe. You do this by explicitly removing their fear of your reaction.

That sentence does three things. It signals intent (you want to improve). It removes the social cost (they won't hurt you). And it creates urgency (now is better than finding out the hard way later). You've made honesty the path of least resistance.

Rule 3: Ask the "skip" question

There's a class of feedback that people almost never give you voluntarily. It's the feedback about patterns — the things you do consistently that grate on people, or the things you're not doing that others expect at your level.

To get at this, ask a question that forces the other person to think differently:

That framing is powerful. It's hypothetical (less threatening). It forces a ranking (they have to pick one, not dodge with "everything's great"). And it activates a different part of their brain — they're now thinking like an evaluator, not a colleague who wants to preserve the relationship.

You will get more honest answers from this one question than from a year of check-ins that start with "any feedback?"

Rule 4: Interview your skip-level

Your manager sees some of your work. Your skip-level — your manager's manager — sees you differently. They see how you show up in the org, not just on the team. They hear how other people talk about you. They have a view you cannot get from your immediate environment.

Most engineers never ask their skip-level for feedback. It feels presumptuous. It feels like going around your manager.

It's neither of those things. It's how the best engineers operate. Schedule a 30-minute conversation once a quarter. Come prepared with specific questions. The skip-level will almost always appreciate it. It shows maturity and self-awareness — which are, not coincidentally, two of the things they're trying to assess about you anyway.

Rule 5: Ask peers, not just managers

Your manager has one view of you. Your peers have another. The engineers you work with daily see things your manager never sees — how you behave under pressure in a debugging session, how you communicate in a design review, whether you actually help people or just say you do.

Peer feedback is often the most useful because peers have no incentive to manage you. They're not worried about your feelings the way a manager has to be. If you've built real trust with a peer, they'll tell you the truth.

Ask two or three peers per quarter. Make it feel lightweight — a ten-minute conversation over coffee, not a formal review. The less formal it feels, the more honest the answers.

The Receiving Problem

Getting feedback is only half the battle. The other half — the harder half — is actually receiving it.

Receiving feedback well is not about acting grateful while internally dismissing everything they said. It's not about nodding along and then doing nothing. And it's definitely not about getting into a debate about whether the feedback is accurate.

Here's what receiving feedback well actually looks like.

Step 1: Shut your mouth and listen

When someone starts giving you critical feedback, your brain will start preparing a response before they finish talking. You will be composing your defense. You will be finding the evidence that contradicts what they're saying. You will be deciding whether their opinion is valid enough to deserve your attention.

All of that is noise. Stop it.

Your only job in the first thirty seconds of receiving feedback is to listen completely. Let them finish the thought. Don't interrupt. Don't rephrase. Don't start your response. Just take it in.

This sounds obvious. It is remarkably hard to do.

Step 2: Acknowledge before you respond

The first thing you say after receiving critical feedback should never be a defense. Not even a polite one.

"That's a fair point, though I think the context was a bit different—" is still a defense. "I hear you, but—" is still a defense. Any sentence that starts well and ends with "but" is a defense. The person giving you feedback hears the "but" and their honesty shuts off. They've learned that you can't receive it.

Instead, acknowledge first. Fully. Then ask a clarifying question.

See what the good response does. It doesn't agree or disagree. It doesn't debate the accuracy. It treats the feedback as data and asks for more data. Which is exactly the right response, because now you actually understand what happened — not just the vague headline, but the specific behavior.

Step 3: Sit with it before you judge it

Here's something counterintuitive. You don't have to agree with feedback the moment you receive it. You don't have to decide on the spot whether it's valid or invalid, fair or unfair, actionable or not.

The smartest thing you can do with hard feedback is to say "thank you, I'll think about this" and then actually think about it. Not defensively. Genuinely.

Give it 24 hours. Sometimes feedback that felt completely wrong in the moment looks completely right the next morning. Sometimes it still feels wrong, but now you can see exactly why — and you can have a productive follow-up conversation instead of a reactive one.

The engineers who grow fastest have one thing in common: they can hold feedback in their head long enough to evaluate it honestly. They don't reject it reflexively. They don't accept it blindly either. They process it like good engineers process everything — methodically, with a healthy prior, and with genuine curiosity.

Step 4: Close the loop

This is the step almost everyone skips. And it's the most important one.

Go back to the person who gave you feedback and tell them what you did with it. Not to perform gratitude. Because it creates a flywheel.

When you do this, two things happen. First, the other person sees that you actually used their feedback, which makes them more likely to give you more. Second, you get a second round of data — whether the change you made is actually working, or whether you changed the wrong thing.

Most engineers treat feedback like a one-time transaction. The best engineers treat it like a conversation with no end date.

The Three Types of Feedback and What to Do With Each

Not all feedback is the same. Knowing what type you're receiving changes how you should respond.

Type 1: Calibration feedback

This is feedback about how you're perceived versus how you think you're perceived. "People find you hard to approach." "Your code reviews feel more like attacks than guidance." "When you explain things in meetings, people look confused but don't say so."

This type of feedback is gold. It's the most valuable kind, and also the rarest, because people are most afraid to give it. When you get it, treat it with extraordinary care. Don't dismiss it. Don't explain why the perception is wrong. The perception is the reality — it's how the world is experiencing you regardless of your intent. Your job is to change the experience, not to prove that the experience is incorrect.

Type 2: Skill feedback

This is feedback about something you're doing technically or operationally wrong. "Your estimates are consistently too optimistic." "Your design docs don't address failure modes." "You're good at greenfield work but when you inherit legacy systems you tend to rewrite instead of improve."

This type is easier to receive because it's less personal. It's about a skill, not your identity. Treat it as a bug report on your professional toolkit. Identify the root cause — is it knowledge, habit, or incentive? — and fix the right thing.

Type 3: Strategic feedback

This is the rarest and most powerful type. "You're working on the wrong problems." "You're spending your energy on execution when you should be spending it on influence." "At your level, people need to see you shaping the roadmap, not just delivering against it."

Strategic feedback doesn't tell you how to do your job better. It tells you that you're playing the wrong game entirely. When you receive it, stop what you're doing and genuinely interrogate your assumptions. This type of feedback, followed faithfully, is how Senior Engineers become Staff Engineers.

Building a Personal Retro Practice

Engineering teams run retrospectives. They set aside time to look back, identify what worked, identify what didn't, and commit to specific changes. It's one of the most valuable practices in modern software development.

Almost no engineer applies the same practice to themselves.

Here's how to build one that takes 20 minutes a week and compounds over years.

1. Keep a plain-text running log

   At the end of every week, write down three things: one thing that went well, one thing that went poorly, and one piece of feedback you received (solicited or unsolicited). Don't overthink it. Two or three sentences per item is enough. The act of writing forces clarity. Ideas that seem sharp in your head often dissolve the moment you try to write them as complete sentences.
2. Do a monthly theme review

   Once a month, read the past four weeks of logs and look for patterns. Is the same thing going poorly repeatedly? Is the same feedback appearing in different forms? Is the thing you said went well actually the same kind of thing every time? Patterns are invisible in single instances. They become obvious when you look at four weeks of data side by side.
3. Pick exactly one thing to change next month

   Not three things. Not five. One. This is important. Engineers are problem-solvers and will identify six improvement areas and try to fix all of them simultaneously. Then they fix none of them, because focus is a finite resource. Pick the highest leverage item and do that. Only that. Come back to the others next month.
4. Do a quarterly calibration with your manager

   Don't wait for the performance review cycle to find out how you're doing. Schedule a 30-minute conversation every quarter specifically about your growth. Come prepared. Bring your own assessment of what went well and what didn't. Ask specifically about any gaps between how you see your performance and how they see it. Calibrate the delta. Then close it.
5. Maintain a "delta document"

   Keep a private doc where you track the specific changes you committed to making and whether they worked. Not your accomplishments — that's your brag doc. This is your growth doc. It should read like a series of experiments: hypothesis, action, result. Over a year this becomes the most useful document in your career toolkit. It shows you the shape of how you actually grow.

The Feedback Flywheel

Here's the thing about feedback that most people don't realize until it's too late to use it.

Feedback is not linear. It compounds.

When you consistently act on feedback, people notice. Not because they're tracking it. But because your behavior changes, and changed behavior creates new experiences, and new experiences change how people talk about you. And how people talk about you determines what opportunities you get. And opportunities determine what you can accomplish. And what you accomplish determines your trajectory.

The engineer who acts on feedback consistently becomes more effective. A more effective engineer builds a stronger reputation. A stronger reputation opens doors. Doors lead to higher-stakes work. Higher-stakes work generates better feedback. And the cycle accelerates.

The engineer who avoids or ignores feedback stays flat. They get better at the things they're already good at — because those things feel safe — and they never close the gaps that are actually limiting their growth. Over time, they become experts at the wrong things and wonder why they aren't being recognized.

The gap between those two engineers at year five is not talent. It's not luck. It's five years of compounding vs. five years of stagnation.

What to Do When the Feedback Feels Wrong

Not all feedback is accurate. Some feedback reflects the biases of the person giving it. Some feedback is based on incomplete information. Some feedback is about them, not you.

How do you tell the difference?

Here's a simple rule: never evaluate feedback in the moment you receive it. Give it 24 hours. Then ask yourself three questions.

1. Is this the first time I've heard this?

   If yes, take it seriously but hold it lightly. One data point is a hypothesis. If no — if you've heard a version of this before — treat it as strong signal regardless of whether you agree with it. Recurring feedback is almost always accurate even when it feels unfair.
2. Do I feel defensive because it's wrong, or because it's right?

   This is the harder question and it requires honesty with yourself. Defensive reactions to false feedback feel righteous. Defensive reactions to accurate feedback feel threatening. They are physically different if you pay attention. Learn to tell them apart. The feedback that makes you want to explain yourself most urgently is usually the feedback that deserves the most careful attention.
3. Can I find one grain of truth in it, even if the rest is wrong?

   Most feedback that feels wrong is not entirely wrong. There's usually a kernel of accurate observation buried inside a misattribution or an overstatement. Your job is to extract that kernel and act on it, without either accepting the whole thing uncritically or rejecting it entirely because the framing was off. This is the advanced skill. Most people can't do it. The ones who can grow faster than almost everyone else.

And if after all of that you genuinely believe the feedback is wrong? You can say so. Not defensively. Calmly, with evidence, at a later point in time. "I've been thinking about what you said, and I see it differently. Here's why. Can we talk through it?" That conversation, done well, is not only productive — it demonstrates exactly the kind of maturity and self-awareness that earns you more credibility.

The Feedback You're Not Getting (and Why It Matters Most)

Here is an uncomfortable truth.

The most important feedback you need is usually the feedback you're not getting. Not because people don't have it. Because they've decided it's not worth giving you.

People stop giving you feedback when they've decided you can't receive it. When they've learned, through experience, that you get defensive. Or that you nod and do nothing. Or that you take it personally. Or that you debate the accuracy instead of engaging with the substance.

In every org, there are engineers who are surrounded by a ring of silence. Everyone around them has an opinion about how they could improve. And nobody says anything, because the last time someone tried, it went badly.

The engineering equivalent of the emperor with no clothes.

The way to break through that ring of silence is to make yourself a safe person to give feedback to. Consistently. Over time. Ask specific questions. Receive the answers without defensiveness. Act on what you hear. Close the loop. Make it obvious to the people around you that their honesty is not a threat to you — it's a gift you actively seek.

Once they believe that, they will tell you things they've never told anyone else. Because almost nobody actually creates that safety. You will be unusual. And the information you get from people who actually trust you will be more valuable than anything else you learn in your career.

The Hardest Feedback to Get: The Promotion Ceiling

There is one specific feedback scenario that trips up more engineers than any other. And it's the one that matters most to their careers.

The feedback about why you're not getting promoted.

Most engineers in this situation are told some version of "you just need more time" or "you're on the right track" or "keep doing what you're doing." And they walk out of the conversation feeling like they have a plan, when what they actually have is a comfortable non-answer.

Here's the truth about promotion feedback: managers often don't give it directly because it's uncomfortable, legally sensitive, or because they themselves don't have full clarity on what the blocker is. So they default to encouragement.

You have to make the conversation more specific.

Those questions are harder to dodge. They reframe the conversation from "am I on track" to "what would block me." And the answer to the second question is almost always more honest than the answer to the first.

Once you have the blocker, you have a real thing to work on. Work on it specifically. Report back with evidence. Create a feedback loop around the promotion itself, not just around your general performance.

A Final Note on Ego

Everything in this chapter is hard because of ego.

Not ego in the arrogant sense. Ego in the more fundamental sense — the part of you that has a story about who you are and works very hard to protect that story from contradictory evidence.

Feedback threatens that story. So your brain fights it, reframes it, dismisses it, explains it away.

The engineers who become truly great find a way to separate their identity from their performance. They learn to hold the story of themselves loosely enough that new information can update it. They are not emotionally attached to being right about themselves. They are attached to getting better.

That shift — from defending your self-image to upgrading it — is probably the single most important psychological transition in a high-performance engineering career.

It doesn't happen all at once. It happens gradually, through a hundred small moments of choosing to listen instead of defend. Choosing to ask instead of assume. Choosing to be curious about the gap between who you are and who you think you are.

Over time, those choices compound.

Just like the feedback itself.