If your feedback comes late, don't call it "feedback"

When feedback is superficial or delayed, you not only risk complicating things but also erode the trust the team has in you.

A few days ago, one of the guys on my team said to me «Your comment was unfair». That feedback caught me off guard, even though my initial reaction was to smile. I smiled because, in that moment, I was genuinely glad that this person felt comfortable enough to give me such a direct and even “heavy” piece of criticism. But, of course, that brief moment of composure quickly gave way to my real feelings: it stung. Let’s take it step by step, though.

A few weeks before that conversation, I created a small sub-team and assigned them the task of drafting a plan to migrate part of our core product from the old monolith to the new website we launched earlier this year. The request also included adding hypothetical release dates for each step of the migration, so we could get a sense of planning and resource allocation for the coming weeks and months. Once the plan was prepared, I was asked to review it. Aside from a few minor details, I approved the plan and gave the green light to start work. After a couple of weeks of not directly following the project, I noticed that some pages had been completed and deployed to production. However, they were still hidden behind a sort of feature flag, meaning they weren’t actually live yet.

My instinctive reaction was to ask the team why those pages were still in this sort of limbo instead of being released. I assumed they might be delaying the release out of fear or anxiety about the consequences of the migration. However, one of the team members responded with something along the lines of: «We’re following the plan. The pages will go live as soon as Page X is also completed. It’s all outlined in the plan you approved»

A few days later, during one-on-ones with two of the team members, both — some more politely, others more directly — brought up the same issue: how frustrating it is to be called out for something that had already been discussed and agreed upon in the past. Especially when weeks of work are built on previously given feedback.

As a result, I was unfair.

Late feedback or shallow feedback

This wasn’t the first time something like this had happened, but these conversations reminded me just how damaging late or shallow feedback can be. It’s not only about wasted time and money, the damage spreads to the point of undermining the trust people have in you.

You may think that late feedback is different than a superficial one but, in my experience, I realized that they are just the same thing.

Imagine a scenario where you’ve given the green light to something, only to realize, after a few weeks of work, that it was completely wrong. Is the problem with the timing of the feedback, or did it start when you approved something without giving it the proper attention? It’s clear that you can’t control everything, and often you don’t have all the information when making a decision. However, I’m talking about those situations where you’re "too busy," or when you think «It’s just a small detail, it doesn’t matter». These are exactly the kinds of cases that can be avoided. The point is that if you can’t dedicate the right focus to something, it’s far wiser to delegate the decision to someone else, or simply be honest and say that, at this moment, you’re unable to fulfill the request.

People start to get tired, but more importantly, they stop working with confidence. A mechanism kicks in where they’re no longer sure of the direction, even after you’ve given an explicit green light. They end up working with the constant hope that there won’t be a change of mind or a shift in direction based solely on a superficial preliminary analysis, rather than on objective data or new information that comes to light later on.

Code Review is feedback

A special mention should also go to code reviews. In this issue, I’m not just talking about product or business decisions — these same principles apply to code reviews as well. Leaving team members waiting for your review for days because you’re too busy, or even worse, doing what we call a "no-look review" in our team — approving a Pull Request without a proper review — has exactly the same consequences I mentioned earlier. It undermines trust and disrupts the flow of work in the same way.

Can we do it better?

Feedback is the gear that keeps everything moving: it prevents rework, builds trust, and makes every project more effective. It’s not enough to say you're available, you need to be actively present. Read, listen, dive deeper. If a project goes off track and you haven’t done anything to steer it back before it’s too late, the problem isn’t the team. It’s you.

How to do better

1. Put feedback first: block time in your schedule to provide timely responses

2. Read everything: if there's a document, thread, or update, take the time to read it. Don’t make assumptions

3. Always ask yourself: “Am I helping or complicating things?”: if you show up after things are done with criticisms that require rework, you're probably complicating things

Common mistakes to avoid:

1. Poor Timing: avoid delaying feedback until the issues have progressed too far. It’s much more effective to intervene promptly

2. Superficiality: make sure you're well-informed about all the details before giving feedback. Criticism based on incomplete information can lead to frustration and misunderstandings

3. Inconsistency: provide consistent feedback based on clear criteria that are shared with the team. Inconsistency can undermine trust and transparency

TL;DR

Being a leader means being helpful to the team on a day-to-day basis. If your feedback is delayed or superficial, you're missing the mark. Your role isn’t just to supervise; it’s to step in with precision when needed, to prevent the team from wasting time and resources. Don’t wait for the perfect moment, don’t make assumptions, and don’t ignore the signs. Timely and well-informed feedback is the way.

Credits: Illustration 1