Three o’clock in the morning, and somewhere an engineer is sitting in front of a wall of dashboards — all of them beautifully designed, mind you, clear labels, logical navigation, visual hierarchy to make a Swiss typographer weep — and the engineer still cannot tell how the failure is propagating, what the automated systems are doing about it, or how many minutes remain before the whole contraption gets worse. That, argues the consultancy Adaptive Capacity Labs in a new explainer of its founding discipline, is the moment when a century-old consolation of the software business — make it usable and the humans will manage — quietly comes apart.
The discipline has a name, and the name is Cognitive Systems Engineering: an interdisciplinary field that studies the cognitive work of people handling difficult situations — making decisions, detecting anomalies, building diagnoses, coordinating with others — in complex and consequential environments. Note the phrasing. Not what people should do, according to some procedure, checklist or run-book, but what people actually do when they are under pressure, the signals contradict one another, and every possible action carries some potential to make things worse. The field’s ultimate goal, per the Labs: use that understanding of cognitive work to design the technical systems — the tools, the interfaces, the artifacts — that support effective human-machine collaboration.
The questions are the tell. How do experienced practitioners recognize that something is going wrong before the alerts fire? How do teams build and maintain a shared picture of what’s happening, what’s been tried, and what’s expected to happen next? What makes some tools genuinely useful in a crisis and others a hindrance — even when those tools are perfectly “usable”? These are, in effect, the liturgy of the incident-room priesthood, the people whose expertise lives in the gap between what the dashboard says and what the machine is actually doing. And the answers, the Labs insists, rarely come from simply asking engineers — they come from understanding what the engineers actually do in those situations.
All of this, the outfit allows, is indeed how it earns its living — CSE is what underpins everything ACL does, and it is not shy about saying so. It is how and why its post-incident analysis goes deeper than the template jobs that only generate action items; it is why the firm keeps its eye on how expertise is built, shared, and sometimes lost. And it is why it keeps returning to what it calls the same uncomfortable truth: the things that make your systems harder to understand are usually the same things that made your business successful. The goose that laid the golden complexity, boys!
Because CSE ultimately informs the design of interfaces, it is often conflated with the “UX/UI” work familiar across the tech industry — a conflation the Labs is at pains to unpick, while directing the curious to a bibliography of seminal works maintained by Lorin Hochstein. The distinction, as the firm frames it, is the difference between polishing the window and studying what the person at the window is actually seeing at 3 a.m., hypothesis by hypothesis, trade-off by trade-off, with the clock running and the dashboards glowing like a chapel full of votive candles.