If outcomes are shaped by systems, then improving results starts with understanding the systems that produce them. The challenge is that systems are often hidden. We experience their outputs, but not the structure behind them.

Flow diagrams help make those structures visible. At their simplest, they show how things move—how inputs become outputs through a series of steps and interactions. But more importantly, they force clarity. The moment you try to draw a system, you quickly discover what you don’t actually understand.

These diagrams aren’t just about sequences but rather causality. They help answer questions like: What leads to what? Where are the bottlenecks? How does feedback shape outcomes?

Take something as ordinary as a shower. You turn a knob, feel the temperature, adjust, and repeat until it’s right. Beneath that simple process is a full system: you as the agent, the knobs as controls, water temperature as the output, and your perception as the feedback mechanism. There’s even delay! If you adjust too quickly, you overshoot and create instability.

When you map this with a flow diagram, key insights emerge. The system is self-correcting, delays matter, and the human is a part of it. Your expectations and reactions directly influence performance.

This matters because without seeing the system, improvement becomes guesswork. With a diagram, you can identify leverage points like reducing delay or automating control with a thermostatic valve.

And this scales. In organizations, controls become policies, outputs become metrics, and feedback loops show up in performance reviews or market signals. Without visibility, people overreact, misalign incentives, and create inefficiencies.

Leave a comment

Share Systems of Human Performance

What separates organizations that truly improve from those that stay busy but stagnant is simple: some are built for action, while others are built for learning.

Most organizations prioritize speed. They decide, execute, and move on. But without structured reflection, they never really understand the consequences of their actions. Improvement becomes guesswork. It may work occasionally, but it rarely compounds. That’s why many organizations end up in cycles of firefighting, often relying on a few high performers to carry results.

Real learning, as described by John Dewey, comes from reflecting on experience. It requires observing outcomes and updating your understanding of how things actually work. In most organizations, though, action outpaces interpretation. Insights are informal, quickly forgotten, or never fully developed.

This becomes even more problematic in complex systems. As Buckminster Fuller emphasized, problems cannot be understood in isolation. Organizations often make changes that improve one area while unintentionally creating issues elsewhere because they don’t see the full system.

That’s where structured learning cycles come in. W. Edwards Deming’s PDSA cycle is not just about improvement, but about building knowledge. In practice, however, the “Study” phase is often rushed or skipped. Organizations assume that if a metric moved, their action caused it. Over time, this leads to “best practices” that are never fully understood. The result is a fragile system where knowledge lives in individuals instead of the organization. When those individuals leave, the insight leaves with them.

Stronger organizations take a different approach. They treat learning as the unit of progress. They run disciplined experiments, study results carefully, and capture what they learn so it persists over time. Frameworks like Lean Startup follow this same principle.

The result is a shift from reactive change to compounding understanding. Instead of relying on heroic effort, the system itself becomes more capable. That is the real distinction. Improvement can happen without understanding, but learning changes the system so that each step forward builds on the last.

Leave a comment

Share Systems of Human Performance

Our Western culture tends to value persuasion. Persuasion is the art of convincing others through reason, argument, and influence. Entire industries and bestselling books are built on the idea that human behavior can be changed by changing minds. But in practice, persuasion often falls short. People speed, eat poorly, ignore safety rules, and act against their own knowledge. Belief does not reliably translate into behavior.

An alternative is Rational Control: shaping behavior through the environment rather than through persuasion. Instead of trying to convince drivers to slow down, you install a speed bump. The outcome is achieved not through agreement, but through design. The desired action becomes the easiest or most natural one.

This idea appears in books like “Nudge” which develops the concept of “choice architecture,” where small changes in how options are presented can significantly influence decisions. As an example, the authors of “Nudge” run an experiment where they place healthy food at eye level to encourage better eating. It works! This notion or engineering choice behaviors has roots in human engineering, where systems are designed to reduce error and guide behavior, as seen in safer cockpit layouts or intuitive product design.

Rational Control works because it is consistent, scalable, and does not depend on constant effort or agreement. While persuasion still matters for values and complex decisions, well-designed environments are far more effective at producing reliable behavior.

Behavior is shaped not wholly by what people believe, but to a surprising degree by the systems they operate within. Good design makes the right choice and the easy road the two of the same.

Science is widely assumed to be a force for good, largely because it is associated with progress, longer lives, and greater control over the world. Yet this belief is rarely argued for, it is simply taken for granted. In reality, science itself makes no claim about being beneficial. It is a method for generating knowledge about what is, not what ought to be. It contains no principle ensuring that more knowledge leads to human flourishing.

This confusion deepens when science is equated with technology and progress. While scientific discoveries have enabled life-saving innovations, they have also made possible new forms of harm. Every technology carries a “shadow”: the train brings the train wreck; aviation brings the crash. These outcomes are not accidents external to innovation, but inherent possibilities that arise alongside it.

Science operates upstream of technology by expanding what is possible. But whether these possibilities lead to benefit or harm depends on the systems into which they are introduced. The same scientific knowledge can produce radically different outcomes depending on how it is used and governed.

Crucially, science not only feeds into these systems; it is also shaped by them. What gets studied, funded, and applied is influenced by political, economic, and cultural forces. As a result, science can amplify both good and bad trajectories, increasing our capacity to solve problems as well as create them.

Ultimately, science generates knowledge, technology creates capability, and human judgment determines ends. But science itself offers no guidance on what those ends should be. Its progress expands our power without answering whether that power should be used. The belief that science is inherently good, then, is not a scientific conclusion.

There is a building in Arlington, Virginia that was designed not merely to house people, but to coordinate them. The Pentagon, with its concentric rings and radial corridors, is often understood as an architectural or military achievement. But its deeper significance is organizational. Every element of its design reflects a theory of how human effort should be arranged, how information should flow, and how decisions should be made at scale.

This is what Lewis Mumford meant by the “megamachine.” He was not describing a piece of equipment, but a structure of coordinated human activity. A system in which individuals are arranged into roles, linked through processes, and directed toward a common output. The machine is not made of steel. It is made of people.

Once seen this way, the history of human achievement begins to look different.

The pyramids of Egypt are usually remembered as early engineering marvels. But the tools required to build them were simple and widely available. What was not widely available was the ability to organize tens of thousands of people into a single, coordinated effort sustained over decades. The true innovation was not mechanical. It was organizational. The method preceded the machine.

This inversion matters. It suggests that scale does not begin with tools, but with arrangement. That human capability is first extended by how effort is coordinated, and only later amplified by physical technology.

We can trace this pattern forward. The Roman Empire is often associated with its roads and aqueducts, but these were expressions of a deeper capacity: administration. A system of governance, logistics, and military organization that allowed activity to be coordinated across vast distances. In the modern era, the same principle appears in different forms. Corporations coordinate capital and labor. Universities systematize knowledge. Hospitals transform care into a structured, repeatable process. Each represents not just an institution, but a technology for organizing human effort.

Even the Industrial Revolution, so often told as a story of machines, is equally a story of organization. The factory did not simply introduce mechanical power. It introduced a new way of arranging work. Tasks were divided, sequenced, and standardized. Workers were brought together not only to use machines, but to be coordinated. Adam Smith’s pin factory is a canonical example, not because of the tools involved, but because of the organizational insight. Output increased because work was structured differently.

In this sense, the machine served as a model. A system in which every part has a defined role, every action contributes to a common purpose, and nothing is left to chance. The factory adopted this logic and applied it to human beings. Over time, that logic spread outward into bureaucracies, education systems, and corporate hierarchies. These were not secondary effects. They were the diffusion of an organizational technology.

But like all technologies, organizational forms are shaped by constraints. Early systems relied heavily on centralization because alternatives were not feasible. Limited communication and measurement made it difficult to coordinate activity without hierarchy. The pharaoh, the factory owner, the military command structure all reflect this constraint.

When those constraints change, the forms change with them. The transition from steam-powered factories to electrically powered ones allowed work to be distributed differently. The same principle applies to organization. New methods, better information flows, and improved coordination mechanisms make new structures possible. The assembly line, the divisional corporation, and more distributed production systems are all examples of this evolution.

Centralization, then, is not the essence of organization. It is one stage in its development.

What remains constant is the function. An organization takes inputs, applies a structured transformation, and produces outputs. It defines roles, establishes processes, and directs effort. In doing so, it creates capabilities that did not previously exist. This is precisely what we mean by technology.

The implication is straightforward but often overlooked. The primary driver of large-scale human achievement is not just the tools we use, but the way we are arranged. The most significant advances have come not from better components, but from better coordination. The power lies in the design of the system itself.

To treat organization as incidental, as background structure or administrative overhead, is to miss its central role. It is the mechanism through which effort is transformed into outcome. It is the machine behind the machine.

And like any technology, it can be designed, improved, and replaced.

What is Technology?

Ask someone what technology is and they will point to objects. Phones, machines, software. The visible artifacts of progress. This is the default answer, and it feels sufficient until you look a little closer. The object-oriented definition leaves something out. It assumes technology is a thing, when in reality it is just as often a way.

The U.S. Army is a premier learning organization and they’re no stranger to using new and advanced technologies. So I thought it would be helpful to see how they think about technology. Interestingly, they define technology in a threefold way: knowledge, techniques, and tools. The implication is easy to miss and hard to overstate. The way something is done is as much a technology as the machine used to do it. Once you see this, innovation starts to look different. It is rarely the product that changes everything. It is the method upstream.

For instance, A manufacturer improves output not by buying new equipment, but by changing how materials are processed. The gains show up in cost and speed, not in new machinery. Artificial intelligence follows the same pattern. The hardware matters, but the breakthrough is methodological. A new way of organizing and associating data. The same electrons, doing different work.

History is full of these surprising revolutions:

Double entry bookkeeping enabled modern commerce without inventing a single physical tool. It created a reliable method for tracking value and detecting error. A new capability emerged from a new way of recording transactions.

The surgical checklist reduced complications and deaths without introducing new instruments or procedures. It ensured that existing knowledge was applied consistently. A simple method, with disproportionate impact.

The Toyota Production System transformed manufacturing not through superior machines, but through techniques. Just in time production. Standardized work. Visual management. Competitors had access to the same equipment. They did not have the same method.

Standards follow the same logic. They are agreements about how something is done, measured, or described. Thread standards made interchangeable parts possible. TCP IP made the internet possible. These are not objects. They are methods that create compatibility and scale.

Measurement itself is a technology. It does not just describe reality. It makes control possible. Without it there is no precision, no repeatability, no improvement. What you measure determines what you can manage, and how a system behaves.

Even the design of environments functions this way. When a workspace is organized so that the right action is obvious and the wrong one is visible, performance changes without new tools or additional effort. The method is embedded in the environment.

The pattern is consistent. Some of the most powerful technologies do not look like technology at all. They look like process, standards, or routine. And this is where organizations make a mistake. Methods are treated as administrative detail. Standards as overhead. Measurement as secondary. But under a broader and more accurate definition, these are core technologies. The constraint is usually not a missing machine. It is a missing method.

You finished the article!

It was free!

Please:

Share Systems of Human Performance

Leave a comment

Subscribe now

Most problems in organizations are diagnosed in the wrong place.

When performance slips, the instinct is to look everywhere for weaknesses. Improve the slow steps, train the struggling employees, upgrade equipment, or optimize each part of the operation. But systems do not work that way. Results are determined less by the average performance of the parts than by the single part that limits the whole.

This idea sits at the center of the Theory of Constraints.

A simple metaphor explains it. Imagine a chain. Each link has a strength, but the chain will always break at one point: the weakest link. Reinforce every other link and the chain still fails in the same place. All that work changed nothing, because the system was always limited by one element.

The same logic governs real systems, both physical and non-physical.

In 1984, physicist Eliyahu M. Goldratt introduced this idea to a wide audience in the business novel The Goal. His insight was simple: the throughput of any system is determined by its constraint.

Picture a production line with five stations. Four can process around 100 units per hour, but one station can only process 60. The output of the entire line is not the average or the maximum. It is 60. Everything upstream piles up in front of that station. Everything downstream waits for it to finish.

That station is the constraint.

Improving any other part of the system does not increase output. It only creates more inventory, more waiting, and the illusion of productivity. The only improvement that matters is the one that affects the constraint.

Goldratt proposed a simple discipline for dealing with this reality. First, identify the constraint. Second, get the most out of it with the resources you already have. Third, align the rest of the system to support it. Only after those steps should you invest in increasing its capacity.

Once the constraint improves, another part of the system becomes the new limit, and the process repeats.

The mistake most organizations make is optimizing locally. Departments try to maximize their own performance metrics. Individuals work to stay busy and productive. The result is a system full of efficient parts that collectively underperform.

The Theory of Constraints flips the perspective. Instead of asking what is weak, it asks what is limiting the whole.

Find that point, and improvement becomes focused. Ignore it, and most improvement efforts will produce activity without results.

A manager notices that their team’s performance is declining. The explanation seems obvious. People are not motivated. An incentive program is launched with bonuses, recognition, and a leaderboard.

Performance improves briefly. Then it slips again. Some strong employees leave. Customer complaints rise. The manager is confused. The solution seemed correct.

The problem was not effort or motivation. The problem was the diagnosis.

This pattern appears everywhere. A parent assumes a child struggles in school because they are not trying hard enough. A city expands a highway to reduce congestion. Someone decides their inability to exercise consistently is caused by weak discipline. In each case the explanation feels clear and the solution appears straightforward. Yet the results are often disappointing.

The issue is not bad intentions. The issue is a linear model used to explain the problem.

The Appeal of Simple Explanations

Most people rely on a simple way of understanding the world. If something goes wrong, there must be a clear cause. Fix the cause and the problem disappears.

This style of thinking treats the world as if it follows a simple pattern. One variable changes and the outcome changes with it. If performance drops, motivation must be low. If traffic grows, roads must be insufficient.

This approach is appealing because it reduces uncertainty. It produces explanations that are easy to understand and easy to present. But simplicity is not the same as accuracy.

The World Is More Complex

In reality, many outcomes are produced by systems. Systems contain multiple variables that interact with one another through feedback, delays, and constraints.

Consider what determines whether a child learns to read well. Effort and intelligence matter, but they are only part of the story. Sleep, classroom design, feedback from teachers, home environment, pacing of instruction, and emotional safety all interact with one another. Improving one factor alone rarely changes the overall outcome because the structure of the system remains the same.

The same pattern appears elsewhere. Expanding highways often increases congestion because additional lanes attract more drivers. Incentive programs sometimes damage collaboration or encourage short term behavior that harms long term performance.

Changing one variable does not necessarily change the result.

A Different Way to Diagnose Problems

Systems thinking approaches problems differently. Instead of asking who performed poorly, it asks what structure produced the result.

This shift leads to very different decisions. A manager who focuses on individuals replaces employees who underperform. A manager who thinks about systems examines the constraints that make good performance difficult and redesigns the environment.

The statistician W. Edwards Deming illustrated this principle with the Red Bead experiment. Participants are asked to reduce defects in their work. They are rewarded, pressured, and evaluated. Yet the results do not improve. The defect rate is determined by the system itself.

Deming summarized the lesson clearly. A bad system beats a good person every time.

Asking Better Questions

The difference between these approaches comes down to the questions we ask. Instead of asking how to motivate people, it is often more useful to ask what conditions make the desired behavior easy or difficult.

Systems thinking does not eliminate complexity. In fact, it forces us to confront it. But by focusing on structure instead of individuals, it produces explanations that better match the world we actually live in.

And when outcomes become understandable, they also become something we can design.

You read the whole article!

Share Systems of Human Performance

Leave a comment

Feel free to message me!

The seatbelt is one of the great triumphs of safety design and human engineering. Nils Bohlin invented the three-point design at Volvo in 1959. Aware of it’s potential to save lives, Volvo gave it away for free. And yet it still took the United States until 1968 to mandate it as standard equipment, and until 1984 before the first state required anyone to actually use it.

It’s a pattern we see again and again. Technology arrives decades early. The system never catches up. This is a story about how we did catch up, and than started going backwards.

Here is what a seatbelt is actually doing. In a collision, the car stops. The human body, obeying Newton’s first law, does not. The seatbelt attaches the occupant to the vehicle, spreading the deceleration force across the chest, shoulder, and pelvis rather than concentrating it on the skull. The result is a 45 to 60 percent reduction in fatalities. That is not a marginal improvement. It is substantial life-saving technology made of nylon, available to every person in every vehicle, for the cost of two seconds.

The problem, then, was never the technology. It was the two-second gesture.

In 1973, NHTSA required ignition interlocks on all new vehicles: buckle the belt, or the car won’t start. Human engineers call these forcing functions. They don’t ask the human to be better. They restructure the task so that the safe behavior is the only available behavior. Aircraft takeoff warning systems work this way. Industrial two-hand press controls work this way. The interlock is not punitive. It is simply good design.

The public was furious anyway. Congress received more constituent mail about the seatbelt interlock than nearly any other issue that session. Within a year, the Motor Vehicle and School Bus Safety Amendments of 1974 didn’t just roll back the rule. They made the interlock illegal as a mandate. The elegant interlock solution was banned by legislation.

By 1983, seatbelt use in the United States sat at roughly 14 percent.

What followed was an expensive workaround: the airbag. A brilliant piece of engineering, certainly. Also hundreds of dollars per vehicle, complex sensing hardware, and a system that can injure occupants when deployed without a seatbelt. The seatbelt interlock, by contrast, is a switched circuit. We chose to add thousands of dollars of engineering to every car to partially compensate for the absence of a two-dollar component we decided we didn’t want.

Every other safety mandate we’ve passed, turn signals, antilock brakes, backup cameras, electronic stability control, was resisted and then normalized. The seatbelt interlock is the one that was not merely delayed but actively prohibited, frozen there since 1974 by a political reaction we have never seriously revisited.

Modern occupant detection systems are already in most vehicles for airbag purposes. The technical objections to the 1974 version were real, but they were objections to a rushed implementation, not to the concept. The concept still works. It has always worked.

The tragedy is not the absence of a solution. The solution exists, has always existed, and costs almost nothing. The tragedy is that we banned it in anger, and then built everything else around the hole it left.

You read the whole article!

Share Systems of Human Performance

Leave a comment

Feel free to message me!

Technology is not just machines, code, or devices. It is the relationship between humans and the systems they use. In practice, that relationship matters more than the technology itself.

We like to tell the story of innovation as a story of invention. New tools. New breakthroughs. New machines. But most transformative moments in technology come from changing how humans interact with what already exists. Steve Jobs did not invent the mouse, the graphical interface, or the touchscreen. Those technologies were already there. What changed was the relationship between the user and the machine.

Over time, I have come to see that people approach technology through a small number of recurring patterns. Not job titles. Not skills. But orientations. Fundamental ways of relating to the technological world.

There are three.

The Promethean Personality creates novelty. They bring something into existence that did not exist before. They are comfortable with uncertainty, novelty, and failure. Prometheans give us breakthroughs, but often leave behind unfinished systems that others must stabilize.

The Atlantean Personality executes what has already been created. They master tools and use them reliably. They keep systems running. Hospitals, schools, airlines, accounting departments all depend on Atlantean competence. Without them, nothing works. They rarely get credit, but civilization rests on their shoulders.

The Faustian Personality optimizes endlessly. They take what exists and make it faster, smoother, and more efficient. Engineers, consultants, and process improvers live here. The Faustian impulse extends our reach, but left unchecked it creates complexity, fragility, and exhaustion.

Every functioning system needs all three. Creation without execution collapses. Execution without improvement stagnates. Improvement without limits overwhelms.

The mistake organizations make is treating these orientations as skills that can be trained rather than dispositions that must be respected. People do not become Promethean, Atlantean, or Faustian because of their jobs. They choose jobs because of who they already are.

Systems fail when we mismatch people to roles, reward the wrong behaviors, or allow one orientation to dominate unchecked. Systems succeed when we design work that lets creators create, operators operate, and improvers improve, while keeping them in balance.

Technology does not shape society on its own. Humans do, through the roles they play inside systems. Understanding those roles is not philosophy. It is systems design.

You read the whole article!

Share Systems of Human Performance

Leave a comment

Feel free to message me!

Heads up displays are not new.

They are not experimental. They are not futuristic. They are not waiting on a breakthrough in AI, sensors, or compute. HUDs are a decades old technology, built on simple optics and well understood physics, with a long and proven safety record.

They emerged in military aviation in the mid twentieth century for a simple reason. Pilots were flying faster, lower, and closer to the edge of human capability. Looking down at instruments, even briefly, was dangerous. The solution was not better discipline or more training. It was to move critical information into the pilot’s forward field of view so attention never had to leave the task.

The result was measurable. Faster reactions. Fewer errors. Better situational awareness. Not because pilots became better, but because the system stopped working against human limitations. This is the principle of human engineering that is espoused on each and every one of this Substack’s posts.

And yet, despite this being known for more than half a century, HUDs remain optional in automobiles. When they appear at all, they are framed as a novelty or luxury feature rather than a safety intervention. This is not because the technology is difficult. Automotive HUDs are mechanically simple and relatively inexpensive. The limiting factor is not feasibility. It is priority.

The contradiction is hard to ignore. We mandate seatbelts, airbags, and anti lock brakes because we accept that humans operate vehicles imperfectly, especially under stress and time pressure. Those features do not make drivers more attentive. They make the system more tolerant. HUDs belong in that same category.

Instead, we continue to design vehicles that require drivers to look away from the road dozens of times per minute. We normalize the resulting errors. We call them accidents. We treat distracted driving as a moral failure rather than a design failure.

The tragedy is not that we lack solutions. It is that we have had one for decades and chose not to use it. Systems do not fail because humans are careless. They fail because we keep asking humans to adapt to interfaces that were never designed to keep them safe.

Share

Share Systems of Human Performance

No one decides to build a fragile system. Nobody sets out to make things opaque or brittle. No engineer intends to leave behind software no one can maintain. No organization deliberately designs processes that guarantee failure.

And yet fragile, incomprehensible, failure prone systems are everywhere. They are the norm. Resilient systems are the exception.

This is because fragility is rarely the result of dramatic mistakes. Fragility is begotten by accumulation. It emerges slowly through hundreds of small, locally rational decisions that make sense in the moment but interact destructively over time. A feature added here. A workaround added there. A procedure layered on to fix yesterday’s problem. Each choice improves something locally. Collectively, they produce systems no one fully understands.

This is why systems thinking matters. Complexity is not additive. It multiplies. As systems grow, the number of interactions grows faster than our ability to reason about them. A small increase in components produces an exponential increase in relationships, dependencies, and failure modes. Somewhere along the way, the system crosses a threshold where risk accelerates faster than visibility.

Complexity enters systems through familiar paths. Feature creep expands surface area faster than it delivers value. Procedural layering creates sedimentary process that no one owns or removes. Informal workarounds keep work moving but hide how the system actually operates. Technical debt accumulates when short term fixes are never revisited. Each is rational in isolation. Together, they erode resilience.

As complexity increases, the ability to understand the system becomes more encumbered. No one holds the whole system in their head. Knowledge becomes siloed. Changes feel dangerous. Better not rock the boat for fear of unknown consequences. Teams avoid touching anything that seems to work. Maintenance consumes more effort than improvement. Integration breaks in unexpected ways. Documentation drifts from reality. This is not a failure of people. It is a failure of design.

Complex systems fail not because individuals err, but because interactions dominate behavior. Most interactions do not matter most of the time. Under stress, rare combinations suddenly become decisive. Emergent behaviors appear that were never intended and could not have been predicted by inspecting parts in isolation.

The warning signs are subtle until they are not. Longer cycle times. Rising error rates. Fear of change. Escalating maintenance costs. When these appear, complexity has already accumulated. The solution is not to eliminate complexity entirely. Some complexity is essential. The solution is to distinguish necessary complexity from accidental complexity, and to treat complexity like debt. Sometimes worth taking on. Always carrying a cost. Dangerous when left unpaid.

Managing complexity requires discipline. Mapping dependencies. Removing low value features. Setting complexity budgets. Designing modular systems with clear boundaries. Standardizing where variation adds no value. Most of all, cultivating the ability to say no. The systems that endure are not the ones with the most features or the most controls. They are the ones that remain understandable. Systems that can be modified without fear. Systems designed not just to operate, but to improve.

Complexity does not announce itself. It accumulates quietly, then fails loudly. The work of systems design is to recognize it early, limit its growth, and deliberately pay it down before fragility becomes inevitable.

You read the whole article! Maybe you’d like to:

Subscribe now

Leave a comment

Share Systems of Human Performance

The original long form post can be found here:

In 2008, financial institutions learned a hard lesson about model risk. Their risk models, built by elite quantitative teams, said portfolios were safe. Reality disagreed. The failure did not come from bad arithmetic or faulty data. It came from assumptions embedded in the models that quietly stopped being true. When those assumptions broke, the system collapsed, and the Great Recession followed.

This is model risk. It is not the risk of executing the wrong plan, or even measuring poorly. It is the risk of measuring the wrong thing altogether. The failure is not that the arrow missed the target, but that the archer was playing a different game.

Every system runs on models. Organizations, technologies, movements, and institutions all operate with assumptions about what success means, how it is achieved, and how progress will be measured. Most of these models are implicit. They live in habits, procedures, spreadsheets, and mental shortcuts. All are simplifications of reality. When those simplifications diverge too far from what is actually happening, systems fail, often without warning.

Model risk shows up everywhere. Mental models shape how managers motivate, how doctors diagnose, how engineers design, and how leaders decide. Operational models encode assumptions into processes that often outlive their usefulness. Analytical models, wrapped in the appearance of rigor and precision, are especially dangerous. They look authoritative even when they are confidently wrong.

The most dangerous assumptions are invisible ones. Models assume stability where none exists, linearity where systems are nonlinear, and tidy distributions where reality has fat tails. Parameters drift slowly until forecasts degrade, or they break suddenly when shocks occur. Overfitting creates the illusion of accuracy by perfectly explaining the past while failing the future.

Organizations run on forecasts, and forecasts are models. Budgeting, staffing, and capital planning all depend on assumptions about a future that will not arrive as expected. When organizations are designed to require accurate forecasts in order to function, model error becomes organizational fragility.

The solution is not better prediction. It is better systems. Make models explicit. Track which decisions depend on which assumptions. Monitor for signs that models are breaking. Build slack, flexibility, and feedback. Favor robustness over optimization. Above all, maintain epistemic humility.

All models are wrong. Some are useful. The danger begins when we mistake the map for the territory and follow it even as the ground shifts beneath our feet. Models will fail. The real question is whether the system collapses when they do, or adapts.

The territory keeps changing. The map must change with it. And the system must survive even when it has not.

Share Systems of Human Performance

Most systems fail long before anything dramatic happens.

An emergency department designed for 50 patients a day feels perfectly adequate until 73 show up. A software system built around 100 millisecond response times works flawlessly until one request takes ten seconds and blocks everything behind it. A manufacturing line balanced for steady supply runs smoothly until a shipment is late and every downstream operation stops.

These are not rare edge cases. They are expected. They are the ordinary consequences of a basic truth about systems: variability destroys performance, reliability, and safety.

We design systems around averages. Average demand. Average cycle time. Average availability. But lived reality never delivers the average on schedule. Actual events fluctuate around it, often unevenly and unpredictably. That gap between the designed-for average and experienced reality is where risk accumulates.

Deming understood this deeply. Common cause variation is inherent to every process. No two patients arrive at the same time. No two transactions take exactly the same path. This variation cannot be eliminated, only respected. Designing as if it does not exist guarantees recurring underperformance.

More dangerous is variation created by the system itself. Feedback loops, batching, tight coupling, and overreaction amplify small fluctuations into large disruptions. Deming called this tampering. Adjusting staffing, inventory, or throughput in response to normal fluctuation often injects more instability than it removes. The system becomes nervous, oscillating rather than stabilizing.

The physics of flow make this worse. As utilization rises, response time does not increase gradually. It bends upward sharply. Near capacity, small fluctuations create outsized delays. Queues explode. One slow event creates a convoy of waiting work. Variability propagates.

This is why emergency departments board patients even when average occupancy seems safe. Why production lines lose throughput despite competent workers. Why logistics networks unravel after minor delays. The issue is not insufficient averages. It is insufficient tolerance for variation.

Averages lie because they hide what matters most. Two systems with the same average demand can behave completely differently depending on variance. Risk lives in the spread, not the center.

The solution is not perfection. It is resilience. Buffers are not waste. Slack is not inefficiency. They are risk management. Systems must be designed to degrade gracefully, to absorb fluctuation without collapse, and to prioritize flow over utilization.

Variability is not an anomaly. It is the water the system swims in. The question is not whether it will appear, but whether your system is built to carry it or be overwhelmed by it.

Catastrophic failure rarely arrives with alarms. It hides in the seams, in quiet, peripheral spaces where one system hands off to another. Everything works beautifully in isolation, yet somehow the whole becomes fragile. This is the paradox of boundaries: the most dangerous parts of a system are the ones we look at the least.

We’ve grown excellent at optimizing components. But the spaces between components? Those remain blind spots.

The Integration Paradox

Think of a hospital. Triage runs smoothly. Imaging is efficient. Labs process tests with remarkable speed. And still patients wait, errors slip through, communication falters.

The problem isn’t inside any department. It’s in the transitions: when triage hands a patient to diagnostics, when results must reach a physician, when orders flow to the pharmacy. Each handoff is a translation moment, a coordination challenge, and a potential failure point.

Deming and Goldratt both saw this clearly: optimizing parts does not optimize the whole. In fact, local optimization often degrades the whole. Two high-performing subsystems can interact to create a low-performing system. The risk is in connections, not components.

Why Boundaries Break

Boundaries concentrate volatility because they house four chronic vulnerabilities:

Semantic mismatches. Two systems can agree on the data and still disagree on the meaning.
Responsibility gaps. When ownership of the handoff belongs to no one, failures flourish.
Queue dynamics. Work waits at interfaces, and waiting work decays.
Signal degradation. Every translation loses context and urgency becomes ordinary.

These aren’t theoretical issues. Supply chains amplify tiny fluctuations into chaos. Hospitals struggle with shift-to-shift handoffs that drop critical details. Software integrations fail not because code is bad, but because two “correct” systems misunderstand each other.

The Hidden Danger of Workarounds

People naturally create their own bridges when formal boundaries fail. Emails instead of systems, verbal updates instead of documentation, manual transfers instead of APIs. These shortcuts feel efficient but quietly accumulate risk. They create invisible dependencies, fragment information, and erode system coherence.

Deming would call this rational behavior within a flawed system. The workaround solves the local problem while harming the system as a whole.

Designing Better Boundaries

Strong systems aren’t built by perfecting components but through mindful engineering of handoffs and interfaces. Here’s how:

• Make boundaries visible. Map where work, information, and responsibility truly cross.

• Monitor boundaries, not just internal metrics. Queue age, handoff errors, missing context.

• Design boundaries with failure in mind.

• Reduce semantic distance with shared vocabularies and consistent models.

• Assign ownership of the interface itself—not just the pieces it connects.

This requires organizational maturity, because boundaries usually cross budget lines and incentive structures. Marketing’s metrics and Sales’ metrics rarely align at the handoff. Neither owns the boundary, so the boundary decays.

The Boundary Mindset

Most failures are boundary failures in disguise.

Systems don’t collapse because parts malfunction. They collapse because connections do. The seams, transitions, and translation points determine whether the whole system is elegant… or brittle.

Master the boundaries, and you master the system.

The Original Longform post can be found here:

We stand amid revolutions in AI, autonomous systems, and biotechnology. These advances bring promise but also more complexity and more hidden pathways to failure. Good design accepts what cannot be foreseen. It builds not just for performance, but for recovery.

From Blame to Design

Failures are often attributed to the person involved, the active failure, but a system is perfectly designed to get the results it gets. Recurring failure reflects structure, not individual shortcomings. Exceptional performance comes from design that makes correct actions natural. Error is reduced when systems are engineered to prevent predictable failure.

Why Systems Fail and How Automation Breaks

Latent errors accumulate and align over time.
The automation paradox shows that automation deskills humans; when it fails, people cannot recover.
Rasmussen’s conundrum reveals that peak performance matters little if systems collapse outside a narrow operating range.

Together they teach one principle: Design must anticipate failure, accommodate human limits, and use technology to extend—not replace—human resilience.

Rickover’s Conservative Decision-Making

Admiral Rickover insisted on restraint: favor the proven, avoid needless complexity, understand how systems fail, and maintain accountability. His ethic aligns with modern systems thinking: the best systems are simple, clear, and resilient.

AI: The Ultimate Test

AI magnifies all existing design challenges.

AI accumulates latent failures through hidden data patterns.
AI erodes human-centered design because its logic is opaque.
AI intensifies the automation paradox as it fails unpredictably while deskilling operators.

Responsible AI requires conservative decision-making: transparency, limits on autonomy, and continued human accountability.

Principles for AI Design

• Assume AI will fail and build for recovery.

• Preserve human skill and oversight.

• Demand transparency and clear boundaries of competence.

• Design systems that degrade gracefully, not catastrophically.

• Keep humans accountable for every consequential decision.

The Path Forward

Technology brings real benefits but also new vulnerabilities. AI will shape the future; the question is whether we design it with the prudence these systems demand.

The full length article can be found here:

Much has been made of Artificial Intelligence, especially its impact on work. Yet if you look beyond the shimmer of the shiny new gadget, you will see the same dynamics between humans and machines that have existed for generations.

At its core, AI, like driverless vehicles, factory robots, and robotic process automation, is a tool of automation. It speeds up a system. It removes the human from routine tasks. It promises greater speed, precision, and safety. It promises better decisions than humans could make. The difference today is sophistication. it is merely a difference of degree, not of kind.

When automation works, it works brilliantly. Superhuman precision. Faster, flawless, reliable. Yet when it fails, even slightly, it can underperform humans. Its window of success, the Optimal Design Domain, is narrow. Humans, in contrast, are adaptable. We maintain moderate performance across changing conditions. We degrade gradually, not catastrophically. This is called the Automation Conundrum.

This plays out in the real world. Driverless cars perform perfectly on ideal roads. but a few flakes of snow and they are anything but high performing or safe. Voice assistants respond flawlessly in quiet rooms. Add in background noise, multiple speakers, or ambiguous requests, and they collapse. Peak performance is seductive, but brittle.

The lesson is not to reject automation. It is to deploy it with care. Automation should handle routine, stable tasks. Humans must remain engaged. Humans must be ready when conditions exceed the automation’s domain. Systems must be transparent. Handoffs must be clear. Human skill must be preserved. Peak performance is impressive, but reliability depends on blending machine precision with human judgment.

Superhuman capability is seductive. Yet it is fragile. The goal is not perfect automation. The goal is resilient systems. Systems that perform across conditions. Systems that survive the unexpected. Systems where humans and machines contribute what they do best. That is the wisdom of the Automation Conundrum.

Subscribe now

This week’s longform post can be found here:

We believe that with the right technology, app, software, or algorithm we will solve problems and make our personal and professional lives more efficient and effective. But this dream remains unfulfilled. From the first auto-looms in 17th century England to today’s most advanced AI systems, the promise behind every new tool has always been automation.

Automation means letting a machine do the work. Solve a math problem with a calculator, heat a home with a furnace, answer customer questions without a call center. None of this is inherently bad. But automation always means giving full control, including decision making, over to a technology. When it works, efficiency and safety improve. When it fails, the failure introduces new problems that are sometimes so disruptive that the advantages evaporate.

Don Norman describes this perfectly in The Design of Everyday Things. Automation handles routine tasks well. It reduces fatigue. It reduces error. But when the situation becomes complex, automation gives up. This is precisely when it is needed most. And because automation reduces the need for human engagement, people lose the experience required to intervene. The less often we practice a skill, the less prepared we are when technology hands control back to us in a crisis.

This is the deskilling effect. Automation handles the routine. Humans stop practicing. Automation fails. Humans lack the skills to respond. The failure cascades. And this is not abstract theory. It plays out daily.

The Boeing 737 MAX crashes remain the clearest example. Engineers designed an airplane with known aerodynamic flaws, then papered over those flaws with a software layer meant to compensate. When MCAS malfunctioned, the pilots, despite years of training, had never encountered a failure of this kind. The paradox killed 346 people. Latent failures in the aircraft’s design fused with the Paradox of Automation to produce a catastrophe that should never have been possible.

Ralph Nader calls this the “Arrogance of the Algorithm”. The belief that technological sophistication grants control over an unpredictable world. But too many variables cannot be anticipated. Road conditions. Behavior of other drivers. Weather. Human irregularities. A long list of factors that no algorithm can fully capture. The confidence we place in automation often exceeds what it can actually do.

And the paradox intensifies as automation improves. The more reliable it becomes, the less we practice the underlying skills. The less we practice, the more helpless we are when the rare failure occurs. You see it in aviation. You see it in navigation. You see it in spelling and grammar. You see it in customer service. Automation removes the need for practice. Then demands skill at the exact moment we are least prepared.

All automation operates within an optimal design domain. Inside those boundaries, it performs beautifully. Outside those boundaries, it collapses. The problem is that real-world conditions constantly push systems toward the edges of those limits. And when they do, we discover that automation fails abruptly, fails in complexity, and leaves humans without the knowledge to recover.

These failure modes are not going away. But the effects can be mitigated. Manual skills can be maintained through periodic practice. Systems can be designed to degrade gradually instead of failing all at once. Automation can be made more transparent so operators know what it is doing. Limits can be respected. Not every task should be automated. And humans should remain in the loop, not merely sitting in the background waiting for disaster.

The deeper truth is that automation does not simply add capability. It reshapes human capability. It can make systems more brittle, not more resilient. A system with moderate automation and skilled humans may outperform a system with extensive automation and deskilled humans, especially when the unexpected appears.

We are entering an era where automation is accelerating. The promises are grand. But the Paradox of Automation remains unchanged. It cannot be eliminated. It can only be managed. The question is whether we will design for human flourishing or repeat the same mistake at ever larger scales.

This week’s longform post can be found here:

Most organizations treat failure as something caused by individual mistakes, but the real story unfolds much earlier, long before any operator presses a button or makes a choice. Latent errors are silent failures embedded in system structures, created by decisions, assumptions, simplifications, and compromises that accumulate over time. They sit quietly in the background, waiting for the right conditions to activate. When they do, they reveal how much of what we call “human error” is actually a systemic design problem.

Designers tend to focus on normal operations, stable workloads, complete information, and idealized users become the assumed operating environment. But real work happens at the edges. People make decisions while under time pressure. They improvise with incomplete data. They compensate for ambiguous rules, mismatched interfaces, and the small irregularities that emerge in the gaps between teams, machines, and procedures. These edge conditions are where latent failures gather, because the design process rarely accounts for them.

The Swiss Cheese Model helps illustrate this pattern. Every layer of a system contains unintentional holes created by earlier decisions. No single hole is fatal, but when several align, the failure slips through every defense. The visible mistake at the end is simply where the deeper structural weaknesses finally intersect. Latent errors create the conditions that make the final error possible, sometimes inevitable.

One reason latent errors are so persistent is that they behave like resident pathogens. They remain dormant until the right combination of stressors brings them to life. As systems grow more complex or tightly coupled, these dormant weaknesses multiply. New technologies introduce new dependencies. Small workarounds harden into unofficial rules. Outdated processes coexist with modern interfaces. Over time, complexity outpaces comprehension, and the system becomes vulnerable in ways no one fully recognizes.

These vulnerabilities concentrate at system intersections. Wherever a handoff occurs, a boundary emerges, or a human touches a machine, the potential for mismatch grows. These are the spaces where procedures are unclear, accountability is vague, information is incomplete, and assumptions go untested. Latent errors incubate in these overlooked connections because they belong to everyone and no one at the same time.

Better solutions begin with acknowledging that failure is not an exception but an expected feature of real systems. Training must shift from rote procedures to context-rich scenarios that mirror the ambiguity of real conditions. Operators need practice navigating edge cases, not just ideal ones. Systems benefit when designers create clear recovery paths, visible cues, and mechanisms that slow down failure propagation. Tools that help the system adjust its behavior based on context can prevent small irregularities from becoming catastrophic sequences.

Latent errors are not rare. They are structural. The question is not whether they exist, but whether the organization can see them before they activate. A system’s true quality is measured by how it behaves when conditions diverge from the ideal, because that is where real life always lives. The strength of any system lies in how well it anticipates, contains, and learns from the hidden forces that shape behavior long before anyone notices something is wrong.

The original longform post can be found here:

The industrial age smuggled in a dogma that has shaped modern life. Technology was treated as synonymous with progress. As long as it advanced, humanity advanced with it. For a long stretch this myth felt true enough because technology pulled societies out of subsistence and into plenty. But in the 21st century, technology no longer carries us toward a fuller humanity. It adds abundance to overabundance, consumption to overconsumption, and for those who build, code, design, or deploy it, the problem is even more inscrutable. Technology is not a surefire path to efficiency, profit, or a better world. It now carries the risk of creating a civilization full of technological emptiness or systems that are hostile to human thriving.

Joseph Weizenbaum, AI pioneer and creator if ELIZA, captured this tension perfectly. Technology promised power. The price paid was servitude and impotence. Power is nothing without the power to choose.

Yet optimism persists. Generative AI, VR, AR, autonomous vehicles. These bright, dazzling technologies promise a better future simply because they are new. If we are to be optimistic, it should be because human flourishing increases, not because the technology does. Flourishing will come not because of technological progress but despite it. Principles and limits must govern how we design, implement, and use technology.

At the center of technology’s allure lies a promise. Automation, algorithms, software, apps. Each invites us to believe that our personal and professional lives will become more efficient and more effective. But this dream is largely unfulfilled. The Paradox of Automation shows why. Automation gives full control to a machine. When it works, it performs well, reduces fatigue, and improves safety. When it fails, it fails abruptly. And because automation reduces human engagement, we lose the knowledge needed to intervene. When it is time to step in, we often do not know how.

The Boeing 737 Max disasters made this paradox unavoidable. A poorly designed plane was propped up by software meant to compensate for bad aerodynamics. When the algorithm failed, the pilots, despite years of training, lacked the experiential knowledge to respond. The price of this arrangement was 346 lives.

Ralph Nader warns of this “arrogance of the algorithm.” Technology seduces us into believing that enough computing power can deliver total control. But too many variables escape prediction. The dream remains unfulfilled.

The risks do not end with automation. Technology embeds values, priorities, and taboos into the world. It generates a technological legacy that future generations must bear. Even an innocuous hospital vignette reveals the stakes. A nurse, once free to act with simple human judgment, is now constrained by systems built around liability, billing, and institutional procedure. Technology is not neutral. It carries the imprint of our values, and it may obstruct the autonomy of those who inherit it.

This is why the telos of technology matters. Philosopher Ivan Illich’s notion of “conviviality” remains the gold standard. Technology should enrich the environment with the fruits of human vision. It should respect limits. Without limits, humans become servants of their own devices through overconsumption, indulgence, and dependence.

From these insights come practical rules. Technology must enhance productivity rather than undermine it. It must decentralize rather than centralize. It must be designed around humans, not as an attempt to replace them. It must embrace self-limitation to prevent the proliferation of harmful or addictive systems. And it must avoid irreversible changes that future generations cannot undo. A technology so deeply enmeshed in the structure of society that it cannot be removed is no longer a tool; it is a trap.

Technology is not an unmitigated good. It is not innately bad either. It is never neutral. Every act of design, development, and use expresses a belief about what matters. The only responsible path is mindful use. The principles outlined here aim to guide individuals, communities, engineers, and designers toward a world in which technology serves human flourishing, not the other way around.