DEV Community

Cover image for Team Leadership Toolkit: Giving feedback
Nico Riedmann
Nico Riedmann

Posted on • Originally published at riedmann.dev

Team Leadership Toolkit: Giving feedback

One thing I keep learning is that giving feedback that works is all about clarity.

This applies to praise as well as critical feedback but is especially important for the latter.

Here are a few concepts I find helpful in delivering feedback :

"I" messages

Giving "objective" feedback is hard and can lead you to state things as facts, that are really just your observation.

It's not just more objective but also easier to clearly state your observations and feelings.

Rather than assuming what effect someone's behaviour in a meeting had on a team, simply deliver how the situation impacted you and why the behaviour was not ok.

The SBI(TM) model - Situation, Behaviour, Impact, (Desire)

A feedback model that lends itself to the idea above is Situation, Behaviour, Impact.

Situation - Clearly describe the situation the behaviour occurred in. When and where did this happen?

Behaviour - Clearly describe the behaviour you observed. Don't try to assume you know what the person was thinking or why they behaved that way, just describe what you saw.

Impact - Clearly describe the impact this behaviour had on you. What did it make you feel or think?

Usually clearly stating your feedback is enough to start a discussion on why this was not okay and how it can be improved.

Ideas on what to change usually work a lot better when they come from the person receiving the feedback, but in some cases, I find it helpful to be specific on what needs to change:

Desire - Clearly state what different behaviour you'll need to see the next time a similar situation occurs.

Timely feedback

Receiving feedback works best (for me) if the situation is still fresh in my mind. As that's the case for most people, try and deliver feedback in a timely manner.

Why "in a timely manner" and not just "immediately"?

In general apply the "praise in public, critique in private" - calling someone out in front of a group will usually just result in a defensive reaction and can lead to bad team dynamics.

Depending on the behaviour you might need to call someone out on something as it happens, to stop it right away, but then deliver detailed feedback in private later.

Sometimes neither you nor the receiver of feedback is in the right mental state for feedback - leave some room for moods to cool off or external stressful factors to pass, to ensure the feedback is delivered and received better.

Just don't wait for your fixed cadence 1:1s or even yearly feedback/development talks to deliver feedback - by that time both you and the receiver of the feedback have probably forgotten the situation and why the feedback is important.

Further reading:


The 'team leadership toolkit' is a series of bite-sized articles on techniques I find helpful as a software engineering team lead.

Having shared most of this with peers and mentees in an unstructured way, I've started this to concisely describe the What, Why and How of things that work for me and might be helpful for others.

What about you? What's in your 'leadership toolkit'?
I'd love to hear your comments or posts!

Top comments (0)