I was reading an article from Ethan Banks, a friend and someone I respect, titled Why Being A Late Adopter Pays Off. It is included in the Human Infrastructure Magazine published by the Packet Pushers. I’m a happy subscriber.
The premise of this article is that early adoption of new and emerging technologies has been a bad bet in Ethan’s experience. I’d say that rings true in a general sense; we’ve all been bitten by the “new shiny” bug once or twice. However, 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.
Contents
Product Investment
Early products are absolutely going to be devoid of many features. In fact, new products typically just do one thing or a small subset of the greater whole. This may actually be refreshing! Beta testing is part of this process to some degree, although I think it’s a misnomer. In the right circumstances this should be viewed more as a product investment to leverage the vendor’s talent to build your ideal end state (or something close).
In reality, most products have a release cadence that clearly identifies the state of the software and related risks. Code that is a bit more experimental is often marked as Early Access (EA) or Directed Access (DA) since it carries with it a specific feature branch or fix for a regression. This sort of code isn’t allowed on production and you, as the customer, sign paperwork to attest this. The remainder of Generally Available (GA) code should be devoid of these little science experiments and much more reliable in production (hopefully).
Being an early adopter means more control over the initial product road map.
Want a button moved? Desire a new API endpoint created? Need something tweaked to a report?
Early adopters enjoy the ability to invest in the future of the product and put their fingerprints on it a bit. Product managers are often on the lookout for “friends of the project” – folks who use the product and understand that both parties are to gain by sharing information and ideas.
Speaking of product managers, check out 5 Books for Product Management.
Will the new technology crash or fail sometimes? Yep. But, isn’t this also true for any other technology?
This model is super fun, stimulating, and forms a relationship that pays off in the future.
Being a Change Agent
I’ve seen a lot of wild environments where the project is just “stuck” at a certain point. The people, process, and tools cycle has failed somewhere. Bringing in a new solution can help shake that up a bit.
For example, I’ll use the initial use case solved at my previous company: backing up data from virtual servers running on premises and storing the backups in public cloud storage. This sort of process typically touches numerous technology groups that control resources and capabilities. The cloud part was the scariest for folks that had never touched a cloud console before and were afraid of creating the next public S3 bucket. Adopting my solution made that problem go away, for the most part. Just a few clicks and things just worked.
This had a huge impact for my customers: time! Buckets and buckets of their time was returned. They used this time to go find other bottlenecks and technical knots to clear up the flow and resume doing their core work.
Imagine if those same people had given up early because they didn’t know all of the variables in play? Cautious optimism can pay off.
Sometimes a little disruption is quintessential for growth.
Check the Interoperability
I’ll finish with a final point on interoperability. Ethan brings up various networking protocols and the horror that is getting them all to work together. No thanks! 🙂
It can be tough to get a new product fully integrated with the greater ecosystem. That said, it’s becoming simpler. Any sane vendor is going to construct an API for customers to consume at a minimum. This is enough to get most anything done, especially getting multiple solutions to talk with one another. Heck, I use API calls for tasks all the time because that’s just how the real world works (even internally). This is the way.
As the new, emerging technology sees greater adoption, the creation of Software Development Kits (SDKs), CLIs, and other handy tools will pop up. This will accelerate the state of the overall project and allow for deeper and less “hands on” integrations. It comes with time and demand.
In the meantime, connect your new shiny API-driven technology all you want. Maybe start with small scripts that are called in the beginning and then shift to an SDK when it releases.
Make sure there’s an API you can consume.
Summary
Don’t discount being an early adopter if you have the chance and the opportunity fits. There are some spectacular benefits to be gleamed.
