Using Fluid Web Linkage (FWL) thinking to solve novel conundrums . . .
Identifying root causes can take significant time, effort, and energy. Many challenges are a thicket. What we think are the issues are often simply the visible tip of an “iceberg”; a clue that points to a wickedly tangled interwoven web–a Gordian knot of issues. I get embedded into the core data set to get to the core issue, having discovered that once we find the key to deal with this, the overlying elements unlock fairly easily.
Imagining Fluid Webs
It helps to imagine yourself standing in the midst of clouds of data with datapoints arrayed around you; you are the moving core of the moving local cloud; and when wanting to look at something particularly closely . . . you gather and stitch the points together into an area of study.
This method seems to be best suited to discover what is the most essential; the tweak–the crux–that when activated unlocks the puzzle. The website at this link showcases my solution sets for different business challenges, including the ones described here:
- [link] Machining an “impossible-to-make” 7-sided part on a hex milling machine design-limited by engineers to stop at 6 sides. My instructor claimed it was impossible to surpass the design maximum established by professional engineers – but I solved it, and he got excited by this.
- [link] Coaching a physically disabled teenager, whose arms and hands were twisted, to roll a kayak after national coaches and athletes gave up – using “Liquid Membraning” – spatially projecting “Anticipated Liquid Data Fields” to find the pivot point where he could roll; and then teaching him to find the pivot – exactly mimic the harmonics’ flow-through – so he could roll himself. Seeing the boy grin to his dad made the day!
- (later…in 2008) using the insights to show BC slalom kayaking Olympian David Ford how he could improve his paddling…shifting his thinking about technique…to obtain explosive bursts of micropower (and hence, microspeed leaps) by leveraging a complex multiple linkage that occurs during the “spring system transition” we experience in whitewater kayaking. Microsecond bursts, consistently applied, sum up to competitive advantage in a discipline where partial seconds decide who stands on the podium. David used the insights to up his game.
- [link] Solving a 6-year old manufacturing flaw in 2 minutes: finding a 1/4 cm stitching flaw in a canoe spray deck (a flexing fabric cover) that could only be found by noticing and tracing a complex flexible double-reverse 4-bar linkage web that only activates when the product assembly is being used.
- [link] Cloudboxing to comprehend what code actually is – a tutorial for spatial/globular thinkers. To learn where flat/discrete 2D data sits.. . . to be able to use it to code. For a spatial thinker, learning 2D thinking must be like what left-handers go through trying to learn right-handedness. Awkward and painful, having to learn a wholly different and unnatural way of cognitive processing. Whilst learning coding, I was getting lost in the fields of datapoints when trying to model the waypoints. But found a way forward through weeks of constant study, interviewing other classmates and faculty to get a sense of what coding actually is. Then taught myself to construct a box out of datapoints in visual thoughtspace: creating the study space using FWL solid-modelling (cognitively akin to AutoCAD™, Solidworks™, or Rhino 3D™).
Note 1:
GDKE: From the German “Gedankenexperimente”
Note 2:
I used to take the time to explain the steps to solutions (often having to take months or years) because uncomprehending evidence-demanders would demand a proof-of-the-how despite the evidence in their hands, but then after a chat with spatial-thinking compatriot Prof. Hugh Wynne-Edwards (who told me of his own challenges and then decision to give up wasting precious time trying to explain solutions to his uncomprehending linear-minded university colleagues), decided that it doesn’t make a lot of sense explaining how we get to solutions, when oftentimes, linear-thinkers decide to ignore the results anyways.
So instead, when ready, I explain what the solutions are, what the measurable impact will be; and only flow-chart the results when absolutely necessary.
NB: Roger Martin has gone into detail explaining why “linear-thinking” and “ambiguity-comfortable design-thinking” do not easily mix in many corporations and universities (book: The Design of Business).