Wes Kao's Super Specific Feedback

Wes Kao’s Super Specific Feedback

Wes Kao wrote a blog about Super Specific Feedback (SSF) from the view of a leader. I am no leader yet so these are my thoughts on her blog from my perspective. I’ll try to compile her excellent blog into what I expect from my feedback and what feedback I want to give.

What is Super Specific Feedback

First, I will confine general feedback from SSF. Wes calls general feedback macro behavioral feedback. This is the kind of feedback you normally get in a performance review. From my experience when you say you are open to feedback you often only get macro behavioral feedback. Which tends to always be the same, be very positive, very nonconfrontational and frankly which does not help me improve. If its negative it wont give a way to: improve, go forward, to understand why, to open up a conversation. If it is positive basically it is basically the same.

To quote from Wes’ the blog:

  • Regular feedback tends to be general, abstract, and mainly about behavior.
  • Super Specific Feedback is extremely concrete feedback primarily on work output, such as writing, product flows, marketing assets, and design. The goal is to strengthen the work product to get it closer to ship ready, and to help the feedback recipient improve their craft and judgment over time.

First, work output is the final form of thinking. […] By giving feedback on the work product, you’re giving feedback on the strategic thinking that went into that asset.

Second, you can’t teach judgment in a silo.

Third, pointing out subpar work and offering coaching will raise the standard of excellence.

These four quotes explain the core of SSF. Wes goes on to say that “high performers” crave this kind of feedback from their managers. She says it results in more motivation and better judgment even though she goes on to later state that SSF is really honest and confrontational in nature. SSF is a win win the team gets better, while the manager in the long run frees up bandwidth. The manager wont be the only one with high standards the culture in the team will promote this standard.

  • By giving detailed feedback on work output, my team members will learn how I think and sharpen their own skills via hands-on concrete work.
  • This will lead to doing better work, faster, that requires fewer edits.
  • Over time, they will proactively address most or all of what I would have given them feedback on. My team members learn on the job, and feel challenged and supported.

How to give Super Specific Feedback

There are 16 ways to give actionable feedback. I will try to break them down and summarize the most important points.

Get “permission” and sell why getting lots of feedback benefits them.

  • SSF helps retain high-performing talent
  • high-performers love getting this kind of feedback
  • get the receivers buy-in
  • make sure people are exited about feedback

Explain the “why.”

  • don’t just say this does not work
  • explain your bigger picture behind the improvements that need to be made
  • solid analogies
  • explain the why behind your feedback
  • share the thought process
  • “this feels of because”
  • “when I see this I think of x”

Note: Wes give an example in the domain of design but this is 100% applicable to software engineering.

Avoid the shit sandwich.

  • just avoid it
  • strait tell whats good
  • strait tell whats bad
  • share specific examples
  • share the thought process behind the negative feedback (and also positive)
  • support with evidence

Share positive feedback.

  • first reason, you want people to keep doing what they are doing
  • second, when you give positive feedback this gives you the rapport to be able to give negative feedback

Aim for being tactical, actionable, concrete, and specific (TACS).

  • Tactical: “This isn’t a generic, hand-wavy theory.”
  • Actionable: “I can put this into practice right now and apply it to my future work.”
  • Concrete: “This can be observed and measured.”
  • Specific: “This is precise advice for a particular situation.”

Structural feedback first, line edits second.

  • if the basis is off give structural feedback and let the person get back to you
  • if basis is right the direction works you can go into detail with line edits
  • don’t loose yourself in details if there are bigger problems to solve

”I believe you were trying to do x, and if so, this part fell flat because y.”

  • mutual understanding

Anytime you’re diagnosing, share what you noticed.

  • as a manager/leader of some kind you diagnose a lot of things
  • every time you diagnose take the extra step and give feedback

Use suggested edits.

  • use edit suggestions
  • (so for SE this means use pull requests and edit suggestions there)
  • they are a great way to improve if read carefully

Show a before and after.

  • before and after can have a huge effect
  • show that you still have it as a leader

Use comments.

  • if you are not sure what to edit specifically
  • key in the thought process

Develop shared language.

  • specific words have implicit shared meaning
  • with shared language less words can give precise information
  • less communication overhead

Annotate screenshots for anything visual.

  • great tool
  • if it is a visual annotate it
  • specifically important for UX

Record a screen share video or voice memo.

  • if it is faster and you don’t have the time it is better than nothing
  • some people work better with screen recordings and or memos
  • you don’t have to have a call for everything

Mention if your feedback is stylistic or a pet peeve.

  • differentiate between this is conventionally a bad thing and I personally don’t like this

Balance what’s easy for you (feedback giver) and easy for them (feedback receiver).

  • self speaking

Summary

Wes Kao wrote an excellent blog post about SSF. Although it was written from a manager’s perspective, it resonated with me. Many of the points also apply to the tech industry, specifically feedback in software engineering. I personally have rarely received such feedback and would love to get it from someone as passionate about software engineering and programming as I am. This article is also meant as a reference for me as to how I should be giving feedback to the people around me at work.

Sources