- Share this item with your network:
- Download
Modern Infrastructure
Rawpixel - Fotolia
Early adopters of technology belong in every organization
In today's rapidly changing tech environment, avoiding new opportunities means falling behind. Thorough research into newly available tools leads organizations to success.
"Nobody ever got fired for choosing IBM." That's how the old quip goes, and that remains the mentality of many IT professionals today -- at least in their aversion to trying something different.
Even as disruptive apps regularly take down decades of business as usual, the people who make everything work under the hood gladly run in the middle of the pack, shun beta versions and stick to the safe bet. Early adopters of technology are out there -- flying in the face of these conventions -- but they're not taking on as much risk as you might think. In fact, executives are throwing their support behind innovative IT.
There was an era when a buyer blindly trusted the salesperson, said Mark Betz, site reliability engineer at Olark, a live chat and messaging software provider. If the tool or platform wasn't right, no one could blame you for relying on a trustworthy major vendor.
With the rise of open source, the risk shifted. You're now responsible for understanding the product you choose, Betz said. "Do you trust yourself to make a good decision? Do you trust your colleagues?"
If you select a tool but don't test it or understand how it's deployed before you send it to production, there's not much doubt who'll be assigned blame. "If the system blows up and 10,000 users can't access their accounts, that was your fault," Betz said. "Maybe you should get fired. But it won't be because somebody lied to you -- it will be because you didn't do a good enough job."
That's democratic and empowering. It's also scary as hell.
When new is the only answer
Early adopters of technology thrive on responsibility because they're trusted to do what's best for the company, without a lot of bureaucracy. The decision-making process gets streamlined, and creativity drives success.
"You work with a small team of smart people and evaluate a tool, decide whether it works for you, test, implement and deploy it and just make things happen," Betz said. While this process is prevalent in small startups, it happens in large organizations as well. It boils down to what the organization expects from its IT department -- will the autonomy and trust invested in smart professionals pay off?
Avoiding the best new tools and technologies carries a cost, both in missed opportunities and in lost focus for valuable team members.
"Engineer labor costs are probably the highest expense we have as a product organization, and every single hour that these guys lose not writing code for our customers is very, very, very expensive," said Lior Gavish, who started Sookasa, a cloud-native company that was acquired by Barracuda Networks.
He adopted SignifAI, a monitoring intelligence dashboard tool, while the vendor was still in stealth mode. With the tool in place, his DevOps team could spend more time writing product code and less time setting up monitoring alerts.
Mark Betzsite reliability engineer at Olark
Dedicating manpower to analyze every part of the system and set the thresholds, which change rapidly, won't create business value, reasoned Gavish, now vice president of engineering at Barracuda. Rather than the user inputting what to track and how to set thresholds, SignifAI absorbs systems' metrics and automatically detects anomalies. It correlates metrics to associate anomalies together and create a full picture of operations and dependencies.
"Even if you make it part of your DNA to monitor every new feature you launch, it's insanely hard to maintain it -- it's impossible unless someone spends all of their time on it," Gavish said. So whether to add an upstart tool for that task goes back to the question: What do you want to pay people to do?
This same reasoning plays out in the rapid adoption of internet of things (IoT) technology and the software platforms that support it. Early adopters of technology seek to differentiate an IoT product or transform a process to be more efficient and effective with predictive insights -- it could be life or death for the business.
For a traditional company such as Boeing, IoT software platforms enable it to sell a plane engine with an uptime promise, said Michele Pelino, an analyst at Forrester Research. The group that made the engine tracks what's happening inside products in the field and sends replacement parts to a plane's next destination if a piece is wearing out.
The aerospace company's goal is not to create an IoT software platform; the goal is to connect devices and gather useful data to sell its engines. The next step for early adopters is to source a platform that simplifies this complexity, which requires a lot of legwork before you buy.
Do it without going down in flames
Everyone's behind you. With an unconventional vendor choice and early adoption of a new technology, it's critical to win the support of senior management. Remember how no one ever got fired for choosing IBM? The person in charge of hiring and firing will decide if the early-adopter-of-technology culture is acceptable. That buy-in will determine how the organization constrains or guides the decisions that innovators make.
Beyond that boardroom champion, build consensus. "You have to get the architects, the engineers, the finance team and the ops team aligned around [one thing,]" Gavish said.
Lean on your colleagues. To go from laggard to early adopter, it helps to have a guide who has been there before. Experienced veterans from startups can naturally undo the instinct to shun risk rather than chase reward.
As part of his duties as vice president at Barracuda, Gavish is tasked with creating a startup stack mentality -- cloud-based containers and infrastructure as code -- to modernize the company's back-end IT. "When we first came in and we were talking about AWS [Amazon Web Services], it was this nebulous idea. … Nobody had really looked at the [AWS Management Console]; nobody had really built anything on AWS," Gavish said. "It's hard for me to explain to other people at Barracuda that you absolutely can't SSH [Secure Socket Shell] into our machines."
His team exposed their counterparts throughout the organization to real production loads in the cloud. When you can see containers, DevOps, immutable infrastructure as code, cloud services and other leading-edge ideas and technologies in action, it clears up a lot of misconceptions and mythology.
Know what you want. When sourcing technologies that don't have traditional maturity benchmarks, research becomes even more important. Don't talk to the vendor until you know what problems you need to solve, Pelino said.
"Many hundreds of [vendors] say, 'I'm an IoT platform' today," she said, and that's common with new technologies that lack a standard definition. In IoT, certain software platforms are better for connected products and others suit connected processes; some work more with consumer-focused users, and others with industrial products. Only some IoT platforms will deploy and scale seamlessly and securely with your enterprise architecture.
When you're ready to engage vendors, ask questions about functionality, pricing, support and integration.
"Early adopters of any technology find that folks are speaking the same words, but they mean something different," Pelino said. Tell vendors to show you -- not tell you -- what they can do. Don't fall into the trap of chasing the best tool rather than the right tool.
"While you may not have the whole answer to everything, you certainly will have a great framework for having that conversation," she said.
The Lonely Road to Innovation
Many disruptive IT initiatives start as pet projects or small experiments. In TechTarget's Internet of Things Pulse Survey, 72% of organizations pursuing an IoT initiative said less than 10 people were involved in the project, with 12% saying it was a single-person effort.
Get what you're promised. Whether the provider has decades of experience or just hours, the key is to evaluate your purchase. Current and past customers are good places to start for objective feedback on the product.
"There are many tools that might be new to us, but have a long following in the open source world," Olark's Betz said. For example, you may be implementing Elasticsearch for the first time, but thousands of other users have experience with the technology.
Some vendors have great capabilities but poor implementation support and professional services for troubleshooting, Pelino warned. Betz added that open source tools, while more transparent, frequently have ad hoc support.
New technologies developed by companies with tremendous scale -- think Google or Facebook -- are cutting edge without commensurate risk. Betz cites Google Cloud Platform (GCP). As an early adopter of GCP years ago, he bet on a company that was new to cloud sales at the time, but versed in cloud-scale operations and management. GCP is now a top public cloud option.
Trust but verify. "Sometimes you go a little cowboy," Betz said, when an unproven tool is the only answer you've found to a given problem. For that enticing new GitHub repository, open source code mitigates danger to production, revealing if a tool is flaky or has security bugs.
The tool goes through preproduction verification as well. Staging and experimentation provide a layer of risk management. "By the time we take it into production, we never feel like we're holding our breath," Betz said.
"People talk about moving fast and breaking things. I don't really like the second part of that, ... but I definitely like moving fast," Betz said.
Next Steps
Facebook's early adoption of DevOps set the stage
Kubernetes is a big name, but just hitting production
Skillset training can't catch up to DevOps evolution
Related Resources
Dig Deeper on DevOps
-
AWS touts security culture, AI protections at re:Inforce 2024
-
Monte Carlo unveils data observability for vector databases
-
Monte Carlo boosts data observability with generative AI
-
Fivetran, Monte Carlo target data observability at ingestion