The Need for Speed

How “second-derivative” strategic thinking can accelerate your company’s ability to respond to change.

Managers have been automating and re-engineering processes for decades. While the aim was to improve efficiency and reliability, the end result has often been to saddle companies with a morass of entangled technologies that make it difficult to keep up with an accelerating rate of innovation in the world at large.

Most companies have tried to drive cost savings and outmaneuver competitors by adopting hulking enterprise resource planning (ERP) systems that are designed to streamline business operations. But, instead of enhancing competitiveness, these systems – which usually take several years to design and install – end up rigid and increasingly inflexible, especially when compared to the new-build approaches of aggressive digital disruptors. The complexity of these systems makes it difficult and expensive to drive any further change. As the pace of technological advance speeds up, companies that can’t continue to change quickly find themselves falling even farther behind their nimble competitors.

Companies that can keep up, or even surge ahead, focus instead on a strategy based on what’s known in mathematics and economics as the second derivative – improving the rate of change itself. In business, a second-derivative strategy means focusing not just on the one-time change a project is designed to deliver, but also the additional changes an enterprise can make as by-products of that project that will make future projects easier. By doing so, companies can create an acceleration effect that can ultimately cut development costs from hundreds of millions of dollars to a fraction of that and reduce their speed of delivery from months to days.

Companies that follow a second-derivative strategy stick to a two-part playbook. First, they are clear about the gap between the way they deliver work today and where they want to be in the future—while accepting that their vision of the future isn’t static and is likely to change multiple times. Then, companies identify the hurdles in the way of achieving that vision. Knocking down these roadblocks is made an explicit goal of each new project so that later projects don’t encounter the same issues. For instance, if every project requires weeks for server provisioning, or bespoke security development, it slows innovation. A better approach is to solve for infrastructure provision, security rules, budget approval processes, and so on once, and then roll the solutions into assets that every project can benefit from. It’s very hard to make a business case to address these kinds of issues on a standalone basis and so it usually doesn’t happen. But the second-derivative approach recognizes that it is often cheap to address them alongside existing work.

Managers should aim to adopt second-derivative strategies that treat agility as a goal in itself—enabled by building a growing tool-chest of capabilities, reusable components, and standardized processes that constantly create value at a faster and faster rate.

Making change a constant for a product

To understand the power of a second-derivative strategy, consider how rapidly Tesla’s cars evolve. Tesla’s strategy was to build a car like a smartphone, making it safer, smarter, and more capable over time, thanks to operating systems that could accept over-the-air software updates. Its software Autopilot 8.0, for example, allowed owners of 2012 models to install 2016 model functionalities, such as enabling the car to process radar signals more effectively and let drivers monitor vehicles two or three cars ahead without having line-of-sight.

Tesla has also prepared for autonomous cars long before they are fully feasible —equipping its cars with self-driving hardware even though the software is not yet written. By installing cameras and sensors necessary to gather data about the car’s environment from multiple angles, Tesla smoothed the path for future change. Essentially, data collection from millions of miles of real-world driving allowed Tesla to test and continually improve braking, collision warning, self-steering, and cruise control. Unlike other car manufacturers that are lab-testing autonomous cars before introducing them, Tesla recently offered over-the-air downloads of self-driving software to 1,000 real-world  drivers so it could continue to learn from real-world testing in actual autonomous cars.

A second-derivative approach to services

Companies that follow a second-derivative strategy can expand their reach faster and with less investment than competitors. For example, German, online, digital bank Fidor, which was acquired by the French bank BPCE in 2016, has a set of open and standardized processes, protocols, and tools for building application software that exists on top of its legacy operating systems. Because the bank’s interface is essentially just code and has minimal interactions with its operating systems, Fidor (or one of its licensees) can reconfigure it and actually deploy a new bank in another country in the time that other banks might require merely to develop a project plan. With its “no-stack software-as-a-service banking,” a digital bank just fires up servers, deploys code, and plugs into a slightly different set of data feeds at the back end. Using this approach, Fidor’s costs per customer are only a fraction of what they are for most major banks.

Modularizing standardized IT components also permits Fidor to push out new products at an accelerated pace. Many of these products are not available at other banks. Fidor can offer real-time loans at many different points of sale and a multi-currency eWallet that allows customers to buy currency, make payments, and view balances. Recently, Fidor became the first bank in the world to accept bitcoin as a currency, and it is now looking to use blockchain to replace traditional low-level banking services that presently cost banks tens of millions of dollars annually to maintain.

Redefining agility

Most companies haven’t fully recognized the hidden costs of the IT mistakes they began making 25 years ago when reengineering first became a buzzword—so they continue to repeat them today even as they strive for agility. Too many companies, when they think about change, still rush to build huge new IT systems that they hope will lead to big improvements—in three years, if they’re lucky. In the meantime, their capabilities will have stagnated and the complex, new system is doomed to be out of date the moment it’s finished. When a company’s level of competitiveness is determined by the vintage of its last systems re-platforming, it is in bad shape.

Instead, managers should aim to adopt second-derivative strategies that treat agility as a goal in itself—enabled by building a growing tool-chest of capabilities, reusable components, and standardized processes that constantly create value at a faster and faster rate. Only then will they be able to raise the speed limit of their businesses, keep up with the world around them, and create lasting competitive advantage.