Are You Using This Strategy to Build an Outstanding Team?

I was listening to the Jocko Podcast, and Jocko was reading from a U.S. Marine Corps (USMC) publication titled "The Squad Leader Makes a Difference". Jocko relayed the story of Corporal Gregory, who served with the USMC in Vietnam. I thought that Corporal Gregory was an outstanding example of a leader who focused on training, …

Giving and Receiving Feedback

As engineers and programmers, we are constantly giving and receiving feedback. This is not a natural process, and it is extremely easy to destroy someone’s motivation with a poor comment. We must practice giving and receiving feedback in a way that preserves the dignity and motivation of ourselves and others. Our goal is to collectively improve the work we are doing.

Table of Contents:

  1. Giving Feedback
  2. Thinking About Feedback
  3. Receiving Feedback
  4. Requesting Valuable Feedback
  5. From Around the Web

Giving Feedback

Whenever you give feedback, you want this outcome:

“The best possible outcome from a response session is for the maker to want to go back to work.
– Liz Lerman

One of the best approaches to evaluating whether our feedback will have a positive impact on the individual is to make sure our response passes through the “Four Gates of Speech” (allegedly) from the Sufi tradition:

  1. Are these words true?
  2. Are they necessary?
  3. Are the beneficial?
  4. Are they kind?

If you cannot answer yes to all four questions, then your response is better left unsaid.

Elecia’s tips on giving feedback are worth studying:

  • Even though the material is not the way I would have written it, it is not wrong
    • For code, if theirs compiles cleanly and works, well, it is not wrong
    • It may not be optimal given other constraints, but it isn’t wrong
  • If I don’t like how it is implemented, that doesn’t mean it is bad
  • My feedback should reflect that I may be wrong because my perspective is different
    • I often think my way is the best because it is the most obvious (to me)
    • When I review someone else’s code, I forget that the way it is implemented is the most obvious way to the developer
    • We can talk about why it is different from what is obvious to me, but I should expect to often be wrong because the developer has put more thought and effort into solving the problems
Note

The key takeaway from Elecia’s points: “That’s not how I would have done it” is not effective feedback!

The Lerman Process for feedback can be effectively applied to engineering. It is important to proceed through the process in order – don’t jump directly to what’s not working!

  1. View the work
  2. Audience: Describe what you observe without value judgment.
    1. What is the work doing?
    2. What takes your attention?
  3. Audience: Talk about what’s working
    1. What do you enjoy?
    2. What’s going well?
  4. Creator: Ask the audience questions (prepare these in advance)
    1. Focus: What areas do you particularly want feedback about?
    2. If you don’t have your questions prepared, you may receive feedback that is not useful to you
  5. Audience: Identify things that aren’t working or that you don’t understand
    1. Ask questions
    2. With the creator’s consent, offer suggestions

Before giving any feedback, step back and take a look at the big picture for a second. Make sure you have the context right. Then dive into the details.

Thinking About Feedback

If you’re stuck on providing constructive feedback, try the following exercises:

  • Ask a question
    • If they approached the work differently than you would have, ask them why they chose the approach
  • Focus on the future: what needs to happen next to improve the work?
  • If you have a problem to point out, what solutions can you propose?
    • Highlighting a problem without a solution is not a constructive contribution
  • If you don’t have anything to add, don’t make something up!
    • “I don’t have any feedback on this at the moment”
    • “I need to look at it again and think more”
    • “I have a couple of notes – I’ll email them to you”
  • If you think the work is really awful, then:
    • Focus on what needs to happen moving forward
    • Be brief, direct, and specific
    • Handle performance issues privately and separately

Receiving Feedback

Receiving feedback is extremely difficult and requires practice. Poorly given feedback can destroy our confidence. You must practice handling feedback with grace, especially when everyone’s goal is the improvement of what has been created.

Know this: You are not your work.

Know this too: Even the most brilliant humans produce work that needs dramatic improvement.

When you need receive feedback, try your best to:

  1. Write it down – it gives you something to do with your hands and eyes during the uncomfortable moment when someone criticizes your work
    1. Write it down in your note system even if it’s saved somewhere like GitHub by another party
    2. Write it down even if you disagree with it
    3. Write it down even if you think you’ll remember it (you probably won’t)
  2. Have questions prepared to make sure you get what you need from the reviewer(s)
  3. Ask questions when you don’t understand a point of feedback
  4. Reserve the right to think
    1. Not every question has to be answered in this moment
    2. Not every decision needs to be justified in this moment
  5. Avoid arguments
  6. Stop talking when you are defensive

If you think bad feedback is being provided, write it down and ignore it. Do not attack the reviewer. Do not point it out to the reviewer. Instead, focus on the good questions and explore those areas. Keep in mind: even “wrong” feedback can expose problems with your work that you address in a different way than what was suggested. You should take the time to think through the feedback and prepare a counter-argument if it is truly invalid.

When a problem is identified without a proposed solution, say: “Excellent point! What can I/we do to address that?”

Feedback on your performance should be handled separately from feedback on your work. When someone attacks you or focuses the feedback on your capabilities, it can set our blood boiling. If this happens, employ the following strategy:

  1. Take three deep breaths
  2. Calmly and politely ask the reviewer to focus on the work itself (and your specific questions), and ask them to handle any performance concerns through the proper channels
  3. End the discussion if the personal feedback continues

Requesting Valuable Feedback

It can be difficult to get useful feedback in some situations. If you find that someone is hesitating to give you honest feedback on a piece of code, some writing, an idea, or a performance, here are strategies you can employ:

  1. Ask for a 0-10 score. Nobody will ever say 10, so then ask how you can get closer to a 10.
  2. Ask what 20% of material the person would cut, and what 20% of material the person would keep.

From Around the Web