Corporate Inertia (and Why it’s a Good Thing)

“Technology has the shelf life of a banana.” – Scott McNealy¹

Agility is all the rage these days. Businesses are constantly emphasising their ability to respond quickly to the market. Technology stacks emphasise just how fast you can get up to speed. Even the development of software is done (or pretended to be done, in some cases) in a Big-A-Agile process.

Inertia is the opposite of Agility: the tendency to continue in the current direction and speed, even when the speed is zero.

I was reminded recently of a term I coined in a class project while writing a group paper maybe 10 or 12 years ago to describe the ability (or lack thereof) of a business to steer.²

Steer away from problems, steer towards opportunities … it really doesn’t matter where it’s steering, what matters is “how soon can the business course-correct?”

A number of factors determine how quickly a business can change course; the bureaucracy, the red tape, the approval levels, the technology and more all determine how quickly a business can change the course of a product, a department, a market or even the entire business itself.

I called this collection of resistance-to-change factors Corporate Inertia.

In some ways, it can have a negative impact on the business - you miss opportunities, competitors eat your lunch, you’re unable to steer away from the abyss even as you desperately watch it approach at a glacial pace.

I feel, on the average, that it might actually be a good thing. Corporate Inertia is a characteristic of really really large organisations.

Being resistent to change means that all these little fads that come around every year, get hyped spectacularly, and then remain used in a tiny niche for the rest of time … well, they tend to not get noticed by companies and institutions that change direction only very slowly and under great force.

If a company is forging ahead and adopting every new idea that looks great, their actual business is in a constant state of disruption. The tech stack alone is probably a nightmare fusion of different databases, languages, version control systems and multiple service providers.

On the other hand, who is going to bother getting their company to, for example, adopt a cloud-first deployment when it took six years of campaigning for the devs to unanimously agree to move off Subversion?

“But”, I hear you say, “That puts the company at a disadvantage in terms of innovation and new products, et cetera. Looks like you outwitted yourself once again, Mr FunnyPants!”

That’s not a problem for a big company: simply buy the small companies that succeed. It’s cheaper than having your own R&D department which develops 10 products, only one of which is ever going to make any money.

Think of it as outsourcing R&D, but only paying for the successes, not the failures. In your own R&D department, you pay the cost of the failures as well as the successes. By letting startups do the work and then acquiring them, you only pay the cost of the successes.^[You can argue that it’s more expensive to acquire than to develop. That’s a valid argument, but what you’re acquiring is a bunch of signed-up and paying customers, while what your R&D department is developing is a product, which has no actual customers when released on Day-1.

By being slow to change, the company will weather all short storms and survive the larger ones by buying an established market.

Footnotes