Don’t fall for symptoms

Over the last few weeks, I’ve been in discussions with several companies and the same problem occurred: my contacts raised a change that they were looking to realize in their organizations and asked me for help to realize it. When I asked how they had ended up in the situation that required the change, most were stumped – it was clear that this had crossed their minds.

Of course, as engineers, we’re trained to think in terms of solutions and many of us follow that training to the dot. However, developing a solution for a problem that actually is a symptom and the consequence of something else is entirely useless as the likelihood of the solution solving anything is about as high as the survival chances of a snowflake in hell.

For example, several R&D departments want to introduce continuous deployment or DevOps in their company but run into strong resistance from sales and customer support. Many lament that the people on the other side of the fence just don’t get it. However, when analyzing the situation, it’s obvious that the introduction brings along significant cost and a fundamentally different relationship with customers. And without a business model to monetize the continuous value delivery, there’s no point in adopting DevOps. So, rather than stressing that the folks on the business side are idiots, work with them to figure out how to create business models and customer engagement models that make sense and then work with lead customers to experiment with this new model.

Many know the “rule of 5 why’s”: the notion of, after observing a problem, asking “why” five times to go from the observed symptoms to the actual root causes. The challenge is that in practice, this rule is followed not nearly as often as it deserves.

A related and subsequent challenge is that even if we’ve identified the root cause and we have an idea to solve it, there’s huge resistance in the organization to actually implement everything that’s needed to actually make progress. Instead, there’s a tendency to support the implementation of something small enough to make it palatable for all in the company. The result frequently is a watered and scaled-down proposal that gets broad support but that offers little more than a token effort with little real impact on the company. As a general observation, my experience is that the more politicized an organization is, the more it tends to focus on symptoms instead of root causes and the more it tends to focus on watered-down change initiatives that create the illusion of action but don’t result in any genuine change.

My advice is obvious. First, use your intelligence and experience to develop a solid understanding of the root causes underlying observed phenomena. Don’t fall into the trap of believing what everyone else believes. Second, use your social and interaction skills to confirm your understanding with others and to build a common platform of a root cause focused understanding. Third, once you’ve established a common understanding, explore multiple (rather than only one) avenues to address the identified root cause and build a platform for the one that has the required impact while minimizing collateral damage. Fourth, when sufficient agreement is in place, move forward with execution in an iterative, experimental manner where you take one end-to-end slice of the organization through the change, observe and measure the impact, adjust accordingly and proceed with the next slice. Throughout all this, find the right balance between driving and being committed to realizing the change and an objective, reflective attitude where you’re able to identify the downsides of the change and the need for adjustment where necessary.

As the Buddhists say, the difference lies in the small window between trigger and response. Rather than instinctively reacting to what life throws your way, pause, reflect and decide on a course of action that actually results in what you’re looking to accomplish. In other words, think rather than react.