To think that incrementalism is relegated to what you build would be incorrect. The reality is that incrementalism runs far deeper than the mere product decisions that make up a portfolio. Incrementalism is not the sum of all decisions but rather the source. It is more cultural than overt acts. And such, it exists somewhere just below the surface, difficult to diagnose in the moment but plainly obvious over time.
Generally speaking, there are three major types of players when it comes to incrementalists:
- Legacy - These tend to exist in a strong incumbent position, but this can also cover new entrants whose business hopes are pinned on “a small percentage of a huge TAM”. You can spot these players because they are so obviously legacy or because they explicitly hope to create solutions that are purely substitutive.
- Innovators - Probably the most difficult of the three groups because their new products are shiny and exciting. They have aspirations to be new and distinct, but in the absence of a different way of thinking, they unwittingly end up in the same place as the legacies they are trying to unseat.
- Revolutionaries - Marked by their differences rather than their similarities, the revolutionaries advance brand new ideas predicated on new ways of thinking. The challenge is that they can lack the pragmatism to see their ideas adopted mainstream, so they tend to either shine brilliantly or flame out in spectacular fashion. The successful revolutionaries marry their ideas with pragmatism – an unrelenting focus on insertion and integration.
Legacy players tend to rely on one tool more than any other: the feature list. The objective of the legacy player is to attribute value to the totality of invention since their inception. Each feature was careful crafted so solve a problem, and the legacy vendor will remind you of that every time there is a new project. They come armed with Excel spreadsheets, and they fight with back room whispers come RFP time: “Remember when…” They bring up with remarkable precision and clarity every issue that has ever reared its ugly head, using them as an opportunity to solidify the need for this feature or that doodad.
The innovators are usually pretty easy to spot: they are proud of being innovative, and their marketing materials and press releases likely use the word to describe the company. To be fair, their motives are pure and their solutions are better than the incumbents. Without the legacy baggage to drag them down, the innovators can start anew, which creates cleaner, more rapidly evolving solutions. They will typically pick a particular vector that the legacy solutions cannot address because they are bloated and overweight. Scale, speed, and cost tend to be those things that suffer most under the heavy burden of decades of feature creep.
The challenge with the innovators, though, is that they are starting with a new product, not a new idea. Fundamentally, they are solving the same problems that have existed for decades. And truth be told, they are re-playing scripts from the past. They will build from “good enough” components to drive down cost, and they will streamline parts to the product. They will utter phrases like “Knowing what we know now…” to indicate that they have learned from their past. But what they learned from their past is how to build the same thing a little bit better. Ultimately, if you start from the same beginnings and think the same way, you are going to end up in the same place.
Legacy players are married to the past, innovators rethink the solution, and revolutionaries rethink the purpose.
If the legacy organizations continue to build the same stuff, and innovators start fresh but end up on the same trajectory, how can anyone hope to build something that is not only better at inception but better over the lifetime of the solution? It’s actually more fundamental than starting with the product architecture.
We have actually seen this in an adjacent space: server virtualization. It took a new company rethinking the purpose of the server. Starting with a different objective, VMWare was able to arrive at a fundamentally different landing spot that moved an entire market forward by leaps and bounds.
In networking, we have taken for granted for more than two decades that the purpose of the network is to provide connectivity. We want point A to be connected to point B and C and Z. Everything has to be connected to everything else. And in the absence of information, we need to build out uniform capacity everywhere in the network. The result is some of the ridiculous network architectures that are in play today that are provisioned for worst case.
But the purpose of the network is actually not to provide connectivity in equal measure to all pairs of end points. The purpose of the network is to enable conversations. Put simply, when we describe our industry (either networking or IT) to our loved ones and acquaintances, we describe it colloquially as “This thing talks to that thing.” Intuitively, we have it right. The purpose of the network is to let this application talk to that application, or that server to that database.
If the purpose of the network is to enable conversations, products and solutions ought to start there. But they don’t. Why not? Because rethinking the purpose isn’t in the toolbox for either the legacies or the innovators. Our industry is in desperate need of some revolutionaries.