The value of downtime

I’ve had a really exciting weekend.  I had a new friend, David Hammond, come over for a brainstorming session. We initially met as part of a new venture we’ve both involved in.  Saturday we started discussing how we were going to build a company from scratch.  He’s taken on the role of COO for a start-up; I’ve taken on the role of systems engineer for the same start-up.  My title and location within the organization has very interesting implications for those that study organizational development –but I’ll save that for another post someday.  Enough to say, the job of building a corporation out of thin air is no simple task, especially when everyone else is concern with production and science concerns expecting you to fill in all the corporate, infrastructure and process definition.   

 To paraphrase his gut; “I was feeling like the lone ranger in this activity”.  Our Chief Strategy Officer and CO-Founder recommended that he talk with me.  After my introduction to my role within the group:  “I’m the white space between all the boxes on the chart” He had a sense I could help.  He had brought a role of several large diagrams from past work that he unfurled across my living room floor.  As he explained each, I would chime in with references and concepts that were in line with materials or provided more details.  And so it went for about an hour; his diagrams and symbols my response to references.  It felt like a scene from “Close Encounters” we were establishing a common language between us; a language of common beliefs, mental models and concepts.   After we’d started communicating in our new dialect, rapid progress was made in what we needed to do and have others do; tools and systems to be built and strategies for how. 

 

At 5:30 we stopped for dinner at his place.  His wife had put together an excellent spread.  The conversation varied between business, politics and family.  All in all it was an almost perfect day.  If my wife had been with me it would have been 10 out of 10.

 

This morning I woke up and started thinking about how to represent simply the areas we have to defined –which so happened to have similar activity I have engaged in with some other friends.  I seem to have become a taxonomist by accident and business designer by intent—to others who have not been involved in the conversation and don’t have a common language.   I came up with the following mode.

  

Later I took a break from all this deep thinking or so I thought to read my LinkedIn page update.  An article “What Happened to downtime” caught my attention.   The past two years had been dedicated to 24×7 execution activities the company I presently works at focuses on.  There has been little downtime to think by others or I, despite efforts to influence people to do such.  Weekends were not much different, until I started to just regain my strategic footing through mentoring others.  Then this article resonated with my thinking.  How often do we get caught up with the urgent and forget to think.  Then I looked how easily I came up with the diagram about a day of identifying a need for it.  I’m sure had I needed to come up with it yesterday we both would have drawn a blank.  It was that 4 hours this morning of downtime that enabled the creativity to pour in.     

 

Visual Thinking

This morning I started reading “Turning numbers into Knowledge” by Koomey; an interesting book gear more towards academics and researchers than typical knowledge workers.  When I say geared, it’s the style and tone of writing more so than the information contained within.  The book presents a how-to organize your problem solving.  The small amount I’ve read so far had me thinking about the problem of problem solving and if in the scheme of issues it ranked high on an organization’s the Pareto List of critical items to address.  Combing through my various graphical notes

–I typically create diagrams and sketches for notes rather than text; I had found visual note taking and thinking to be more information intensive than typical text when I was studying architecture.  This was later reinforced by a business associate, Eileen Clegg; I met at the Congress on the Future of Engineering Software (COFES) several years ago.  Her company Visual Insights      http://www.visualinsight.net/ is a welcomed regular fixture at this annual event.  I think the one year she missed attendance there were several people, myself included, asking why.  Many of the Engineering and Engineering Software community’s best; the most creative, innovative and productive are visual thinkers.  I can’t recall a single member of this esteemed group that didn’t have to have a whiteboard or some graphical tool suite in order to think or relate information during our conversations.

At first I thought it was because these were complex topics with lots of detail, which each could be.  The diagrams and pictures though were for the most part very simple, no more than a few simple lines, circles and arcs, etc.  However, like the Chinese saying “One picture is worth a thousand words” these minimalist sketches were very dense in the information they chaptered and represented.–        

 I bring up graphical notes as to indicate that during my career, as I’ve taken notes, I have captured in my graphical journaling much more details than just the issue that was to be address at the time.  Many times I would capture the process of how the group solved the problem or made the decision.  The various projects I’ve been involved with regarding reengineering processes for Rockwell, Boeing, Microsoft, IBM, Samsung and a host of small companies has introduced me to multiple graphical techniques.  Even as I write this post this morning I find myself drawn to mindmap my thoughts as opposed to writing out these ideas.  Writing –as skill I’m trying to improve upon these past few years—is basically one dimensional while my thinking in multidimensional so relationships between concepts are lost in translation as I peck out the words.  Thankfully Hypertext had been created, so I can come back at a later date and establish those relationships.  This has become a long way around and may still have some missing links between my initial thoughts and the insight below, but I’ll come back at a later time and address that bridging issue.

 What I discover –again, which was the rationale for creating Intellectual Arbitrage Group—was that most problems companies are addressing are the same.  What makes them appear different is the context in which they live.  The majority of the activity people in organizations perform is not really deep problem solving but daily searching and translation to the context they’re working in.  Some of the interesting issues around that is identifying the core solution set.  Often because problem/solution pairs are not well documented, people will take the closest solution metaphor at hand to use.  This from my findings is one of the root causes of project failure as opposed to technical failure.  So the end results of many projects are technical success but not achievement of business objectives.

 The cause of this misalignment and how to avoid such will be the topic of future post as I continue to diagram out a working Information Management Methodology.