We commonly draw a distinction between revolutionary and evolutionary change. We categorize some changes like the invention of the PC as revolutionary, and others like a new development framework as evolutionary. I suppose there is something about that idea that makes sense. There are changes that have immediate and wide-ranging effects. But I’ve never seen this as a useful distinction when you are trying to effect change.

This distinction is commonly used to comment on big changes in an industry, product category or culture. Commentators see the big, evolutionary change leapfrogging over many smaller changes. They categorize changes into these categories as an either/or proposition. A given advance must fit into one bucket or the other. There is another group besides pundits that also commonly uses this paradigm to think about how change works: managers.

This kind of hard, binary distinction is something that only an observer and not a creator could come up with. Creators know that these kinds of changes are really two sides of the same coin. That’s not to say that we don’t need both managers and commentators, but their perspective is, for the most part, that of an outsider to the creative process. Creators know that there is a very fine, if even distinguishable, line between the evolutionary and the revolutionary.

A revolutionary change can only be sustainably made after many smaller changes lay a foundation. Wi-Fi was revolutionary, but it was built on the back of other technologies. The TCP/IP protocol, radio communication, low-power radio receivers, fast high-quality encryption and more led the way to making Wi-Fi possible. For the outside observer, this appears to be an evolutionary change out of the blue, but to anyone in the networking sphere it was the inevitable result of many smaller (from this perspective) innovations.

We must keep this in mind when we are responsible for changing systems, be they software, hardware or processes. Small evolutionary changes fuel the big, revolutionary change. New principles and ideas build on what came before them. To effect change in a large scale system, leaders and designers must emulate this evolutionary process.

I think the easiest example here is contemplating how a large development organization might make the move to an agile methodology. The leaders certainly can decide to just institute the process changes—daily stand-ups, backlogs, fast iterations and the like—and train the staff in how it should work. This is the way many companies do it. But it is usually not very effective. Because agile is not just a way of running projects, it’s a way of thinking about software, a very different way than many people were trained to think about it. Implementing the changes to the process without changing the way people think, without trying to change the culture, will not result in a meaningful change.

Small changes—like your team seeing the wisdom in the agile principles—is not always easy, and it does not occur overnight. A change like this is evolutionary by its very nature. By constantly fostering small changes you can build the foundation for the evolutionary change you want.

Big changes are possible—they happen every day—you just can’t skip building the foundation for them.