Constraints on giving feedback. @ Irrational Exuberance

Hi folks,

This is the weekly digest for my blog, Irrational Exuberance. Reach out with thoughts on Twitter at @lethain, or reply to this email.

Posts from this week:

- Constraints on giving feedback.

Constraints on giving feedback.

Back when I was managing at Digg and Uber, I spent a lot of time delivering feedback to my management chain about issues in our organization. My intentions were good, but I alienated my management chain without accomplishing much. I also shared my concerns with my team, which I thought would help them understand the organization, but mostly isolated them in a Values Oasis or demoralized them instead.

Those experiences taught me that pushing your organization to improve is essential leadership work, but organizations can only absorb so much improvement at a given time before they reject the person providing the feedback. Being rejected while trying so hard to help is painful, and it’s also a predictable outcome.

It’s also a bad outcome for your team. When I focused on how the environment could change to make my team more successful, I was usually technically correct, but usually didn’t help my team very much. Because work environments change slowly, it benefits your team more to give them feedback about how they can succeed in their current environment than to agree with them about how the current environment does a poor job of supporting them. Agreeing feels empathetic, but frames them as a bystander rather than active participant in their work.

I’ve pulled together a few related thoughts on this topic:

• my framework for delivering cross-functional feedback,
• modifying that framework for communicating within your team,
• how I see many folks get caught up on “feedback legalism”, e.g. fighting the format of feedback, as a way to avoid hearing feedback
• why it’s still worthwhile to improve how you deliver feedback, even if you believe that the focus on format of received feedback is unconstructive

This is more a collection of notes than a grand theory, but hopefully the notes are useful.

Feedback framework

As mentioned above, I used to give a lot of feedback, and found I tended to damage the relationship rather than improve outcomes, so I recalibrated. My framework these days is:

1. Determine why I am confident in my perspective. Is it because I worked on a similar problem previously? Is it because of research I’ve specific done on the topic? Have I modeled the problem out?
   
   If you can’t explain why you’re confident, then it’s extremely unlikely you’ll convince others. Similarly, there’s a power dynamic where depending on your perceived positions in hierarchy, the less senior you are, the more you’re expected to have strong rationale. (I’m not saying this is good, as this dynamic often prevents good feedback. Conversely, I’m not saying it’s bad, as it avoids senior leaders wading through a deluge of feedback. I’m just saying this is real.)
2. Once I’ve been able to determine where my confidence comes from, I’m able to articulate the strength of the feedback. For example, much of the feedback I give these days is formatted as, “I’m not positive, but I think it’s worth quickly checking if the number of upsells is actually low, or if we have a significant dropoff right before the last stage of the conversion funnel.”
   
   You can deliver a much higher volume of lightweight feedback than heavy feedback.
3. Determine the size of the “feedback pipe” between you and the other party. If it’s someone who you or your team is in active conflict with, the size of the feedback pipe might be “absolutely no feedback can successfully be transmitted,” In that case, you have to start by trying to invest into the relationship before delivering feedback (try getting dinner with them, or a joint project, or figuring out a joint interest – yes, it can seem silly, but yes this is how humans work).
   
   It’s so tempting to skip this step, but it basically doesn’t work. Even folks who are good at receiving feedback will focus on merely understanding your feedback rather than valuing your feedback. They will poke at it a bit, and maybe try it on for size, but you’ll be starting from a difficult place.
4. Prioritize the feedback that you want to give. Particularly in cases where you’re having a lot of trouble working with a set of stakeholders, you might have built up a backlog of dozens of pieces of valuable feedback. You have to figure out the order you want to work through those pieces, recognizing that each piece might take months to work through.
5. Based on the size of your pipeline and priorities, deliver as much feedback as you can, but no more. The two rules here are. One, delivering too much slows down improvement and harms the relationship. Two, delivering too little slows down improvement and harms the relationship.
   
   If your relationship is quite good, I find that sometimes folks don’t deliver valuable feedback because they don’t have time to format it well. I recommend using the full feedback pipe, and sometimes that means delivering imperfect feedback to people you have a strong relationship with; this is the executive-perspective of Extracting the kernel.

All-in, I think it would be fair to call this “very obvious,” but it was also something that I messed up for a long time until I figured it out, so I think it’s more the category of “obvious once you’ve seen it, but hard to perceive before then.”

Commentary isn’t feedback

Feedback is conveying information to someone about how they are impacting something. For example, “Hey Will, it felt like you focused on convincing the CFO about the cost impact of your hiring plan, but didn’t spend time convincing anyone else that the plan was worthwhile, even if the cost was low. It would have worked better if you’d started on why it’s useful before getting caught up on how to minimize the expense.” People also talk a lot about their views on the behavior of a third party. Going back to my last example, if the head of product complained to the CFO that Will (the head of engineering) didn’t even explain their proposal, that’s not feedback (it’s being delivered to an uninvolved party), that’s just commentary about the head of engineering’s behavior.

I think it’s important to distinguish between these two behaviors, and I’d argue that commentary generally has few positive impacts. It polarizes the team. It harms your relationships, reducing the bandwidth for feedback. It makes you harder to work with, even when the commentary is accurate.

This is particularly true when you share your concerns with your team. You may have to acknowledge the problems around you to maintain credibility, but done frequently that creates a values oasis. It also frames you as an observer of the problem rather than part of the solution, which diminishes you in the eyes of whoever you’re talking with.

Ultimately, I believe that people want to work with an inspiring leader who believes they can overcome even messy internal problems. Commentary generally reduces your ability to solve internal problems, reduces your visibility as an inspiring leader, and anchors your own attention on problems rather than opportunity.

If you do want to complain, ah, I mean provide commentary, external friends and colleagues are the best recipients.

“Situation Behavior Impact”

There’s an industry around delivering good feedback, such as the Situation-Behavior-Impact (SBI) framework, and these things are useful guide rails for giving feedback. In particular, I think they’re the sort of thing you can actively practice for three months (e.g. spend time proactively framing every piece of your feedback this way) and reflexively deploy without much effort from that point onward. However, I see them get misused in two different ways.

First, often folks never really get comfortable with them and end up viewing them as “too heavy to apply quickly” so they start pocketing more and more feedback rather than delivering it. This is often net-negative because these trainings trying to help deliver better feedback result in folks getting significantly less feedback. If this seems surprising, then draw the Econ 101 supply/demand chart, and model the impact of the price of delivering feedback going up: the supply will naturally go down at any given point on the line.

Second, I see folks reject feedback because they don’t like how it was delivered. Essentially, they become feedback lawyers who fixate on the weakness in how feedback was delivered rather than trying to understand the content within the feedback itself. This lets someone feel justified in ignoring feedback because it wasn’t properly formatted, but doesn’t accomplish anything other than discouraging future feedback. Again, if we look at the impact of this behavior, it’s just shifting the demand curve on the Econ 101 chart down, once again resulting in less feedback.

The advice I give to people is that feedback recipients are obligated to extract the kernel of insight from feedback, even if it isn’t well delivered. Other approaches might feel better short term, but they don’t work.

“Radical Candor”

While I’d caution you to avoid getting too caught up in formatting feedback, I’d similarly avoid the overly simplistic message that many folks take from the “Radical Candor” school of thought. Delivering feedback abruptly is better than delivering no feedback, but it’s still less effective than taking a bit of time to get better at this. Again, I’d push you to spend a few months actively practicing how to structure feedback, after which I think you’ll be better able to quickly deliver feedback as long as you put ongoing effort into maintaining those relationships.

That's all for now! Hope to hear your thoughts on Twitter at @lethain!

This email was sent to you why did I get this?    unsubscribe from this list    update subscription preferences Will Larson · 77 Geary St · co Calm 3rd Floor · San Francisco, CA 94108-5723 · USA