Feedback 360
The beginning or the end of the year is usually full of 1:1s with managers talking about devs performance. But how is this info collected…
The beginning or the end of the year is usually full of 1:1s with managers talking about devs performance. But how is this info collected, how much feedback sessions do you usually have, just with managers, just top-down?
Feedback occurs when outputs of a system are routed back as inputs as part of a chain of cause-and-effect that forms a circuit or loop.
wikipedia
In software teams feedback is used related to personal performance, we used to talk about my manager gave me this feedback to improve or just to justify a decision that company took about my performance.
But feedback in my opinion should be a central point inside software teams, not just for measuring individual performance (good luck trying to do that) but for improving the results inside the team.
A system is not the sum of its parts, but rather, the product of the interaction of the parts.
Russell Ackoff
Software teams are systems shaping a virtual product, a software product. I also said before that from my point of view, the bottleneck in software is the knowledge.
And until we find a way to be in the minds of others our only possibility to gain knowledge is through communication, the best way to communicate ideas or feelings is through talking, even is the more expensive way, but the best.
So, software is usually a social activity.
Social activity
We usually write software with teammates, in different grades of coordination. So as in any kind of human relationship, we have frictions discussions, different points of view, funny moments, sad moments, etc.
We are a gossip animal:
Social cooperation is our key for survival and reproduction. It is not enough for individual men and women to know the whereabouts of lions and bisons
…
It’s much more important for them to know who in their band hates whom, who is sleeping with whom, who is honest and who is a cheat.
Sapiens: A Brief History of Humankind
So we should take all of that into account when we are building software teams, people need to talk, we have to create an environment where we can talk constructively about ourselves, face to face with our teammate.
We should try to avoid bad habits that happen a lot, as giving bad feedback about a person to our manager without talking to that person.
We are gossip animals, but we don’t want to create silos of hate inside our software team.
Sometimes this happens because we don’t have the space, teams are so much focused on being a feature factory. Don’t understand me wrong, we are paid to build things, so this is our main and more important activity, but we need other things to support development in time, with a good pace.
We need to coordinate our efforts, it should be great to feel good working with our teammates, but it’s just enough being able to work together.
So we need to find spaces to talk about ourselves and how we feel working with each other, to avoid misunderstandings that create bad feelings.
The best way I know to make people to understand others is through feedback sessions, I’ve tested several different flavors:
announcements
1 on 1s
speedfeedback
natural feedback
public feedback
We can do this in person or remotely.
Announcements
This is a public feedback to the whole team, we want to change something and starting from today this is the new process or rule or whatever and people need to know about it.
Please don’t think that people are going to follow a process just because it was published, we don’t work in that way.
Announcements are needed, but they are not enough to change things.
1 on 1s
This is basically to schedule sessions with one person to give and receive feedback. There are a lot of people that have experienced doing this with his/her manager, but that’s usually one way feedback, top-down.
The top-down feedback is not the best interaction, it’s much better to be open to receive opinion from people, if you are a manager, ask for feedback from the people you are also giving feedback. If they told you that they cannot give feedback to you because they don’t know you too much, or your work, there you have your first thing to think, why is that happening?.
When I have done this, the session was 30 mins, 15 mins to give feedback and 15 mins to receive it. It’s a good idea to write the feedback you give, or some lines to remember what you want to tell to that person.
And it’s also a good idea to schedule this feedback session close to an interaction you have had with that person, time is important because we tend to forget things.
If you do this frequently, for example once per week with your team-mates, you can ask for specific feedback you are interested on. You can use these sessions to understand if one experiment you are trying with yourself is working, imagine that you want to improve your knowledge on React, so you can ask your teammates about this, if they have seen an improvement in the code you are creating or if this is not happening and suggestions to learn.
Speedfeedback
I love it, the problem with 1:1s is that if your team is big, they are very time-consuming, and sometimes you don’t have any specific feedback for the other person, this makes them sometimes not so useful.
But you can have that contact talking with people about your feelings etc, in a speed date format.
The format is having a session with the whole team, use 5 mins to explain the rules, the rules are:
x mins in a small interview between two people, x/2 mins to give feedback and x/2 mins to receive feedback.
rotate the pairs and have another interview
repeat until we have talked all of us between us or the time has elapsed
So for example if we have a team of 5 people we can schedule 1 hour and having rounds of feedback of 10 mins.
If you are odd numbers in the team, one person can wait thinking on a joke to say before the next round start.
In remote, this can be done through zoom and virtual rooms, more about this here.
In person with a space with chairs one against the other in different places and a central place to talk all together is enough.
Natural feedback
I have seen this to happen a lot when you are doing Pair Programming, you can use some time talking about your feelings with your pair about what happened before lunch.
Some people use the first 15 mins of the day when they start pairing with someone to talk about the day before, or the last 15 mins of the day for talking about the current day.
Public feedback
This is also great, but it requires people to feel really secure in the team, talking in public about themselves, so it’s hard to achieve this situation inside the team, a high level of trust between team members.
Disclaimer: If the team is not in this or some people don’t feel comfortable doing this, don’t do it, could be harmful.
This kind of feedback is basically creating a circle with someone in the middle, that person is going to receive feedback from the whole team:
Each team member apart for the person in the middle will give that person feedback during x mins.
Once everyone has talked, then we rotate the person in the middle by someone else.
Repeat until this is done for everyone or the meeting time has elapsed (try to calculate it)
In remote, you just need a remote session with your team.
Initial sessions
When we start having 360 feedback sessions inside the team I have noticed people tend to give “good” feedback to others. Sometimes this seems naive but I think it creates links between people, everyone wants to feel that others value positively their work.
It creates team, it’s a good side effect.
As time elapsed, I also try to train people on giving and receiving feedback, feedback should be more constructive, because that kind of feedback is the one that will make us to improve.
After one or two sessions, you can play this video:
We want to be the radical candor, we want to care about others but also we want to challenge them to improve.
But receiving feedback is also important, we need to understand that feedback is a gift. We have to trust that others are giving me that feedback because they want me to improve, so feedback need to be digested.
When we receive constructive feedback and we feel that we are emotionally impacted, don’t overreact, wait, think about that feedback one or two days, whatever you need. Think on the fair points, try to work with that and start taking actions.
As a summary feedback in software teams is an impressive tool to improve, try it, don’t use just top-down feedback.
Try to create an environment where this happens and people think it’s useful.