As a technologist helping an organization form an IT strategy, I’m usually hesitant to recommend new tech. Why? Because it’s new. Adopting technology early in its lifecycle is a risky endeavor. For most organizations, I find that shiny new tech isn’t worth the risk.
Emerging products and protocols are often accompanied by great fanfare. Talks are delivered at conferences, whitepapers are written, and Gartner Cool Vendor designations are awarded. The idea is to make you and me believe that this new tech solves a problem in a novel way that’s never been done before. This is the thing we’ve been waiting for. This is so much better than it used to be in the bad old times. Right. I’m sure it is.
Despite my cynical tone, I am hopeful when it comes to new tech. I really am. In part, technologists are employed because of tech’s ever-changing landscape. But I am also dubious during any technology’s formative years. I take a wait-and-see approach, and I’ve never been sorry for doing so. I believe that being a late, not early, adopter of technology pays off for most organizations.
You Aren’t Stuck With Abandoned Tech
If you adopt early, you are hoping that the tech takes off. Maybe it will, but often it doesn’t. If the tech never sees broad market adoption, vendors are likely to abandon it. Then you’re stuck with it, as any tech you implement creates technical debt that’s hard to get rid of.
There are many reasons technology is abandoned.
- Sometimes, standards are created that compete with other standards. One wins. Another doesn’t. How’s that TRILL fabric working out for you? Okay for a select few, but not many.
- Startups build interesting products, but those products don’t always make it in the marketplace. The founders might have to give up if there’s not enough money coming through the door.
- Sometimes, a startup is acquired, and the new parent company kills the product either purposely or by ignoring it.
Being stuck with technology no one is developing isn’t the end of the world if it’s working for you, but it’s a tradeoff. You’re stuck with the security holes, lack of features, and other quirks that are never going to get fixed. I suppose this is an argument for open source, since an organization could throw developers at the abandoned project if needed. But realistically, few organizations are able to do this.
You Avoid The Burden Of Beta Testing
When a new product comes to market, it’s not fully formed. There will be bugs. There will be features you want that aren’t there and won’t be there for a while. You are, in effect, helping to develop the product. You’re an unwitting beta tester, and you’re paying for privilege. For some companies, that’s actually what they want. They want to provide input to the vendor to help steer the direction of the product.
For most folks, beta testing is actually not what they’re looking for. For me, the issue is time. I don’t have the time to shepherd the product along. I need the product to work as advertised out of the gate, and not spend half my time frustrated by non-existent (but necessary) features, logging bugs, or finding workarounds.
I want to implement and operate the technology. Not test it. I’m happy to let other folks take on that thankless task. I’ll adopt later in the product’s lifecycle when it’s grown up a bit.
You Don’t Have To Figure It Out For Yourself
If you rely on training to get a handle on a new product, good luck when the product is new. Official vendor training often doesn’t exist early-on. Third-party training gets created due to market demand, but most new tech doesn’t have much demand yet…because it’s new. It will take time for the product to become known to the market and demand to ramp.
If not training, then perhaps documentation, right? Some vendors will, as a standard part of their product creation process, release robust documentation for that product. But in other cases, that documentation will be…less robust, shall we say.
If no training or documentation, then vendor support, right? Um, you know how you’re calling support because you’re struggling to find the answers due to a lack of docs? The vendor support team is likely to be in the same situation. You might have a hard time finding a support engineer with the answers.
Adopting technology later in its lifecycle means that you’re more likely to find community support, decent documentation, or training for the product in question.
Vendors Solutions Are More Likely To Interoperate
When a new protocol comes to market, the standards are not always rigidly defined. For IETF RFCs, there’s a pure evil in the words “MUST” vs. “SHOULD” vs. “MAY”. When an RFC reads “SHOULD”, that means the specific point is optional practically speaking, despite being recommended. You should do it. It’s the right thing to do. But you don’t have to do it. There’s usually a behind-the-scenes reason an RFC specifies should instead of must. Someone involved with the writing of the RFC didn’t want to have to while someone else knew it was proper. Read IETF BCP 14 for more detail on how these words are meant to be adhered to.
The openings left in some standards can lead to vendor interoperability. The shiny new thing as implemented by Vendor C doesn’t work the same as Vendor J’s implementation. If you’re all in on Vendor J, no problem. But if you have islands of Vendor C that need to work with islands of Vendor J, there are problems where the island edges meet.
Sometimes, these are long-standing problems. For instance, there are vendor interoperability challenges and/or competing standards with segment routing and EVPN that have been ongoing for years now. Sometimes these differences are philosophical and unlikely to be resolved. Other times, the differences might simply be time-related–one vendor implemented a new feature sooner than another vendor.
If you wait a while to allow the technology to mature, you might avoid interop headaches. And by headaches, I mean the inevitable workaround we technologists have to come up with to make the thing work that should have been working in the first place had the standard actually been more than a suggestion.
Your Organization Can Skip Needless Disruption
Change, in general, is disruptive. Changing to a new technology is certainly disruptive. Adopting the tech has operational impact. Transitioning legacy infrastructure to the new tech is risky. Business stakeholders might need training to use the new tech, and certainly the front line IT support staff will have to ramp up. And let’s not forget the dollar cost with its supposed ROI disrupting the budget.
New tech is not a casual undertaking. Is it worth disrupting the business? Is there a payoff? Late adopters are more likely to know the answer to this question, because they can examine the stories of those who have gone before them.
I believe part of SD-WAN’s success in the marketplace is a result of early adopters working out the difficulties, finding the victories, and now being able to conclusively explain how SD-WAN technology is a better solution than what they had before. The disruption to cut over remote offices and workers, and cloud connectivity to the new model paid off.
By the same token, I think many who have adopted public cloud too early have experienced needless disruption. The ill-considered lift-and-shift approach many organizations took early on has resulted in additional IT spending (not a reduction), major operational change, and massive IT staff stress. In some cases, workloads have come back from the public cloud to private data centers, a phenomenon known as cloud repatriation. A late adopter approach would have made more sense as the market remains, even now, unsettled as to what “cloud” is actually supposed to look like.
Examine The Tradeoffs
One argument against late adoption is that of opportunity cost. New tech could give a business a leg up on a competitor (faster to market), improve the bottom line (reduction in cost), or improve the top line (increased sales). Could it be that your organization is giving up revenue by delaying adoption? Perhaps, but I think this fear is overblown most of the time. I’ve seen many abandoned projects in companies over the years, where the organization would have been better off waiting to see if the new thing was going to become an industry mainstay.
I’m not saying that early adoption of new tech is never worth the risk. Once a while, I suppose it is. Still, new technology is rarely as transformational as it is in PowerPoint. You can probably wait a little longer.
For an alternate viewpoint, check out my friend Chris Wahl’s take, Power to the Early Adopters. Chris says, “I wanted to point out a few of the good things that come from being an early adopter from someone who contributed towards a product that was adopted early by numerous folks.”