Confidence

A CEO decided that he wanted to "shake up" his rather stodgy company to turn it into an outward-looking innovative juggernaut. The industry had been so comfortable for so long that innovation had not been necessary for survival. With the market upended and significant pressure on margins, the CEO thought that the innovation imperative would be evident to all. He envisioned a company where a question from Asia would find an answer in France, and where people who didn't know each other would collaborate to innovate. He put a team in charge of innovation, reporting directly to him, and bypassed the IT department to launch an enterprise social network (ESN).  

He acted fast and decisively, and expected quick results - an enthusiastic snowball effect of sorts. What he did not foresee, however, was that instead of rising to the challenge of the transformation, the majority decided to either 'wait and see' or to oppose him outright. In particular, there was strong resistance among second and third-line managers against the ESN. An idea that seemed obvious at HQ failed in the hands of the people it was supposed to help.  

What happened? 

For one, this is a classic case of "transformation by bus". The tools are deployed in the hope that people will use them. There is no clearly articulated and desirable target that the organization will reach by using this tool, and the employees have not formulated a need for the tool as a means to reach the target.  

  

Further, signing up for the ESN was an individual initiative for each employee. In a culture steeped in conservatism, that was already a stretch. Some staff resisted using a tool for which they were not specifically trained.  

More disturbingly, some second and third-line managers actively forbade their direct reports from using or engaging in discussions on the ESN. Upon inquiry, three things stand out:  

• the time spent collaborating and innovating (through the ESN or not) could not be clearly tallied towards the objectives guiding the managers' decisions. Nobody was going to get a bonus for or by using the ESN - it was "a waste of time". 
• the managers seem to have perceived the ESN as the threat to their authority. Specifically, if their reports could bypass them to engage directly with others in the company, they might discover that their bosses were less competent than previously believed. Alternatively, if someone had to ask the ESN for help, it might reflect poorly on the manager who, it would be assumed, had not provided the answer or guidance.  
• the managers also perceived, in a less explicit way, that an informed workforce requires leaders, rather than managers - that is to say bosses that inspire and facilitate rather than know and control. Ill-trained (or untrained) for this new responsibility, they could not take it on. 

We see here that this attempt to free knowledge and information in the corporate organization was thwarted by fear; fear of being exposed as less-than-competent and fear of actually being unprepared for one's new tasks. This fear, obviously, is just that: most of the managers are actually competent, and it results from lack of confidence. 

Confidence both in oneself and in the goodwill of others is a crucial ingredient for success that appears to have been lacking at the individual and corporate levels. To "develop individual initiative and individual ability to work with each other" in particular through the liberation of information flows within the organization - the ESN's purported objective - we need to ensure that the staff understands and buys into the shifts required in their positions, prerogatives and responsibilities. I propose that one way that this can happen is if those affected by the changes are :  

1. sufficiently self-confident that they accept to challenge the status quo and their position therein 

2. convinced that their management, peers, and reports will treat their experimentations and questions (and potential failure) with goodwill and that they will be given the necessary training and support to succeed.  

Treating employees with kindness, trust and respect is a good place to start building  self-confidence and corporate goodwill. Almost more importantly, giving employees the freedom to err, and even to fail, is the highest show of confidence and encouragement to their ability to make decisions - to take initiative.

Accumulating Knowledge Vs Learning

I'm an IT guy. I've been working for 25 years in this business doing just about any job you can think of. I've been working in different industries, different countries, using different types of technologies, from IBM Mainframe technology built in the 60s to 00's avant-garde mobile start-ups.

My strategy to survive in this fast-pace changing business has been to think in patterns. This comes from IT industry standards called Design Patterns. The baseline is : for every problem that will slow you down you while designing a software solution, someone has already bumped into it and standardized a generic design solution.

This is both a bless and a curse. This is a bless because it has saved me time, it has allowed me to easily navigate the IT world and be somehow successful. The curse is that it has deeply shaped the way I think : rather than really trying to understand the problem, I've just tried to recognize known situations to apply prepackaged patterns : talk about preconception and jumping to solutions ! What's more, this thinking results in over-engineering (a disease of Java programming language and more generally enterprise software) and a tendency to tackle world complexity with abstract, generic and complicated solutions while forcing patterns where they may not have necessarily applied.

This is just a continuity of the way I've been educated : building stocks of knowledge (accumulating patterns as "how to" or anti-patterns as "how-not-to"), thinking the more stocks I have, the more weapons I will have to shoot problems and discordant voices down. The issue here is that you don't eradicate problems this way, just their symptoms : the difference between fast thinking and deep thinking. Not to mention that in the process you don't really show much respect to people.

For the last couple of years it has just occurred to me that lean thinking is different. It aims at really showing respect to people while trying to understand the problem (and being kind to it), then making hypothesis, testing them and learning while measuring the difference between the expected result of hypothesis and the real world. Learning while doing and fully, deeply understanding what hinders our thinking process while surfacing our preconceptions. As Joshua Foer puts it, this helps in trying not to stay too long on the OK plateau and the comfort zone to get back to the cognitive stage.

 
Design Patterns are stocks of knowledge and, as such, static entities, which make every problem looking like the proverbial nail. Learning is a dynamic discovery process. Accumulating stocks of knowledge is not learning : this is what Lean has helped me to clearly see.