Information Processing Theory: Organizations Are Processors, Not Machines

I want to start with a framing that I think gets underused in IS research. Most theories about why organizations adopt technology focus on individual behavior: perceived usefulness, ease of use, social influence, cognitive fit. Those are real factors. But they operate at the level of the individual user, and a lot of the interesting IS design questions are not about individual users. They are about how organizations handle coordination, decision-making, and uncertainty at scale. Galbraith's information processing theory gives a starting point for those questions that I find more useful than most alternatives.

Jay Galbraith published his organizational design framework in the mid-1970s. The central argument is that organizations design their structures to handle the information processing their tasks require. Task uncertainty is the key driver. When a task is routine and predictable, it can be handled through rules, procedures, and hierarchy. The information required to complete the task is knowable in advance, the responses are programmable, and coordination can happen through standardization. But when a task is uncertain, meaning that the information needed to complete it cannot be known in advance, the organization faces an information processing challenge. Exceptions arise. Situations occur that the rules did not anticipate. Decisions that were supposed to be made at the bottom of the hierarchy have to be escalated upward because nobody at the bottom has the information or authority to handle them. The hierarchy gets overloaded.

Galbraith described two general strategies for managing this. Organizations can either reduce the need for information processing or increase their capacity to process information. Reducing the need involves creating slack resources, so that performance targets are loose enough that exceptions require less escalation, or creating self-contained units, so that each unit has all the resources and information it needs to complete its tasks internally. Increasing capacity involves investing in vertical information systems, meaning formal mechanisms that allow more information to flow up and down the hierarchy, or creating lateral relations, meaning direct communication channels between units that bypass the hierarchy.

What makes this relevant to IS is that information systems are, in the simplest possible framing, investments in information processing capacity. An ERP system creates a vertical information system. It allows a finance executive to see inventory levels, order backlogs, and supplier delivery times without asking each functional manager to prepare a report. The organization's capacity to process information about its own operations increases substantially. A business intelligence platform reduces the escalation burden on analysts who previously had to write custom queries every time a manager wanted to see data cut a new way. A project management tool creates lateral relations by allowing teams in different departments to share status, dependencies, and decisions directly without routing everything through a shared manager.

The design mismatch problem follows directly from the framework. When the information system is designed for one level of task uncertainty and the organization is operating at a different level, the system either over-constrains or under-supports the people using it. This is one of the things that Tushman and Nadler worked on when they extended Galbraith's framework. My reading of their contribution suggests they emphasized that the fit between organizational design and information processing requirements is a dynamic problem, not a one-time design decision. As the environment changes, as tasks become more or less uncertain, as competitive dynamics shift, the information processing requirements change, and the organizational design needs to adapt. A system that fit the organization's needs three years ago may be a mismatch today because the tasks have changed.

ERP implementations are a productive case to think through here. Large ERP systems are built around the assumption of high information processing demand at the coordination layer, meaning that finance, procurement, supply chain, and HR all need to share a common data substrate so that decisions in one area can be made with visibility into the others. For a large manufacturer with complex supply chains and multi-entity reporting requirements, that assumption holds. The uncertainty at the coordination layer is high, and the ERP's vertical information system architecture is a real capability increase. For a small organization with simple operations, the same system imposes a processing overhead that exceeds what the tasks require. The rules, workflows, and reporting structures that the ERP builds in are designed for uncertainty levels the small organization does not face. The result is a system that is technically operational but organizationally exhausting, because people are processing information that the task does not actually demand.

The same logic applies to the AI integration decisions organizations are making right now. There is a real temptation to instrument every organizational process with AI-driven monitoring and decision support, on the grounds that more information processing capability is always better. Galbraith's framework says that is not right. What matters is whether the information processing capability matches the task uncertainty. A checkout process in a retail store has low uncertainty. The task is almost fully programmable. Adding an AI layer that monitors for exceptions and escalates anomalies is unlikely to improve performance, because the existing rule-based system can already handle the information requirements. A supply chain disruption response process has high uncertainty. The information needed to respond well cannot be known in advance, exceptions are frequent, and the decisions require integrating data from multiple sources quickly. An AI system that surfaces relevant supplier alternatives, models inventory implications, and recommeps reallocation options can genuinely reduce the information processing burden on the people who have to make those calls under time pressure.

The question IS researchers should be asking about any technology implementation is not just "does this improve user experience?" or "does this increase adoption?" It is "does this match the information processing requirements of the tasks it is meant to support?" That question requires understanding the task structure. Which tasks are routine and which are uncertain? Where are the coordination bottlenecks? At what level does exception escalation happen, and how does that translate into overload? The information processing framework gives you a way to diagnose those questions before the implementation rather than after.

One thing I notice in the IS design literature is that the information processing perspective has been somewhat absorbed into adjacent frameworks without always being credited explicitly. The organizational fit literature in IS, which asks whether a technology fits the task or the organization, is doing something very close to what Galbraith described. The concept of task-technology fit, which Gordon and Iris Vessey developed in the 1990s, asks whether the technology's capabilities match the demands of the task. That is a narrower operationalization of the same basic logic. The coordination theory work in CSCW draws on information processing ideas about when different coordination mechanisms are appropriate for different kinds of interdependence.

The reason I keep coming back to Galbraith as a starting point is that the framework is clear about causal direction in a way that a lot of IS theory is not. Organizations face uncertainty. Uncertainty creates information processing requirements. Organizations design structures and systems to meet those requirements. When the design fits the requirements, performance is higher. When it does not, the organization either under-processes information and makes bad decisions, or over-processes information and wastes capacity on coordination overhead that adds no value. That is a clean mechanism. It generates predictions. And it has almost certainly been operating in every IS implementation you have ever seen, whether the people who designed the implementation knew it or not.