Feeding Back
A slim figure takes to the stage, dressed in orange and black, wreathed in a bandanna, 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. IBM’s System/360 has been reshaping the world of business for half a decade.
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 or taking feedback, positive or negative, can be just as much a minefield. When there’s a problem, it’s too easy to resort to either silence or complaint. When there isn’t a problem, it’s 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, destabilised 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 being a team leader, an architect or a coach 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. People? Teams? Organisations? These are very complex systems indeed. They do not fit comfortably into processes and tools bound by basic commands and responses.
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, relationships and cognitive biases.
If the only feedback you offer is negative and corrective — regardless of whether or not it is factually correct — you are more likely to dampen spirits than inspire change. 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 is vague and lacking in guidance. There’s little they can take away from it beyond feeling congratulated. What exactly 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 adding detail doesn’t help. Just saying something is not good does not tell someone what is good. There’s little they can learn from such feedback. Like a no-entry sign on a one-way street, you are told which way you should not go but not which way you should.
Negative feedback is often given in response to seeing a problem, but it is not intrinsically problem solving or constructive. In simple domains, to recognise the problem is to see a path to the solution; in complex domains, to recognise the problem is to have the new problem of determining a solution.
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.
As a term, feedback is often taken to be unidirectional but, as its engineering origins suggest, it is definitely about a relationship. It has force. Bring balance to it.
