Lesson 1, providing feedback. Hello and welcome to our content on turning around poor performers and failures. By the end of this module, you'll learn how to provide feedback, how to manage disagreements, conflicts, and escalations, and how to receive and assign corrections of errors or abbreviated COEs. At the start of this specialization, we share 10 common engineering manager interview question. The following content helps you answer these questions. One, who is your worst hire and why? Two, how did you handle poor performance and three, tell me about a time you managed a conflict. Fergus Henderson, who is a staff software engineer at Google, writes about software engineering at Google. Regarding poor performance, he writes "Poor performance is handled with manager feedback and if necessary, with performance improvement plans, which involves setting very explicit concrete performance targets and assessing progress towards those targets. If that fails, then termination for poor performance is possible." As an engineering manager, how should you think about addressing poor performance on your team? First, as a manager who is responsible for a team, your priority is the growth and accomplishments of the team as a whole. One obstacle to your team achieving its potential is that one or more poor performers on your team. You might have already spent a lot of time and effort recruiting an engineer onto your team who turn out to be a poor performer. Alternatively, this might be a longtime engineer who used to do really well, but for some reason has declined recently in their productivity. Either way, other members of your team might have started raising concerns about how they're having to pick up the poor performers' duties in addition to their own and that this is unfair to them and they're right. As a manager, you should expect that every team member should be able to keep up with the rest of their team and contribute meaningfully and you should communicate your expectations to the poor performer through manager feedback prior to resorting to performance targets or considering termination. What does effective feedback look like and how can you get into the habit of delivering effective feedback? Effective feedback has the following three characteristics. Number 1, your feedback should be specific and direct. Your feedback should enable your engineer to understand exactly what they did in a particular situation and the impact it had on others. Number 2, your feedback should be actionable. Your feedback should indicate the different actions or choices available to the engineer. Why the choice they chose was incorrect, and how to make a better choice in a similar situation in the future. Two examples of real feedback I've heard deliver on other teams in the last week that is neither specific nor direct nor actionable are "Well, you're just not that good" and "Well, this document is largely a redo." Both examples of ineffective feedback because the manager delivering the feedback was unable to articulate what was specifically wrong and how the person should fix it next time. You should see how feedback is not actionable because it doesn't necessarily help the engineer improve. Next time if you're attempted to give feedback to someone like, well, you're just not that good, stop yourself and ask what choices did this engineer make that caused you to think that they weren't that good? What choices what I like this engineer to make, in a similar situation in the future. Then communicate your answers to those questions as your feedback to your engineer. Number 3, feedback should be timely. You should deliver your feedback as close to the time of occurrence as practical so that it feels relevant to the recipient. For example if you're in a meeting and an engineer behaves inappropriately or says something that is wrong, you can immediately cut them off, redirect the conversation. Or if the issue is not of critical importance, direct message them on Slack. The faster your engineer receives that feedback, the faster that they can course correct. Also, if your feedback is not timely, your engineer might have forgotten about what they did already, then the engineer might become confused about your feedback or might simply deny that the event happened at all or that your feedback is necessary because they honestly forgot about the event. Feedback does not need to be goal-oriented. Some manager training materials tell managers that effective feedback should be goal-oriented, meaning that the feedback should mention your engineer's goals. Goal oriented feedback sounds like this. "Hey, during the meeting, you kept interrupting your teammates, please stop interrupting your teammates if you want to remain on this team." In this case the employee's goal is to remain on the team. My personal opinion is that software engineers in companies like Amazon, Microsoft, and Google are some of the most intelligent people in the industry. Your feedback doesn't need to be goal-oriented. For them to understand its important and constantly talking to an engineer about her goals is patronizing, and might raise more questions than the answer. However, you might encounter one or two engineers during the course of your career who are simply oblivious and don't understand why your feedback is helpful to them. In these cases, you might need to make clear to those engineers that following your feedback can help them achieve career goals on your team. As we've discussed, you should treat members of your team as individuals. Each engineer who reports to you, has different backgrounds and life experiences. Some of them might react to feedback in a manner differently from how you expect or want them to react. For example they may become defensive, start blaming someone else, wave away the feedback, or even tell you, worst-case that they don't care. They might be so self-confident that they simply ignore the feedback. They might respond to the feedback very seriously and then immediately go back to doing the things you told them not to do. In extreme cases, they might become traumatized by the feedback and start avoiding contact with you. All of these examples, are signs that you need to create and strengthen a feedback culture within your team. A feedback culture helps team members feel empowered and safe to deliver and receive effective feedback to each other. One way to quickly foster a feedback culture is during meetings with your team to show the results of your team's surveys of your own performance. You can say something like "This week the team reported that whether workload was manageable on a scale of 1-5, the average response was a three. Therefore, I would like to hear feedback about the workload. Who has ideas on how I can earn a better score on this question the next time that is asked. I'd like to hear from at least two team members." Then as you collect input and ideas, start implementing some of the good ideas. By showing that you are receptive to feedback, you normalize a culture of feedback for everyone on your team. Other ways to strengthen a culture of feedback include set expectations, that feedback is normal. You can talk about the benefits of regular feedback and the expectation that it had always been part of the team's usual way of doing business. Better yet, frequently solicit feedback yourself and ask other leaders, like your tech leads to do the same. Two, encourage both positive and constructive feedback. Make it a habit to find genuinely good things about your employees. When positive feedback is provided regularly, it could make the negative feedback more credible and also less threatening. Three, deliver feedback frequently on a schedule. Natural times to deliver feedback are during weekly one-on-ones, daily stand-ups and the starting and ending sprint meetings. Make sure to use these times to provide both positive and negative feedback to either deep dive during a one-on-one, or to spread your expectations to the entire team during team meetings. Sometimes you'll notice that some engineers have different communication preferences than others. For example some might prefer to receive all their feedback in Slack, while others might want to speak to you in person. To the extent that you're able it's always a nice touch to respect different communication preferences among your team. Now, let's talk about an important and often overlooked part of giving feedback.
