Innovation Is Not a Campaign, It's a Culture

They say a new broom sweeps clean. Before the new CEO’s three opening strokes have even been dealt, the company has launched another full-throated innovation campaign, and suddenly innovation has become the high-sounding buzzword on the boss’s lips. The question mark in everyone’s mind is: how long can this sudden wave possibly last?

I don’t deny that a campaign like this — the executive team humbling itself to solicit ideas broadly, hosting hackathons, regularly rewarding employees who contribute innovations — can raise the innovation atmosphere across the whole company. In fact, these are all good tactics; they get people paying attention to innovation. But this kind of “rectification movement” produces only surface prosperity, not a lasting solution.

When front-line employees fall short on innovation, it isn’t simply a matter of lost motivation; there are likely deeper causes worth exploring. It’s like anemia: the body is weak and pale, and a jog or two will flush the skin red and make the person look a little more energetic — but it does nothing about the underlying insufficiency of blood supply.

If I were to take the pulse of this innovation deficit, I’d say it has to do with the following factors.

Performance Management

There’s a maxim in management: “What you measure is what you get.” Put another way: “What you don’t measure — or can’t measure — is what you lose.”

That’s just how it is: point the performance review at something, and the output follows.

If innovation metrics were folded into every team’s performance review, it might well have a positive effect on innovative behavior company-wide. But innovation is not an especially tangible thing; if you can’t measure it, you can’t appraise it.

Internet companies (or companies with an internet mindset — Tesla, Xiaomi) do very well here. Internet products also enjoy a natural advantage in bringing innovation into the performance system: gray releases, A/B testing, user behavior logging and analytics — all of these can measure and validate innovation. This way, a newly added feature can usually be validated within a very short cycle: trends such as user growth or shifts in user behavior quickly yield data. As a result, a team’s capability and performance in (product) innovation become readily apparent.

Traditional software companies without an internet mindset find it very hard to genuinely fold innovation into performance management. The number of patents and papers published might be one metric, but that’s a research-lab metric; a company is ultimately driven by products and profit, and innovation that doesn’t make money just sinks everyone together. Take the telecom industry I work in — here’s what the product landscape looks like:

• Product cycles run about six months (sometimes longer), so innovation cycles around a product are longer still, which makes measurement even more of a headache.
• Once a product ships, beyond after-sales service there is almost no good channel for understanding how it actually performs in the field. How much effect a new feature or bright idea really has, how much it influences sales — there’s essentially no direct data, only guesswork.

So if you can’t measure the effects of innovation, folding innovation into performance management is a non-starter. And without the support of the performance system, innovation is just talk.

Some say traditional software companies simply can’t measure innovation the way internet companies do. Save it. If a car company can build a vehicle that collects all kinds of information to understand how it’s running — one that can even download firmware over the air to update its systems and raise its chassis a little — then why can’t a telecom company?

The Work Environment

Complexity is the great enemy of software, and a complicated work environment is the great enemy of innovation. If a workplace isn’t simple enough, isn’t open enough, and getting the information you need to innovate isn’t straightforward, then innovation is off the table.

A few examples.

Many companies like to build their own toolchain — the entire build environment, say. The upside is encapsulation and uniformity; the downside is insularity and a split from the community. If you want to bring some new community tool into the work environment, it’s basically impossible.

Many companies, for the sake of internal network security, isolate the work environment from the internet. The downsides go without saying: git clone, go get, and the like are simply castrated. Downloading a library from the web — a few keystrokes — becomes an exhausting struggle.

Source-code protection. If the code directly relevant to your work sits behind strict access controls, efficiency itself suffers — so how could innovation survive?

A good work environment should be transparent and open. The ideal is this: by default, everything is accessible; if you want to hide some piece of information, you need to file a request.

Time to praise internet companies again. Generally speaking, they are far more open than traditional software firms in their work environments. The startups that have sprung up in recent years especially have taken openness to its limit. Docker and CoreOS are typical. Beyond open-sourcing their main business (to build an ecosystem), they’ve open-sourced nearly everything they have — including many internal tools they had no obligation to open-source (no one would have criticized them for keeping those closed), even the source of their own websites. You might argue that this isn’t their core business and that open-sourcing costs them nothing. But doesn’t that precisely reflect an open, inclusive mindset? With a work environment like that, how could innovation fail to appear?

API-fication

API-fication means that the systems we use at work — even the organizational form of the entire product — expose public (though authorized) interfaces for access. API-fication arguably belongs in the discussion of the work environment, but it’s so important that I have to pull it out on its own so it doesn’t get buried there.

An ideal software company should API-fy every internal system related to software development, and ideally its infrastructure too. API-fication produces many side benefits — because things are within easy reach, employees can readily build something that makes existing systems better.

If the company’s employee information system had an API, an employee could chart headcount trends and cross-reference them against business data, and might reach some interesting conclusions.

If the company’s server resources (test environments) had an API, an employee could build a build-and-test environment that operates across time zones (for a multinational), scheduling servers and network equipment more intelligently and cutting energy consumption dramatically.

…

The space for imagination is infinite.

API-fication lets information truly flow inside the enterprise. And only when information flows can innovation be everywhere.

People

The factors above look like management problems; at a deeper level, they’re cultural ones.

I’ve said before, in an earlier piece, “Talking Nonsense About Agile”:

“Agile’s primary goal is delivery — continuous delivery, from small deliverable features all the way to a finished product. Teams that use Scrum, slicing projects into iterations but still shipping once every six months, aren’t agile — even if every member holds a ‘Scrum Master’ certificate.”

If the company’s culture has no “agile” gene, then no matter how much agility is emphasized at the operational level, it’s just a pretty shell. If “innovation” isn’t genuinely woven into the culture, front-line innovation will keep rising and falling without ever reaching scale.

Someone may say that innovation is executed by people, so the human factor matters most. But unless the culture problem is solved first, replacing every person who seems to lack innovative ability won’t help. In an environment full of constraints and friction, people’s capabilities are invisibly suppressed.

Of course, one human factor matters enormously — the CEO.

Apple under Steve Jobs is an extreme example. Almost single-handedly he rebuilt Apple’s innovation culture, injecting vitality into a company that had grown stale and was bleeding talent.

So to build a company capable of sustained innovation, you must have a CEO genuinely obsessed with it.

The sugar-water salesman (John Sculley) and the finance wizard (Gil Amelio) couldn’t bring innovation to Apple. They’re ideal candidates for COO, but not for CEO. The CEO should be someone who delivers breakthroughs — someone who can boldly tell employees and the market: think differently.

Innovation should not be a campaign; it should be a culture rooted in the company’s blood.