Ladder Jumping for Problem Solvers (lateral knowledge transfer)

In a prior article, Black Swan Hunting, I referenced a concept that is worth a seperate treatment as a tool for any problem solver, ladder jumping, I originally got the concept-tag "ladder jumping" from the book Smartcuts by Shane Snow (which, as should be obvious from me having added the author on this platform, is a book that I highly recommend).

In Smartcuts, Snow differentiates between ladder climbers and ladder jumpers. The main differentiator between the 2 is that the former completes the steps to accomplish a goal sequentially, like climbing the rungs of a ladder, and the other does what appears to be skipping steps by jumping from another adjacent ladder,.

This process is what I described in my article as lateral knowledge transfer. Put another way, this is learning things from an activity that apply to another activity that you've never performed before. In this article, I'm going to talk a little bit about what that looks like and how to do it. But first, a brief detour into different types of thinking.

2 types of thinking

I recently finished (and cannot stop talking about) the book Visual Thinking by Temple Grandin . When I mention the name Temple Grandin, many people require an explanation, which I find interesting because I have found her story to be indispensible and thought that a major motion picture being made about her life would have assisted with notoriety. Anyway, in Visual Thinking, Dr. Grandin lays out, and supports, a very compelling argument for acknowledging peoples' differing primary modes of thinking and how society currently privileges people who think verbally.

The 3 basic models of thinker described are primarily verbal thinkers, who use words to think and process input sequentially, object visualizers, who rely on images of things they have directly observed in the past, and spatial visualizers, who tend to rely on abstracts constructed from prior experiences but do not need to recall or think in individual instances and who excel at thinking about things geographically or in 3 dimensions. I make no bones about this. This article is for the last type of thinker; folks like me. I would write something for everyone else but I don't know how to yet.

Let's play a game

I'm a pretty strong proponent for "serious play", a term coined by Lego meaning that we should use games to achieve not only enjoyment of our time but also our mature, professional objectives because it just works better more consistently. I was having a conversation with my dad the other day about problem solving. We both work in professions where we have to solve problems and we were comparing methods (meaning, I was trying to learn from his tremendous expertise on this subject). One of the tools in his toolchest is a game that we are all familiar with; "Which one of these things is not like the other? Which one of jthese things just doesn't belong?" This is a tool that I only really get to use sparingly and typically in an inverted way. That is to say, I really end up playing the related game of "What do all of these things have in common?" or "What does this remind me of?"

The reason that I have isolated a particular group of thinkers to target this message for is because this game relies on having a vast mental library of models to pull from. In the prior article, Black Swan Hunting, I made a comparison between 3 very different situations. The situations were getting driving directions in a rural area, chemical synthesis, and task analysis. Why? I used those examples because each one of them carries with it an associated set of tags like "geolocation", "technical operations", or "popularly accessible concepts", and all 3 of them had the same tag; "Steps in a process related by the condition the prior step left things in".

This game is the primary way that I think about ladder jumping, though the jumps are usually not over such large gulfs of knowledge as the farther apart 2 domains of knowledge are from one another, the less they will share highly effective tools. While driving around a rural area is, in some limited sense, very much like transfering the product of one chemical process to another, and also with knowing what to do to accomplish a goal, the similarities pretty much end there. Knowing the right tone of voice to use and the right words to use with a stranger to get directions (rather than the bird) could not be less related to ensuring that you are using clean tubes before placing something on a bunsen burner.

Skill overlap, the critical component

For the purposes of this article, and in my general opinion, everything is a skill. Having an understanding is a skill. It's something that requires practice and that is enriched through activity and examples. Having a belief is a skill. It's something that you can take specific steps to accomplish and which may require maintenance. These are results of material action. They are things you do, not things you have or are. (Major disagreement with Alex Hormozi on that point)

For effective ladder jumping in any situation, your mental game of "What does this remind me of?" must include a component of "If I can do it there, can I do it here?". Your mental game of "What do all of these things have in common?" must come with the caveat of "that I can use to help me right now". I can think of 2 easy examples from my life.

Turtles and Snakes

When I was in elementary school, we had the old school Macintosh all-in-one computers with the funky translucent colorful casings to use and we were in the lab using them every week. One of my favorite activities at that time was playing Logo (or some variant of it). In that game, you would give a turtle commands relating to movement and drawing and it would accopmlish them. These commands were limited only by what you could express in a language the turtle understood (movement pattern in degrees, length of line to draw, whether to draw or not for a specific movement). I remember spending a lot of time creating beautiful complex designs and printing them out on the old printer paper with the holes on either side that were perforated so you had to separate it from other sheets of paper and also from the sides.

When I began learning Python for my graduate program, I remembered the turtles, especially when a program wasn't doing what I thought it should be doing based on what I wrote. Anytime I started thinking "stupid computer", I stopped myself and said "No, stupid user." I knew that the program was only doing as I instructed and therefore if there was an error, it was with my thinking, my code, and my reading of the situation, not with the compiler. I believe that ingrained concept of "the turtle only does what you tell it to do" saved me a lot of potential frustration during that first year.

Graphics and Gadgets

A long time ago, I was a clothing designer. I mean, I'm still one but I was one a long time ago too. The image above is actually a t-shirt design from last year. Anyway, my experience as a clothing designer gave me a ton of extremely valuable experiences and lessons that I use to this day, especially when pursuing a new personal project (device, program, book, game, etc).

The lesson that ended my "career" as a designer of urbanwear was "begin with the end in mind". I had created a portfolio of hundreds of designs, had done dozens of fashion shows, and had sold a considerable amount of merch p2p at the point when I began looking for shops to sell my clothing. I went door to door on Canal st. asking to speak with the Buyer for each store until I found one that would have a meeting with me. I scheduled the meeting and brought my binder full of designs for their review. They thought they could sell some of them and we started talking price. This is where the SHTF.

At this point in the story, most of the t-shirt designs that I was proud enough of to show to other people were very colorful (more than 4 colros) and highly detailed. I had sold on platforms that primarily used Direct to Garment (DTG) printing (which was the latest technology at the time) and passed the cost on to the customers. This was not a situation where that would work. The costs that the Buyer was used to were unreachable using that method since DTG printers didn't offer the same economies of scale that screenprinting or dye sublimation did. I was mortified when I ran the numbers and realized that there was no way that I could fulfill an order for those designs, in that quantity, and at that price without taking a deep loss of funds I didn't have.

This story that I had the chagrin and horror of living through has served as a guiding landmark for every project I begin. "Begin with the end in mind" is the general lesson but the specific takeaway here was "Will this work if you scale it?" or "Will this work the same way if you have to do it a million times instead of just once?" In one of my latest projects, a unique timepiece that I haven't released for public consumption yet, I dwelled on those questions very hard. Due to the nature of the device, the design involved a lot of curved edges and required translucent materials. I thought about 3D printing and asked myself "Will this work if I scale it?". I thought about glass-blowing and asked myself "Will that work if they have to fulfill an order of a million units?"

Without that earlier failure, I would not have a distinction that came to mind as easily to help me in moments like these. When I design something or get something manufactured or prototype something, I have a very good model going into it of what this is for (a prototype is just for testing while a production run has different variables involved) and what to expect out of it (cheap, low quality, problematic vs higher cost, higher consistent quality, limited problems).

Everyday carry

One of the things that I require to make this method work is an always-already-on mentality for categorizing instances and their associated tags. As I have experiences everyday, I'm actively filing them away into groupings based on the required skills to be successful at it. This way, when my brain reaches into the memory archives to see "What does this remind me of?", litanies of things jump out. What I haven't mentioned previosuly, but what I do find extremly useful are models. These are abstract constellations of ideas that someone else has created that I can find wide utility for. For example, DND classes. No person-typing system (MBTI, DISA, etc) has proven as useful to me as categorizing people into Paladin, Bard, Sorcerer, Thief, etc. Another parallel system that I use is "preihistoric" man. No role classification system I've seen yet compares with Chief, elders, medicine man, hunter, gatherer, cook, guard (every job description I've ever read is basically these roles applied to different niche activities). When I was studying for Azure certification, my model was a castle. A castle is essentially it's own ecosystem and so is Azure, and the parallels were too rich for met o avoid using it. So, one of the things for you to do is also to get these swiss army knife ideas and use them frequently.

Borrowing models allows easy ladder jumping by providing you with useful analogies. These analogies come with sets of rules and understandings built in. For example, Bards are generally great at parties but terrible in projects that don't have a presentation/ sales copmonent, so avoid them if that's what you need. Whereas a sorcerer who took a level in bard will be able to walk the talk, and you'll know them by their relationship to what you would expect this archetype to look like.

Again, I have written this article for thinkers like me and this is a method that will work for those spatial abstract thinkers. If those don't work for you, dear reader, you must find a method that works for you.