Practice is everything, right? Actually not. Practice doesn’t make perfect if to practice the same wrong over and over again. 

We often believe that the more we do something, the better we will be at this over time. But it doesn’t work this way. Time spent on an activity doesn’t automatically translate into improvement. 

That’s why constructive feedback is one of the best things in the world. And one of the most important. Studies show that a feedback culture, where employees feel comfortable sharing and receiving comments about their work, breeds productivity. It entails careful preparation to not just swap likes and dislikes, but also course-correct the selected development trajectory, create a clear action plan, and set professional growth objectives. But here's the key: people don’t like to receive feedback that is more negative than their view of themselves.  

So how to give feedback to your developers and, at the same time, not to scare them off? For you to be on the right track, we at Svitla have featured major characteristics of a constructive feedback, things to avoid, one-on-one essentials and whatnots. 

Value of Feedback

Constructive feedback for software engineers fosters effective communication when all participants know what to expect and how to achieve objectives. This tool helps all teammates align their efforts and serves as a great driving force. 

When used correctly, it motivates to progress, engages in the project and encourages to innovate. The outcome is a timely and accurately delivered project, and consequently – happy clients. 

To reveal this power, developers should be ready for giving feedback to their team members and Team Leads too. The thing is, the supervisors cannot be the only praisers or critics, as otherwise, the feedback will be too subjective and one-sided. Also, feedback for junior developer is a very important thing to make his/her work more productive and effective. Junior developers are usually very highly motivated and timely feedback increases their  motivation even further and drives them to work even harder.

To make it work, you need to initiate regular check-ins. For better effect, try to make short intervals between them and ensure your feedback for developers is logically structured with both corrective and positive points in place. They all should be based on facts, not guesses, which is why keeping everyone’s performance visible may be a good idea to follow. Knowing successes and weak points of each other, teammates are more likely to exchange their experiences.

Giving Constructive Feedback: How, When, What

So, is there any kind of method on how to give feedback to a software engineer? The effective formulas for providing insightful feedback in the workplace are numerous, and the SMART method is among them. This abbreviation often interpreted as ‘specific, measurable, achievable, realistic, and timely.’ These are the quality metrics for the feedback to be fact-based and clear. You can use SMART as a how-to-deliver-feedback guide.

Specific. The more you focus on particular actions and examples, the better. It helps sound straight to the point and avoid inconsistencies. Being specific also means that the impact of any action should be clarified. It is important to do it based on your own observations rather than on someone’s judgments. In such a way, your software engineers will be well aware of what to correct, how to do it, what results to achieve, or what behaviors to pursue.

Measurable. Giving measurable feedback stipulates that some quantifiers should be applied. In other words, if you want to understand whether the goals were reached or not, the results should be easy-to-evaluate.

Achievable. Ensure the objectives can be achieved by the employee, though leave a free space for the challenge. This encourages an employee to endeavor to reach the goal while they make sure their efforts bring them closer to finish. Achievability also presupposes the availability of the required information, tools, knowledge, and skills.

Realistic. Every developer needs to feel that their role contributes not just to the project, but to the company as a whole. That’s why all objectives should be aligned with the overall strategic objectives of the software development company. Otherwise, people become demotivated, and their efficiency and job satisfaction plummet.  

Timely. This characteristic speaks for itself: all objectives should be tied to deadlines. When defining due dates, check whether they are tied to any other deadlines and select them based on that. Make sure they allow for better progress measurement and simplify it.

Briefly, effective feedback defines what to accomplish (objectives), how to do this (action plan), when to implement (realistic due dates), how to measure success, and what is meant under success, actually.

This formula fits one-on-ones perfectly. However, there are a few more things you need to take into account prior to scheduling the meetings.

Holding Effective One-on-Ones

Conducting one-on-ones requires some knowledge of psychology. As Team Lead or Project Manager, you need to keep your emotions, tone of voice, and facial expression under strict control no matter what is to be discussed. 

People Managers advise starting the conversation on a high note by giving performance appraisal to eliminate stress and tension and let the interlocutor speak out too. The latter also encourages a developer to find a better solution on their own. This is a good way to introduce constructive criticism without making an employee feel confused.

But is constructive criticism so crucial? The answer is yes. Despite the fact that giving positive feedback to team members motivates them to perform better, pointing out mistakes is also essential. It helps make things function well and better track progress comparing past and present achievements. 

Thus, highlighting even minor issues shows what needs fixing and advocates people’s growth. So balancing positive and negative feedback is critical, indeed.

When coming to the end of the one-on-one meeting, check whether you have reached an agreement on the desired outcome. It is never redundant to do so. 

Things to Pursue and Avoid When Giving Feedback

For you to dive deeper into the do’s and don’ts of how to provide feedback to team members, we have summed up the most popular ones for you.

Things to pursue:

Making expectations known in advance. We recommend having them documented and shared with dev team in advance. Even when communicated verbally, they help guide your team’s decisions.

Sharing feedback instantly. The bigger the delay in delivering feedback to teammates, the more important details get forgotten. Feedback is valuable when shared on the spot.

Thinking and planning ahead. Get into the habit of thinking long-term, not just with respect to the employee performance on the current project. It will enable you to plan your team career development better and positively impact the retention rate.

Things to avoid:

Giving no chance to respond. It is not only you who can speak during retrospectives or one-on-ones. Your team members should speak first and come up with some corrections or suggestions. Otherwise, they would feel underestimated.

Not agreeing on the action plan. If you tend to make this mistake, then exchanging feedback has little sense. Right after the feedback session is complete, you should devote some time to discussing the action plan. This way, you will act in sync and prevent any misunderstandings.

Focusing on the achievements of other developers. It is a taboo. Comparing to others causes rivalry instead of a smooth teamwork. 

Takeaways to Share

Providing constructive feedback to employees directly impacts their performance improvements. It may turn to be rather challenging, especially when you need to motivate high-achievers. But when feedback loops are made short with a focus on deeds rather than intentions, you are doomed to succeed. Here are a few more takeaways to help you run one-on-ones smoothly and deliver feedback in the best way possible:

• When sharing feedback, avoid mentioning the names of those being concerned about the job performed by the employee.
• Initiate one-on-ones to make the team member ready to receive the feedback from the peers.
• Create a favorable environment for continuous feedback with a brief and handy feedback log.
• Ensure the feedback you pass on has no personal preferences.
• Avoid giving feedback just for the sake of it.

Please keep in mind that every piece of feedback for a developer is valuable for the software development process. If your feedback is given on time, with precise information, consistency, necessary technical details, and descriptive use cases, it will definitely help to achieve better results.