Specific feedback on performance, often in the form of "performance reviews", plays a central role in the further development of software developers. In this article, we show some practical examples of how to give – feedback to software engineers in various situations such as performance reviews, annual performance reviews or performance appraisals, i.e. in any form of one-on-one conversation and contact.
Why is feedback so important (and difficult) for software developers?
Motivating feedback for introverted software developers
Software Engineers are traditionally more interested in working with technical details than in working with other people. It can therefore be a challenge for managers to communicate feedback in an effective and motivating way, especially with more introverted software developers.
As a manager of DevOps software engineers, however, you must learn to communicate both positive and negative feedback in a constructive manner during one-on-one performance reviews so that the software developers are actually motivated to realize the development potential identified. The following examples of feedback in this article will help you with this.
If you're interested in a general introduction to regular one-to-one meetings, take a look at our post on the subject: A guide: 6 tips for successful 1-to-1 conversations.
Attention: Assess software engineers individually
For your information: Studies show that software engineers are traditionally more introverted. However, the trend is towards more diverse personality types among software developers. You should therefore always question and assess which personality type is sitting opposite you and communicate accordingly.
Source: Evolution of Software Engineers' Personality Profile
Questions & a survey for feedback discussions
Software developer performance review: typical questions
A note before I give you lots of examples, templates and phrases for your appraisal interview with the DevOps software engineer: Of course, in many situations it makes sense to lead by asking questions to first check the common understanding of the status quo – not only in the IT industry.
That's why I've put together a few questions for employee appraisals with software developers:
🎯 1 to 1 questions for software engineers: Focus
- What interrupts your concentration at work?
- When was the last time you experienced a state of flow at work? How easy is it for you to get into flow?
- When and how have you realized that you have exceeded your personal "work in progress limit"?
- What could we change to help you achieve an appropriate WIP in the future?
- How are the speeches in your team distributed? How do you reflect on your role in it?
- Who are our customers as a company and how does your work specifically contribute to meeting their needs?
- What are the things you want to learn when you think about your colleagues in the company and beyond?
🏦 1 to 1 questions for software engineers: Business mindset
- What is preventing us from meeting our customers' needs?
- What do you think of our business objective: is it easy to understand, comprehensible and motivating?
- How could we strengthen the link between your daily work and our business goals?
- How can we better enable you to contribute to our business goal?
Source with further questions: 100+ smart On-On-One-Meeting questions (for managers)
This should give you a good feel for how to approach such an appraisal interview intelligently. If you would also like a specific survey, I can provide you with an initial template or form.
Software engineer performance review: a survey
Corresponding surveys can help to make the development of DevOps software engineers measurable over time, independent of the fact if they are senior software engineers or rather junior.
However, they can also serve very well as an interactive basis for a joint discussion.
The following survey focuses on four different areas that are important to DevOps software engineers. These statements are usually rated on a scale from one (strongly disagree) to seven (strongly agree), for example.
🪞Employee interview survey: For software developers
- I scrutinize our work based on my understanding of our # team goals and the needs of our # customers.
- I proactively contribute to the continuous improvement of our team. #TeamPlay
- I know the challenges and problems of our # customers.
- My work tasks usually progress very quickly, even if external # feedback is necessary.
Note: This appraisal interview template asks for agreement to the Health Check items (questionnaire) on a 1-7 scale.
As you can see from the green button, you can even use this survey in our 1-to-1 meeting tool Echometer for free if you feel like it. We also have many more templates for questions and entire coaching templates and forms.
There is another article in our blog if you are interested in detailed templates for various one-to-one meetings (e.g. weekly, annual, 1-1 with difficult employees...): 15 proven 1-1 meeting templates to edit (free).
But now, further on in text –, we come to concrete examples and phrases for feedback to software engineers (those apply independent of the fact if they are senior software engineers or rather junior)
General template for feedback to software developers
Avoid classic feedback methods such as the feedback sandwich
Templates for feedback in one-on-one meetings are often based on the sandwich method. Please avoid this with software developers. The "talking around the bush" in performance reviews doesn't help anyone and DevOps software engineers in particular are often allergic to such methods (see: Criticism of the sandwich method for feedback).
Software developers usually realize when managers give generic positive feedback that it is just a tool to make the other person feel better.
Fortunately, that works better too.
Radical Candor: The feedback method that works better for software engineers
Instead of wrapping up your one-on-one meeting feedback with gobbledygook in a feedback sandwich, I recommend the Radical Candor method as the basis for your feedback template. Incidentally, it is not only helpful in the software IT industry, but also in the private sector – let's go deeper.
Radical Candor means giving as much honest and direct feedback as possible in appraisal interviews. At the same time, it also means showing empathy and keeping the other person's well-being in mind. Radical Candor shows that you don't have to choose one or the other: Either direct and honest, or empathetic and considerate. Instead, you can do both at the same time:
More under: What is Radical Candor?
Software developers will be grateful if you get straight to the point with negative feedback.
Feedback template for software developers based on Radical Candor
This template or form is based on the SBI model (Situation, Behavior, Impact). It helps you to communicate in a sincere, direct and yet appreciative way.
See also "Give Feedback Playbook"
Here are the instructions for the individual parts of the feedback template or form:
Feedback template part 1: Preparation in advance
Before giving feedback, take a few minutes to think through the following points:
- Situation: What situation are you referring to specifically?
- Behavior: What behavior did you observe from the person?
- Impact: What impact did the person's behavior have (on you and others)?
- Wish: What state would you like to achieve and why? (Note: This is not about directly wishing for a specific behavior – that is part of the measure (see below). Rather, it is about the wider context of why the impact is a problem for you).
- Action: What suggestions do you have for the person? What changes in behavior could bring us closer to the target state? What support can you offer?
It's best to write down the points briefly so that you don't forget anything during the conversation.
Feedback template part 2: Starting the conversation
Instead of starting with an elaborate one-on-one meeting feedback sandwich, you can now start directly with the situation as a conversation starter:
- "I wanted to talk to you about the situation when we ..."
Describe the situation and then ask:
- "Do you still remember the situation?"
Feedback template part 3: Behavior
Then you can address the person's behavior that you have observed in the performance review, which can be both positive of negative - you are not judging:
- "You shook your head at the situation and said..."
Before you talk about the effect, give the other person the opportunity to comment on your perception or memory:
- "Am I reflecting this correctly from your point of view?"
Give the person the space to describe their perspective on things. Try to leave both perspectives in the room without commenting on them. Limit yourself to substantive questions about the other person's perspective.
Feedback template part 4: Impact
Only in this part is it about discussing the effects of the behavior, saying that - in your perspective (!) - the behavior had negative consequences, for example. Still, remain as objective as possible at first:
- "My impression was that after you [observed behavior], the colleague Marc seemed very offended and was no longer willing to continue working cooperatively with us."
However, if the effects also affect you, it is important to share this too. Of course, you should always remain professional, but you can also show your human side:
- "I was also honestly embarrassed by the situation and found the conversation unpleasant from that point on."
Feedback template part 5: Wish
Express your specific request in this part of the appraisal interview:
- "It is important to me that we find a good basis for working with our colleague Marc again."
Put it into context again:
- "And beyond that, it is a great need of mine that we work together to ensure that we maintain good cooperation and relationships with all neighboring departments."
Also make reference again to relevant goals that explain why you have this desire:
- "Only through a good relationship can we achieve our goals as a team in this company. It is also important to me that we enjoy a good reputation as a team within the company."
Feedback template part 6: Measure
Before you present your own solution ideas, you can ask open questions in your one-on-one conversation:
- "I have a few ideas about this. But I'd like to hear your opinion first: How do you think we can achieve the goal?"
You can then share your ideas. Agree together on a binding and specifically defined follow-up. Put this in writing.
Feedback template part 7: Rejection
Ask whether the appraisal interview was helpful for the other person and whether they have any unanswered questions. Arrange a check-in for the next time you will talk about the topic.
Show your appreciation for the open conversation and thank the person for their insight and cooperation.
Feedback template part 8: Reflect on your feedback retrospectively
At the end of every feedback session, you should ask yourself the following question:
- Honesty: Have I shared my feedback honestly and as unvarnished as possible?
- Appreciation: Does the person feel valued by my feedback?
If you can answer all the questions with "yes", your feedback interview went very well. If not, don't worry. Reflect on how you can formulate things differently in the future. And again, most of these tips don't just apply to the software IT industry.
At this point, I would like to point out that there is of course also software for simplifying feedback discussions and longer-term coaching of software developers.
Our one-on-one meeting software offers you various templates and forms for employee meetings with DevOps software engineers and even makes employee development measurable. Take a look at our tool and try out the following template:
1:1 Meeting Tool Template: Mood as weather
- If you had to describe your emotional state as the weather, how is the weather in your project or your tasks at the moment?
How is the weather in relation to your employer, your personal life and your private life?
1:1 Meeting Tool Template: Mood as weather
- If you had to describe your emotional state as the weather, how is the weather in your project or your tasks at the moment?
How is the weather in relation to your employer, your personal life and your private life?
Now let's get started with the help of this appraisal interview template or form and run through a few practical examples!
Examples of feedback to software developers in one-on-one meetings
Example feedback to software developers in 1-to-1 meetings: Code quality
With Tanja 👩🏼🦰 in the role of team lead and Marc 👨🏽 in the role of employee.
Describe the situation
👩🏼🦰
Tanja (Team Lead): "In our last code review, we looked at your pull request to implement the new feature in the dashboard. The code was functionally correct and met the requirements."
👨🏽
Marc (employee): "Yes, I remember!"
Observed behavior
👩🏼🦰
"I commented on passages that were quite complex and difficult to read. For example, there was a method with over 50 lines that combined several responsibilities. However, you only commented on this comment superficially and didn't go into it any further."
👨🏽
"To me, the comment sounded like an optional suggestion. It seemed too time-consuming to change the solution again."
Impact
👩🏼🦰
"Anyway, your comment made me a bit frustrated to be honest and instead of insisting on a fix from you, I just improved the method myself afterwards because I was already thinking about the code anyway."
👨🏽
"Oh, I didn't realize that."
Goal and desire
👩🏼🦰
"Our common goal is to ensure that our code is not only functional, but also maintainable and easy to understand for everyone."
👨🏽
"That's exactly how I see it!"
Action items
👩🏼🦰
"What is your suggestion on how we can improve the quality of the code more smoothly in such cases in future?"
👨🏽
"It would help me if it were easier to see in the comments whether an improvement is only being suggested or demanded."
👩🏼🦰
"Well, let's do that – I'll include that in the team meeting again. But I still think you need to follow up on your side as well."
👨🏽
"How about we go straight into pair programming together for the next topic so that you can sharpen my understanding of code quality requirements again?"
Conclusion
👩🏼🦰
"That sounds like two good follow-ups! Then let's keep it that way. I'd be happy to set a date in my calendar for the middle of next week to start pair programming."
👨🏽
"All right, I'm looking forward to it!"
Example feedback to software developers in 1-to-1 meetings: Ownership
With Tanja 👩🏼🦰 in the role of team lead and Marc 👨🏽 in the role of employee.
Describe the situation
👩🏼🦰
Tanja (Team Lead): "Marc, I want to talk to you about the last task where we developed the new feature for the export process. The feature is now live, but there were some challenges along the way."
👨🏽
Marc (employee): "Yes, I remember. What exactly do you mean?"
Observed behavior
👩🏼🦰
"I noticed that there were several long delays after the code was handed over for testing. For example, some comments from QA colleagues were not answered for days. It also happened that I had to remind you twice about a missing review."
👨🏽
"Hmm, I see. To be honest, there was quite a lot going on and I thought the testing would continue in parallel."
Impact
👩🏼🦰
"The result was that we had to postpone our deployment because of this issue."
👨🏽
"Oh, I didn't even realize that. I thought you'd get in touch if something was urgent."
Goal and desire
👩🏼🦰
"Our aim is to minimize unnecessary delays and for developers to adopt an ownership mindset during implementation. This means that everyone actively ensures that their ticket gets through from start to finish – and that also includes communication with QA."
👨🏽
"I understand what you mean. I definitely want the processes to run more smoothly."
Action items
👩🏼🦰
"From your perspective, what could we do so that you can act more proactively and show ownership in such situations?"
👨🏽
"I think it would help if we set clearer expectations, for example that I do a daily check-in on open issues during the testing phase. That way I can make sure that nothing is left undone."
👩🏼🦰
"That sounds good. And I would suggest that for the next major tasks after the code is completed, you make a brief plan of how you want to see the topic through to the live launch. You can show the plan to me or a QA colleague."
👨🏽
"Agreed. Then I can keep a better eye on things myself."
Conclusion
👩🏼🦰
"Great. Let's record the two measures like this: You do daily check-ins during the testing phase and plan to follow up on your next major task. Is that feasible for you?"
👨🏽
"Yes, that fits. I'll put it straight in my calendar."
👩🏼🦰
"Great. I'm sure that will make a big difference. In our next one-on-one meeting, we'll take another look at the status of our measures. Thank you!"
Examples of feedback to software engineers in the performance review
A note: Traditional performance reviews tend to be unpopular with both software developers and managers, and many argue that good one-to-one meetings are sufficient and should replace performance reviews. See: "Performance reviews are pointless and insulting" by Forbes.
However, performance reviews are often still a predetermined format within the company. Of course, this should not stop you from conducting performance reviews as a dialog at eye level with your employees instead of limiting yourself to making top-down assessments. The following examples of a one-on-one conversation show how it can work.
Note: As mentioned, templates for performance reviews can of course help to communicate feedback constructively. The following blog post may help you if you are more interested in the topic: 5 templates for regular employee check-ins.
Example feedback to software engineers in performance reviews: Team Work
With Tanja 👩🏼🦰 in the role of Team Lead and Marc 👨🏽 in the role of Software Engineer.
Describe the situation
👩🏼🦰
Tanja (Team Lead): "When I had to rate the point 'Team Work' in your performance review template, I was unfortunately only able to give you 5 out of 10 possible points. I would like to explain this to you to give you a fair chance to improve on this point."
👨🏽
Marc (employee): "Oh, okay. Please help me understand."
Observed behavior
👩🏼🦰
"I've noticed that there have been situations in recent months where collaboration with the team has not been optimal. For example, in our last sprint there were several cases in which you worked on tasks alone, although they could have been better solved together with others. One specific example was the integration of the new API. We had considered having you and Alex work on it together, but you took on most of the steps alone and only involved Alex minimally."
👨🏽
"I thought it would be more efficient to do it quickly myself. I didn't realize that this was seen as a problem."
Impact
👩🏼🦰
"However, this led to a loss of transparency in the team. Alex later had difficulties getting involved in related tasks because he didn't know exactly how the API was set up. I also got feedback from other team members that they sometimes didn't feel involved enough and found it difficult to get support from you when they had questions."
👨🏽
"That surprises me, to be honest. I thought I'd help out when I was asked."
Goal and desire
👩🏼🦰
"Our aim as a team is not only to work efficiently, but also to share knowledge and involve everyone. This strengthens collaboration and ensures that we can all represent each other. I would like you to make more use of your role as a knowledge carrier in this team in future to actively share knowledge and empower other team members. Team productivity is more important than individual performance."
👨🏽
"Okay, I understand what you mean. I think I've just been too focused on my own productivity so far."
Action items
👩🏼🦰
"What could help you pay more attention to involving the team in your work and sharing knowledge?"
👨🏽
"I could get into the habit of clarifying who can work on larger tasks and how right at the start. Maybe we can also establish something like a kick-off for tasks to agree on the rough architecture decisions and identify tasks that someone else should do alone or that we should even do in pair programming."
👩🏼🦰
"That sounds good. I also had an idea: how about you get into the habit of not only reporting progress at our weekly team meetings, but also actively providing insights into the code and architectural decisions?"
👨🏽
"That's a good point. That could help to make it easier for our inexperienced colleagues to work on my code later."
Conclusion
👩🏼🦰
"Great. Then we'll record the follow-ups in our template for the performance review:
- From now on, you will proactively share your knowledge and architectural decisions with the team in the Weeklys.
- From now on, you will kick off your topics with another developer so that you can work out the solution together and divide up the implementation."
👨🏽
"Sounds good."
👩🏼🦰
"OK. I would make a note of both measures for a review in two months' time. Then we can discuss the status in our one-to-one meeting and see how we proceed."
👨🏽
"Yes, and then let's also see if you can't improve your 'teamwork' score. I'd like to get at least an 8 out of 10."
👩🏼🦰
"I'm glad to hear that! I absolutely believe that's realistic and will support you where I can."
👨🏽
"Thank you!"
Example feedback to Software Engineers Performance Reviews: Ownership
Let's move on to the next example of a one-on-one conversation, which is about feedback to the software developer on the topic of ownership, something that Junior Engineers probably struggle more often with than Senior Developers. Still, it can have very negative consequences, so you should be giving potentially rather negative feedback on this rather early.
As always with Tanja 👩🏼🦰 in the role of Team Lead and Marc 👨🏽 in the role of Software Engineer.
Describe the situation
👩🏼🦰
Tanja (Team Lead): "When I had to rate the point 'Ownership' in your performance review template, I could only give 6 out of 10 points. I would like to explain why this is the case and give you the chance to develop further in this area."
👨🏽
Marc (employee): "Wow, that surprises me a little. After all, I've worked on more topics than almost anyone else in the team. Please explain it to me."
Observed behavior
👩🏼🦰
"In recent months, I have noticed that there are often delays in your tasks. There are several examples where QA comments or code reviews from you have gone unanswered for a long period of time. As a result, your topics only went live after weeks of delays. One specific example was bug fixing for the export. You only answered feedback from QA after repeated requests, and it took a total of three weeks for the changes to go live."
👨🏽
"Yes, I remember. I was working on two other topics at the same time and didn't get around to entering the feedback that quickly."
Impact
👩🏼🦰
"This had an impact on the velocity and productivity of the entire team. QA had to follow up several times, which tied up their capacities. The release plan also had to be postponed. In addition, it feels as if you are not taking full responsibility for the completion of your topics, which puts a strain on the team dynamics. Some team members have told me that they feel unsure whether they can rely on you for dependencies."
👨🏽
"Oh, I'm sorry about that. I wasn't aware of that. I tried to do the tasks in parallel, but apparently that didn't work out so well."
Goal and desire
👩🏼🦰
"My goal is for you to focus on fewer topics, but to take full responsibility for each task from start to finish. This means that you not only write the initial code, but also ensure that QA feedback is processed promptly and that the topic stays on schedule. In this way, we can avoid tasks remaining open for longer and blocking others."
👨🏽
"That makes sense. I often felt overwhelmed because I had too many topics at the same time. Maybe it really is better to concentrate on fewer tasks."
Action items
👩🏼🦰
"How could we get you to focus on a few topics and take responsibility for implementing them fully?"
👨🏽
"I could try to limit myself to a maximum of two topics per sprint and never work on more than 3 topics at the same time. I should also block fixed slots in my calendar to work on comments and reviews regularly so that nothing gets left undone."
👩🏼🦰
"That sounds sensible. In addition, I think it would be good if you proactively ask for help in our stand-ups if you are working on too many topics at the same time. There should usually be someone who can take over a topic from you."
👨🏽
"OK, fair."
Conclusion
👩🏼🦰
"Let's set these measures as a goal for the next two months:
Less work in parallel:
- You take on a maximum of two topics per sprint and do not work on more than 3 topics in parallel.
- Demand active support from the team in stand-ups
- Fixed slots in the calendar to work through comments and reviews."
👨🏽
"That sounds realistic. Let's do it that way."
👩🏼🦰
"Great. We can see in two months' time in the Performance Review whether these measures have worked and whether we can raise your rating in the Performance Review for 'Ownership' again."
👨🏽
"Thank you, Tanja. I'll do my best to put that into practice. I used to always get top marks for 'Ownership'. Do you think I'll get there again by the next performance review?"
👩🏼🦰
"I'm pleased about that. Yes, I believe that a rapid improvement is absolutely achievable with these measures. Let's discuss the status and whether you need support in our bi-weekly one-on-one meetings."
👨🏽
"Thank you! Yes, I would be delighted if we could achieve a noticeable improvement here within a few weeks!"
Examples of feedback to software developers in the annual review
If you already have regular one-on-one meetings or performance reviews with your developers during the year, you probably no longer need detailed annual meetings. The exchange on performance, feedback and further development should already be an ongoing dialog. Having regular conversations makes it way easier to give "negative" feedback comments and get into a continuously improving flow, because you will have a better relationship with each other:
Nevertheless, there are companies that require a classic annual appraisal.
💡
If, as a manager of software developers, you already have regular 1:1 meetings or performance reviews, the annual review should only be a formality:
The software developer should already be aware of the feedback and should already be working on development potential.
So if you, as a manager of DevOps software developers, have to fulfill the formality of an end-of-year meeting (possibly in addition to regular one-on-one meetings), let's also go through an example of an annual performance review with a software developer.
By the way, another tip at this point: If your first one-to-one meeting with a new employee is just around the corner, I can recommend our article on this: 5 tips for one-to-one meetings with new employees.
Sample agenda, template or form for an annual meeting with a software developer
Review and performance
Successes: Which projects or tasks went well? Where were expectations exceeded?Challenges: What didn't work so well, and why? How can these challenges be overcome in the future?Reflection: How does the developer himself see his performance? What feedback does the team or the manager have?
Cooperation and team culture
Communication: How is cooperation within the team and with the manager perceived?Working atmosphere: Is there potential for improvement in the team culture or working environment?Feedback on leadership: How can supervisors better support developers?Feedback from the developer: Are there any suggestions for improving processes, tools or work culture?Work-life balance: How do you feel about your current workload? Are there any overtime or stress factors?Resources: Are the tools, processes and framework conditions sufficient to work efficiently?
Competencies, goals and development
Strengths: What technical, methodological or social skills characterize the developer?Further training: What new technologies or skills does the developer want to learn? Are there any relevant courses, conferences or projects?Career goals: What position or responsibility is the developer aiming for in the medium to long term? Which steps lead there?Project focus: Which projects or technologies would the developer like to work on more intensively?
Compensation
Performance-related remuneration: Is there a need to adjust salary or bonuses?
Conclusion
Short-term goals: What specific goals should be set for the coming year?Agreements: What are the next check-ins for the respective measures?
The following is a typical example of feedback within an end-of-year review or annual performance review: The employee's request for a role change.
Example feedback in the annual meeting: Desire for role change
With Tanja 👩🏼🦰 in the role of Team Lead and Marc 👨🏽 in the role of Software Engineer.
Entry and situation
👩🏼🦰
Tanja (Team Lead): "Marc, it's great that we can talk about your annual feedback and your goals today. Are there any specific topics that are particularly important to you?"
👨🏽
Marc (employee): "Yes, I have been thinking about my further development. I could imagine developing in the direction of software architecture. I've been interested in the subject for a long time and I'd like to get more involved with architecture decisions and strategic technology management."
👩🏼🦰
"That's exciting, Marc. I'm pleased that you have such clear goals. Let's talk about how we can prepare you for them. There are a few points where I think you need to develop further before we take the next step."
Give feedback
👩🏼🦰
"First of all, I would like to emphasize that you have made a lot of progress this year, especially in the quality of your implementations and in dealing with new technologies. You have also shown that you have an eye for the bigger picture, for example with the introduction of the new caching system."
👨🏽
"Thank you, I'm glad to hear that!"
👩🏼🦰
"When I think about the role of a software architect, however, there are still some requirements that I don't believe are currently fully met. For example, communication with the team and involving others in technical decisions is a key component. I still see potential for you there. You often make decisions independently without involving the team early enough."
👨🏽
"Okay, I understand that. I didn't want to hold anyone up sometimes, but I can see that it's not ideal for the role of architect."
Goal and desire
👩🏼🦰
"Exactly. A software architect is also a coach and communicator. It's about getting others on board, communicating technical concepts and developing solutions together."
👨🏽
"That makes sense. I also realize that I can't yet communicate my thoughts on architecture as effectively to my team members."
Plan measures
👩🏼🦰
"I think we can work together on this so that you qualify for the role in the next 6 months. How about we define specific measures?"
👨🏽
"I'd love to. What do you have in mind?"
👩🏼🦰
"Above all, I would like to see you moderating the decision-making process for the software architecture instead of making the decision yourself. How about moderating an architecture kick-off for each of the next major topics? The aim would be to support colleagues in the decision-making process and then let them implement the solution themselves."
👨🏽
"That sounds good. I'm learning to exert my influence as a coach instead of implementing everything myself."
👩🏼🦰
"I can also imagine that there are good courses to prepare developers for the role of software architect. In addition to the hard skills, these courses will certainly also cover the soft skills required for the role"
👨🏽
"Yes, I've actually already picked out a course."
Conclusion
👩🏼🦰
"Great, then I'll make the following notes for our annual meeting:
- Development goal: Software architect
- Action items:
- Moderation of architecture kick-offs in a team
- Participation in a course for software architects
Of course, we talk about these topics continuously in our one-on-one meetings, but the next official check-in would be at our performance review in three months' time."
👨🏽
"Sounds good. We should have achieved a lot by then."
👩🏼🦰
"I think so too! In the meantime, if you can think of any other things I can do to support you in this matter, please feel free to contact me at any time."
👨🏽
"Can we talk about my intended role change again in three months' time?"
👩🏼🦰
"Sure, of course I can't promise you anything when it comes to changing roles. But I have noted your wish and will try to support you as best I can."
👨🏽
"Thank you!"
Conclusion: Motivating feedback for software developers
The examples and templates show that it doesn't have to be that difficult to give motivating feedback to software developers in one-on-one meetings and end-of-year meetings, right? Remain authentic and benevolent, don't beat around the bush and show that you are interested in a joint solution.
If you manage to implement "Radical Candor" in your appraisal interviews and beyond by showing appreciation and honesty, the reaction may even be more positive and constructive than you think.
Good luck for your next feedback meetings!
And if you like hacks that make your life easier, I recommend our Echometer software. You can try it out completely free of charge.
Our one-on-one meeting software offers you various templates and forms for employee meetings with DevOps software engineers and even makes employee development measurable. Take a look at our tool and try out the following template:
1:1 Meeting Tool Template: Mood as weather
- If you had to describe your emotional state as the weather, how is the weather in your project or your tasks at the moment?
How is the weather in relation to your employer, your personal life and your private life?
1:1 Meeting Tool Template: Mood as weather
- If you had to describe your emotional state as the weather, how is the weather in your project or your tasks at the moment?
How is the weather in relation to your employer, your personal life and your private life?
