Chapter 11. 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 in 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 have no business making.
This is feedback. Not the negative feedback that dampens sound and enthusiasm. Positive feedback. Not gushing and uncontrolled, neither excessive nor insincere. There is an art to feedback.
Feedback, particularly 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 as much of an art form. When there’s a problem, it’s too easy to resort to 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, destabilized perhaps by a hole or a bump: you change behavior, 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; you stop at junctions and red lights, and 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 complex systems indeed. Feedback is a guidance technique, but there’s 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.
We generally don’t consider people, no matter how upstanding they might be, 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 don’t attribute this to a subjective judgment of the test or the emotional state of the compiler (unless we’re having a bad day). When we receive feedback from people, we’re more likely to hear what they say through a veil of emotions, cognitive biases, and relationships.
If the only feedback you offer is negative and corrective, it’s likely to dampen anyone’s spirits, independent of whether or not it’s factually correct. Negative feedback is likely to breed mistrust and resentment. It’s disempowering and unmotivating. The absence of any positive feedback, by implication, suggests that there’s nothing the person is doing right.
Relentless feedback of any one form doesn’t offer the guidance or build the trust that’ll help you, the individual, or the team. This statement applies 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’ve ever been privileged to work in a literal, rather than figurative, vacuum know that support is a necessity, not an option—but there’s a balance to be struck. Excessive and unwarranted positive feedback becomes saccharine and insincere.
Feedback should also be contextual and concrete. Saying someone’s work is good is a pat on the back, but it’s vague and there’s little guidance, little they can take away from it beyond feeling congratulated. Specifically what about their work is good? Whether you’re talking about someone overcoming a personal or technical challenge, meeting a goal, or fielding ideas, be specific. Unless you’re specific, it’s difficult for them to know what is good about what they did, in order that they learn from it, repeat it, and build on it.
The concept of learning and allowing someone else to do the learning highlights the weakness of negative feedback. Even without the question of self-esteem, pointing out that something isn’t good isn’t helpful, and in this case adding detail doesn’t help. Saying something isn’t good doesn’t tell someone what is good. There’s little they can learn from that feedback. It’s like a no-entry sign on a one-way street: you’re told which way you shouldn’t go, but you aren’t told which way you should go.
Negative feedback is often given in response to discovering a problem, but it isn’t intrinsically problem-solving and constructive. To be constructive, you need to offer a concrete suggestion for improvement, or you need to make giving 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 needs purpose and it should enable purpose.
Feedback, as a term, is often taken to be unidirectional; but as its engineering origins suggest, it’s definitely about a relationship. It involves guidance and balance.
Roy’s analysis
This is great advice. It’s simple, yet many leaders aren’t following it, because it’s also hard to do. It requires the ability to sit face to face with a person and confront an uncomfortable subject head on.
From the point of view of a team’s phase, I believe it would definitely fit into all phases. The type of feedback you’d choose to give at each phase might differ.
In the survival mode phase, if you’re trying to get the team out of survival mode, and command-and-control leadership is active, feedback might be related to people doing things that are confusing the situation, people not contributing, or even explaining why someone must do an unpleasant task. “You have to stop working on X and focus only on Y,” or “If there’s one thing I need you to get done this week, it’s X,” are some things you’re likely to hear from me in this phase.
In the learning phase, feedback would usually be related to any missing skills, or current challenges being faced by a team contributor. “You did great work on X. I could tell that was difficult for you,” is something you might hear more often from me in this phase.
In the self-organization phase, feedback would be more about the decisions the team as a whole has made, or the overall goals for the team. “It’s great that you’ve come up with this idea. Please come up with two more and then choose the one you’d like to try out first,” and “How are we doing on our goals? Is there anything you need from me to get things done?” are some things you might hear from me at this phase.
Exercises
- In which phases of the team’s maturity (survival mode, learning, self-organization) would this advice fit best? Would you implement feedback differently in each stage? Why?
- Consider the context of the six influence forces: personal ability, personal motivation, social ability, social motivation, environmental ability, and environmental motivation. If you implement the feedback advice listed here, which of the influence forces would you be using?
KEVLIN HENNEY is an independent consultant and trainer with an interest in programming, patterns, practice, and process. He has been a columnist for a number of magazines and websites, not all of which have folded, and is the coauthor of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series (Wiley, 2007). He’s also the editor of 97 Things Every Programmer Should Know (O’Reilly, 2010). Kevlin speaks at conferences, lives online and in transit, and writes short fiction in what perhaps qualifies as his spare time.