Amazon Web Services (AWS) is the fastest-growing business in the history of technology. (Per analysts at Deutsche Bank who measure such things, AWS is the fastest-growing business in history, period.) AWS also innovates faster than any other commercial technology player, averaging one product release or major upgrade per day since their founding in 2006.
This column isn’t a commercial for AWS or the cloud. But there are useful lessons in AWS’ inception and rise to prominence that are relevant to all of us working to drive innovation in the insurance enterprise, irrespective of tool or stack.
First, a little history.
The year was 2000. Amazon was struggling to grow amid headlines predicting “Amazon Dot Bomb” and “Amazon Dot Toast.” It was trying to launch an e-commerce platform called Merchant.com to help third-party retailers like Target and Marks & Spencer build online shopping sites on top of Amazon’s e-commerce engine. I say “trying” because Amazon’s development teams were missing key milestones and blowing deadlines. Raise a hand if you’ve been there. I’m raising mine.
The problem was Amazon’s legacy technology. When Amazon launched in 1994, they geared their platform to selling only their own inventory. They didn’t plan for future requirements such as shared environments and secure multi-tenancy.
In parallel with Merchant.com, Amazon was hiring hundreds of engineers to build out their core e-commerce capabilities. More engineers, the thinking went, should result in more innovation delivered faster. But project teams, forced to provision their own database, computing and storage resources, were waiting three months for infrastructure--for projects that should’ve taken less than three months to complete. Amazon’s technology operating model, based on best practices, was proving itself too slow for the high-velocity e-commerce market Amazon was striving to create.
Slowing revenue growth, a dwindling cash pile, nervous investors and a NASDAQ in free fall meant that everyone with a pen or keyboard was urging Amazon to cut costs, on technology in particular, to weather the storm. But Amazon went the other way, doubling their technology spending. Analysts freaked.
Job One was to untangle Amazon’s monolithic legacy stack into a well-documented set of distinct services capable of interacting with each other through a well-defined set of application program interfaces (APIs). The good news for Amazon was Merchant.com ultimately went live. The bad news was it was a total flop. The silver lining was the Merchant.com platform was repurposed for Amazon’s Third-Party Seller network, which today delivers about half of Amazon’s e-commerce revenue.
Job Two was to build a common set of computing, storage and database resources that internal development teams could provision in minutes instead of months. The result was all good news here for Amazon as development cycles and innovation accelerated as team sizes and development costs shrank. New features such as “customer reviews” and Amazon Prime were added quickly, about as quickly as the ideas themselves were conceived.
See also: Why Analysts Need Business Awareness
Competing against Walmart’s massive size and razor-thin 3% margins, as Amazon’s new technology operating model bore fruit, internal development teams were tasked with finding open-source alternatives to expensive commercial software. Why spend, for example, $100 million on Oracle licenses when there were open source options? Building and operating their own datacenters, Amazon likewise cost-optimized everything from building construction to CPU design to server procurement to energy consumption.
As Merchant.com was an attempt to let other retailers leverage Amazon’s platform for their own e-commerce, AWS was about letting businesses in any industry leverage Amazon’s tools and processes to rapidly build and scale technology solutions at a low price, paying only for capacity used.
The time between the first business case for what became AWS and writing the first line of code for what became their first product--S3? Eighteen months. Amazon spent that time forcing a specificity of thought and intent around the product, working customer-back. “Slow down,” went the internal mantra, “to move fast.”
Though several lessons can be drawn from this mini-case study, I take four:
- What’s your real problem? What aspects are people/process-related versus technology-related? Humans tend to blame their tools when results are suboptimal. Missing targets, is it the archer or the crossbow? If it is in fact the latter, by all means accelerate replacement.
- Are your best practices still best? The acceleration of technology innovation means best practices expire faster. This isn’t about chasing every fad. It’s about questioning core principles from time to time, especially if you’re struggling to deliver results, disconfirming beliefs.
- Slow down to move fast. The larger the initiative, the bet, the more planning required. “Build fast and break things” may be a winning mantra for tech startups in Silicon Valley beginning life with zero customers. But you have customers, and you can lose them if you’re not careful. Rigorously think and plan things through, always working customer-back. Speed comes later.
- If you believe you’re right on the first three points, then gut it out, stick with it, be prepared to be misunderstood internally and externally for what may be an uncomfortably long time. Go ahead, let the analysts freak out.
