Giving feedback when people are doing well is easy. But it gets difficult when it is actionable. The fear of losing respect, or the "friendship" with the engineer makes the manager silent in fear of how the engineer will react.

Managers imagine engineers leaving because they got mad about being given feedback, which rarely happens, assuming that you are hiring mature people.

Feedback lifecycle - Make sure you have the right rationale

Trust

There is no healthy work relationship without trust. It is wrong to assume that your report has malicious intentions unless proven otherwise.

If you accuse your report it means you don't trust them, which means there is no future in the company for them because they will feel that you will be hindering their growth.

You also will need to trust that they are mature enough to receive feedback. Probably the person is not even aware the problem exists at all, they could have come from a different background or are not used to seeing things from that perspective.

Don't spread gossip. You can't defend a point of view that you are not sure you even believe in or were there. You will need to own the feedback given or encourage whoever talked to you about it to reach out directly. Doing otherwise might be seen as "taking sides".

Investigating the problem

Before having "the talk" it is best first to check if the problem exists.

For example, if you feel or receive feedback that an engineer is underperforming, first check this person's deliverables. In this case, an investigation could start with:

• If they are slow at shipping, check their commits, the cycle time between receiving a ticket and completing it, and the effort behind those, and compare to the deliveries of their peers.
• If the code quality is low, check the time stuck in PRs, and incidents related to their PRs.
• If the communication is faulty, check meeting attendance, and time between work hours replies (respecting their focus time and time zones).

Scheduling the talk

The best thing to do is talk about it in a 1:1 as soon as possible. A meeting of 30 minutes is enough to clear the air. If one won't happen soon, it's better to schedule right away.

The more you wait, the more likely this person tends to form a habit, if this affects others they will think the company has a lower bar and they will probably get angrier at this person and you for not acting on it.

Some managers are perceived to be "assholes" when giving feedback because they get emotional about repeated bad behavior, the same behavior that the report isn't even aware of.

Give feedback in private. If you give in public people will assume that the person receiving the feedback is incompetent and that you are that kind of a boss. They will be afraid to be publicly embarrassed by you. People leave after being publicly scolded and I don't blame them.

The talk - getting to the root cause

With the problem that is happening, now it's necessary to dig into the root cause.

Breaking the ice

Start by asking questions, to understand their perspective first.

Good questions allow pushing towards a point that can help get into the conversation, let's say the conversation is because you feel this person is no longer motivated, questions like:

• Are you happy?
• Do you feel motivated in this actual job?

They are bad because they can simply be answered with a yes/no, and it will be necessary to ask more questions. The conversation will feel more like an interrogation, and the report will feel that you have a hidden agenda.

Ask those interesting questions instead:

• How are the last months here on the team going for you?
• How are you feeling lately about the product we are doing?

Here you are showing you care for their point of view, and help get to the point of the conversation.

If the problem is troubling them as well, they will mention it. If so, the conversation gets way easier because they will get into the root cause already!

Discussing the problem

In order to not miss the mark, have the problem stated and discuss it before moving to a solution. Give examples, and be brief don't talk too much, one example of how to deliver would be:

I observed (examples),
and this creates (problem).
Therefore I want to ask what we can do
to avoid that happening in the future

That is it. Don't make speeches, or play an attorney/prosecutor. Talking too much makes people more likely to miss the point entirely.

Also, don't sugarcoat the problem, patronize by making excuses for them, or be aggressive, keep the emotions out of it..

Dialog loop

Hear them, it is more important to listen at this point, as the conversation will most likely enter a loop on those states:

• They will be confused about why this is a problem, and if this happens pinpoint what is the exact problem. If they don't feel that is a problem you can tell them how this negatively affects the team.
• They will ask questions, to gather more details, you can dive in more on the examples, give more context, or into your point of view.
• They get defensive or do not visualize the problem, it is important not to be aggressive or provoke. Show how things are from your or others' perspective and how their behavior affects them.

The conversation will loop on those states until it arrives at one outcome which is more likely to be either:

• They realize their mistakes and apologize. You can ask for reverse feedback, what they will do to fix it, and how you can help them. It is good to encourage them and tell them that they will be in a better position once they resolve this.

• They provide evidence that contradicts yours, and maybe you were wrong, and the feedback does not apply because you did not have context. Well, "Even the very wise cannot see all ends". Apologize and tell how you made that mistake, and how you work to avoid it next time.

Actions

Check the process

It would be wise to check if that is the process's fault and how to fix it.

An example of where the process fails the most is at the onboarding, where new hires are perceived as slow, but what might happen is that the onboarding was built around having context or prior knowledge.

You can ask others involved about it and get their points of view, the best person to ask is the ones in the same role, if the process is a problem it means more people will fail there too.

Some processes can be bad for some and not for others. For example, senior engineers can work better around flaky documentation. They might be able to Ctrl-F their way around the project and know how to Google for better answers. Juniors will not.

Closing thoughts

Don't be afraid to have a culture of feedback and have others do the same, even with their peers, you should not be the center of giving feedback.

The engineers should work together and help each other. The more they can do that directly the less work for the manager to handle.