There isn’t an organizational leader who will claim that they don’t need some kind of process improvement. Ditto, there isn’t a leader who won’t agree that modern methods of digital transformation, like Agile, Lean, Data-driven or Cloud ought to be adopted. This would be to go against the grain of progress, or be like denying the value of innovation — i.e. foolhardy. And so, in the interests of progress, various transformation programs are rolled out in corporations. However, many of them deliver lackluster results, or fail.
5 Major Problems
Here I rely upon direct experience to diagnose, at least partially, the malady. I have identified five major problems, although there are more. These are:
- The Dunning-Kruger effect
- Backdoor Hedging
- Authority Bias
- Mindset vs. Method
- KPI Syndrome
Each of these is worthy of its own article, but I will summarize all five whilst taking Agile as the transformational method in question. Before diving in, I should say that no one problem is sufficient to kill the project, nor does any one problem have a dominant effect. As with all organizational maladies, they typically conspire to produce a death by a thousand cuts. This is well discussed in Clayton Christensen’s Innovator’s Dilemma. In this article, I only explain the problem. I will leave the solutions to a follow-up article.
The Dunning-Kruger (DK) effect is the well studied phenomenon of overestimating one’s ability. For example, about 80% of drivers claim to have above average driving skills. Clearly, this cannot be the case by the ordinary laws of statistical distributions. But this attitude is widespread and prevalent in organizational behavior.
For transformation projects, it works as follows. Somewhere, a manager senior enough to influence the project (leader) will have comparatively little Agile experience. They will rely upon others to introduce the method, typically subordinates who are relative experts, if not outright experts. However, the leader will interfere with the implementation because of their overestimation of abilities. On the surface, Agile, like all methodologies, is fairly easy to explain and understand. This results in the leader overestimating their understanding, per the DK effect.
We don’t know what we don’t know
To understand this, we have to dig a little deeper into how this effect works. The simple explanation is that we don’t know what we don’t know and so tend to assume that our partial understanding is sufficiently complete to judge our ability. Returning to driving as the example, only a trained expert driver knows what good driving actually looks like. Armed with that knowledge, it is easy to judge an average driver’s averageness because the expert will spot all kinds of mistakes about which the average drive is unaware.
So how does the leader’s overestimation of ability (their understanding of Agile) affect results? As with all projects, there’s a superficial implementation and a proper implementation. We don’t need to know what these two ends of the spectrum look like, just that the spectrum exists. Typically, the leader, impatient for results, will push towards a superficial implementation whilst the instigator will push towards a proper implementation because that’s what actually works. (It is worth noting that a leader’s impatience for results is often exacerbated by the DK effect i.e. an underestimation of what’s involved accompanied by an overestimation of their confidence in setting timeline expectations.)
This tension will manifest in discussions during which the instigator will be forced, due to the leader’s lack of knowledge and experience (with Agile) to explain how something works or why it’s a good idea. In this dynamic, the leader will over-assert their view due to their overestimation of ability. Consequently, compromises will be made. Note that they are not compromises at all, but often implementation defects.
The effect can quickly strengthen
Justifying doing things the right way is often an unexpected challenge for instigators because what they take to be common knowledge (of how Agile works) will, for the first time in their experience, require justification. Many instigators are poorly equipped to make such arguments because they, like many practitioners, know how to make something work without necessarily knowing why it works (at least in any detail). It would be like an experienced driver trying to explain why so-called defensive driving is a good habit to someone who just doesn’t get it.
Ironically, this dynamic causes the leader to inappropriately judge the instigator as lacking expertise as witnessed in their poorly explained justifications for proper implementation. This only exacerbates the leader’s inflated estimate of ability thereby strengthening the DK effect.
By definition, anything new involves uncertainty, either in the method itself (such as Agile’s ability to handle unknown or incomplete requirements) or its outcomes — i.e. how well the transformation will work. Leader’s hate uncertainty, even though, ironically, that’s why Agile was invented — i.e. as a method to cope with the unassailable existence of uncertainty in complex projects. In essence, Agile is a set of heuristics.
A lack of experience leads to hedging bets
The leader seeks to lower risk. But this isn’t just about uncertainty of implementation or lack of faith in the method. This returns to the reality of the leader’s lack of experience with the transformation in question. So, instead of taking the time to dig deeper into the method and thus lower perceived risk via increased knowledge and familiarity, the default behavior is to hedge bets via a backdoor method that the leader claims is something else. I call this the Backdoor Hedge.
In its worst case, an Agile project ends up being a waterfall project via the backdoor. Participants are still required to draw up a project plan that is anti-agile. It might be disguised with words like Roadmap or Resource planning but is, in essence, a waterfall plan. Worse still, it is done in a tool like Excel, or, God forbid, Powerpoint – i.e. tools not fit for purpose and exceptionally cumbersome. The net effect is to add burden to the instigator’s workload and compromise their implementation of Agile.
A parallel plan undermines
Whilst the team is doing Agile, the leader is mostly relying upon the parallel project plan in Powerpoint to keep track of where things are and who’s doing what and when deliverables will drop. This massively undermines the transformation and, in many ways, makes a mockery of it.
By the way, this isn’t necessarily an age thing. Plenty of young folks will default to the backdoor method, but using a cooler tool like Airtable. The result is the same: they aren’t truly committing to transformation. Surprise, surprise — the leader secretly (or openly) wonders what’s so special about the transformational method whilst the old-school method still seems to work. And, as you’ve probably guessed, this reinforces the DK effect even further. At this point, we have fully fledged DK-spiraling (downwards).
As discussed, the knowledge gap between the leader and the instigator, amplified by the DK effect, causes tension between superficial implementation and proper implementation. This manifests itself in progress meetings during which instigators try to assert themselves — i.e. advocate for a proper implementation. It isn’t automatically the case that the leader wants a superficial implementation, although this happens with surprising frequency because often the leader’s true intent is merely to tick the transformation box. And, as many an instigator will know, many leaders will ask for a proper implementation but within the resource constraints of a superficial one: the unimaginative more with less mentality.
The impatient and disagreeable leader
However, some leaders truly want to do the right thing but, due to their lack of knowledge, can’t quite see why the extra effort is needed, especially as their patience begins to run out. Naturally, leaders will want to debate why going the extra-mile(as they see it) is needed. In those debates, it will be common for other relatively senior leaders to be present who also suffer from the DK effect, often even more so.
A compound effect occurs when these senior folk feel the need to inject their opinions in order to assert and reinforce their status. Often, the easiest way to do so is to take the contrary position of the instigator because that’s the only method of assertion available. Disagreeing with someone is a method to assert power, or, in this case, reinforce it. The problematic outcome is invariably that these senior leaders’ opinions will be heard – and valued – by the overall leader because of authority bias — the value of a statement being tied to the person’s status (authority) rather than the content of their speech.
It’s a lose-lose
For the instigator, it’s a lose-lose position. They fail to assert their argument, often because in their mind they are saying something so obvious as to not require justification, and now have to counter the (incorrect) counter-claims made by senior leaders. Disagreeing with seniors is also problematic in itself, especially when the culture (wrongly) makes it difficult to do so. The end result is that the leader falsely uses the arguments of senior naysayers to win the implementation debate with an instigator. Inevitably, this leads to an insufficient, or defective, implementation. Ironically, later on, this deficiency will be used against the instigators.
Mindset vs. Method
A transformational method cannot be applied like paint-by-numbers, just as a diet won’t be effective without a lifestyle change — i.e. a change in attitude, or mindset. If anyone doubts the power of mindset, I recommend reading Dweck’s Mindset: The New Psychology of Success. Put simply, method and motivation must align, as channeled through an overarching attitude.
Agile is a good example. The core of the method is really about letting go of trying to anticipate the future, recognizing that it is uncertain and, if we are honest, largely unknowable. Indeed, the irony here is that the more predictable the future is, then the more we must be repeating ourselves and, by definition, failing to move forward or to innovate.
The ‘highest paid person’s opinion'(HIPPO)
Mindset leads to behaviors which, in turn, reinforce mindset by setting the tone. This translates into company, or team, culture. If a leader acts in a way that insists on knowing the outcome of projects before they happen, then they are acting against the spirit of Agile. This approach will manifest itself in subtle, if not obvious, attempts to undermine the adoption of Agile. For example, in meetings the leader might default to the Backdoor Hedge as their main focus of attention and thereby undermine the value of Agile.
Another part of Agile mindset is the willingness to rely upon proper user research and representation in defining product features. All too often, a leader will assert his or her opinion as to which features are important. This leads to HIPPO pursuit of features – i.e. the highest paid person’s opinion. You’ve probably guessed that HIPPO is also a manifestation of the DK effect. In the absence of actual user reactions to features, leaders can become quite certain of their opinion of requirements just as the amateur driver is certain of their above-average driving. Rather, a leader ought to be making it clear to the team that the voice of the customer is uppermost, be it via data or research or — and this is controversial — actually talking to users. [Loud sigh here.].
Lack of genuine willingness prevents change
These failures of leadership mindset can be way more detrimental than perhaps imagined. Transformation relies upon the willingness of the entire team to adopt new methods and attitudes. Inevitably, not everyone will be equally willing — transformation often brings about associated discomforts. The instigator’s peers will be less willing to change if they see that their leader is only paying lip service to the transformation. This lack of willingness will seldom manifest as an outright protest or refusal to change. After all, don’t forget that the official position of the leader is that the transformation matters. However, the in real life lack of willingness will manifest as lots of subtle drags on the project. Don’t forget what I said — no one malady will destroy the project and the company, but rather it will die by death of a thousand cuts. Many of those cuts will come about due to misaligned mindset.
KPI Syndrome (and Vanity Metrics)
Leaders love KPIs, even though it is arguable that a good deal of KPIs are useless. Part of the problem is often the creation of vanity metrics. These are KPIs that are easy to make look good or drive upwards, but don’t really mean much. An example might be the number of tasks being performed, such as the number of sign-ups to a service, ignoring the efficacy of those tasks.
Brute force vanity metrics
These vanity metrics, and metrics in general, often become the focus of reporting, especially once leaders learn how to drive them in the right direction, often just by assigning more resources — i.e. brute force. Once you’re in the brute-force way of doing things, transformation is going to prove problematic because, if it’s any good, it ought to be making your business processes more efficient – i.e. the need for brute force ought to lessen. Leaders might be motivated to continue with brute force methods as these are making the leader look good via the bump in vanity metrics.
The double whammy of transformation and its interactions with metrics is as follows. Firstly, leaders don’t want to threaten their KPI trends and so worry about potential negative impact from transformation. Inevitably, this adds more pressure on the leader to resist transformation covertly, if not overtly via refusal to rethink metrics. Secondly, as said, the gaming of metrics is often via assignment of more resources, as in headcount. Transformation might call headcount into question., thus increasing resistance.
Conclusion and Caution
I have outlined five blockers to transformation. The Dunning-Kruger effect is one of them, but exacerbates all of them. As such, it is the biggest obstacle to change. There are ways to overcome this, but that is best discussed in a follow-up post. I wouldn’t want anyone reading this to think that, by centering my argument around the DK effect is the same as saying that the average leader is probably dumber than he or she thinks.
Applying Intelligence and assessing the situational are key
This is not about dumbness or ability per se. Rather, it’s about situational ability. The way that we conventionally measure ability is via academic achievement and, later, status e.g. career-climbing. We all fall into the trap of believing that our above-average intelligence, as exhibited in a good GPA, say, translates into above-average competence. This is simply not the case. Competence is about applied intelligence, not book intelligence. Indeed, I have encountered so-called Star Hires with PhD-level education from elite schools who are, on the job, extraordinarily ineffective. This is because the DK effect is not about levels of dumbness in any absolute sense, but relative to situational and domain knowledge — you don’t know what you don’t know and this causes you to believe in what you do know even stronger. There are other biases that emphasize this effect, such as preference of our own ideas over others simply because we are more familiar with our own ideas, which makes it easier to apply favorable heuristics to them (because that’s literally how we’ve rehearsed them in our heads).
We’re all at risk of these effects
I once coined the expression Moronically Brilliant Administrators as a tongue-in-cheek remark about MBA graduates overwhelmed by the DK effect due to their over-belief in ability conferred via schooling versus experience. Nicholas Taleb popularized a similar term – Intellectual Yet Idiot (IYI), although he seemingly had a more disparaging intent in mind. It is vital to understand that we are all IYIs. This is perhaps the most stunning insight from behavioral economist Daniel Kahneman — that even the most expert economists were fooled by their overconfidence and made seemingly simple mistakes in economic assessment of data. If we think we understand transformation, we probably don’t. This is why it often fails.
Paul Golding is an expert in applied technology, such as AI and Machine Learning. He is an IEE prize recipient with over 30 patents in diverse fields. Having worked in, or founded, numerous innovation teams, he is also well versed in innovation and transformation techniques. To read more from Paul check out his website.