The Issue with Feedbacks

I love feedback. I believe in feedback a lot. However, not all feedback is good, not all feedback is applicable, and not all feedback is fair. Feedback is critical for course correction and growth. However, feedback can be manifested in a variety of shapes, forms, and intentions. I believe in creating several mechanisms for feedback because, eventually, what needs to be found will be found. Feedback is a signal; sometimes, it tells more about who is giving the feedback than the person receiving it. Other times, feedback is just wrong. Whether feedback is written or bad, it’s an important signal. I believe in being more effective and in the speed of change and improvements. However, can you go fast if you dont understand what you are doing? That’s my issue with feedback. Oftentimes, feedback is poorly constructed and missing essential details. So, dealing with feedback is not so different than handling high-priority, difficult production bugs. Requires deep tought, introspection, and time.

Handling a production bug

Let’s talk about a production bug. Getting an empty JIRA ticket with no stack trace, error, or steps to reproduce the problem is common. So you need to investigate; the standard steps start with:

• Talk to someone: Usually, who opens the bug, you might uncover some tips and clues.
• Look at the code Changes: A recent change could have introduced the bug. Check version control in Git and see if any commits catch your attention.
• Look at the Logs: Look at the production logs; usually, central log solutions have good query capabilities that can allow you to have more clues and, if you are lucky, some stack track or error.

You are gold once you have good clues, reproduce locally, and write a test that fails. However, sometimes that is not enough. Looking into dashboards, metrics, and alerts and understanding the effect downstream and upstream. But sometimes, this is not enough, and you need to go deep and do:

• Look at the code: Not only application code but libraries code and frameworks code, all the way down to platform code and even languages and kernel code.
• Debug and Profile: Yes, debug and profile locally, and sometimes it’s even necessary to do it in production.
• Simulation: Write code to simulate the problem in the form of POC; you might have an easier time understanding what’s happening.

If you are very lucky with a couple of Google searches and you find someone with the same symptoms the solution works. No matter what you are ready and prepare for a battle because is production. When we talk about people and feedback, we do not have 1% of these tools and techniques because often information is sealed and hidden, so how can you debug something without looking at the code and without proper observability and troubleshooting tools is hard, right? That’s the issue with feedback.

Feedbacks are Riddles

Comparing feedback with troubleshooting a problem in production should make us realize how little we know about the real problem (if it exists). Feedback often comes in riddles, subtle comments, and small gestures. It’s hard to capture that and reason with a lack of information.

The more you share details and talk openly, the more maturity your team needs. However, dealing with and fixing problems is easier when we are open and discuss issues like production bugs or incidents.

Systems don’t have emotions (for now, AGI is not here yet). It’s much easier to fix a bug in production than to get good feedback and the facts straight to resolve the issues. We need trust and maturity to get better feedback and better results.

In his classic Five Dysfunctions of a Team, Patrick Lencioni discusses the dysfunctions every team has. Without addressing the foundations’ roots, it’s impossible to create a high-performance team because you can only go so far. I strongly believe in highly competitive sports teams like the NBA in the US and the Champions in the EU. If you are looking for a great feedback book, the best one I ever read was Thanks for the Feedback by Douglas Stone and Sheila Heen.

Getting Better

In order to get better feedback, here are some things that can be done:

• Detach you from your work: It’s okay to make mistakes and have things to improve.
• Be comfortable with discomfort. Nothing grows in the comfort zone, and being uncomfortable is good. It means we are into something.
• Make feedback public: Like blameless incident reviews, the more open you talk, the more facts we have and the better chances we have to fix the “bug”.
• Don’t take things personally: Where you are today does not matter; where you will be tomorrow matters. As long as you are constantly evolving. It’s fine.
• Don’t take problems from others as yours: IF John got a call out and has things to improve, this is John’s problem, so Adam should not take it into his heart.
• Mind the Culture: When you work internationally or with different countries, understand that the culture is different, don’t assume things are personal, and understand that there are things you need to learn. Being direct is a good thing. Feedback is good. The lack of feedback is much worse.
• Share the facts: Be as open as possible and share as much as possible; more information is critical for better understanding and addressing problems.
• Give more feedback, Ask for more Feedback: Give feedback more often, ask for more feedback; you will see it’s not a monster with 7 heads, and you will grow and learn how to appreciate transparency.
• Trust your Leader: Trust your leader knows what he is doing and ask for help when you don’t know what to do and how to proceed.
• Practice: The more you do, the more moral will be better you will be.

Silence is the worst thing you can do. As I wrote in my Ignoring Culture,?Cost of Silence and Training like Pros. If you want to learn more, I recommend my 3rd book.?Continuous Modernization?covers the mindset, practices, and shift to better work data with teams dealing with feedback and other soft-skills in complex, distributed systems at scale.

Cheers,

Diego Pacheco

Originally published at https://diego-pacheco.blogspot.com on February 25, 2025.