· Metacognition · 6 min read
Learning to Respond - Synthesize
Creating a trustworthy response depends on synthesizing knowledge, expertise and sound reasons.
The cure for a fallacious argument is a better argument, not the suppression of ideas. ― Carl Sagan
This series:
After a brief pause for travel (including workshops at Codecamp, NewCrafts and DDD Europe), we are wrapping up our Learning to Respond series. Creating a trustworthy response depends on synthesizing knowledge, expertise and sound reasons.
When someone shares a solution in a meeting, the first thought that comes to your mind is (usually) your opinion. Do I like this? Do I agree? Is this right (aka does it feel right)? Does it match my ideas about what is good?
Opinions are important information but they are not responses. Knowing whether or not you like an idea is an indicator of your mental models. Knowing your mental models is helpful. But your opinion doesn’t tell you much about whether the idea is sound or appropriate to the circumstances.
The trick to changing your opinion-giving habit is to change your goal: can we arrive at the best possible solution, under the circumstances, even though we can’t be certain what is right?
When faced with a new idea, we get curious. What are the reasons that support this idea? Are they sound? Will we learn from this idea and if so, what? Do we understand the circumstances sufficiently?
Rather than focus exclusively on what I think and feel, I synthesize my own knowledge and experience with other people’s knowledge and experience. How did they reach this conclusion? What convinced them? Do they know, think, understand or experience something I don’t? I apply sound judgment, does this reasoning hang together? Does it make sense? Are the reasons valid? We’ll talk about the “valid reasons” part next time. Here, is an example of creating a response …
I am in a meeting with Holly, who is recommending a change. She is describing an API that will be layered over a piece of software because, at the moment, another piece of software is accessing the database directly. gasp
My reaction is – I agree. This is important and we need to make this shift. My reaction is also – I don’t agree. I imagine the API vomiting the messy, software-centric information currently in the database, with no semantic structure. The data is a mess, this might be a chance to clean it up a bit.
I can see that this developer has deeply considered the idea and has information I probably don’t have. So, I mentally recognize my opinions and begin crafting a response.
Say Yes
First, I acknowledge what I’ve heard. Starting with Yes instead of No improves my ability to think well with others, more than any other habit change.
“I appreciate the work you are doing to establish better software communication patterns. Thank you for explaining it so clearly. I agree that we need to shift away from the current relationship.”
Experiment with this. Notice how often someone responds with some form of “No”. Some people believe this keeps the bad ideas out. Perhaps it does, sometimes. But it also keeps the good, new and fresh ideas from flourishing. Who wants to fight a battle every time they speak?
Restate what you’ve understood
I restate what I’ve heard. “If I understand correctly, you’re recommending that we shift the query [describe] to an API that [describe]”
We are often responding to the wrong thing. It’s shocking, frankly, how often I am certain that I’ve understood, only to discover later, I’ve missed something. By restating the idea, as I’ve understood it, the other person (or persons) has a chance to correct any misunderstanding. Try this, you’ll see how often your existing biases influence your hearing.
Ask for time, if you need it.
If you don’t know what your full response is, follow the 24-hour rule, especially if what you want to say is reactive or negative. Give yourself 24 hours to consider it. More often than not, you’ll say something different the next day.
“I’d like some time to consider this. My initial thought is that improving the information structure and giving consumers more control over what they get might make this solution stronger. But I want to learn more. Can we meet again in a couple of days?”
Build a response
Depending on the impact of the idea you are considering, you can invest 10 minutes or 10 days in doing this part. Generally speaking, a little goes a long way. It’s not about the time you invest, it’s about cultivating the habit.
Do three things:
Write down your recommendation and the reasons that convinced you.
By putting your thinking on paper (digital or otherwise) or in a model, you can see what you think. And play with it. Include your recommendation AND the reasons that convinced you.
“I recommend structuring the information for consumers of the API. Here is an example of a user-friendly schema [link]. The information the API provides is valuable beyond the current team consuming it directly from the database [include example]. When possible, using a canonical data model is a best practice we want to follow whenever two or more of our software parts communicate. Consistency in our data model and information flow will help resolve the “data is localized, duplicated and hard to get” issue that led to this problem in the first place.”
Go deeper.
Flesh out your thinking. Why is this recommendation important, right now, in this circumstance? Is data flow a high-impact focus? How does it serve the system’s purpose? What are the drawbacks to doing nothing?
Synthesize other people’s knowledge and experience with your own.
Research and ask questions! What will the consumers of this information do with it? (Reread the original recommendation, Holly probably thought about this already.) Do you understand why the other team is hitting the database directly and the impact of the change?
Are you considering everything you heard? If Holly said “We don’t have time for a more robust solution”, do you understand why? Can you justify the extra work you are recommending to do the thing you prefer? If you think the original idea will have negative repercussions down the road, is there data to support that?
While these steps support wiser thinking, they are also a kind of magic. By changing the dynamics of our responses and improving our relationship to other people’s ideas … we will discover solutions that were previously hidden under the weight of our opinions.
Informal Logic: A Pragmatic Approach
by Douglas Walton
A textbook on the process of crafting sound responses. This one goes deep, recommended if you want to get really good at this type of thinking.
Mental Models for Better Thinking
taught by Farnham Street
Simply doing the work to engage your mental models will help you think better with other people.