I came across a video the other day that had this catchy title – Radical Candor. I watched it and was intrigued by the talk AND its implication to agile teams, organizational transformations, and sustainable cultures.
Kim Scott was the presenter in the video and she was sharing lessons she’d learned in her leadership journey at Apple and Google. In a nutshell, she was advocating radical candor for leaders in communicating with their direct reports.
The stories she told made me think about my own career and leadership journey. A couple of which I’d like to share with you.
I’ve been presenting at conferences for years. Over 20 years to more precise.
One of the common occurrences is that someone points out a typo or grammatical error on one of my slides in the comment section of the feedback form. I recently had this happen in a Certified Agile Leadership class. One of the feedback post-it notes on the first day pointed out a few typos. While I appreciate the feedback, I often wonder if there is more feedback than simply minutia…
If you read the feedback on Amazon for my Scrum Product Ownership book, some of the reviewers say the same thing. They talk about copy edit quality and the errors. These folks are right. I should have spent more time and money on the editing process. But if you look at the vast majority of the reviewers, they seemed to have overlooked those mistakes and received great value from the book.
And the detractors really seem to rate the book much lower based on the simple errors, simply overlooking the real value of the book. It’s as if they can’t see the forest for the trees.
There is an old, old movie called the Marathon Man with Dustin Hoffman. In it, there is a compelling scene where the evil doer continues to ask Hoffman – “Is it safe?” while giving him a free dental checkup.
You can watch the scene here, if you’re up to it: https://www.youtube.com/watch?v=kzw1_2b-I7A
There seems to be several things that are incredibly difficult for many folks to do.
You see it in general, but it’s particularly interesting in agile contexts. Agile Teams seem to rarely want to:
- Ask for help
- Or say, I don’t know
I’m wondering why?
I was reading an online HBR article the other day about leadership communication. Here’s the HBR article –
https://hbr.org/2016/03/two-thirds-of-managers-are-uncomfortable-communicating-with-employees
I thought this might be a nice way to RE-explore leadership communication challenges. And a new twist might be some ideas on HOW to improve it.
Giving feedback is one of the things I like most about agile methods. There’s this thing about it though. It’s not that easy to give effective feedback. Lately, I’ve been hearing agile team members start their feedback with the following statements:
- I don’t want to rain on your parade, but...
- I don’t mean to be negative, but...
- I don’t mean to criticize, but...
- I don’t mean for you to take this the wrong way, but...
And then there’s the Ricky Bobby quote from the movie Talladega Nights regarding – “With all due respect…”
In my last post we explored a situation where a Product Owner had a long-term challenge with their performance that was weighing their team down.
But as I finished that article, I realized that there might be something else going on that I wanted to explore here.
In that situation, the teams’ coach assured me that conversations and escalations had happened between herself, the team, and the Product Owner. She even said she’d escalated things to the PO’s boss. She made it sound like there was a huge amount of clear feedback over the course of two full years.
Given this, they seemed to be at an insurmountable obstacle—a poorly performing Product Owner and nobody willing to do anything to improve the situation. In other words, they were stuck.
I was talking to a fellow coach the other day and she was venting a bit about one of her teams and their Product Owner.
Bob, she said, I have an outstanding agile team. We’ve been working within our product organization for nearly two years. In that time, we’ve delivered an application upgrade that everyone has viewed as simply fantastic. Now we’re onto a building a critical piece of new system functionality for them—so we’ve earned everyone’s confidence in our abilities.
We work hard, we work well together, we deliver high-quality working code, and we have fun doing it.
Ok, I asked. That sounds like a fantastic situation. To be honest, I’m a bit jealous.
