Big mountain, the 8th fatal flaw
I do not count the brainstorming sessions where people fall into what Matthew E. May called the fatal flaws in his book ”Winning the brain game” (@MatthewEMay). The facilitator has displayed the brainstorming rules on the wall and has made everything possible for the group to feel confortable, physically and mentally (http://bit.ly/2tEVauV) but inevitably everyone comes back to what he’s been doing everyday at work (and probably at home) jump to a solution in no time, forget to ask the others when sticking his own post-its, challenge the contribution of the other members instead of expanding or building on them. Things that our working practices ask us to repeat everyday.
Leaping (jumping to a solution), fixation (sticking to the proposed context - hard to detect in a digital environment, I would do everything possible to prevent people for proposing “an app” as the ultimate solution to a problem), overthinking (like a brain game in an engineers world), satisficing and downgrading (convincing ourselves that we’ve detected our overthinking flaw by deciding that it’s good enough now), not invented here (also called NIH, not easy to detect in the abstractions of the computers world) and self-censoring (even harder to detect). Those are the seven fatal flaws described in Matthew’s book. According to my own statistics, my top 3 would be: leaping, fixation and self-censoring, immediately followed by NIH.
But there’s another one that I keep experiencing everyday that I couldn’t match to any of those 7 flaws that I call “Big mountain” (Matthew, if you read this, can you help me ?).
Last January, we got a very strong escalation form our customer and the request to fix our patch management action plan in due time. Some security deviations had been published for more than 2 years and nothing had been done to tackle them seriously, despite the strong dependance with the application layer. We were enjoined to provide an agressive action plan with delivery dates. But this action plan did not make progress in the first quarter and I was asked, if not urged, to fix it by next month. But the team just couldn’t make a single move in front of this big mountain. I knew we were working under drastic costs and staffing constraints, that we had to face turnover in the middle of this. At the same time, I was studying the Agile methodology from which I retained 2 capital concepts: minimize work in progress (WIP), minimum viable product (MVP). How could I explained and convince the team to minimize WIP in a context were workload was at his maximum ? Well, let’s cut this action plan into small pieces. But there was a blocking effect that I cannot explain (is there a cognitive bias for this ? I haven’t found anything in my numerous readings). When asking my team leader to cut the action into small pieces he replied to me “this is impossible”. I decided to to look at it with him in detail. Looking at the deviations I could see that they had already been categorized in an Excel sheet. Some categories were even divided into waves, according to the weight of the deviation. Also, the fixes had to be applied to different categories of servers, critical and non-critical, and we also had to follow the deployment cycle, test, validation, pre-production and production servers. Very classical stuff for those who are familiar with managing servers in a Data Center. Everything was in front of our eyes, but there was no energy (again, I don’t know how to explain) to take the list of thousand deviations and cut it into small pieces and GO. I do not say that we fixed everything in one month but we started moving ahead, reported our constant progress in climbing the big mountain one step after the other.
I threw away the action-plan-follow-up-spreadsheets and replaced them by a Wall-of-work and started to reinforce the different principle of an Agile team. Minimizing the WIP make better moves than not moving at all. Every customer is ready to accept that. The effect is simply stunning and help the team to restore some confidence.
Another action plan, and another customer escalation was raised last month. We addressed it in our weekly meeting. Another backlog had developed and we had to provide resolution dates for the week after. I asked a team leader to cut the plan into pieces (just like we’re doing for everything now) and the answer was: “But it’s impossible”. OK, let’s look at it. The action item in the backlog was again classified into categories, types of servers, different middlewares, different criticity classifications. It was there, in front of our eyes. Why was it impossible to cut the action into pieces ? What make this big mountain block our vision, impair our ability to frame the problem, forget for a moment the urge to provide the solution in one row ?
We find ourselves in front of Big Mountains and cannot just make the first step. I remember a nice television show where a star is taken to a country far-way. She shares the living conditions of a tribe for a couple of days. No electricity, no running water, no solid house, they always eat the same food, whether it is fish or reindeer, the tribe moves their tents from one place to the other regularly and they take their herds to the other side of the mountain. The star, a young actress, had to climb with them to the top of the mountain. Looking at the peak, she felt disheartened. One of the native told her: “don’t look at the objective, take a step one after each other”.
Here is the Big Mountain syndrome. Problem: feeling paralyzed in front of a big challenge. Solution: cut into pieces. I can’t really match this syndrome to any of the 7 fatal flaws, although I have been impressively confronted to it a number of times. Where does it come from ? What does neuroscience (or just psychology) says about this ?
Also read “Super Hero, the 9th fatal flaw” (http://bit.ly/2wQjwaI)