Feeding Back

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

By Kevlin Henny

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 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 onsider 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 is good about what they did 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.

Analysis Exercise

Ask yourself:

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 6 influence forces: personal ability, personal motive, peer pressure, peer pull, environmental reward/punishment and physical environment ability.

If you implement the feedback advice listed here, which of the influence forces would you be leveraging?

Take some time before reading my thoughts, and try to answer this on your own. It is an important skill to develop.

Roy’s Thoughts

This is great advice. It is so simple; it’s hard to believe so many leaders aren’t taking it. But it’s also very hard to do, because it requires the ability to sit face to face with a person and sometimes confront a sometimes 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 are trying to get the team out of survival mode, and command and control style of leadership is active, feedback might usually be related to people doing things that are helping stir the ship around, people not contributing, or even just 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 are 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’re doing great. 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 has made as a team, 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 the fire out which one you’d like to try out first”, “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.

About Kevlin:

Kevlin 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 web sites, not all of which have folded, and is the co-author of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series. He is also the editor of 97 Things Every Programmer Should Know. Kevlin speaks at conferences, lives online and in transit, and writes short fiction in what perhaps qualifies as his spare time.

Book cover

This article is excerpted from Elastic Leadership by Roy Osherove. For a discount on this book, visit here and use the discount code osheroved for a 39% discount on this book in all formats.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories