dein.fr

This article is also available as a presentation

Uber practices "T3B3", which encourages everyone to share feedback regularly with their peers and their manager. The feedback format is:

• "Ts": 3 things that the person does well
• "Bs": 3 things that they can improve on

I will be focusing on the latter category in this post, identifying a few redirecting feedback antipatterns I've seen. Examples will be about software engineering but can easily be transferred to another area.

Note: "negative feedback" is not a particularly good expression - I usually prefer "redirecting feedback".

Introduction to giving redirecting feedback

Giving negative/redirecting feedback is a vital skill you'll need for your whole life. It's not a skill that is only useful in the workplace - you're already giving feedback to your friends and family members. Why not learn to be better at it?

Book recommendation

Crucial Conversations: Tools for Talking When Stakes Are High is the classic reference on this topic. I recommend reading it. It's a bit repetitive though - you can find some good summaries on the web.

Another similar school of thought on the topic is non-violent communication (wikipedia). The book that lays out the method is Nonviolent Communication: A Language of Life, 3rd Edition: Life-Changing Tools for Healthy Relationships. It provides a similar model as Crucial Conversations.

My feedback model: OFNR

Here's the model I follow to deliver feedback (it's the non-violent communication one).

1. Observation of a fact. A fact is rarely controversial, so it's a great way to start a conversation.
2. Feeling: express your feelings and your story. Clarify that it's your story.
3. Need: state what you value, or the kind of impact you'd like to see.
4. Request: explain what concrete action the person who's receiving the feedback would need to take.

E.g.:

[Fact] You said during the review meeting that the wifi-enabled toaster's code was "a piece of shitty spaghetti code". [Story] I think people were put off by that comment, and I felt a bit demotivated because I had spent so much time on it. [Need] We need team members to deliver concerns in a respectful and constructive manner. [Request] You should have proposed some concrete ways we can improve the code, for instance a different code architecture, examples of refactor to take on, and holding people accountable for code quality.

Concrete ways to train

• The best way to learn to deliver good negative feedback is to start by being great at delivering positive feedback, because there's less barriers to do so. Train yourself to use the model above to deliver positive/reinforcing feedback.
• Write the feedback down and hold yourself accountable to deliver it. Often we either forget about the feedback itself, or because we have to think too much about the delivery model, we never actually deliver it.
• Don't deliver it in public unless you know exactly what you're doing. Make it safe for the other person to receive it, and for you to fail at delivering it.
• Acknowledge that you're trying to improve your delivery. Start the feedback session with "I'm not great at delivering feedback, so I'm using this new model since a couple days. Tell me how I'm doing".
• Acknowledge when you failed to deliver it properly. "I'm sorry - I did not deliver this well and I've hurt your feelings. Let me try again."

Antipatterns

Let's look at a few antipatterns.

The "Untargeted feedback" antipattern

This is a pretty classical one. Here's an example:

Our team could have been faster at shipping this wifi-enabled toaster.

It's totally unclear how this piece of feedback applies to the individual in question. I usually write my feedback writing with the second person ("you"), and then I quickly sanity check that I'm using it in the redirecting feedback section. This way I'm sure the feedback is targeted to this person.

Better:

During the kick-off meeting for the wifi-enabled toaster project, you did not clarify that there was a strict timeline behind it. As a result, we missed our customer's expectation and delivered late.

The "Things you can't impact anyway" antipattern

A very common antipattern is to talk about things that the feedback receiver has no impact on.

E.g. (assuming the feedback receiver is an hardware engineer):

The toaster was missing a key feature: toasting an image of the weather on the bread.

This feedback is totally pointless if the feedback receiver has no impact on feature prioritization. Or, if they have, it needs to be made clear in the feedback (see "Untargeted feedback").

The "I'll only talk about things you didn't do" antipattern

It can be tempting to make the Ts very insightful and specific, and to keep Bs evasive (human beings tend to not like giving redirecting feedback). Here's a classical example:

T1: You did ... which resulted in ...

T2: You did ... which resulted in ...

T3: You did ... which resulted in ...

B1: You could have done more hiring.

B2: You could have done more training.

B3: You could have done more mentoring.

While it's not necessarily a bad idea to talk about things the receiver did not do, it's not very helpful if that's the only feedback there is. What's more, the impact of those things missing is usually not laid out for the receiver, which makes the feedback even harder to receive.

I recommend to have at least two items which are about concrete things the person did, but could have done better. This will be much more actionable. Then you can have one or two "stretch" Bs, i.e. pieces of feedback that focus on things your interlocutor could have done more of. In that case, make sure to clarify why they were part of your expectations, and how it could have been done (e.g. better time prioritization, delegation).

E.g.:

B1: Yesterday, you said X but did Y.

B2: You decided to keep working on adding bluetooth to the toaster, even though we decided against it. ...

The "Let's not be specific" antipattern

E.g.:

You sometimes tend to cut corner and sacrifice quality over speed.

Not only this misses an example, but it reads as a personal attack. It is very improbable that the person will react well and find it constructive. Always start with one or two examples, and make sure you link them very concretely to one of the receiver's action.

Better:

During the toaster project, you decided to not spend any time on manual testing, relying on other people to test your code. As a result, a number of bugs (including ticket T000 and T001) were introduced, and led to a decrease in the product's quality.

The "Ts but no Bs" antipattern

E.g.:

T1: ...

T2: ...

T3: ...

B1: ...

B2: Sorry I don't have any.

B3: Sorry I don't have any.

A good rule of thumb is that if you have enough context to give three positive feedback, you need to be able to give three pieces of redirecting feedback. While positive feedback gives a good "tap on the back", negative/redirecting feedback helps us grow. You're actually not helping the receiver if you don't give them actionable and concrete feedback.

The "Feedback sandwich" antipattern

E.g.:

You did an amazing work with the toaster's admin panel. You did not take into consideration accessibility though - which means that our handicapped users won't be able to use it. But the look and feel of the icons is amazing!

The idea behind the feedback sandwich is to soften the blow by putting the piece of redirecting feedback between two positive ones.

It's an antipattern because it makes the overall point much weaker, and as a result, will decrease its effectiveness with the receiver. Compare with:

You did not take into consideration accessibility in the toaster's admin panel - which means that our handicapped users won't be able to use it.

The point is much more direct and focused.

Conclusion

Try the OFNR model in your next feedback session!

Did you like this article? Check out my engineering-management Github repository where I curate a list of useful management resources.