March's exploration-exploitation tradeoff applies to IT strategy more directly than almost any other management domain. Bimodal IT was an attempt to solve it. Here is why that attempt keeps failing.
The IT strategy problem that organizations never quite resolve is this: the people and budget responsible for keeping SAP running are the same people and budget responsible for building the next generation of the business. Sometimes they are literally the same people, wearing different hats on different days. More often they are different teams inside the same function, competing for the same resources, evaluated by incompatible metrics. The SAP team is evaluated on uptime, ticket resolution, and change control compliance. The innovation team is evaluated on velocity, creativity, and whether the prototype impresses the executive who sponsored it. These two sets of incentives, in the same budget line, under the same CIO, produce a tension that organizational theorists have a name for.
March (1991) gave us the vocabulary. His Organization Science paper separated organizational learning and adaptation into two modes. Exploitation refines existing capabilities: efficiency, reliability, execution, and the steady extraction of value from what the organization already knows how to do. Exploration builds new capabilities: search, experimentation, variation, and the uncertain pursuit of what might become valuable. Both are necessary. Neither can fully substitute for the other. And they tend to be in conflict because the returns to exploitation are immediate and visible while the returns to exploration are distant and uncertain. When the same organizational unit has to do both, the immediate tends to crowd out the uncertain. This is what March called the competency trap: organizations get very good at what they already do and lose the ability to adapt when what they do becomes insufficient.
I have written about the ambidexterity concept in other posts, and the organizational theory response to March is well-established. You separate the exploration and exploitation activities into different organizational units, with different cultures, different metrics, and different management logics, and you integrate them at the level of senior leadership. This is structural ambidexterity, associated with Tushman and O'Reilly's work in the mid-1990s. I want to note that I did not find Tushman and O'Reilly in my local study materials, so I am drawing on the broader management literature here, but the core argument is well-documented in the IS ambidexterity literature I have worked through.
In IT specifically, Gartner attempted to institutionalize this split through what it called bimodal IT, and I think the bimodal IT story is one of the more interesting practical experiments in applied ambidexterity theory. Mode 1 was supposed to be traditional IT: stable, reliable, waterfall-managed, focused on keeping the business running. Mode 2 was supposed to be fast, experimental, agile, focused on building the new. The framework appeared in Gartner research roughly around 2014 and had a few years of significant influence on how CIOs were thinking about their organizational structure. I am linking to the Gartner newsroom rather than a specific report because I have not retrieved the original document and do not want to misattribute a specific framing to a specific publication.
The problem with bimodal IT, as I wrote about in a separate post on two-speed IT, is that Mode 1 and Mode 2 tend to fight each other in practice rather than complement each other. The fight is predictable and follows directly from March's framework. Mode 2 is doing exploration. Exploration requires tolerance for failure, long time horizons, and protection from the efficiency demands that make exploitation work. Mode 1 is doing exploitation. Exploitation requires reliability, predictability, and the kind of governance that prevents unauthorized changes from breaking production systems. These two operating logics need different structures, different people, different performance reviews, and different budget cycles. Bimodal IT put them in the same IT function under the same CIO and called them different modes. That is a naming solution to a structural problem.
The specific fights I hear about are budget and talent. Talent first: the best engineers want to work on interesting problems. Mode 2 has interesting problems. Mode 1 has necessary problems. Over time, Mode 2 attracts the senior engineers and Mode 1 gets whoever is left, which is exactly backwards from what the business needs. The systems that the whole organization depends on are best maintained by the most experienced engineers. The innovative initiatives that may or may not matter in three years are fine for junior engineers learning on the job. But the incentives point the opposite direction, and CIOs who do not address this explicitly watch their Mode 1 teams gradually deplete while Mode 2 accumulates senior talent.
Budget is related. In most organizations, IT budget is a single line item that covers both modes. During the annual planning cycle, Mode 1 can point to SLAs, contracts, and legal obligations to justify its budget requests. Mode 2 argues for funding based on uncertain future value, which is a harder argument in a room where the CFO is focused on near-term margins. Mode 1 wins more budget arguments than Mode 2. Over time, Mode 2 becomes underfunded relative to its ambitions, which means it delivers fewer results, which makes it harder to defend in next year's budget cycle. This is the competency trap at budget level. The organization keeps funding what it already does and starves the exploration that might matter.
The organizations I think are doing this well have made a structural choice that bimodal IT avoided: they have separated the governance and accountability structures, not just the team names. The exploration arm of IT has its own budget, its own reporting line, its own performance metrics, and its own risk tolerance framework. It is not a different team inside the IT function. It is a different entity, with different rules, that happens to be integrated with IT at the CIO or CDO level. This is closer to what the academic ambidexterity literature actually recommends, separate units integrated at the top, than bimodal IT's approach of two modes in one function.
The integration point matters as much as the separation. If the exploration arm produces something that needs to move into production, there has to be a mechanism for that transition. Not a twelve-month procurement process, but not an ungoverned hand-off either. The architecture review, the security assessment, the data classification, the operational runbook: these things have to happen on a time scale that does not kill the momentum of what the exploration team built. This is the hardest operational design question in ambidextrous IT. Separation is easier to design than integration. Integration is where the theory meets the specific power structures, budget cycles, and governance processes of a particular organization, and where the abstract recommendation becomes a negotiation.
March's framework says organizations fail at exploration because the incentive structures favor exploitation. That prediction holds in IT as well as anywhere else. The question is not whether you believe the prediction. It is whether you are willing to change the incentive structures.
About the author
Share
More notes
Related notes