This post is part of an ongoing series entitled “a post a day every other day for the month of May.” It’s an unfolding exploration of the concepts from the book “Get Lucky.”

Once in awhile you get shown the light
in the strangest of places if you look at it right.
-Scarlet Begonias by Grateful Dead

Preparation in the context of Get Lucky is the skill of readying oneself to identify and capitalize on serendipity. The authors discuss a handful of examples of how this works in practice. From Phil Jackson’s zen coaching exercises to the case of the floppy-eared rabbit discovery, moments of grand insight seem to share a common ancestor. The magic occurs when the subject is able to shed his or her “curse of knowledge” and see a situation through fresh eyes. If we want more of these epiphanies in our lives the authors encourage us to play with injecting distance into our problems.

The proposed mechanism here is a theory the authors reference called Construal Level Theory (CLT) which is basically the psychological underpinning behind the technique of pre framing in sales. Rather than hash through the examples cited in the book I’ll share an example of one of these quantum leap epiphanies that occurred for me that came via chance exposure to certain imagery at the most unsuspecting time.

It was sometime around 2003 and I was working a brief stint as a software developer for a company called Interactive Sites. We had a custom content management system that allowed us to host the websites for thousands of hotels around the world. The task I had at the time was to write a script that would do the modern day equivalent of “rake” in a Ruby on Rails application: basically a reset button that would let us clone the database and wipe the data so we could work with a fresh copy of the application.

As simple as this task seems with today’s tools, at the time it was non-trivial. We were using Microsoft SQL database and a programming language called Coldfusion. The way our database had been setup to strictly enforce what’s called “relational integrity,” this programming challenge was the knotted conceptual equivalent of this:

Deleting data from one table that referenced data in another table would cause this kind of cascading gridlock of integrity check errors such that you had to trace the foreign key dependency out to the “leaf nodes” which had no dependencies and then trial & error work your way backwards sequentially deleting data.

With upwards of fifty tables in our database each sharing relationships to between one and twelve other tables this proved to be a tricky thing to untangle. I used a tool that analyzed the database and produced something called an Entity Relationship (ER) diagram to help visualize things. It looked something like this (not the actual ER diagram):

I wrestled with this problem for two full days trying to see an elegant solution. I concluded at the end of the second day that a brute force approach of untangling the dependencies manually one at a time would have to be the solution. I was not looking forward to the next day that I would spend doing the intern-level monkeywork equivalent of licking stamps and hand addressing thousands of envelopes. Little did I realize the answer would strike a few hours later that evening in the most unsuspecting way.

I was on a Nova, Discovery Channel, History Channel kick at the time sponging any and all documentaries I could find on space travel. That night while decompressing watching one of those PBS specials a 3D graphic animation showing the planets of our solar system in their orbits came on.

As the camera panned from our planet backward to the outer reaches past Pluto an odd insight hit me: that image had a weird similarity to that ER diagram in how bodies revolved around a central entity. I went back and stared at the ER diagram thinking about the root “Person” table and imagining what it would look like if it were the sun and the surrounding linked tables were planets and moons clustered in “orbits of dependency” around it. What if you could then with the tables grouped like this “peel back” the dependencies starting with tables in the outer-most orbit like layers of an onion until you worked your way to the Sun? Goosebumps.

It turned out that indeed the tables in the database could be grouped this way into clusters based on how related they were to the root node and that the brute force fifty-step approach I was planning to undertake the next day could instead be distilled into just five steps. By focusing on the “orbits of dependency” instead of the individual tables it gave me an entirely new way to think about the problem. This chance exposure to an abstraction of concentric 3D orbits took my 2D problem of flat tables on a page and let me see the problem in a new light which led to an elegant solution that never would have otherwise materialized.

Was it pure luck I saw that particular imagery that evening? Sure. But it was the cognitive distance from the problem and the cessation of searching for an answer that prep’d my mind to receive the insight. This is distance. And if Thor and Lane’s ideas have merit then spending less time working and a lot more time playing is something that companies need to embrace. Google and their famous “20% time” is one example of a progressive company that consciously baked distance into its culture and has already seen massive rewards (Adsense and Gmail among others).

We’ll play around with some other theories from psychology next time investigating something called Transfer Appropriate Processing and my favorite, The Availability Heuristic. In the meantime, what problem are you wrestling with right now and what’s a random unrelated decompression activity you could undertake today to send your mind somewhere decidedly unrelated? Oh and change your tune: Ghostland Observatory – Black Box