We all know that constructive feedback is often the catalyst that propels us forward in our careers. Those of us who accept this will gladly listen to feedback provided by others, and we might even listen attentively when it is being offered. We may, if we are so inclined, request feedback from our customers and managers because we have heard that in order to improve we have to take feedback seriously. So we go through the motions and we process feedback. However, in all the situations above, the feedback is being pushed to us, not pulled.
Learning to pull feedback is an entirely different mindset, and rarely will you find people who get into this mode, especially in my world of highly technical people. The big difference between feedback we receive and feedback we pull is this. When you are actively pulling it in, you are doing something about it. You are making changes to your life, to your process, to your code. You are keenly interested in applying the lessons both retrospectively and immediately.
You can tell the difference rather easily. The eager eyed new developer who comes into your office and says, Can I get some feedback? is not really pulling feedback. They are saying this because they want a raise, or they have heard it is a great way to appear teachable. Usually, they are not going to apply what you say. The pull request looks much different. The pull request is incentivizing you, even demanding you, to provide feedback before the next cycle can continue. It is annoying for those of us who are in fast paced mode, but those who demand feedback before progress can continue are the ones who will actually use the feedback to better their work product. There is a major difference. Note this well, because if you want to know the members of your team who are actually going to make measurable progress, it will be the ones who are constantly pulling feedback.
You can also tell which companies want feedback and will use it to improve. Most companies give feedback lip service, but do absolutely nothing about it. I was in a large company where we had a quarterly survey that went to all employees and it was reviewed carefully by management. However, this was a tool used for measurement only. The feedback was not in a pull state because it never made it into any process changes. It was only used as a measure of employee satisfaction, not as a method for making meaningful changes to the root causes of dissatisfaction.
People and companies that pull feedback respond. They do so quickly and with purposeful direction. They do not talk about feedback loops; rather, they are the feedback loop. The entire nature of the organization is one that pulls, responds, and reacts to feedback. In a pull situation, the one receiving the feedback does not have to be asked to put these items at the top of their priority list.
In the end, pulling feedback is a commitment, not a technique. It is a decision to be changed by what you learn, and to let that change show up in your next action. If you want progress that you can measure, make feedback a gate that you must pass through, not a suggestion you consider when convenient. Build your day so that you ask, receive, and respond. Teach your teams to do the same.
Do this long enough and the culture shifts. People stop defending, they start improving. Work gets cleaner, decisions get clearer, and trust grows because everyone can see that input becomes action. That is the quiet proof. When you pull feedback, you do not need to promise improvement. You simply become the kind of person, and the kind of team, that improves.
