Personally, I have a long trajectory in the field and started my career in a very technical way, which provided me with a solid foundation. This foundation began during my internship, and my first big challenge was studying a document from Sun, available on their website, about Java: the Java Code Conventions. The words I heard the most for almost two years were ‘maintainability’ and ‘cognitive effort.’ The focus was always on structuring the code in a way that was easy to read, maintain, and evolve.
At the time, we were creating an IT hub in Recife, Pernambuco, because until then, all the technology and development area was centralized in Brasília. Part of my challenges, for example, was defending which tools we would use. Docker didn’t exist yet, virtualization was just starting, and all configuration was done manually, with the documentation of the tools being the main source of information. So, comparing, installing, and configuring SQL databases and operating systems were part of my early career, in addition to developing tools in Java 5 and Swing. It was during this period that I had my first contact with Linux, in 2006.
I can share more details about this beginning on another occasion, as there were many valuable lessons that I consider important for my journey.
I then began to delve deeper into topics such as design patterns, integration patterns, data modeling, object-oriented modeling, distributed systems, and system architectures. What I want to highlight here is that my entire background was extremely technical. In this context, I also studied topics related to project management and agility. In another company I worked for, I participated in a project that was selected for an audit aimed at CMMI certification. As a junior member, I needed to have a good understanding of the certification requirements because, if the auditor called me for an evaluation, I should know the details of the processes and be prepared to discuss our team’s adherence. Even so, these topics, although challenging and relevant to the organizational context, were not directly related to developing leadership skills or people management.
The Complexity of Leadership
However, when the focus shifts to leadership, the situation changes. We are no longer talking about bits and bytes, project phases, or a specific level of CMMI maturity. The big difference lies in how what you learned as a technician simply doesn’t apply to people. What do you mean by that, Manoel? Let me explain.
In programming, you learn to create a function that, when given two numbers, returns the sum. If this function is built following best practices, every time it receives the same parameters, the result will always be the same.
“The fundamental problem of computer science is not to find faster algorithms, but to ensure that a given algorithm works correctly and consistently.” – Donald Knuth
“Good design is as much about eliminating things that don’t belong as it is about adding things that do.” – Fred Brooks
With people, it doesn’t work like that. If you convey a message to a room with ten people, there is a possibility that none of them will understand the message exactly the way you intended. Some may understand and reinterpret what they already knew before; others may add the new information to their repertoire. There are also those who might adjust a large part of their repertoire based on a transformative new piece of information. And finally, some people might understand exactly the opposite of what you said or infer things you never mentioned. The dynamics of human communication are, in fact, much more complex.
“Language is not only a part of human behavior, but a reflection of our cognitive ability and our interaction with the world around us.” — Noam Chomsky
I will share a case that I have experienced in several other environments: when a company, with a more orthodox project and people management model, decides to adopt an agile model focused on product management. This represents a true cultural shock. They are two completely different worlds, almost like two planets colliding.
As a result, what usually happens is that those with more experience, who lived through the previous model, try to adapt the new one to the old — something that clearly doesn’t fit. From these adaptation attempts, with changes and adjustments to various practices, the departments and teams are unable to assimilate the new model. The result: it doesn’t work as expected.
Then, the blame falls on agility and the new management models, when, in reality, the problem lies in the lack of a significant cultural shift. Without this transformation in organizational culture, it becomes very difficult to achieve the desired results with agile practices. Making this transition requires deconstructing the old model and learning the new one. Trying to make associations with the past usually doesn’t work.
“The biggest obstacle to adopting Scrum is not learning Scrum, but making the cultural changes necessary to create an agile environment.” — Mike Cohn
Feedback: A Tool That Goes Beyond Metrics
When I talk about metrics, for example, a company that doesn’t have a testing-driven development practice decides to adopt test coverage as a quality factor in deliveries, with the goal of reducing defects. I often respond that this will create problems, not solve the issue. And I don’t say this with a negationist mindset. By adding tests to code that already has design defects and implementation problems, the situation won’t improve. The result will be that the problems will be ‘covered’ by tests. The focus will shift to just achieving the coverage goal, not improving the code, the application design, or the application itself. I’ve encountered code with over 80% coverage but without assertions. And the justification? ‘Delivery time.’
You might be wondering: Manoel, what does all of this have to do with feedback and the topic? The thing is, just like adopting a management model or adding a new KPI, applying feedback effectively only works when there is a culture that supports it. Feedback is not just a tool for signaling behavior and result metrics. If you’re using feedback this way, I’m sorry to inform you that you are using the tool inefficiently, without exploring its full potential. It’s like using a screwdriver to hammer nails. It works, but there are much more efficient ways.
I believe the first point to highlight is: feedback should not be an isolated session. It doesn’t make sense to schedule a meeting exclusively for that. Huh? What do you mean, Manoel? Isn’t feedback a ceremony? Certainly not.
This format is a reflection of an orthodox, highly hierarchical model that forgoes several tools for control, setting expectations, coordination, alignment, mapping, risk monitoring, among other more modern tools. And, when a problem occurs, someone is sought to be held responsible.
“Feedback is the breakfast of champions.” — Ken Blanchard
Responsibility in the Process
In many situations, when an obvious error occurs, such as a NullPointerException reaching production, it is common to hear justifications that try to attribute responsibility to a single person. In one example, a coordinator justified that the implementation and delivery of the task had been done by an intern. However, by focusing solely on this explanation, responsibility ends up being shifted to the individual, without considering the failures in the process as a whole, such as the lack of proper follow-up by the team, code reviews that could have been more effective, or gaps in test coverage done by the QAs.
The problem in this case was not the intern, but the development steps that were neglected throughout the process. First, inadequate planning and the lack of a clear definition of requirements may have contributed to the problem. Next, the absence of effective code reviews — a crucial step to ensure quality and detect design errors before they are propagated — was also neglected. Finally, test coverage, which should have been a safety mechanism, was insufficient, leaving the code vulnerable to failures.
An intern, like any new team member, needs guidance and continuous support. Throwing an intern into a complex problem without the proper support and then blaming them when something goes wrong is neither a fair nor constructive approach. The responsibility for ensuring the intern has the necessary support lies with leadership and the team as a whole. Instead of focusing on finding someone to blame, the focus should be on identifying failures in the process and improving the training and support provided to new team members.
This type of problem could have been identified and prevented at several stages of the process, from planning to delivery. Practices such as better planning, continuous code reviews, and more comprehensive testing are essential to ensure the quality of the final product. The true cause of the failure is not in an isolated individual, but in the lack of adequate support and supervision throughout the entire development process.
It is essential that leadership takes responsibility for the success and development of the team, ensuring that everyone, including interns, has the necessary conditions to learn, grow, and deliver quality results. Ultimately, the responsibility for the team’s results lies with leadership, especially when failures occur.
This topic is crucial and could be explored in more detail in a future article about the importance of onboarding new team members and having an effective integration process.
“The world needs leaders” — JB Carvalho
The Difference Between Understanding and Applying
But, Manoel, then shouldn’t I ask for feedback, or as a manager, shouldn’t I share feedback? I’ve learned that, as a leader, I should provide constant feedback and have recurring conversations to offer this guidance.
The issue lies in the difference between understanding and knowing how to apply. I can understand concepts like nuclear energy, fusion, and fission of atoms, but building a reactor, ensuring safety, handling the problems involved, and putting all of this into practice is something completely different. It’s like starting a business and thinking that now I’m an entrepreneur. Although these things go hand in hand, one doesn’t guarantee the other.
First, comes the environment. By creating a safe space where people can express their opinions, you enable the necessary adjustments to achieve the goals. This helps to build an environment that fosters innovation. And, surprisingly, it is from this environment that practical solutions to complex situations filled with technical requirements will emerge.
Creating a Safe Environment
The first factor for a feedback culture to work is the creation of a safe environment, where leaders play a key role in cultivating this atmosphere. In this environment, feedback should be used continuously and constructively, without being seen as personal criticism. A safe environment does not mean the absence of mistakes, but rather the ability to handle them in a healthy and productive way. Instead of fearing mistakes, they should be seen as an opportunity for learning and growth.
In this context, true learning occurs not only based on our own experiences but also through the experiences of others, shared knowledge, and, above all, the mistakes we make and learn to correct over time. The process of trial and error, although often uncomfortable, is the engine of both individual and collective evolution.
“Feedback only works when it is given with the necessary care, where the goal is to help the person improve, not to punish.” — Kim Scott
Open communication is essential for creating and maintaining a safe environment. For employees to feel truly comfortable sharing their ideas, feedback, and concerns, it is crucial that leaders encourage a transparent flow of communication. This involves not only being clear and direct when giving feedback, but also actively and empathetically listening to the team’s needs and concerns.
In this way, an environment of open communication helps reduce the fear of making mistakes and fosters trust, creating a space where people know that their opinions and mistakes will be treated with respect and constructively.
“Effective feedback happens when we create a safe space, where vulnerability is welcome and people know they can grow from it.” — Brené Brown
In addition to open communication and continuous feedback, there are other tools that contribute to making the environment safer, such as a resilient approach to mistakes. Some of these tools include practices like ‘fail fast, fail cheap,’ error post-mortems, and approaches like those adopted by Google, which uses the concept of ‘blameless post-mortem.’ The focus of these practices should never be punishment, but always learning and continuous growth.
The Case of ‘Gemba’ and Toyota
At Toyota, there is a philosophy called ‘Gemba,’ which refers to the place where the work truly happens, such as the production lines. The idea is that problems are often better understood by those on the front lines, and Toyota has always encouraged its workers to share ideas, regardless of their position. This creates a culture where everyone has a voice.
In a real example that is widely discussed at Toyota, an assembly line worker (not an engineer or senior manager) noticed a small but recurring problem in one of the stages of the car production process. He observed that the machine was frequently malfunctioning, causing considerable delays. The problem seemed technical and complex, but instead of immediately calling an expert, he suggested that a simple adjustment in the position of one of the operators and a change in the sequence of activities could help minimize the errors. His suggestion was accepted, tested, and, surprisingly, had a significant impact on reducing the delays.
The important thing in this case is not just the solution, but how it reflects the principle of everyone’s participation. Even though he was a person with less formal technical qualification, the worker had the ability to observe and suggest a practical and efficient change that improved the process.
“The true leader is not the one who solves the problems alone, but the one who creates an environment where people can solve problems on their own.” — John C. Maxwell
The Leader’s Role: Balancing Proximity and Objectivity
Next comes the relationship. A good manager finds the balance between being present to get to know their team and maintaining enough distance to preserve objectivity, avoiding carrying the problems as if they were their own. There is always a chance to help someone recover by understanding what phase of life they are in. It’s unrealistic to expect someone who is taking care of a mother with cancer or a sick child in the hospital to perform at their best at work. Therefore, focusing solely on metrics in a fear-driven environment may lead to firing someone who just needs temporary support to get back on track.
When setting up a recurring agenda, like 1:1s, it’s not just to give feedback, address behavioral adjustments, or set goals, but also to get to know each other and understand where one can help the other. After all, there are times when leaders also need help. The key to a safe environment is proximity. Familiarity and increased trust come from being able to sit face to face and talk about anything: music, soccer, company or team goals, what you’re studying or reading, knowledge exchanges, etc.
I believe that, within a safe environment, people gain the maturity to listen and express what they think. This makes it easier when it’s time to be guided in a certain direction and hear what needs to be adjusted. A crucial point here is that feedback doesn’t become personal. It’s not about the person’s character, but about the absence or lack of a certain behavior. Character issues should be identified during recruitment.
Feedback needs to be given at the moment the event happens. There is a timing for it, which makes it easier to recognize the mistake and make the necessary adjustment. And for that to happen, it is essential that you are open to discussing it.
“Radical feedback is giving feedback with sincerity, but also with care, and always focusing on the person’s development.” — Kim Scott
Feedback at the Right Moment
Once, I participated in an online meeting and, in the heat of the moment, I made a joke without filtering it through reason. I don’t remember the exact context, but I remember the intention of being funny. I made a joke and, instinctively, I looked back to see if my wife had heard. It was at that moment that I immediately realized I had made an unfortunate choice with the joke, which, although unintentional, ended up being of a religious nature.
Right away, the manager I was working with sent me a private message via chat, respectfully and carefully alerting me that it was inappropriate to use a religious characteristic in a joking manner. He didn’t expose me in the meeting and spoke to me privately, with the respect and care the situation required. I acknowledged my mistake, reinforcing that at that moment I realized I could have offended my wife and felt bad about it. Yes, I also made mistakes, and learning from them is crucial.
My point with this story is twofold: first, as a leader, he didn’t wait for a ‘more appropriate moment’ to give me feedback. The right moment was that one. And, moreover, he gave me the feedback privately, without exposing me in the online meeting, which allowed me to reflect on the mistake in a constructive way. Not only did I learn to be more cautious with jokes, but I also learned the importance of giving feedback at the right time and in the appropriate manner. From that day on, I started to respect and admire even more the wisdom of that person, because I learned a lot just by observing him, both technically and as a leader.
“The biggest barrier to personal and professional growth is our own resistance to hearing what we need to hear.” — Marshall Goldsmith
Emotional Maturity
There is also the other side of feedback: the one who receives it. Emotional maturity is crucial in this process, as hearing that you did something wrong or that you need to improve is by no means comfortable or pleasant. The immediate emotional reaction may be one of defense or even resistance, but it’s important to understand that feedback is an opportunity for growth, not a personal affront. At this moment, the ability to listen openly, without interruptions, is essential to understanding the full message. Only hearing parts of what is being said and starting to counter-argue can create distortions about the intentions of the feedback and hinder learning.
Another crucial point is avoiding the temptation to self-justify. Feedback is not about justifying actions or decisions, but about recognizing the impact they had and how we can improve. Self-responsibility should prevail, and this doesn’t mean blindly accepting everything that is said, but rather being willing to reflect on what was communicated, unless there are external factors that weren’t sufficiently clear. In that case, it is valid to ask for clarification or discuss the situation constructively.
A useful tip is: take notes on the key points of the feedback while the other person is speaking. This helps to stay focused on what is being said, preventing the mind from starting to seek justifications or getting distracted. After the feedback, it is important to ask questions to validate what was said, seek more details, or request suggestions for improvement. After all, feedbacks that only point out what is wrong are often more critical than constructive feedbacks. Therefore, aligning them with ‘feedforward,’ or suggestions for the future, is an effective way to turn criticism into practical learning.
Feedforward is a technique that focuses on suggesting actions for the future, rather than criticizing the past. It is particularly powerful because it gives the person something tangible to work on, instead of simply pointing out failures. This makes it more useful for continuous development, as it provides a clear path for improvement.
“Feedforward is about suggestions for the future, not criticism about the past. It can be more useful because people can do something with it.” — Marshall Goldsmith
Informal Feedback
There are also scenarios where feedback happens informally. Throughout my career, I have often gathered feedback in a more spontaneous way, with the aim of validating or adjusting processes. One example of this was when I had the opportunity to act as a tech lead and wanted to apply XP practices, such as TDD and pair programming. To do this, I encouraged training sessions and gradually shaped the team’s culture.
At one point, I switched teams to replicate this model and encountered resistance from a senior developer, who was initially skeptical about adopting these practices. I had already successfully applied these methodologies in another team, and the results were clear: faster deliveries, with higher quality and fewer incidents. However, the resistance from this new member made me realize that, for there to be adoption, it was essential that he saw the benefits of the practice for himself.
After the adaptation process and after the first week of practice, during one of my 1:1s, this colleague opened up for an interesting conversation. He said something like: ‘I wasn’t really buying into the practice, but I paired with So-and-so, and he started asking some questions. Those questions made me reconsider the solution, and I realized that the design of what I delivered turned out much better than I expected. I also learned other things from him.
This conversation was informal feedback, but extremely valuable to me, as it confirmed that the practice was working, especially coming from someone who was initially resistant. This type of feedback is powerful because it doesn’t come in a forced manner, but as a genuine perception of learning and evolution. From that moment on, the team as a whole started to flow better in their deliveries, and the initial resistance was overcome by practical experience.
Conclusion
In summary, feedback should not be seen as an isolated evaluation tool but as part of a continuous growth process. For this to happen effectively, it’s essential to foster a culture of transparency and safety, where everyone can and should listen and speak openly. This includes building genuine connections and encouraging familiarity among team members, facilitating an environment of mutual trust.
The leader’s role is to cultivate this safe environment where feedback can be given at any time, constructively, with a focus on growth. It’s important to emphasize that feedback should always focus on the behavior or action to be adjusted, rather than a personal critique. The objective is always evolution and learning. For this to happen effectively, the way feedback is communicated is crucial. It must be delivered respectfully and thoughtfully, avoiding any form of aggression or unnecessary exposure.
Moreover, feedback is not just a correction of the past but also an opportunity for suggestions on how to improve in the future — known as feedforward. This continuous and constructive process helps to strengthen collective learning and collaboration, creating an environment where people are not afraid of making mistakes but are encouraged to evolve and seek solutions together.
Choosing just one book to highlight was truly a challenge, as all of them have been invaluable sources of inspiration and knowledge! If you’re looking to dive even deeper into these concepts and transform the way you lead and learn, click here to get your copy. Not only will you benefit from the ideas of these masters, but you’ll also be supporting the platform. Take this opportunity to invest in your growth!
