Feedback vs Criticism: Why the Difference Matters

A few years ago I sat in a design review where a senior engineer told a junior one that his caching layer was "a mess." That was the whole comment. The junior nodded, went quiet, and rewrote the entire thing over a weekend. The rewrite was worse. It missed the one edge case the original had actually handled correctly, and we shipped a subtle cache-invalidation bug into a payment reconciliation job that took three days to trace.

The senior engineer was not wrong that the caching layer had problems. He was just useless. He gave criticism when the moment called for feedback, and the gap between those two things cost us a production incident and a demoralized junior who nearly quit. I have thought about that review a lot since, because the distinction is not academic. In a regulated fintech shop, it shows up in your defect rate, your retention numbers, and eventually your audit findings.

The Actual Difference

Criticism is a verdict. It tells someone that something is bad. Feedback is a map. It tells someone where they are, where you think they should be, and enough about the terrain in between that they can actually walk it. The two get confused constantly because they often start from the same observation. "This code is a mess" and "this module has four responsibilities and I can't tell which one owns the transaction boundary" both begin with someone noticing that a module is hard to follow. Only one of them helps.

The tell is what the recipient can do next. After criticism, the honest answer is usually "feel bad." After feedback, the answer is "change these specific things." I don't care how the message is delivered, whether it's gentle or blunt or delivered over Slack at 11pm. I care whether it leaves the person with a next action. If it doesn't, it was criticism wearing a helpful voice, and it was a waste of everyone's time.

Why Fintech Makes This Sharper

In some industries, vague criticism is merely annoying. In payments it is expensive. When your work touches money movement, ledgers, and regulatory reporting, "make it better" is not a spec, and neither is "this is sloppy." The stakes push people toward strong reactions, and strong reactions default to criticism because criticism is faster to produce. It takes two seconds to say something is wrong. It takes real effort to say why, and what right would look like.

I have watched this play out during incident retros more than once. A settlement job double-posts a batch of transactions. Everyone is tense, the numbers are visible to finance, and the temptation in the room is to find the person who wrote the bug and make sure they feel the weight of it. That impulse is human and completely counterproductive. The engineer already feels it. What they need is a precise account of what the code assumed, what reality did instead, and what guardrail would have caught it. That's feedback. Blame is just criticism with a body count attached.

The Cost of Getting It Wrong

The obvious cost is the demoralized engineer, but the expensive cost is quieter. When people learn that raising work for review means getting hit with verdicts, they start hiding their work. They review less. They ask for feedback later, when it's harder to change anything, or they stop asking at all. On one team I inherited, the pull requests had gone almost silent, three-line descriptions, no design docs, changes landing with a single rubber-stamp approval. It wasn't laziness. It was self-defense. The previous lead had a habit of turning every review into a referendum on the author's competence, and people had simply stopped exposing themselves to it.

That is the real damage. Not a bruised ego, but a team that has quietly decided the safest move is to show you as little as possible. In a domain where the whole point of code review is to catch the mistake before it hits a customer's balance, a team that hides its work is a team that ships surprises. You trade short-term emotional venting for long-term blindness.

A Test I Use Before Speaking

Before I say anything critical about someone's work, I run it through a short filter. It has saved me from being the useless senior engineer more times than I'd like to admit:

• Can I name the specific thing, not the general vibe? "This function is confusing" fails. "This function returns null in three different failure cases and the caller can't tell them apart" passes.
• Do I know what better looks like, concretely enough to describe it? If I can't, my opinion is a feeling, not feedback, and I should say so honestly.
• Am I addressing the work or the person? "You always overcomplicate things" is about the person and helps no one. "This has more abstraction than the problem needs" is about the work.
• Would I want this said to me in front of my peers? If not, I either change the wording or change the venue.

None of this is about being soft. I am perfectly willing to tell someone a design is wrong and we are not shipping it. But there is a difference between "we are not shipping this, and here is the concrete risk" and "this is bad." The first is a decision with a reason. The second is just a mood I have imposed on someone else's afternoon.

Feedback Is Not Only the Negative Kind

Here is where I'll take a side that annoys some managers: most teams are far worse at positive feedback than negative, and it matters just as much. People treat praise as optional garnish. It isn't. Feedback is information about the gap between where you are and where you should be, and "you nailed this, keep doing it" is exactly that kind of information. If an engineer writes a genuinely elegant piece of error handling and hears nothing, they have no idea it was elegant. They might refactor it away next quarter.

The lazy version of praise is the same failure as the lazy version of criticism. "Great work" is the "this is a mess" of compliments, a verdict with no map. I try to make positive feedback as specific as the corrective kind. Not "nice PR" but "the way you split the idempotency check into its own middleware means we can reuse it on the refund path, that was the right call." Specificity is what makes praise land as a signal rather than a pat on the head.

In Defense of the Blunt

I want to be careful here, because "be kind" advice curdles quickly into an argument that all directness is cruelty. It isn't. Some of the best feedback I've ever received was blunt to the point of rude, and I'm grateful for it. Years ago a staff engineer looked at an architecture I was proud of and said, "This is going to be a nightmare to operate at 3am and you know it." He was right. He was also not being gentle. But he was being useful, because he immediately followed it with the specific operational failure modes he was worried about.

The kindest thing you can do for a good engineer is take their work seriously enough to tell them exactly what's wrong with it.

That is the reconciliation of the whole tension. Bluntness is not the enemy of feedback, and gentleness is not the essence of it. The enemy is vagueness. You can be brutally direct and deeply helpful at the same time, as long as the directness is aimed at the specifics. What you cannot do is be vague and helpful. Those two are simply incompatible, no matter how warm your tone is.

Building It Into the System, Not Just the Manager

Relying on individual managers to be good at this is a fragile plan. People are tired, incidents happen at bad hours, and even careful people give sloppy verdicts when they're stressed. So I try to build the feedback-over-criticism norm into the system itself. Pull request templates that ask the reviewer to state the concrete risk of a change. Retro formats that separate "what the code assumed" from "who touched it last," because the second question is almost never the useful one. A standing rule that a "no" on a design has to come with either a concrete alternative or a concrete risk.

These structures don't make people nicer. They make it slightly more expensive to be lazily critical, and slightly cheaper to give real feedback, and over a few months that shifts the culture more reliably than any speech I could give. The best feedback cultures I've worked in weren't full of unusually enlightened people. They just had habits that made the useless kind of criticism awkward to produce.

The Other Side of the Table

All of this cuts both ways, and I've had to work on the receiving end harder than the giving end. When someone hands me a verdict instead of feedback, the productive move is not to sulk, it's to ask the follow-up they skipped. "When you say this is a mess, what specifically would you change?" Half the time the person had real feedback underneath and just hadn't bothered to unpack it. Dragging it out of them turns a useless comment into a useful one, and it quietly teaches them what you actually wanted.

The other half of the time there's nothing underneath, and that tells you something too. Not every critical comment contains buried gold. Some are just someone having a bad day and aiming it at your code. Learning to tell those apart, and to not reorganize your work around the empty ones, is its own skill. I lost a weekend once rewriting something because a loud senior voice didn't like it, and it turned out he didn't have a reason, he just didn't like it. I try not to make that mistake anymore.

Conclusion

If I had to compress all of this into one habit, it would be this: before you tell someone their work is wrong, make sure you can tell them what right looks like. If you can't, you don't have feedback yet, you have a reaction, and reactions belong to you, not to them. Sit with it until it turns into something specific, or say plainly that it's a gut feeling and let them weigh it as one. The engineers who rewrote things badly over lost weekends didn't fail because someone was too harsh. They failed because someone handed them a verdict and called it help.