Seeking root cause

Systems thinking

I don’t know whether I became a systems thinker because I read about it in the Fifth Discpline fifteen years ago, or whether I was already a systems thinker but didn’t know the label. Either way, I remember how it gave me a visual method to expose a system, and the diagnostic power of its archetypes.

I also remember in about 1994 being trained as an Apple technician, in the days when we did component-level repair within a Mac, and the trainer using sticky-tape to break a circuit to teach isolation-testing. Of course, he didn’t tell us that, we had to find the fault by reducing the problem scope and gradually isolating the cause of the video flicker. This is a linear form of problem, though, and not a system. Companies are complicated systems.

Whatever the genealogy, I’m a systems thinker and I seek root cause when dealing with problems. In systems thinking, root cause is not the proximate cause, but the deeper systemic issues which gave rise to the observed problem. This author uses the popular iceberg analogy to help explain systems thinking, and I wrote about it as a sales perspective a few years ago.

When effecting change in an organisation it is necessary to find points of leverage within the system that manifested the issue you want to change. This author describes that analysis process well. Doing this requires that you sufficiently understand the issue such that you can improve the situation with minimal unintended consequences, and is generally the opposite of a quick fix.

I like fixing things

One of my core behaviours is that I like to fix things, and to leave them sustainably fixed. Here’s an example of how it presents:

Recently RightScale developed a new vSphere integration technology and made it available in closed beta to our clients. I wanted sales people around the company to understand it and sell it, because I believed it hadsignificant potential. Because it was such new tech there was not any training material for sales people or client-facing content to explain it. I was also concerned about whether the developer-beta tester feedback process would ensure the product had capability which could easily fit into an enterprise’s technology and process environment.

So, I learned about how the RightScale appliance worked, which required learning more about how VMware worked first (and that included their pricing structure), and being able to explain how the vSphere API is different to a cloud API. I found a model to explain our product development cycle, and what lifecycle stage it was in, and put all this content onto an internal wiki page. I put together and delivered sales training which distilled the ‘so what’ of the innovation and explained how it fits in architecturally.

Across a few domains I wanted to be sure of a sustainable momentum:

  • developer-beta tester feedback,
  • sales force engagement into the client base,
  • internal knowledge sharing about the current and future state.

I knew that simply having a product would not translate to sales unless a number of systems were influenced, and that wasn’t being done, so I fixed it.