TBD 5/53: It's Hard to Learn If You Already Know
Recently, I found myself angry because someone was doubting me.
I was explaining one-day sprints, and how that practice had worked for my team in a particular context. Their questions smacked of mistrust (to me, at least). I asked myself “Why don't they trust me? Why are they so pessimistic?”
A couple days later I found myself doubting someone. They were explaining how an accountability framework had worked for their team. I wasn't buying it (though I tried to remain respectful and curious).
Why did I doubt them? I thought they were solving for a symptom, not the actual problem. I also have strong opinions about individual accountability vs. team accountability. The framework they mentioned seemed to favor individual heroics over teamwork. I have firsthand experience with that going very wrong.
Alas, they sensed my skepticism. I don't have a great poker face, and genuine curiosity is hard to fake. Unfortunately, I squandered an opportunity to learn and help.
Working in the beautiful mess of product development is often about suspending disbelief. The challenge is that we're quick to ask others to suspend disbelief, but slow to suspend our own beliefs. We are quick to tout a growth mindset when it is growth we like, but slow to support growth in others that makes us uncomfortable. Quick: first principles when they back us up. Slow: first principles when they challenge us.
I’m reminded of Amy Edmondson's wonderful talk How to turn a group of strangers into a team
It's hard to learn if you already know. And unfortunately, we're hardwired to think we know. And so we've got to remind ourselves -- and we can do it -- to be curious; to be curious about what others bring. And that curiosity can also spawn a kind of generosity of interpretation.
"It's hard to learn if you already know" is a powerful statement, especially considering how people in cross-functional teams often feel it necessary to prove what they know (and defend it).
My intent with these weekly posts was to discuss something actionable. I keep a work diary. Lately, I've been trying to sense that exact moment when the threat response kicks in. And write down what's happening. I also try to keep track of when I'm the one doing the judging. Taking the time to write instead of respond immediately has been very helpful.
Maybe give that a try for a week?
Wonderful thread on the path to product management
I’m speaking about Great One-Pagers at ProductTank SF on Feb 20
Slides from a semi-recent Roadmapping workshop