THE RIOT POINT

The Lab

The fruits of riotous experimentation.

Create the demand to participate

I’m not sure if I always get the whole ‘change management’ thing. I have been in full-time employment for over 30 years, and I have seen basic problem-solving or simply getting stuff done, be cordoned off for execution by a recipe-following, jargon-laden club whose membership have derailed or even prevented business improvement. I have seen real movement, real change and genuine heart-felt challenge ignored, overrun or dismissed—to the detriment of many organisations.

Let me be blunt. I have seen some ‘Change Management’ projects snuff out feedback loops; I have seem them absolve leaders from explaining weak decisions; I have seen Change Managers override warning signs, and even driven creaky transactional processes into chaos. Yesterday I heard a Change Management professional decrying a group of lathe operators who had successfully developed and implemented an improved manufacturing workflow by ‘chatting over tea,’ instead of forming a guiding coalition and then adhering to the remaining 6 or 7 steps—as per the CM manual issued in February.

I kid you not.

 

Now, I apologise if I have offended those who make a living in this subject. However, I am confident though that, if you are a reader of this website, you are more likely a discerning Chef of Change Management rather than a recipe follower anyway.

So why the frustration? Because I believe context is an important advisor on what tools we use and when, and many of my change management colleagues lack the confidence to step away from instruction manual and demonstrate judgement on what to use, when and where.

My perspective on change is straightforward. Homo-sapiens are problem-solvers. If we can’t solve a problem as individuals, we form problem-solving units to mutual benefit. Businesses are therefore problem-solving units which form to generate a variety of benefits, including profit. The mutual benefit component is important( as Snowden has pointed out , but it is often only addressed implicitly. Bring out into the open. If you wish to tap into my problem-solving capabilities, you need to give a compelling reason to do so. This is the part, in my experience, where Change Management processes stumble because questions asked can be challenging, conversation is often difficult, and the output often highlights that leaders are not all knowing. For these reasons, the less confident frequently use stick over the carrot to ensure we avoid awkwardness, or at least accelerate quickly through the objections of the cynics and skeptics. This is unfortunate as they are often the most passionate about the success and health of the organisation.

But it need not be so. By opening up the conversation safely and with the emphasis on mutual benefit, much can be achieved by employing a context sensitive approach,.

I am currently engaged with a sophisticated company facing turbulent market conditions in the communication industry. Anticipating the need to be more resilient rather than robust, they decided to consolidate some of the activities in their engineering department, taking previously ‘complicated’ activities and making them ‘simple.’ These ‘simple’ activities included stream-lining of workflow, use of one CAD system, consolidation of a Drawing department, and unification of disparate costing system. The change management programme was overseen by a member of the Executive, but program management delegated to external Change Management ‘experts.’

Now the engineers in this organisation are a critical resource, contributing directly and overtly to the commercial strength of the organisation. They were, naturally, probing, sometimes voluble (and on one occasion volatile) about the perceived loss of control over these activities. The ‘Guiding Coalition’ were given a less than flattering sobriquet, and younger managers recruited into the team were ostracised. The most senior engineers who asked the most pointed questions were perceived as laggards, resistant to change, and with their names reported to the sponsoring Executive. They had also written over 70% of the patents in the preceding 15 years.

In response to request by the Head of the Engineering Department, I sat in one of the joint CM-Engineer meetings; on one side the consultants with rolls of brown paper and chisel-tip pens, and on the other side, Engineers with sharpened Rotring pencils and well-oiled slide rules; you didn’t any special skills to sense combative nature of the relationship

To me better understand the aim of the Change Management programme I introduced the Cynefin framework. I provided the group with a copy of Snowden Boone HBR article, and after a short break, we used the Cynefin framework as means of diagnosing the context of the problem. Both parties placed the Engineering community on the complicated side of the complex/complicated boundary. Both sides then agreed that long term success of the business was critically dependent on Engineering continued support of commercial activities in the complex domain. In fact, involvement was even more important in the uncertain climate. However, at no time in the project had any devolvement of Engineering activity to the simple domain be linked, overtly and transparently, to an increase in Engineering’s influences of complex activities.

Placing the whole change management in a broader context, there was a palpable shift in dynamics within the groun, and the collective tested the change management proposal with two questions:
1. Does this allow engineers to spend more time engaged in complex/complicated activity?
2. If not, how can the proposal be modified to allow this to happen.

As a result of conversation around these questions, the change management project was modified (in fact broadened to include the link to the complex domain) and success measures co-evolved. It wasn’t all lovey-dovey but perhaps the biggest change was a shift in climate that encouraged feedback loops. The biography of the Russian engineer, Peter Palchinsky, has now become a standard text on the internal engineering professional development programme.

This stuff works.

Simon LuntComment