Nov 292008
 

Warning: this post may read like a lot of braggadocio, and for that I would like to apologize. I don’t tell this story in order to wallow in my own celebration but rather because I’ve come to realize it explains a lot about how I see the world and approach solving its problems, and I want to be able to point back to this explanation from future posts that might implicate this particular perspective.

So, without further ado: did you know I invented the suspension bridge?


Well, perhaps the word is “REinvented,” as in “reinventing the wheel,” since clearly the concept predated me. But when I was a kid, despite having had no instruction about how a suspension bridge worked, I figured it out on my own.
In my eighth grade science class we had a contest: using a finite amount of materials (wooden dowels), each team was to build upon a standard base whatever structure was needed to allow their base to hold the most weight. Most of my classmates simply glued triangles onto their base, because, after all, suspension bridges often look like triangles. I, however, managed to avoid such cosmetic traps and instead visualized a better solution.

It seemed to me that the reason the base (a rectangle made of thicker dowels) wouldn’t last long under much weight was because all the downward force of the weight would be focused on just one particular spot of it. As soon as that spot absorbed all the weight it could, the bridge would break. The solution, then, was to find a way to distribute the downward force around the entire bridge in order to raise its ultimate weight-bearing capacity. To do that I constructed a parallel base to sit above the lower one, and then devised a system of loops to connect them. That way the downward pressure of the weight would press down on the lower base, which would in turn press down on the loops, which would then pull down on the upper part of the bridge, whose weight was now distributed over a wider portion of the bottom base.

Naturally it worked and my team won, and the only reason the bridge ultimately shattered was because it was a rigid structure that couldn’t resist sideways torque. But the point of this story is not to brag about my construction skills or lament that I missed my true calling as a structural engineer. No, the point is to demonstrate how I tend to visualize problems. I tend to see them as overall systems of pressures and tensions, and thus I try to devise solutions that channel these varying forces into complementary ways.

I think it’s good to approach problems this way. If you just try to focus on a small piece of a problem without recognizing its place in the whole you run the risk of wasting resources for no real gain. It would be like gluing triangles onto the base of a bridge; without understanding why the triangles were necessary, it just consumes materials that now won’t be available to solve the problem in a more systemic and connected way. Instead it’s important to define goals, identify the potential points of failures, take stock of the available assets, and then figure out from as high a level as possible how to reconcile everything together.

Of course, doesn’t everyone do this? I want to think so, but I’m not sure. Because I’m not just talking about mechanical engineering; this problem solving approach applies to any sort of situation. In managing organizations and projects, it’s the methodology for how to get things done. Or for information technology applications, because you can’t just throw information technology at a situation and expect it to suddenly be better than before, it requires you to understand the dynamics of the situation — e.g., the exact nature of the information needs that need fulfilling — to then be able to tune the technology to those needs comprehensively and effectively.

I remember one tale in particular from back in the days when I used to implement information technology for a living, where I seemed to bring a necessary insight with this kind of thinking. I was sitting in a meeting with a department at a large technology company that was getting very frustrated over not being able to design a piece of web-based software to help them manage the approval process for partner applications. The hang-up was that the process wasn’t standard: the humans always knew who was next in the approval chain, but it was impossible to program the software in advance. They were all set to construct two different systems, one to collect the original applicant data, and then one to hold all the data for the approved partners, with all data being passed from one to the other via a single forwarded email, which would have been an information management nightmare, laborious and rife with risk of data corruption. However in listening to everything they said they wanted and considering the capabilities and limitations of the available technology, I couldn’t see why one system couldn’t do the job, capturing the original data and managing the approval process by having each person on the approval chain, as they logged in to review the application, simply inform the system whom next to notify to come and review it. It all seemed perfectly obvious and sensible to me, a solution that addressed the single point of trouble without introducing a slew of other problems while maximizing the tools available. Yet everyone at that meeting looked at me like I’m brilliant.

So who knows, maybe I am? While I want to believe that everyone approaches problems this way, the amount of bad processes and ineffective information technology applications I encounter make me think that perhaps it is more rare of a skill. It really does seem to be a skill, being able to visualize the underlying confluence of tensions and understanding how they can be effectively linked. Still it’s a skill like reading is, something that once you’ve mastered you stop recognizing as one because it’s become so intuitive.

But, like reading, it’s one I tend to employ just as often and in everything I do.

 Posted by at 1:49 pm

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)