In the O’Reilly book Seeking SRE our colleague Richard Cook and I wrote a chapter entitled “SRE Cognitive Work”.
You might notice on this blog (as well as Lorin Hochstein’s, Thai Woods’, and Resilience in Software Foundation (RISF) community posts, and many others) we often reference the term cognitive work when talking about the challenges engineers face in the all of the work they do.
But what is “cognitive work”? Is it just a pretentious way of saying “thinking”? Or “psychology”?
What’s the difference between the way Cognitive Systems Engineering (CSE) and Naturalistic Decision-Making (NDM) use it, and how traditional psychology uses the term ‘cognition‘?
In the context of classical psychology, cognition (memory, attention, perception, reasoning) are typically treated as a properties of an individual mind, studied by isolating mental mechanisms from the specific context the person is in. Historically, the primary goal has been to develop general laws about how minds work, applicable across domains because they’re abstracted away from any particular one.
Cognitive work is a different thing with a different unit of analysis. It is cognition as it functions to get something done in a specific field of practice, and under the actual demands people face: time pressure, uncertainty, incomplete and changing information, multiple interdependent actors, consequences that matter, etc. The “messiness” of this is a feature, not a bug.
A few things follow from this:
- It’s macro, not micro. CSE & NDM ask “What does this situation demand cognitively: sensemaking, anticipating, replanning, managing uncertainty, coordinating across people?” rather than “Which memory subsystem is engaged?”
David Woods and Gary Klein talk about macrocognitive functions (sensemaking, planning/replanning, coordination, detecting, etc.) as the relevant vocabulary that is different than the microcognitive processes (working memory capacity, attention allocation) that experimental psychology studies focus on. - It’s focused on the distributed, not the individual. In CSE, the primary focus is the joint cognitive system. This is the particular coupling of people, artifacts, representations, and automation that together produce the work. You can’t locate the cognitive work inside one person’s head when it’s actually happening across a Slack channel, a set of telemetry interfaces, and teammates. If you were to ask “whose cognition?” the honest answer would often be “the system’s.”
- It’s context-dependent. Cognitive work is shaped by the structure and constraints of the work domain itself. The same “cognitive process” (for example, diagnosis) looks different and demands different things in a NICU than in an air traffic control tower, because the domains impose different demands. As a result, CSE’s move is to first analyze and then aggregate, rather than what many other fields do which is to first aggregate and then analyze.
- It’s situated. In other words, it is revealed through practice and not self-reported through surveys or through artificial tasks. Gary Klein’s critique of classical decision theory (which held that when making a decision, people construct a list of options, weigh them against each other and then choose the optimal one), was that it didn’t describe what skilled practitioners actually do. He and colleagues studied firefighters, ICU nurses, pilots, all experts, in their own settings, on how they made decisions that matter. This led to recognition-primed decision making as a description of real expertise, which classical decision research would never have surfaced because it wasn’t looking at work.
So, psychology asks what minds generally do; cognition typically describes the individual mental machinery psychology studies in the abstract; and cognitive work is what CSE/NDM actually cares about. This is because it’s about the real and messy business of meeting the demands that real-world work creates, jointly by people and their tools, and observable only by going and looking closely at the work itself instead a simulated shadow of it in a lab.
Ok, great. Enough abstract description, let’s take a look at what this looks like in software engineering.
The big-but-zoomable image below lays out (after some minor adjustments to make it easier to map to real-world work) six areas of cognitive work, some high-level examples of each, and a few concrete ways they typically manifest in software engineering work. (Some areas do lean a bit in SRE directions, that is deliberate.)
Does this help make the concept of cognitive work a little clearer?
In an upcoming post, I will outline the many ways that cognitive work connects to the rapidly-growing adoption of AI usage and use cases…for the better, and the worse!
