I really enjoyed reading this. I've noticed that I use reductionism to encourage people to take action, hoping that once we are committed to even the first small step, owning the problem will come more easily. I get really frustrated if I am right in principle but blocked from being useful in practice. Thank you so much for giving me the words for that feeling, I hope to use them next time I am frustrated :)
I think a lot of the success I've enjoyed as a product person, and also a lot of the frustration I've caused for the teams around me, is that uncomfortable balance between those two forces.
The near term certainty and simplicity we need to align around, and the much messier complexity and mysticism that more accurately maps out our future.
I am a reductionist in the sense that I probably veer towards oversimplification of complexity in order to make the next step. I mitigate this by making my steps small and reacting accordingly. In that way I try to reduce the harm of my (often) incorrect assumptions.
A lot of this comes down to a group’s capacity for awareness. It’s only complexity if we struggle to fathom that something exists outside of where we typically place our attentional resources! Otherwise it’s just “the way things are.”
The hope is we can encourage others to expand awareness, but in the meanwhile, maybe reductionism can be effective … if it places interested attention to a part of the system that needs most attention at the moment.
Perfect. I can relate. Even after leading three major transformations and three enterprise software turnarounds at Nike over 25 years, the tendency was to buy services from reductionist firms. That's a long story.
I like Peter Block's thoughts on consulting, but it's too philosophical for the average, busy person. Most, even the best, consultants are not reflective of what they are doing.
I gravitate to Buckminster Fuller's phrase "Comprehensivist." His CADS approach was something I could teach my client teams (either explicitly or implicitly) to accelerate their design thinking-doing, and it closed most of the gaps. It's unappreciated, and most people don't have time to think about it. That's ok. We are the "meta-improvers" of the "improver-creators" (as coined by Douglas Englebart). We enable and elevate our teams by architecting what they work on and how they work.
Once the architecture is "clear," then the unfolding known-unknowns and unknown-unknowns can be addressed by developing your teams as "complex intelligence systems." There are simple practices for identifying new issues and testing new solutions.
A nicely nuanced set of reflections. The tension between reductionism & 'complexity-induced paralysis' is real and ever present.
This is partly why I prefer describing the PM role as helping teams and orgs continuously 'move towards clarity and action' - because more often than not there is always some residual fuzziness/uncertainty/lack of clarity - but ultimately we have to decide how best to act irrespective, otherwise we become the impediment to progress.
Prototyping can allow us to reduce uncertainty through action & engagement - bridging the gap between the two.
I really enjoyed reading this. I've noticed that I use reductionism to encourage people to take action, hoping that once we are committed to even the first small step, owning the problem will come more easily. I get really frustrated if I am right in principle but blocked from being useful in practice. Thank you so much for giving me the words for that feeling, I hope to use them next time I am frustrated :)
I think a lot of the success I've enjoyed as a product person, and also a lot of the frustration I've caused for the teams around me, is that uncomfortable balance between those two forces.
The near term certainty and simplicity we need to align around, and the much messier complexity and mysticism that more accurately maps out our future.
Thanks for articulating it so clearly, John
I am a reductionist in the sense that I probably veer towards oversimplification of complexity in order to make the next step. I mitigate this by making my steps small and reacting accordingly. In that way I try to reduce the harm of my (often) incorrect assumptions.
Beautifully stated. This resonates with my lived experiences as an over thinker and as a leader.
You have put words on what I have been struggling with for years. Thank you so much for this.
A lot of this comes down to a group’s capacity for awareness. It’s only complexity if we struggle to fathom that something exists outside of where we typically place our attentional resources! Otherwise it’s just “the way things are.”
The hope is we can encourage others to expand awareness, but in the meanwhile, maybe reductionism can be effective … if it places interested attention to a part of the system that needs most attention at the moment.
Perfect. I can relate. Even after leading three major transformations and three enterprise software turnarounds at Nike over 25 years, the tendency was to buy services from reductionist firms. That's a long story.
I like Peter Block's thoughts on consulting, but it's too philosophical for the average, busy person. Most, even the best, consultants are not reflective of what they are doing.
I gravitate to Buckminster Fuller's phrase "Comprehensivist." His CADS approach was something I could teach my client teams (either explicitly or implicitly) to accelerate their design thinking-doing, and it closed most of the gaps. It's unappreciated, and most people don't have time to think about it. That's ok. We are the "meta-improvers" of the "improver-creators" (as coined by Douglas Englebart). We enable and elevate our teams by architecting what they work on and how they work.
Once the architecture is "clear," then the unfolding known-unknowns and unknown-unknowns can be addressed by developing your teams as "complex intelligence systems." There are simple practices for identifying new issues and testing new solutions.
A nicely nuanced set of reflections. The tension between reductionism & 'complexity-induced paralysis' is real and ever present.
This is partly why I prefer describing the PM role as helping teams and orgs continuously 'move towards clarity and action' - because more often than not there is always some residual fuzziness/uncertainty/lack of clarity - but ultimately we have to decide how best to act irrespective, otherwise we become the impediment to progress.
Prototyping can allow us to reduce uncertainty through action & engagement - bridging the gap between the two.