Can We Please Talk About Capabilities?

As a researcher, I look to provide executives (or indeed anybody who takes from their precious time to read my work) with insights from data that I have collected; construct patterns from what I am observing or hearing from interviewees (at least my interpretation), often by piecing together disparate views, to help a reader or listener makes sense of a particular phenomenon; and sometimes, if I can, offer recommendations. Regarding the latter, something has been bugging me for a long time, particularly prescriptions relating to what it takes for success with digital transformation, an area where I conduct research.

Anyone who has been reading academic or practitioner articles or indeed reports from consultants on this topic will no doubt recognize that prescriptions almost invariably recommend building certain – listed – capabilities. Irritatingly, most don’t usually go beyond bland statements of ‘build this...’ or ‘build that …’ capability, without providing any guidance as to what the writer understands by the concept of capability. It is as if the assumption is ‘sure everyone knows what a capability is.’ Unfortunately, this not the case, although everybody will likely have their own personal viewpoint. Cynically, it could be argued that the capability label has become a convenient tag to attach to a recommendation to give it a semblance of credibility. Moreover, it is as if using this label somehow absolves the writer from going beyond making glib statements or providing single sentence descriptions. In fact, I would argue that the term is now used so frequently, for different purposes and in confusing ways, that it has rendered it almost meaningless.

Let us look at some examples. Overnight, one IT management maturity model changed what had for many years been labelled as ‘critical processes’ in its model to ‘critical capabilities.’ Research reports from another academic research center invariable recommended building capabilities, yet there seems to be no consistency in usage of the label or guidance as to how all these capabilities they have recommended organizations build actually ‘fit’ together; whether there are any overlaps or indeed if there is a sequence in which they should be developed?

The notion of a capability is very ambiguous anyway. Poll any c-suite as to what a capability is and you are likely to get as many different responses as there are members of the leadership team. The academic literature has debated the concept for many years, although the notion of competence seems to have gained early traction among some scholars, with core competence and more latterly dynamic capabilities appearing frequently in the scholarly discourse, particularly in the strategic management discipline. Despite this, there is little consistency or agreement in usage of all these terms. Indeed, you would be forgiven for leaving the debate with the puzzling question as to whether a competence is really another name for a capability?

A review of the literature also reveals that capabilities are portrayed at different levels: individual (e.g. a person’s problem solving, analytical, decision-making or communication capacity), organizational (e.g. a company’s design, analytics or supply chain ability), even country (e.g. manufacturing heritage). Technology itself is seen as providing particular capabilities, although exactly what these are or whether they are different from other capabilities can be unclear. Data is sometimes represented as a capability (but confusingly referred to as an asset or a resource in other streams of research, begging the question as to whether both are in reality capabilities?). Some researchers make reference to digital capabilities, as in the need to build such capabilities, without elaborating on the concept.

Recommendations referring to capabilities can also appear bland. For example, one study identified ‘conversations at Executive Committee on operating model around digital issues,’ ‘investing in the right infrastructure’ and ‘measuring digital spend and performance over time’ as so called Foundational Capabilities for digital. While it is unlikely that arguments will be made against any of these, it might even be argued that they are obvious, they do not seem to be at a similar level of analysis. Moreover, I would have imagined that having ‘conversations’ are central to any decision-making process concerned with identifying the ‘right’ infrastructure and in making investment decisions, begging the question as to why are conversations at the ExCo labelled a capability. Even the notion of an operating model can have multiple interpretations. Moreover, perhaps a company might ‘invest in the right infrastructure’ but implement it badly, then what?

Some researchers argue that they have abstracted the reported ‘capabilities’ from their data, and it is a label that they are using to capture and convey what they are observing. The underpinning logic is that this <named> capability (or these capabilities) was observed and is attribute to the success being studied. On closer inspection, such data is often from a single case study or a small number of cases. Either way, there will be limited generalizability. What is usually not evident from the case descriptions is exactly how the case organizations have built the so called capability or capabilities. Of course, the simple reason is that the research didn’t have this as an objective, the capability is what was observed.

What is often not acknowledged is that it is incredibly difficult to prescribe exactly how to build a capability. Research that seeks to uncover how a particular capability was built frequently finds that it was either not planned or its emergence didn’t follow the planned route and that it is only in hindsight that it can be pointed to. Moreover, whether what one company did to build a so-called capability is applicable to others is a moot point. Organizations are, after all, different.

It is probably for this reason that capabilities have been described as an ‘amorphous heap.’ Even companies themselves struggle to unpack their so called capabilities, particularly those that – usually believed by others – provide them with a competitive advantage. Indeed, companies often try to replicate a competitor’s winning capabilities (or are they core competences?), frequently by headhunting some of their staff, trying to create what is observable, but struggle to achieve this objective.

One reason is that a capability can be seen as the emergent property of a myriad of elements. Some of these can be tacit, making them difficult if not impossible to observe. For example, a capability will emerge from a mix of organization structure, processes, knowledge, practices, standards, routines, social fabric, leadership, champion, culture, language, etc. Identifying all of these and the prescribing how they come together is extremely difficult. In-depth studies can provide some insight but few researchers have the time or resources to really get ‘into the weeds.’ The secret sauce remains just that, secret. But, of course, this does not fit the narrative for the audience; executives like prescriptions!

Another reason is that research has also shown that building capability is very likely to be path dependent, that is, history matters. Everything has causes, and sometimes different causes can lead to different outcomes, especially in different contexts. For example, if you decide you would like to be a world class marathon runner, you cannot just copy the training schedule of an elite runner. They will have had years of training behind them that enables them to now train at this high level. Even if you have a similar physical and psychological make-up, a big assumption in itself, over the years they will have adopted both physically and mentally to the rigors of training as well as learned the craft of racing. Don’t believe me? Trying running 20 miles (32 Km) a day from a base of little or no training! And, of course, there are also many different theories as to what contributes to elite performance.

This not to suggest that authors are wrong to suggest building capabilities as a recommendation from their research. It is just that they should be a bit more specific in the language they use; don’t just throw the label around like confetti. Elaborate on what the reported research understands by the notion of a capability. Go beyond a mere description of the capability. If the capability was observed from data, make that clear and emphasize that the research did not seek to understand how that observed capability was developed. Recognize also the path dependent nature of capability development. Include the important health warning that there are probably tacit elements to the capability that limit prescriptions.

In the end, the notion of a capability might provide a nice conversation point but there are likely to be many ways to build one. Insights from other organizations can be useful and provide food for thought, but a leadership team will have to figure out what is applicable in their particular context. There are no quick fixes. Remember, you cannot just take the training schedule of an elite marathon runner and expect to become world class. If it was only that easy….