"We Should've Talked Sooner" — The Quiet Cost of Delayed Feedback

A story from after-work drinks reveals why "We should've talked sooner" might be the most avoidable sentence in team life. Learn how to turn delayed feedback into real-time partnership with four practical techniques you can try this week.

Perfect for: Developers, team leads, product managers, and anyone who wants to build better team dynamics.

Transcript

Ricardo: 0:01

Welcome to Not the code where we explore the human side of software development. Today we're diving into something that happened to me just a couple of weeks ago that's been stuck in my head ever since. After work, drinks, casual conversation, and a fellow team lead shares a story that made me realize how many teams are making the same costly mistake. Without even knowing it, we should have talked sooner. That's what his senior developer said. After receiving their quarterly review, two pages of feedback about communication issues, missed context and code reviews, team alignment problems in this developer, they had no idea any of it was happening. My colleague swirled his beer and said something that hit me. That's when I realized this wasn't really about the developer. This was about us, about a team that had spent three months collecting grievances instead of having conversations. And that's exactly what we're talking about today. The quiet, expensive cost of delayed feedback and how to build teams where we should have talked sooner becomes, I'm glad we caught this early. But before we dive in, let me tell you why this matters so much. I've been in this industry for years, and I've seen brilliant teams fall apart. Not because of technical challenges, but because of communication breakdowns. I've watched talented developers lose confidence. Product managers burn out in entire projects, derail all because we couldn't figure out how to talk to each other in real time. The thing is we're great at debugging code. We know how to trace through logs, identify problems, and fix them quickly. But when it comes to teen dynamics, we let issues compile for months before we even acknowledge they exist. There's a particular kind of silence that creeps into teams, not that productive heads down kind, where great work happens. It's the quiet that fills the space where a conversation should have occurred but didn't. I've been thinking about this pattern for years, but that conversation crystallized something important when feedback arrives as a surprise in a formal review, we've already failed. Not because the feedback itself is wrong, but because we've turned what could have been a coaching moment into damage control, I. Let me pit you a picture of how this plays out in real teams. Someone struggles with project planning for weeks, but we only mention it during their review. A product manager keeps interrupting in team meetings, but nobody says anything until tensions explode. A designer's prototypes consistently miss technical constraints, but we save that conversation for the feedback session. Sound familiar? I thought it might. Here's what happens when we let this pattern continue. The team member who's struggling starts to doubt themselves. They know something's off. Maybe they're not getting the engagement they expect, or they're sensing tension, they can't quite identify, but without clear feedback, they fill in the gaps with their own assumptions. Usually the worst possible assumptions. Meanwhile, the rest of the team gets frustrated. They start working around the person instead of with them side conversations happen. People begin to avoid certain meetings or collaborations, and everyone's productivity suffers, not just the person who needed the original feedback. Each time we wait, we're not just delaying helpful information, we're compounding the problem. The longer poor habits continue, the harder they become to change, but there's something deeper happening here. We're sending a signal. Either we don't care enough to help in real time, or we don't trust the person enough to handle a direct conversation. Neither message is what we intend to send, but that's often how it lands. Now before we dive into solutions, let's talk about why this happens because it's not just careless teams that fall into this trap. I've seen brilliant well-meaning teams struggle with this exact issue, the accumulation habit. We think we're being thorough by collecting observations over weeks, but by the time we share them, the context is stale. I once spent six weeks building up to tell a colleague that their code review comments felt dismissive. When I finally mentioned it, they barely remembered the examples I was referencing. The perfect moment myth. We wait for the right time, the right setting, the right words. Meanwhile, the moment when feedback would be most useful immediately after the behavior occurs. Passes by. I spent two weeks crafting how to tell a teammate their demo style wasn't engaging stakeholders. By then, they had already given three more ineffective demos. The comfort zone problem I. This one's harder to admit. It's easier to complain to other team members than to speak directly to the person who could actually change something. This creates a weird dynamic where everyone knows about an issue except the person who could fix it. But here's what I've learned. The uncomfortable we feel about giving feedback is usually much worse than the actual conversation. We build it up in our heads, but most people, they appreciate the honesty when it's delivered with care. I remember avoiding a conversation with a designer for three weeks. They kept creating mockups that looked beautiful, but were technically impossible to implement. I kept thinking, how do I tell them this without crushing their creativity? I built this whole narrative about how they'd be devastated, how it would damage our working relationship. When I finally had the conversation, you know what happened? They said, oh, I had no idea about those constraints. This is super helpful. Can you walk me through what's technically feasible so I can design within those parameters? Three weeks of stress on both sides solved in a five minute conversation. So how do we fix this? The solution isn't more formal processes. It's building micro habits that make feedback feel normal rather than nerve wracking. Let me share four techniques that have transformed how my teams handle feedback. First, the 24 hour rule. If something significant happens in a meeting or collaboration, mention it within 24 hours, not in a formal sit down. Just a quick, Hey, can I share something I noticed. This keeps the context fresh and the stakes low. I started doing this after missing too many opportunities. Now, if someone asks a great clarifying question in a meeting, I'll mention it right after. If an explanation falls flat, we talk about it the next day. The key is immediacy. Second anchor two specifics. Instead of storing up vague impressions, tie feedback to concrete moments rather than you need to communicate. Better try. In yesterday's team meeting, when you mentioned the API delay, walking us through the impact would've helped the team adjust our plans. People can't fix what they can't picture. Specific feedback gives them something actionable to work with. Third, lead with intent. Start feedback conversations by clarifying your motivation. I'm bringing this up because I want us to nail this project, or I'm mentioning this because I think it could save you time in the future. This frames the conversation as collaboration, not criticism. When people understand your motivation, they hear partnership instead of judgment and forth. Make it bi-directional. Ask for feedback at the same time. You're giving feedback. I noticed X in the meeting. How did you experience that moment? Or, here's what I observed. What's your perspective? This transforms feedback from a one-way critique into a shared problem solving session. It also normalizes the exchange, which brings down everyone's defenses. Now, here's something important I wanna mention. Timing isn't just about speed, it's also about context. There's a difference between immediate feedback and impulsive feedback. If someone makes a mistake in a high stress moment, pulling them aside right then might not be the best timing. But within 24 hours when things have settled, that's the sweet spot. I also wanna address something that comes up a lot. What if the feedback isn't well received? This is a legitimate concern, but here's what I've learned. When feedback is delayed, it's almost always received worse, not better. When you wait three months to mention something, it feels like you've been silently judging the person the entire time. When you mention it within a day or two, it feels like you're paying attention and you care about their success. Now, I know what some of you might be thinking. This sounds great in theory, but what does it actually look like day to day? Let me give you some examples that you can try literally this week. If someone asks a clarifying question in a team meeting that prevents a misunderstanding, mention it right after that question you ask about the API dependency probably saved us a day of rework. If someone's code review comment is unclear, ask about it in the moment rather than trying to interpret it. I'm not following the suggestion. Can you elaborate? Or help me understand the reasoning behind this approach. These things take seconds, but they keep teams aligned and prevent misunderstandings. The goal isn't to become the feedback police, it's to normalize the flow of useful information when it's most valuable. Here's something interesting. I've noticed teams that do this well have fewer formal feedback sessions, not more. When information flows regularly, those quarterly reviews become summaries of a journey you've already walked together. Not surprise revelations, but let me be clear about something. This isn't about turning every interaction into a feedback session. Some conversations are just conversations. Some meetings are just about getting work done. The goal is to create an environment where useful information can flow naturally when it matters. Not to make everything about feedback. We want feedback to feel like a natural part of collaboration, not a constant performance evaluation. But let's zoom out for a moment because this isn't just about individual conversations. This is about building a different kind of culture. Teams that master timely feedback share a common trait. They've made small course corrections feel safer than big confrontations. When feedback happens in real time, it's usually small and manageable. When it gets delayed, it becomes large and overwhelming. Last week, a project manager pulled me aside after a client call. She said, your explanation of the technical constraints was really clear. The client seemed to relax Once they understood the trade-offs, it took her 15 seconds to say, but it gave me useful information I could use in the next client conversation. I. That's the kind of feedback culture we're aiming for. Not more formal reviews or structured processes, but the everyday habit of helping each other see our blind spots while there's still time to adjust. I. Here's what I've learned about this shift. It requires trust, but it also builds trust. When people know they'll hear about problems quickly, they stop worrying about hidden issues or surprise reviews. When feedback flows regularly, it stops feeling like judgment and starts feeling like partnership. There's also a compound effect that happens when team members see that feedback is given kindly and received well. They start giving feedback to each other. It becomes part of the team's DNA, rather than something that only managers do. I worked with a team where this transformation happened over about six months. At the beginning, feedback was this formal dreaded thing that happened in reviews. By the end team members were naturally helping each other improve in real time. The productivity games were noticeable, but the morale improvement was even more dramatic. People felt supported instead of evaluated, they felt like they were growing instead of being judged. Here's what I want you to try this week. Pick one person on your team and commit to giving them one piece of immediate feedback, not saved up, not formal, just a real time observation about something that could help them or the team. Start small. Notice when someone does something well and mention it. Notice when something could be clearer and ask about it. The key is to practice when the stakes are low, so it feels natural when the stakes are higher. Pay attention to how it feels most of the time. You'll find that the conversation you are dreading is actually fine, maybe even helpful. The anticipation is usually worse than the reality. Here's a specific framework you can use. Start with positive observations first. Get comfortable getting immediate positive feedback before you tackle the constructive stuff. That explanation of the database structure really clicked for me, or the way you handle that stakeholder question was perfect. Once that feels natural and it will because people love hearing what they're doing. Well then you can start with gentle clarifying questions. I'm not sure I followed that last point. Can you elaborate or help me understand the reasoning behind this approach? Notice that these aren't even feedback statements, they're just curiosity, but they open the door for the person to self-reflect and often self-correct. The next time you find yourself thinking, I should probably mention something to them, don't wait for the perfect moment. Create it. A quick conversation today beats a difficult review next quarter because the most expensive feedback is the kind that arrives too late to be useful, and we should have talked sooner, is probably the most avoidable sentence in team life when we remember that our code isn't the only thing that needs continuous integration. Our communication does too. We build better teams. Better products and better relationships. Thanks for listening to Not the Code. If this resonated with you, try that one small feedback conversation this week and see how it goes. Until next time, keep building better things together.