Feeding Back

A slim figure takes to the stage, dressed in orange and black, wreathed in a bandana, his guitar flipped over and strung for left-handed play. It’s the close of over three days of hedonistic and culturally shifting psychedelia and sound. Humans have recently and for the first time set foot on another world.

It’s 1969. It’s Woodstock. It’s Jimi Hendrix. During his set he splices metallic whale song into his fluid solos, coaxing sounds from his Stratocaster that guitars simply have no business making.

This is feedback. Not the negative feedback that dampens sound and enthusiasm. Positive feedback. But not gushing and uncontrolled, neither excessive nor insincere. There is an art to feedback.

Feedback, especially positive feedback, is normally a sound engineer’s nightmare. A skilled guitarist can make it part of the performance, part of the music. For software engineers, offering and taking feedback, positive or negative, can be just as much a minefield. When there is a problem, it is too easy to resort to silence or complaint. When there isn’t a problem, it is too easy to resort to silence.

When you ride a bicycle, feedback is essential. Sight, hearing and proprioception allow you to navigate and balance, to respond to the bike and the road. You respond when the bike is balanced and on a steady course: you respond by continuing to do what you are doing, preserving your course and your balance. You respond when the bike loses balance, destabilized perhaps by a hole or a bump. You change behaviour, you react to recover and put the bike back on course. And you respond when the situation on the road changes. You avoid pedestrians, cars and other bikes, stop at junctions and red lights, cycle more carefully in the rain.

Part of team leadership involves leading by example, but part involves guidance. For simple systems, guidance is programmatic, a matter of command and control. This doesn’t work well for complex systems, and individuals and teams are very complex systems indeed. Feedback is a guidance technique, but there is an art to it that goes beyond the simple presentation of the facts as you see them. To be effective, feedback also needs to be trusted, concrete and constructive.

No matter how upstanding they might be, we do not generally consider people to be objective sources of information in the way that inanimate objects and software tools are. When a piece of code fails a test or doesn’t compile, we do not attribute this to a subjective judgement of the test or the emotional state of the compiler (unless we’re having a really bad day). When we get feedback from people we are more likely to hear what they are saying through a veil of emotions, cognitive biases and relationships.

If the only feedback you offer is negative and corrective, it is likely to dampen anyone’s spirits, independently of whether or not it is factually correct. Negative feedback is likely to breed mistrust and resentment. It is disempowering and demotivating. The absence of any positive feedback, by implication, suggests that there is nothing the person is doing right.

Relentless feedback of any one form does not offer the guidance or build the trust that will help you, the individual or the team. This applies just as much to unconditional positive feedback as it does to negative feedback. Positive feedback is psychologically necessary, otherwise people feel like they’re operating in a vacuum — the few humans who have ever been privileged to work in a literal rather than figurative vacuum know that support is a necessity not an option — but there is a balance to be struck: excessive and unwarranted positive feedback simply becomes saccharine and insincere.

Feedback should also be contextual and concrete. Simply saying someone’s work is good is a pat on the back, but it’s vague and there is little guidance, little they can take away from it beyond feeling congratulated. What is it that is good? Whether we are talking about someone overcoming a personal or technical challenge, meeting a goal or fielding ideas, be specific. Unless you are specific, it is difficult for them to know what it is about what they did that is good so that they can learn from it, repeat it and build on it.

It is this question of learning and allowing someone else to do the learning that highlights the weakness of negative feedback. Even without the question of self-esteem, simply pointing out that something is not good is not helpful, and in this case adding detail doesn’t help. Just saying something is not good does not tell someone what is good. There is little they can learn from it. It’s like a no-entry sign on a one-way street: you are told which way you should not go, but you are not told which way you should go.

Negative feedback is often given in response to seeing a problem, but it is not intrinsically problem solving and constructive. To be constructive you need to offer a concrete suggestion for improvement or you need to make the giving of feedback part of a problem-solving conversation. If you want someone to learn, create the opportunity and environment for them to discuss and contribute, otherwise the feedback becomes more about the person giving the feedback than the person receiving it. Feedback should have purpose and it should enable purpose.

Feedback, as a term, is often taken to be unidirectional but, as its engineering origins suggest, it is definitely about a relationship. It involves guidance and balance. Steady as she goes.

This is based on material previously published in Roy Osherove’s Notes to a Software Team Leader : https://leanpub.com/teamleader