Principle of Low Cognitive Load

The DocOps principle of low cognitive load states that DocOps efforts—the implementation of new technology, and processes—must observe the fact that there is a natural limit to how much information humans can process at one time. The importance of respecting “the intrinsic limitations of the human mind” was key to Dijkstra (1979) and is the last but most important principle in DocOps.

In 1956, George Miller suggested that there is a fixed capacity for the human ability to receive information, and that this limit lies at around seven items. There is, in other words, “an inherent constraint on the brain’s bandwidth” (Klingberg, 2009)

Except that seven is an actually rather optimistic limit. As explained by Nelson Cowan (2005):

“Miller did not really mean it. As he mentioned in an autobiographical article (Miller, 1989), he introduced the magical number 7 in a tongue-in-cheek fashion to allow him to link together two lines of his own research that he perceived as having little in common. Many readers have failed to perceive the situation in that manner and have accepted the number 7 at face value.”

Cowan, a distinguished professor of psychological sciences at the University of Missouri, who specializes in working memory, found after years of research and conducting various experiments that “the average adult can retain three to four chunks in working memory, and that this near-constant capacity of working memory holds true across a wide range of test situations.”

In addition to the experiments conducted by Cowan and others, he also suggested that there might be a theoretical explanation for this natural limit. Two scientists, Dirlam (1972) and MacGregor (1978)—under the assumption that memory is structured hierarchically—argued that “a capacity of about four items may allow the most efficient working memory search operations.” This finding would not come as a surprise to holders of degrees in computer science.

The process of reducing cognitive load is not something that we have achieved simply by shifting from mechanical typewriters to computers. We are still in the process of optimizing our writing systems—now digital—around the issue of cognitive load. As explained by Walter Ong (2002), a former president of the Modern Language Association, “…we find it difficult to consider writing to be a technology as we commonly assume printing and the computer to be. Yet writing (and especially alphabetic writing) is a technology.”

It wouldn’t be preposterous to consider those who created—and then optimized—the alphabet, the first DocOps engineers. The original alphabet was invented by the Semitic peoples around the year 1500 BCE, which revolutionized writing by capturing sound using simple strokes—in contrast to the Egyptian system based on hieroglyphs. The Semitic alphabet had a serious flaw, though: it was consonant-based. For example, “this is ancient writing” would be written as something like “ts s ncint wrtng”

Fixing the Semitic writing system would be the job of the Greeks, who by adding vowels, democratized writing in the ancient world, creating a system that was accessible to everyone and easy for children to learn. The Greek alphabet was such a game changer in the ancient world that it “provided a way of processing even foreign tongues.” as explained by Ong.

But many other ‘bugs’ would need to be ironed out to reach our current, and not yet complete writing system. The alphabet used by the Western Roman Empire, for example, had no spaces between words. In this case, the sentence “this is ancient writing” would be written as “THISISANCIENTWRITING”, also considering that Latin did not use lowercase characters. The curious omission of spaces—for us people in the twenty-first century—is easy to spot on inscriptions found on Roman monuments when visiting Italy.

Nicholas Carr (2020), a Pulitzer Prize finalist, and former executive editor of the Harvard Business Review, explains, based on the work of Paul Saenger, that such a system caused significant “cognitive burden” to the readers of that time:

“Reading was like working out a puzzle. The brain’s entire cortex, including the forward areas associated with problem solving and decision making, would have been buzzing with neural activity. The slow, cognitively intensive parsing of text made the reading of books laborious.”

The organization of books into paragraphs and chapters would not appear until the end of the fourteenth century. 

Today, armed with a better understanding on how our memory works, and what our cognitive limitations are, it is our responsibility to build documentation systems that, in addition to being low in cognitive load, are also a delight to use.

Working Memory versus Long-Term Memory

The reasons as to why so many large enterprises suffer from atrocious documentation practices—such as maintaining monolithic files stored in silos such as Microsoft Teams, DropBox or any other ‘shared folder’ mechanism—can be probably partially attributed to the lack of understanding between the differences between working memory and long-term memory.

Working memory “is normally used to keep information active for a few seconds, while long-term memory can keep it stored for years on end” as simply explained by Carr. The expectation that a knowledge worker would read a series of documents A, B, and C, store them in memory—under the wrong assumption that there is only one type of memory—after which the knowledge will be consolidated and readily available in the worker’s head does not agree to with the science on how our brain works.

Committing knowledge to long term memory requires substantial amounts of re-reading, re-interpretation, outlining, summarization, and rehearsal. The required effort is a function of the complexity, unfamiliarity, and length of the document in hand. All of which is further compounded when two or more documents need to be contrasted or correlated.

Knowledge workers in the enterprise, unlike priests and pastors, are not in the business of memorizing passages of texts—let alone entire documents—but in the pursuit of solving concrete problems for which only pointed, relevant information is useful. This requires active reading, also known as skimming. As Steve Krug (2006), in his bestselling book, Don’t Make Me Think!, noted, “we don’t read pages”, instead, “we scan (or skim) them, looking for words or phrases that catch our eye.”.

Active reading involves first setting the information items that describe the goal in hand in working memory. Any matches that we find, while retaining the goal in mind, will consume further working memory ‘RAM’. Also, any relevant detail committed to long term memory that is useful needs to be ‘activated’, which means that it will consume further RAM as well. The notion that both ‘new items’ and ‘old items’—drawn from our long-term memory—consume a shared pool of working memory is what Cowan calls the embedded process model. The issue, as discussed before, is that we can only store, on average, only four of said items in our limited brain ‘RAM’.

Context Switching

While every—average and adult—human being is bound by the four item limit, the enterprise knowledge worker faces an additional problem, context switching, which they incur whenever they have to multi-task to satisfy a knowledge goal. In the words of Carr, “every time we shift our attention, our brain has to reorient itself, further taxing our mental resources.”

The passage of time, together with constant context switching rapidly depletes our working memory, forcing us to ‘refresh’ our working memory over and over, a phenomenon that is familiar to those of us who frequently wonder why we ended up with so many browser tabs, so tiny that we can’t even read their titles anymore.

Miller (1960) identified five additional behaviors that a person may exhibit under cognitive load:

• Error — processing the information incorrectly in some way 
• Queuing — delaying processing of some information with the intention of catching up later 
• Filtering — processing only that information identified as having “high priority”
• Multiple Channels — splitting up the incoming information in order to decentralize the response
• Escaping — giving up the burden of attending to inputs entirely

Reflection

While the impact of context switching is relatively obvious at a macro level—e.g., being interrupted during an intense mental activity when the boss taps you on the shoulder to ask a question—it is less understood within the context of a pure digital knowledge workflow.

The purpose of rolling out contemporary documentation systems and applying DocOps best practices is precisely to relieve users and their employers from falling onto such unproductive knowledge gap-filling workflows.

The opposite of high cognitive load—caused by context switching—is commonly known as flow state (Nakamura & Csikszentmihalyi, 2002) or being ‘in the zone’. In a flow state, the user fills knowledge gaps almost immediately as they appear, without losing track of the context that gave rise to them.