Stop asking for feedback. Start asking for action

The real reason your team doesn't give you feedback (and why that might be okay)

I took the opportunity of a new member joining the team to give some love to our internal knowledge base: reorganizing the information architecture, adding missing information, and reviewing existing content to fill any gaps. It was quite a significant task and, to avoid making decisions on my own that could impact the whole team, I asked for feedback multiple times to make sure I was moving in the right direction.

However, the outcome was quite disappointing: most of the time, the message didn’t lead to any concrete feedback, and in some cases it was completely ignored. It’s quite frustrating when it feels like you’re talking to yourself and you don’t know whether all the effort you put in was really worth it.

During the same period, however, I also found myself documenting some changes introduced to internal processes that directly involved certain people. In that case, the response was immediate and 100%: everyone shared their thoughts or at least added a reaction to the message to indicate they had read the material.

So why did I get such different results in what might seem like the same type of action? I wanted to investigate and explicitly asked the people on my team during our 1:1s. I received different answers, but after analyzing them, I realized that the main issue actually originated earlier: it was my expectation about why I wanted a response that was wrong.

But let’s take it step by step. The process that led to this conclusion is, in my opinion, worth sharing, because it offers very useful insights for all those times when explicit feedback is necessary and we struggle to obtain it.

So, there are two distinct parts in this article:

1. What we can do to make sure people give us feedback when needed

2. Why sometimes we ask for feedback just to be reassured that our work makes sense.

Why do people struggle to give feedback?

The pattern is very clear: when you tag people directly, you get a 100% response rate, whereas when you ask generally, you get almost complete silence. This isn’t random, and it doesn’t necessarily mean that your team is uninterested or uncooperative.

One of the possible solutions that came up in my mind was asking them to leave, at least, a 👀 reaction to the message to indicate that they had read the message. That didn’t work either. But I’ll come back to this later.

First of all, let’s see some of the possible reasons why you don’t get feedback.

Diffusion of responsibility

When you write «I need feedback on X», no one feels directly responsible for responding. Everyone thinks “Someone else will reply”, or “I’m not the right person to comment”. The more people are involved in a general way, the less each individual feels called to act.

Cognitive overload

Your teammates probably receive dozens of notifications every day. A generic message like «I reorganized the knowledge base» becomes background noise, even if it’s very important. It may be that their brain is triaging priorities, and a message without a specific call-to-action ends up at the bottom of the list.

Ambiguity about “what you expect”

«I need feedback» is vague. Feedback on what? How detailed? By when? Is it mandatory or optional? Who should respond? This ambiguity may create paralysis in your teammates.

Cultural gap in communication

In some contexts (especially Nordic/Central European, but also in certain tech teams), people only respond if they have something substantial to add. Silence means agreement. In other contexts (more Italian, more Mediterranean), silence might be interpreted as “I haven’t seen it / I’m not interested”.

They don’t feel authorized to give feedback

You are their leader and they could think “Who am I to say whether my boss’s KB is well done?”. Even if you ask for feedback, the power dynamic may inhibit critical responses.

What can we do to improve the way we ask for feedback?

Here are some examples of changes I put in place to change the direction and that brought improvements.

While asking for feedback:
🙅 Avoid: «Folks, I reorganized the KB, give me feedback please».
👌Say: «I reorganized the KB. @Mark @John @Sofia: by Friday, I’d like you to read section X and let me know if it’s clear how to find the information on deployments. Can you please do it by the end of the week? Even a 👍 if everything looks good is enough».

While introducing something new:
🙅 Avoid: «Folks, here is a new document about the new process. Please share your thoughts».
👌Say: «I’ve written a document about the new process. @Mark, since you often work on feature X, can you tell me if point 3 is clear? @Sofia, for your use case of Z, does point 5 make sense? Can you please share your thoughts by the end of the day?».

During the planning:
🙅 Avoid: «Remember to update the task planning».
👌Say: «Mark can you update the estimate for that task before the end of the day? If it takes more than 5 minutes, we can discuss it afterwards».

All of the examples above follow a similar pattern: Assignment + Request + Constraint.

• A: Who should do what

• R: Exactly what they should do. Not just «feedback» but «tell me if X is clear»

• C: Time constraint as this creates urgency

What’s the real reason behind your need for feedback?

Everything I’ve talked about so far starts from a very important assumption: there is a valid reason behind the request for feedback.

When I started asking my team why I wasn’t getting any responses (and some of those reasons are exactly the ones we’ve seen above), I began to realize something else important. Even though it was useful to know whether the work made sense to them too, my reason for wanting an answer at that moment was not the right one. But most of all, the way I asked for it was not effective.

The first thing I realized is that asking people to at least react with an emoji to show they had read the message was not the right approach. It may be understandable as a response to frustration, but it risks being interpreted in many negative ways: as micromanagement, like “I need to check that you’ve read it”, or even worse as mere compliance without real engagement, like “I’ll just put a 👍 because that’s what they want, and then they won’t bother me”.

The point is that this does not solve the real problem: I shouldn’t be interested in knowing whether they had read it, but rather if they were actually using the process, if they truly found the information useful, and if they were able to navigate the knowledge base.

That’s when I asked myself why I really cared about getting an immediate response to that message: partly to make sure they would use the documentation, and partly because of the frustration of feeling like I was “speaking into the void”.

Problem 1: Making sure they will use it

This is an adoption problem, not a communication problem. And here comes the bad news: a chat message will never change an established behavior. Even though we profess to be agile, we say we fully adopt the agile manifesto, people are reluctant to change and change takes time.

Why is change so complex?

What effectively works to improve adoption?

1. Make the new system easier to use

2. Create friction in the old system. Eg: if you want them to use a new process, remove or break the old one

3. Show them it actually works. People often emulate behaviors more than they read documents

Problem 2: the frustration of “speaking into the void”

This is a more personal issue, and it’s also legitimate to feel frustrated, but there are two important aspects to consider:

The need to know you’ve been heard
This is human, but it risks turning into micromanagement. If you’re doing your job well as a leader, you will often be speaking into the void. Many things you communicate are important but don’t require an immediate response.

The need for validation that your work makes sense
Reorganizing a KB or writing a process are big tasks. It’s normal to want to hear “thanks, this is useful” or “great job”. But you are asking for validation from the wrong people in the wrong way.

How to better handle this?

1. Change your expectation: expect that 90% of broadcast communications will be ignored. This doesn’t mean they are useless.

2. Look for indirect validators: if nobody is no longer asking how to do X or where they can find Y, well you did a good job. The absence of problems is often the best feedback.

3. Read the silence as neutral: no answers doesn’t necessarily mean “I don’t care”

TL;DR

If I really want to dig deeper into the problem, there is an even more important reason behind this need for immediate feedback: ignored messages, missing emojis, “I had nothing to say” are all symptoms. The real problem is that I had the feeling that I did a huge amount of work that no one saw, no one thanked me for, and that left me feeling like I was wasting my energy into the void.

But as I already mentioned in the very first issue of this newsletter: the main difference between being an individual contributor and a leader is that the real impact of a leader’s work is never immediate. It often takes months, and often no one will ever know because the problems you prevented simply don’t exist.

If you want to read my first issue, you can find it here:

What the comfort zone of a Leader looks like

Credits: Illustration 1