10x Invent and Simplify

How to drive innovation through cycles of simplification

Amazon is a multinational technology company based in Seattle, Washington. Founded in 1994, it has grown to become one of the largest online retailers in the world, offering a wide range of products and services to customers globally. In addition to e-commerce, Amazon has also expanded into areas such as cloud computing, artificial intelligence, digital distribution, and consumer electronics. With a focus on customer satisfaction and innovation, Amazon has disrupted traditional retail and changed the way we shop and consume products. Despite facing criticism for its impact on the retail industry and working conditions, Amazon continues to shape our world and set the standard for modern businesses. Amazon has famously and very publicly codified their leadership principles that help drive their day to day execution.

Invent and Simplify

Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here.” As we do new things, we accept that we may be misunderstood for long periods of time.

While invention gets all the attention in the industry, it’s worth pointing out, that simplification is at least as much, if not more, important when it comes to technology, for several reasons:

1. Increased Accessibility: Simplifying technology makes it easier for people of all ages, backgrounds, and technical abilities to use and benefit from it.

2. Improved User Experience: A simple and intuitive user interface can make technology more enjoyable and efficient to use.

3. Better Adoption: When technology is easier to understand and use, more people are likely to adopt and integrate it into their lives.

4. Enhanced Productivity: By streamlining complex processes and reducing the learning curve, users can spend less time learning and more time being productive.

5. Increased Innovation: Simplifying technology can also make it easier for developers and engineers to create new and innovative solutions, creating a flywheel effect.

Let me share a story of innovation that went through multiple rounds of simplification.

MVP for Virtual Machine Failover

At Springpath, I led teams on a tight schedule to develop Native Replication and Disaster Recovery technologies to deliver VM centric periodic protection. This was a precondition to the acquisition by Cisco, so the pressure was high. When routine scheduled maintenance activities are required, or for other management purposes, virtual machines can be migrated from the source cluster to the target cluster. Migration of a virtual machine leaves the replication pairing between the two clusters in place, so that the VM can be protected again in the opposite direction of the original replication. While all of our direct and indirect competitors offered rich primitives when it came to data protection, we didn’t have the luxury to build out the full solution set before we launched. We started off by defining the MVP (minimal viable product) for VM (virtual machine) failover - the operation that is at the center for enabling disaster recovery. In our early customer tests, while the solution was a bit “clunky”, it was immensely useful especially with an early version of the “runbook” we published (Refer to 17 step process under section Virtual Machine Migration). The power of our DR (disaster recovery) solution came from instantaneous and space efficient snapshots, and network efficient data transfer. This was enough of a hook for the customers to endure the “pains” of a less than ideal recovery experience.

Primitives for Reverse Protection

Launching it early (in retrospect, a bit too early) allowed us to gain feedback around critical gaps in our disaster recovery story. While the failover workflow addressed the migration part, the quick follow-through most customers wanted was an ability to protect the same VMs in the opposite direction. This was addressed in the MVP (step 17) albeit inefficiently, as the protection in the reverse direction ignored presence of any previous snapshots, and as a result, the first protection in the reverse direction was required to transfer the content (copy) of the entire VM. This was the problem we set out to address in the followup release. What we envisioned was an “iPhone like” protection system, and we wanted to lay down the groundwork. This was the release where we introduced four primitives that would eventually enable us to abstract away complexity from the users - prepareFailover, failover, prepareReverseProtect, reverseProtect. Refer to this guide for a detailed explanation of these commands (pages 11 through 16). This enabled our customers to develop even more “runbooks” to simplify their DR operations.

One-Click Migrate

Natural next step in the evolution was to start automating some of the “runbooks” that customers had started developing on their own. We also released a PowerCLI library including a set of standardized “runbooks” for our users to customize and use. This gave us clear insights into what set of “runbooks” customers were most frequently using. Failover followed by ReverseProtect was by far the most frequently deployed “runbook”. We chose this hero use case and simplified it for our users by exercising the aforementioned primitives in the background with state machines, and retries (in case of transient failures) and exposed this as a “one-click” option in the UI. Refer to this guide (section Managing Virtual Machine Disaster Recovery) This was a massive hit and we followed it up by automating a few more “runbooks” including ReProtect (where the VM can be protected against a replacement server). 

N:1 Edge Replications

As the adoption of our data protection solution grew (to an annual $100M in revenue), we gained even more insights. By this time, we had a number of “runbooks” in production. Customers had started experimenting with multiple topologies, and started mixing backup and DR workflows. By performing data analysis of common usage patterns from thousands of customers using backup integrations and DR operations, and leveraging the feature called “Server Profiles” from Cisco Intersight, we created a scaled up workflow for both configuration of backup for multiple topologies, and enabled automations through “runbooks”. The end result was N:1 Replication for Cisco HyperFlex Clusters. Refer to the solution brief here. This was initially targeted to take over the simplified backup market by reducing costs (licensing costs per backup pair) and by simplifying operations (“iPhone like” backup experience). The solution was also extensible to support DR operations.

So, there you have it, a story of innovation through customer feedback cycles, data driven insights, and rounds of simplification! 

~10xManager