Paradox Theory and the Tensions That Don't Resolve

Every few years at a certain kind of company, the IT department swings between two modes. First, there is a period of tight centralized control. Everything goes through IT. Shadow IT is banned or at least strongly discouraged. Standards are enforced. The cost is that business units complain constantly that IT is slow, unresponsive, and a bottleneck. Projects take months to get approved. Simple changes take weeks. Eventually the pressure builds enough that leadership decides to decentralize. Business units get more autonomy. Local IT decisions are allowed. Shadow IT is tolerated or even encouraged under the label of "innovation." The cost is that the technology environment becomes fragmented, security risks accumulate, and the organization discovers it has seventeen different tools doing the same job with no integration between them. At which point leadership decides to recentralize.

I have seen this cycle described as a strategic failure, a governance failure, and a leadership failure. My read is that it is something more fundamental: a paradox that is not being managed.

Smith and Lewis (2011) developed what is now called paradox theory in organizational research. Their argument, as I understand it from the broader management literature, is that organizations face tensions that are simultaneously contradictory and interdependent. Contradictory because pursuing one pole actively undermines the other. Interdependent because each pole depends on the other for meaning and existence, and suppressing one causes buildup that eventually erupts. My study-hub sources do not contain the Smith and Lewis (2011) paper directly, so I am drawing on my understanding of the broader organizational theory literature here, which consistently characterizes their work this way.

The tensions they described cover four types: performing (different stakeholders, different metrics), organizing (stability versus flexibility), belonging (individual versus collective), and learning (building on past knowledge versus creating new knowledge). In IS and IT management, the control-versus-autonomy tension fits the organizing type. The stability-versus-change tension runs through almost every IS implementation decision.

What paradox theory says about these tensions is different from how most organizations try to handle them. The instinct when facing a contradictory demand is either to choose one pole and commit to it, or to sequence them, being centralized now and decentralized later, or stable for this project and innovative for that one. The theory says this is usually wrong, because the tensions are structurally inherent. Choosing a pole and suppressing the other does not make the suppressed tension go away. It creates pressure that accumulates until it erupts, producing the kind of swing I described in the opening.

The alternative is what Smith and Lewis called dynamic equilibrium, which is not a balance point or a compromise but an ongoing management of both poles simultaneously. Organizations that do this well are not splitting the difference between control and autonomy. They are finding ways to maintain both, in different spaces or at different levels, through structures and governance mechanisms that keep both tensions alive rather than resolving one.

This connects directly to organizational ambidexterity, which I wrote about in more detail in a previous post on exploration and exploitation. Ambidexterity is essentially one answer to the exploration-exploitation paradox, the tension between building on what works and searching for what might work better. The structural ambidexterity solution, separating exploration and exploitation into different units, is a way of maintaining both poles without letting one eliminate the other. Paradox theory is the broader framework that explains why ambidexterity is necessary in the first place, not just a useful organizational design choice.

For IS organizations specifically, I think the paradox framing surfaces something the efficiency-versus-innovation debate tends to obscure. IT departments are often told they need to "become more agile" or "enable innovation" or "get closer to the business" while simultaneously maintaining system reliability, managing security risk, controlling technology sprawl, and keeping costs down. These demands do not reduce to a single optimum if you squeeze hard enough. They are genuinely contradictory. An IT organization optimized purely for reliability is not the same thing as one optimized for speed. The organizational structures, processes, metrics, and culture that make reliability happen actively work against the structures that make speed happen.

Gartner introduced what it called "bimodal IT" as a framework for addressing this tension in enterprise contexts, describing it roughly as running two modes of IT simultaneously: one focused on stable, predictable delivery and one focused on fast, exploratory development. That framing was controversial. Critics argued it created confusion about which mode applied when, and that two-speed IT could entrench slow delivery in the stable mode rather than improving it. But the underlying problem the concept was trying to address, that IT organizations face genuinely contradictory demands that cannot be resolved by picking one, is real. Gartner's research on digital initiatives has continued to engage with this question (see Gartner newsroom for recent coverage of digital transformation governance).

The paradox theory response to the bimodal critique would be, roughly, that the problem is not having two modes, it is treating the two modes as a permanent division rather than a managed tension. If "stable mode" becomes a permanent home for legacy work that never gets renewed, and "innovation mode" becomes a permanent home for projects that never reach production, you have not managed a paradox. You have just institutionalized both poles in a way that prevents them from informing each other.

What makes the tension productive, in Smith and Lewis's framing, is that each pole creates the conditions for the other. Stability creates the platform that makes exploration possible. Exploration creates the capabilities that eventually become the new stability. Cutting the connection between them, which is what structural separation without strong integration can do, removes the generative quality of the tension.

I think this is also the right frame for thinking about IT governance more broadly. The question is not which governance model is correct, centralized or federated, controlled or flexible, standards-based or contextual. The question is whether the governance structure maintains enough tension between the competing demands to keep both alive. An IT organization that has completely eliminated shadow IT has probably also eliminated the signal that tells it which user needs it is failing to meet. An IT organization that has completely tolerated shadow IT has probably also lost the ability to provide the integration and security foundation that makes the business work.

The organizations that manage this well are not the ones that found the right point on a spectrum. They are the ones that stopped looking for a resolution.