Feedback Is a Habit, Not a Hard Conversation

The best engineering managers aren't the ones who deliver the perfect hard conversation once a year. They're the ones who made feedback so regular, so structured, and so routine that it stopped being hard. The framework you use matters far less than the cadence you keep.

Most feedback advice gets this backwards. It obsesses over technique — SBI versus STAR, whether to use the "sandwich," the exact wording of a difficult message. And technique isn't nothing. But after two decades of engineering and nearly a decade managing engineers at Google, Capital One, and a handful of startups, I've become convinced the framework debate is the least important part of feedback. The thing that actually separates good managers from great ones is boring: they give feedback often, on a predictable rhythm, tied to a shared standard — and they treat it as a system they run, not a confrontation they brace for.

This post is about that shift. Why cadence beats technique, why systematizing feedback makes it land better, what to do if your company gives you no tooling to support it, and a simple framework to use once you've got the habit in place.

The mistake most new managers make with feedback

The single most common feedback failure I see in new engineering managers isn't harshness. It isn't bad wording. It's avoidance — putting off feedback until it's too late to be useful, or until it's curdled into a bigger problem than it needed to be.

Here's a story I still think about.

Years ago I had a tech lead on my team who was genuinely valuable — sharp, productive, the kind of engineer other engineers listened to. But in group meetings, he'd speak negatively about the product strategy coming down from upper management. Not once. Repeatedly. And because other engineers respected him, his frustration was contagious. It quietly dragged on team morale.

I regret not addressing it sooner. What I eventually did — and what I'd do again — went like this.

First, I listened. In our one-on-ones I tried to let him do most of the talking, aiming for something like 70% him, 30% me. I took notes. I wanted to actually understand why he was frustrated with the product direction before I said a word about the behavior. That mattered, because his frustration wasn't baseless — he had real concerns about the strategy.

Second, I gave him the benefit of the doubt and waited for a pattern. When I first noticed it, I gave a very gentle, private nudge — nothing heavy. But it kept happening in meetings. Only after I'd seen it two or three more times did I move to structured feedback. I didn't want to escalate over a one-off. (The exception: if something is severe, unprofessional, or clearly out of line, you don't wait for a pattern — you address it immediately.)

Third, when I did give the structured feedback, I opened by describing the pattern I'd observed and asking for his view first. "I've noticed this, this, and this — and it seemed like you were concerned. What's your take?" Then I took what he said and responded: here's how it's affecting the team, and here's the behavior I'd like to see change.

And here's the part that made it work. I mapped the feedback to the behaviors already expected in the performance requirements for his role. This wasn't just me having a problem with him. It was a company expectation that applied to everyone at his level. Because I pointed to a shared, documented standard rather than a personal grievance, he didn't feel singled out — he understood this was the same bar every engineer was held to. He took the feedback well, and the behavior changed.

That last move is the whole game, and it's worth pulling apart.

Why feedback lands better when it points to a standard

System-backed feedback works because it depersonalizes the message. When feedback points to a shared, documented standard — role expectations, a team norm, a defined process — the recipient hears "I'm not currently meeting a bar that everyone is measured against," not "my manager has a personal problem with me." That reframe lowers defensiveness dramatically, because there's nothing to defend against. You're not attacking them; you're pointing at a gap between where they are and a standard that predates the conversation and applies to everyone.

This is why systematic feedback beats heroic feedback. The heroic model — a brave manager summoning the courage to deliver one perfectly-worded hard message — puts the entire emotional load on a single conversation and a single person. The systematic model spreads that load across a standard, a cadence, and a process. The manager becomes a messenger for an expectation rather than the sole source of judgment. That's easier on the recipient and easier on you.

It also explains why avoidance is so costly. Every piece of feedback you swallow is a data point the person never gets — a small course-correction that compounds into a surprise PIP, a blindside resignation, or a team culture that slowly rots because nobody says the quiet part out loud. Feedback withheld isn't kindness. It's a debt that comes due later, with interest.

Why regular feedback separates good managers from great

Once you see feedback as a habit rather than an event, the benefits stack up fast. Regular, structured feedback:

• Levels people up faster. Engineers grow through tight loops between action and correction. The longer the loop, the slower the growth.
• Removes surprises. No shock performance reviews, no blindside departures. If feedback is continuous, nothing that shows up in a review should be news.
• Makes you a better leader. Frequent feedback teaches you how each person actually receives it — who wants directness, who needs to talk it through, who needs a day to absorb it.
• Builds real evidence for performance reviews. When review season arrives, you're working from a documented trail of specific, timely anecdotes — not a recency-biased guess about the last three weeks.
• Raises the professional bar of the whole team. A team where feedback flows normally is a team with higher psychological safety and higher standards.
• Compounds downward. Culture Amp found employees under high-performing managers are roughly 4.5x more likely to be high performers themselves. Your feedback habit doesn't stay with you — it propagates.

None of these come from a single great conversation. They come from the rhythm.

How often should a manager give feedback?

Give feedback continuously and lightly, with a heavier structured checkpoint on a regular cadence — quarterly is a reasonable default. The two work together: continuous feedback keeps corrections small and timely, while a required checkpoint acts as a forcing function so nothing important slips through.

At Google, this dual rhythm was built into the system. Managers were encouraged to give regular informal feedback, but were also required to use a tool to document feedback during quarterly performance reviews. The continuous part kept things human; the quarterly part kept things honest and on the record.

On the balance of positive to corrective feedback: aim for meaningfully more positive than corrective. Some sources suggest a ratio as high as 6:1, though the research varies — the Center for Creative Leadership argues for something closer to 3:1, and notes an uncomfortable finding: employees often want more corrective feedback than they actually receive. So don't treat any ratio as gospel. The real point is that recognition can't be an afterthought you tack on before delivering criticism. Positive feedback is feedback too, and it's doing real work — reinforcing the behaviors you want more of.

One caveat, worth keeping as a footnote in your own head: treat any single piece of feedback as a data point taken with a grain of salt, not as gospel. A lone complaint, a peer with an axe to grind, a recency effect — weight the signal, look for patterns, consider the source. Frequency is the goal, but frequency without judgment just means you're absorbing noise faster.

What if your company has no feedback tools?

You don't need corporate tooling to build a feedback culture — you need a philosophy and a cadence you commit to. If your company gives you the rails, use them. If it doesn't, build your own framework, write it down, and get your team to adopt it.

This is the part most feedback advice misses, because most of it is implicitly written for large companies. My own formative experience was at a company with excellent tooling. At Google, alongside the quarterly documentation requirement, there were mechanisms I leaned on constantly:

• Cross-team feedback collection. Managers could solicit feedback on their reports from people outside the team, who'd choose from a set of predefined prompts (open feedback, start-doing / stop-doing, something they appreciated). Because the giver wasn't on the team, the input was a little less biased — useful anecdote-gathering for year-end reviews.
• Skip-level feedback. Skip-level managers would privately ask engineers two levels down for the same structured feedback about their direct manager, always with a request for clear, factual examples.
• Onboarding that taught feedback. New hires were trained on how the feedback process worked, and encouraged to submit unsolicited feedback through the same tools.
• Retro ceremonies. Sprint retros had structured time built in for positives and negatives.

But here's the thing: the tools were never the point. Every one of those mechanisms was just a delivery vehicle for two things — a philosophy (feedback is a normal, frequent, standard-referenced act) and a cadence (it happens on a predictable rhythm, not when someone works up the nerve). If your company hands you those rails, wonderful — use them, because they do the depersonalizing work for you automatically.

If it doesn't, you build the rails yourself. Concretely, for a small team with no tooling:

• Put recurring feedback reminders in your own calendar. A standing prompt to give at least one specific piece of feedback per week. The reminder is your tooling.
• Bake feedback into rituals you already have. Retros are the obvious one — reserve structured time for what's working and what isn't. Add a standing "feedback" beat to your one-on-ones.
• Adopt a fixed set of prompts. Steal Google's: start-doing, stop-doing, something-I-appreciate. Consistency lowers the effort and makes the feedback less arbitrary.
• Collect anecdotes ahead of review season. Keep a running doc per report so that when reviews come, you're working from evidence, not memory.
• Write your framework down and share it. Tell your team: "This is how I give and collect feedback, and here's why. I'd like us all to work this way." A committed, documented philosophy that everyone follows is a feedback culture, whether or not a single piece of software is involved.

The manager with mediocre SBI wording but a real, committed feedback rhythm will out-develop the manager with flawless technique and a closed, sporadic team every single time.

A simple framework for giving feedback

Once the habit is in place, you do want a lightweight structure so your feedback stays specific and behavioral instead of vague and personal. You don't need ten models. You need one you'll actually use. I recommend SBI — Situation, Behavior, Impact — with one addition.

• Situation. Name the specific context. "In yesterday's architecture review…" Anchoring to a moment keeps it concrete and hard to dismiss as a generalization.
• Behavior. Describe the observable behavior — what you actually saw or heard, not your interpretation of their character or motive. "…you cut off two people mid-sentence." Not "you were being dismissive."
• Impact. Explain the effect. "…and a couple of folks went quiet for the rest of the meeting, so we lost their input on the design."
• (+ Next step.) Add a forward-looking beat so the conversation ends on "here's what better looks like" rather than a post-mortem. "Next time, could you hold questions until each person's finished? I think we'll get more out of the room." This borrows from feedforward — future-focused feedback tends to land as more motivating and less personal than backward-looking critique.

SBI works for positive feedback too — same structure, pointed at something that went well. Use it in both directions and it stops feeling like a "we need to talk" signal and starts being just... how you communicate about work.

The one thing to do Monday morning

If you take a single action from this post, make it this: put a recurring reminder on your calendar and give one specific piece of SBI feedback in your next one-on-one — then do it again the week after.

That's the whole thesis in one habit. Great managers didn't find the courage for one perfect hard conversation. They made feedback so routine it stopped requiring courage at all. Frequency over perfection. Systems over heroics. Start the rhythm this week, and let it compound.

---

Nick is a Senior Engineering Manager with 22+ years in engineering and 9+ years managing engineers across Google, Capital One, and multiple startups, including a successful acquisition. He writes about the craft of engineering management at Engineering Manager++.