This is the listening series. Check out all the posts in the series here.
In the last post, I shared the results of my observations about listening.
I noticed something fascinating: people only cared what I had to say in about 25% of the cases where they asked me.
Why do you think there’s so much asking and so little listening? I recommend taking a moment to consider it.
I have an idea about why. We’re not quite there yet. We’ll talk about it in the next post.
Here we are at the next post.
So, why don’t people listen?
It feels like the answer should have something to do with people’s individual behavior. However, human behavior is relatively consistent: we do what we’re incentivized to do, and different behavior happens when we change our incentives.
Our environment incentivizes us to seek recognition. An individualistic, capitalist society rewards individual accomplishments. It even tends to attribute team accomplishments to a single person. We talked about this in the second listening post, and we talked about how this incentive causes people to optimize for their own speaking time rather than overall discussion productivity.
How do we optimize for our own speaking time? We butt in. But in order to butt in, we’re forced to stop listening to the person currently speaking so we can focus on finding a lull in their speech pattern that allows us to take over the talking.
We also steer the conversation toward the contributions we want to make. That’s why we ask questions where we’re not listening to the answers: the point wasn’t to hear anybody else’s answer. The point was to create space in the conversation to say our own answer. We’re looking to make our contribution, to be recognized, to be validated.
We’re so focused on these machinations to get recognition, that we forget to give it.
It’s a ridiculous collective predicament, isn’t it?
That last sentence reads like the climax of a Dr. Seuss book1, but learning to give recognition can have a selfish motive: the bar is so low for giving recognition, that you can differentiate yourself as a mentor and collaborator by providing the consideration and recognition that most people are sorely lacking.
Chelsea, what does any of this have to do with making an impact?
Since people mostly aren’t listening, butting into a conversation doesn’t ignite much of an impact. In order for words to have impact, people have to listen to them.
I have found that my interactions produce much greater impact when I set aside the way that I want to do things and focus on helping other people do things.
Tempted By Lasagna
My coworker is thrilled: they have an opportunity to architect an important piece of software from scratch. They come to me for advice on how to do it.
When I tell them exactly how to do it, they feel like Jon in this Garfield comic:
Because I have eaten their lasagna.
They worked for that lasagna. This project is exciting to them because it’s their opportunity to make meaningful decisions. And they have mustered up the humility and the courage to share that lasagna with me.
And instead of sharing it with them, I have eaten it myself.
That’s not fun for my colleague. The next time they get a lasagna, they might think twice before bringing the plate to my office.
In one-on-one discussions like this one, I rarely open with an opinion anymore.
Instead, I listen to the orator. I ask them (or let them explain) what they’re trying to do, the options they have considered, and what they’re thinking. Then I ask questions to solicit their opinions on the factors that I would consider in such a decision.
Suppose they’re building a mobile app and deciding whether to go fully native or use a dual-platform framework like Xamarin, React Native, or Flutter. I might ask:
- Will your app use the camera, flashlight, or other hardware features?
- Will your app need to store data on your users’ devices?
- Will there be forms in your app?
- Do you anticipate growing a team to maintain this app?
These questions lead to discussions about how to make the decision, rather than what the decision is. I might ask questions that my colleague didn’t think about and thereby influence their decision-making. Or maybe they’ll bring something up that I hadn’t considered, and I’ll get to learn from this exchange, too.
We’re sharing the lasagna.
This method eliminates much of the friction that happens when we individually describe our solutions. Because if we have different solutions, we now must either commit to an argument, or individually commit to avoiding an argument and hope that the other person does the same. That’s stressful.
Remember when we talked about how our traditional framework for giving feedback sets up an adversarial relationship between the giver and receiver? We talked about how to change that adversarial dynamic to a collaborative one. We’re doing exactly the same thing here for technical conversations that we did there for feedback conversations.
When we start from solutions so we have to backtrack to figure out why we disagree, we accidentally set up an adversarial conversation from the beginning. Asking questions about how to make the decision instead produces a collaborative conversation: we walk through the decision together and co-create a final result.
You’ll notice, this is not the same as the socratic method. I’m not placing myself on a pedestal and attempting to teach my colleague something by way of questions. I am expressing interest in their decision-making process; I’m asking their advice with respect to my framing of the decision. I learn, my colleagues learn, and we work together on things with a lower risk of some misunderstanding or disagreement getting between us.
Won’t people notice I’m not answering their questions and get annoyed?
Honestly, not really. I have been doing this for about six months. Exactly one person has noticed that I didn’t answer his question about how I would do something, and pressed me for my actual answer. Usually people come to a discussion like this with their own ideas about what to do. They’re hoping I’ll be a sounding board, so I try to do just that—and no more.
We’ve looked at one example, but there’s a broader framework here.
For much of our careers, we have optimized for our own speaking time. We have learned to cut in during conversation and spout sound bites. We have learned to get ourselves recognized in a system that rewards individual achievements and misconstrues team achievements as the achievements of the most visible individual. That’s a set of skills.
Optimizing instead for our impact requires an altogether different set of skills. In the next two posts, we’ll go over two: deliberate inquisition and deliberate appreciation.
In the meantime, here’s the exercise that I think deserves your consideration:
The next time someone asks for your advice, resist the urge to give it right away.
Instead, why don’t you experiment with asking some questions first? What factors are important to you in making this decision, and what does your conversation partner think about those factors?
You might learn something new—and your conversation partner almost certainly will.
1Theodor Seuss Geisel is best known for his popular children’s books, some of which attempt to communicate pressing social issues. The picture above shows the cover of The Lorax, a story about the importance of preserving our natural resources. Prescient, for 1971—and a quaint way to expect to make a difference, right? Well, some of the children who read that line grew up to be federal appeals court judges. And when the U.S. Forest Service attempted to grant a permit in 2018 for the Atlantic Coast Pipeline to build through two national forests, that appeals court revoked the permit. The judges cited The Lorax as inspiration in their decision.
If you liked this post, you might also like:
The feedback posts—They are numerous and have garnered high praise 🙂 I also have a 20 minute talk about giving and receiving feedback that got rave reviews at the CTO Summit in Chicago, and I’m happy to use it as an excuse to travel. Perhaps to your city?
The conference organizing series—I don’t organize conferences all the time, but when I do, I write about the whole thing.
The series on the Structure and Interpretation of Computer Programs—Probably utterly useless to you professionally, but cool as hell as far as I’m concerned.