How to Build a Virtuous Feedback Loop

Much has been written about the process of giving professional feedback, yet a lot of us are amateurs at it. A leader—be it a CEO, an activist, or the captain of a sports team—who fails to incorporate a good feedback loop is unknowingly encouraging miscommunication. Bad feedback or no feedback at all prevents the exchange of dialogue between team members. Most of the things are left unsaid, and this leads to build up of resentment.

Despite that it’s actually tough to inculcate a good feedback loop without understanding the root cause: hidden expectations. You see, we have certain expectations most of the time—expectations from ourselves, from teammates, from projects, etc. The problem, however, is that these expectations exist, but we aren’t aware of them most of the time, because we seldom talk or think about them explicitly.

Now, when things go wrong (as they often do), it leads to these automatic internal narratives—the other person is bad at their job, they were slacking off, they aren’t smart enough, etc. We start blaming others, and this happens automatically, without our conscious thought. Now this feedback is either withheld to avoid conflict, or it’s blurted out violently. “You know you screwed that up. Why did it take so much of time? Why isn’t the quality up to the mark?” Both of these are red signals. Both of these are examples of failure to actually work out the confusion from our internal narratives. A good feedback loop incorporates a good exchange of dialogue between the stakeholders.

The correct way would be to start by working out your confusion first. For starters, you have to be explicit about your expectations with yourself, and then with other stakeholders. You have to be clear about what looks good, and how the team is going to go about achieving it. You should sound like, “I just want to be explicit about the goals, and how everything should work out.” The idea is to set a standard and get in sync with all the other team members before a project even begins.

The next part of the conversation comes after a project (or a sprint, or a batch—same idea, many names) is either midway, or just finished. Regardless of things going well or not, you should start by talking about your experience. If things didn’t go well, your goal is not to cast blame on somebody. In fact, your goal is not even to diagnose the project. You are just sharing what you’ve experienced. “This project wasn’t delivered on time,” or “I’m confused why did we have to wait so long before shipping this feature?”

At this stage your aim is to give your teammates transparency into your confusion, and try to figure out what they themselves have experienced—are they in sync, or was something not clear. This gives them an opportunity to share their side of the story, and prevents the build-up of a one-sided narrative in your head.

If you hear something like, “Yeah I delivered it a bit late because I miscalculated the timelines and my effort,” or, “I hit a roadblock, and it took me quite a while to figure a way around,” you are most probably on the right track. Ask your team to detail out their experience. It’s not a short process. Give them enough time and room to do their thinking and find out what went wrong.

Now the team and you can clearly see the difference between the standard that was set early on, and what has actually happened. The gap between the two things is the gap of performance. This is the feedback that you are trying to deliver. But rather than saying it in words, and pointing things out, you’ve now incorporated your team into the process and get the conversation started.

This method sends out the message that there are no counter-parties here, and nobody is accusing anyone. You are here just to get some clarity. You are literally looking at reality side-by-side and openly asking, “Okay, do we agree that this is a bad outcome?” Instead of assigning blame, you are trying to understand if everybody aligns with you, and then start discussing what to do now, and how to make sure that such events can be avoided in the future.

Personally, I’ve found this process very handy. This, however, works only with teammates with growth mindset. If somebody is really working just for the pay check, and doesn’t really care about quality work, they would have no interest in the feedback loop.

By following this process, you’re actually doing a couple things differently: For starters, you are being explicit about your expectation. You are making clear what is important and what everyone needs to know. This way you are also being open-minded. During expectation setting, you are putting in your opinion, and asking for others feedback. This way, others can chip in if they have anything to add or modify. Others can point out if your expectations are sky high, and not possible in the timeline. This way you’re also conducting the feedback in a way that others feel enlisted in the process because, and if things go wrong, take full ownership and not feel accused. This process is an attempt to discover what is true—and that’s the ultimate goal of a good feedback loop.