Dynamic Capabilities and Why Agility Is Not a Buzzword

"Agile" has become one of those words that means something precise to theorists and almost nothing in practice. I have been in rooms where "we need to be more agile" meant "we need fewer approval layers" and also "we need to move our servers to the cloud" and also "we need a new project management tool." These are not the same thing. They are not even close to the same thing.

The theoretical concept that is actually being reached for in those conversations is dynamic capabilities. Teece, Pisano, and Shuen (1997) defined dynamic capabilities as the ability to integrate, build, and reconfigure internal and external competencies to address rapidly changing environments. That definition does real work. Notice it does not say anything about being fast, or having a certain tool, or running two-week sprints. It is about the capacity to reconfigure, to change the resource base itself when the environment demands it.

The distinction Teece and colleagues draw between ordinary capabilities and dynamic capabilities is the part that tends to get lost. An ordinary capability is something your organization is good at doing right now. A dynamic capability is the ability to change what you are good at when the situation changes. Both matter, but they are doing different jobs.

An organization with strong ordinary capabilities has mastered current operations. They deliver on time, they run efficient processes, they execute well. An organization with dynamic capabilities can sense shifts in the environment, seize opportunities that emerge from those shifts, and transform their resource base to fit the new situation. Teece later described this as three linked activities: sensing, seizing, and transforming.

Here is why this matters for IS managers specifically. When organizations invest in technology, they are usually investing in ordinary capability. They are getting better at doing what they already do. The ERP makes existing processes more efficient. The data warehouse makes existing reporting faster. None of that is wrong. But it leaves an organization dependent on the assumption that what they do today is what they will need to do in two or five years.

The case of Kodak is widely discussed in management literature as an example of this failure. Kodak had exceptional capabilities in film processing, chemical manufacturing, and photographic printing. These were genuine strengths. The problem was not that Kodak was bad at what it did. The problem was that what it did became the wrong thing. Their capabilities were ordinary capabilities. They did not have dynamic capabilities sufficient to sense the threat of digital photography and transform their resource base before it was too late. My understanding from the literature is that this is treated as a canonical example of dynamic capabilities failure, though I am working from secondary sources here.

Blockbuster is another example widely cited in this literature. Excellent logistics for physical video distribution. Real supply chain capability. But when the environment shifted toward digital streaming, the capability they needed was not an improvement on what they had. It was a different capability entirely. Sensing that shift early enough, seizing the opportunity, and transforming the organization accordingly was the dynamic capability problem. By most accounts they did not solve it.

What makes this specific to IS is that technology environments change fast, and the pace of that change seems to be accelerating. An organization that made good technology choices in 2015 might find those choices creating lock-in by 2020, and genuine liabilities by 2025. The dynamic capabilities question is not just "do we have good systems?" It is "can we change our systems when we need to, and can we change them faster than our competitors can?"

Eisenhardt and Martin (2000) added an important nuance to the Teece framework. They argued that dynamic capabilities are not vague organizational traits. They are specific, identifiable routines: product development processes, strategic decision-making patterns, alliance and acquisition practices. The reason this matters is that it makes dynamic capabilities something you can actually examine and improve. It is not just a general organizational culture claim. You can ask: do we have a reliable process for scanning emerging technologies? Do we have routines for running experiments? Do we have decision rights that allow rapid resource reallocation? Those are operational questions about specific capabilities.

In IS research, this translates into a set of concrete questions organizations should be asking. Not "are we digital?" but "can we adopt the next generation of digital tools when they arrive, and can we abandon current tools when they stop serving us?" Not "do we have analytics?" but "do we have the routines to ask new questions of data when the business changes?"

The irony is that "agile" as a methodology, the sprints, the standups, the backlogs, is a partial answer to the dynamic capabilities question applied to software development. It is an attempt to build sensing and adaptation into the development process at the team level. But organizational dynamic capability is a much bigger scope than software delivery. It spans strategy, structure, people, and culture, not just engineering practice.

The organizations I have seen struggle most in technology transformations are usually not struggling because the technology is bad. They are struggling because their sensing routines did not pick up the need for change early enough, or their seizing mechanisms could not mobilize resources fast enough, or their existing capabilities created so much institutional inertia that transformation became politically impossible. Those are dynamic capability failures. No technology purchase fixes them.