Implementation Is Not Realization
 Why introducing change does not determine what the organization actually becomes Organizations often evaluate transformation by asking whether planned changes were implemented. Was the technology deployed? Was the process redesigned? Was the structure changed? Were new ways of working adopted? These are legitimate questions. But they answer only part of a more important question. What did those changes actually become once they entered the organization? Implementation tells us what was introduced. It does not necessarily tell us what was realized. That distinction matters because an organizational intervention does not enter an empty space. It enters an existing system of people, relationships, routines, incentives, technologies, capabilities, authority structures, interpretations and constraints. And once it enters that system, it interacts with what is already there. Those interactions may reinforce, modify or constrain the original intention — or produce something that looks similar to what was designed while functioning very differently in practice. Implementation introduces an intervention. It does not determine the organizational configuration that will be realized. What We Introduce Is Not Necessarily What We Get Consider a familiar transformation objective: Increase team autonomy. The organization may redesign roles, delegate responsibilities, reduce approval layers and formally empower teams to make more decisions. The change has been implemented. But what has been realized? Teams may genuinely acquire greater decision authority. Or responsibility may move downward while important decision rights remain centralized. Formal approvals may disappear while informal escalation continues. Managers may intervene less directly while digital monitoring increases. The same intervention - “increase team autonomy” - can therefore produce very different organizational realities. The difference cannot be understood simply by asking whether the intervention was implemented. We have to examine what happened when it encountered the existing system. Organizations Do Not Simply Receive Change The previous article established that organizations do not simply receive interventions. They respond to them through existing relationships, incentives, capabilities, authority structures and interpretations. That response matters here because the intervention is only one causal element in what follows. What is realized results from the interaction between the intervention and the system into which it is introduced. This is why apparently similar interventions can be realized differently across organizations — or even across different parts of the same organization. Implementation tells us that something entered the system. Realization tells us what developed from the interaction. Formal Change and Realized Change Are Different Objects This distinction becomes particularly important when transformation involves organizational architecture. A new organizational chart can be implemented. That does not tell us where authority actually resides. A process can be redesigned. That does not tell us how work is really performed when deadlines, exceptions and competing priorities appear. An AI system can be deployed. That does not tell us how humans will rely on it, challenge it, override it or reorganize their work around it. The formal intervention is observable. But so is the organizational reality that develops around it. And they are not the same object. Formal architecture describes what has been established. Realized architecture describes how the system actually operates. Without this distinction, transformation can appear complete on paper while producing a very different organization in practice. Adoption Is Not Realization Either There is another distinction we need to preserve. Implementation is not realization. But neither is adoption. A technology may be widely used. A process may be routinely followed. Teams may use the prescribed tools. All of this can demonstrate adoption. But adoption tells us that a practice has entered organizational behavior. It does not necessarily tell us what that practice is doing to the organization. An agile practice can be adopted while decision authority remains centralized. AI can become embedded in daily work while human approval continues to determine consequential decisions. So the progression is not necessarily: Design → Implementation → Adoption → Success because adoption itself is not the final organizational reality. The more important question is: What patterns of work, authority, coordination, learning and behavior are actually being produced? The Same Design Can Be Realized Differently The distinction becomes clearer when apparently similar designs produce different organizational configurations. Imagine two organizations reducing management layers and formally increasing team autonomy. In one, decision rights move closer to the work. Teams gain access to relevant information, managers provide context rather than routine approval, and governance establishes clear boundaries within which teams can act. In the other, layers are also removed and teams receive broader responsibilities, but important decisions remain centralized. Coordination shifts to digital systems, monitoring increases and people have fewer managers without necessarily gaining greater authority. On an organizational chart, both organizations may appear to have implemented the same transformation. What they have realized is not the same. The difference lies not simply in whether the design was implemented correctly. It lies in how the intervention interacted with authority, information, governance, capability and behavior. This is why transformation cannot be understood from design variables alone. We have to observe the resulting system. When Structures Disappear, Functions May Move There is another possibility. A visible organizational structure may disappear without the functions it performed disappearing with it. Suppose an organization removes a layer of middle management. The positions disappear. But what happens to the functions those positions performed? Coordination may move to teams. Monitoring may move to digital platforms. Information synthesis may move to AI. Some decisions may move upward. Others may move closer to the work. The structure disappeared. The functions did not necessarily disappear with it. This distinction matters because transformations are frequently described through visible structural changes: fewer layers, fewer roles, more automation, greater autonomy. But structures are only one place where organizational functions reside. A technological intervention illustrates the same principle. What begins as task automation may gradually alter the distribution of work, knowledge, coordination or influence across the organization. A technological intervention can become an organizational architecture. But we cannot infer that architecture simply from the technology introduced. To understand realization, we therefore have to follow the functions, not only the structures. A visible structural change can conceal a deeper functional redistribution. Realization Can Produce What Nobody Designed Not every consequential organizational pattern corresponds to an explicit transformation objective. Some patterns arise through interaction. A new process creates a workaround. The workaround becomes routine. The routine creates an informal coordination mechanism. That mechanism gradually becomes more important than the formal process. A new technology removes one bottleneck but creates another. Teams compensate. New dependencies form. Responsibilities migrate. Eventually, a practice that nobody formally designed becomes part of how the organization operates. This does not mean that organizational change is arbitrary. Nor does it mean that design is irrelevant. It means that design interacts with adaptation. The realized organization contains what was intentionally introduced, but it can also contain patterns that developed through the system's response to those interventions. This is where emergence becomes important. Emergence does not mean that outcomes have no causes. It means that some system-level patterns arise from interactions among elements and cannot be understood simply by inspecting any single intervention in isolation. What is realized can therefore be partly designed and partly emergent. Realization Is Not Evaluation One more distinction is necessary. Suppose an organization formally increases team autonomy and we subsequently observe that decision authority genuinely moved closer to teams. We now know something important about what was realized. We still do not know whether the result should be considered desirable or successful. That is a different question. Realization is descriptive before it is evaluative. To evaluate what was realized, we need criteria. We need to know for whom, at what level and over what period consequences are being considered. Those questions matter. But they are not the question of this article. Before evaluating what transformation produced, we first need to understand what it actually produced. Look for the Organization That Actually Exists This distinction changes what we need to observe during transformation. Implementation evidence asks whether the intervention entered the organization as intended. Was the technology deployed? Was the structure changed? Was the process introduced? These remain useful questions. But realization evidence asks something different. How is work actually being performed? Where do information, coordination and authority reside? Who can make, challenge or override consequential decisions? What capabilities and dependencies are developing? These questions direct attention away from the intervention alone and toward the organizational configuration developing around it. Implementation evidence tells us whether the intervention entered the organization. Realization evidence tells us what organizational reality developed around it. That requires us to look beyond formal structures and prescribed processes to examine the organization as it actually operates, including where functions have migrated and which relationships now shape its behavior. The system may have realized something different from what the transformation intended. Implementation Is Not Realization Organizations need to implement change. Without implementation, intentions remain intentions. But implementation should not be confused with the organizational reality that follows. So the critical question is not only: What did we implement? It is also: What did the system actually realize? Because introducing a change does not determine what that change becomes. Implementation describes the intervention. Realization describes the organizational configuration that develops through the interaction between that intervention and the system. But knowing what was realized still does not tell us whether it should be considered successful. The same realized change can have different consequences depending on what we examine, where we examine it, for whom and over what period. So another question follows: How should we evaluate what was realized? That is where we go next. Article 11 — The Same Change Can Succeed and Fail at the Same Time |
Posted on: October 04, 2026 06:40 AM
| Permalink |
Comments (0)
