Money matters: The difference between R&D and innovation

R&D is about turning money into science; Innovation is about turning science into money

I learned this rule on a site visit to the sticky-note company, 3M, many years ago when I ran emerging technology for a major investment bank. It’s a simple rule and one you should never break.

The challenge with running an innovation function within a business has little to do with the work. Let’s be honest, for most people like me – let’s label us “innovation specialists” – what we do isn’t really “work” at all. Who wouldn’t want to play with GPT-4 all day and get paid for it?

This stands in strong contrast to the drudgery that constitute many people’s roles within a business, and therein lies the real challenge.

For every chunk of satisfaction (delight, even) found from innovation specialists, there is a large and equal amount of pent-up frustration in the “traditional” IT structures of large organisations. Including the banks I work with.

In terms of aptitude, capability and experience, there is an unquestionably deep skillset in most IT professionals that I’ve met from the “mothership”. That is, the name colleagues and I used to give to the central IT team.

Perhaps it’s not surprising that they don’t only feel frustration, but resentment also.

Resentment, because many of our colleagues who’ve been patiently building their career for ten or 20 years already also like to dabble in their spare time with blockchain and big data, while reading up on quantum annealing or whatever. And when they look at folk like me, sitting in the perceived “ivory tower” of innovation – they feel a deep sense of FOMO as their day job consists of migrating the Oracle database from version 12.2.0.1 to 12.2.0.2.

The IT mothership

This is one reason why it’s so important for innovation specialists to break the golden rule of not mixing R&D and innovation.

You see, innovators are there to learn how the mothership operates, internalise the strategic goals, and analyse the opportunities for improvement. Not disruptive improvement, but incremental improvement. When I say incremental, I don’t mean such things as swatting up on the feature list of version 12.2.0.3, but understanding the capability differentiation for graph-databases like Neo4j and how this might be able solve business problems that aren’t so easy to do with Oracle.

At the same time, as an innovator, you need to better understand the technology landscape. Not in the way that an architect will – for understanding the integration points between systems is not likely to be your forte. Instead, you should understand what Oracle is brewing in its own innovation labs and compare this to what’s going on with IBM, Microsoft and your other strategic vendor relationships.

At the same time, where is the startup ecosystem and where is venture capital flowing? And for the long-term bets like quantum, where is academic research focussed, and how might that research commercialise over the coming five to ten years?

With these two pools of knowledge – where the mothership needs help and where the technology innovation is occurring – you can operate an intelligent matching exercise. Feeding your innovation funnel with good ideas for experimentation that are likely to leapfrog the steady state of IT change upgrades and lead to new capabilities.

But you should never, ever look to do the fundamental research behind invention. Not only because that’s not your job, but because that’s the very thing that will kill your credibility in the eyes of your mothership colleagues. And stir up even more hostile resentment that will ultimately not only undermine you, but your entire function’s existence.

Return on investment from R&D and innovation

You see, an innovation function should operate with a strict ROI in mind. It should manage its initiatives as a portfolio. Experiments are okay, but they need to be grounded in what the potential financial pay-off is for the mothership, and how they align to the strategic objectives of that company.

Best practice is to stage-gate initiatives. Over time you’ll generate enough data to learn on average how many ideas turn into projects that are handed over to IT, and how many pilots never see the light of day.

Accordingly, you might discount your pilots to 75% and ideas to just 1%. So the 25 “good ideas” that your team is managing, each worth £100,000 to the organisation, are valued in aggregate at £25,000. If the same 25 initiatives make it to pilot stage, then they would be valued at £1.875m.

Consequently, the budget for innovation can be supported against its portfolio ROI value and not based on an arbitrary benefit to the mothership. Sadly, many innovation capabilities are justified by exactly that.

The R&D difference

For R&D on the other hand, the ROI to the business is much more difficult to quantify. Besides – unless your business model depends on new science, as it does for the likes of 3M, companies in the pharmaceutical sector, or organisations more generally that can put a value on intellectual property – then it’s unlikely that this is at all a capability that you should be building, let alone something which you should be distracting your innovators with.

As the rule states, R&D is about turning money into science; and this is antithetical to the raison d’etre of technology innovation. Technological innovation should be there to discover those opportunities to leapfrog competitors. It should deliver incremental benefit to the organisation: 1% faster, 1% cheaper. And all this with a lot less risk.

So, let your innovators instead focus on turning science into money. Leave the R&D to others who are better placed to play that game. Instead, tune your innovation capability towards applying innovation on the organisation. If you do this, then they’ll have much greater success at articulating their value to the mothership, and be much less vulnerable to criticism from those who wished to be doing their jobs.

As for the potential resentment between business-as-usual IT and innovation? Well, there are many strategies that can be deployed to mitigate this, but from my experience the grass is always greener on both sides. As innovators will attest, we rarely get to see our work completed and in production. Our colleagues in core-IT, on the other hand, very much see the satisfaction at the end of a hard day’s work.

Difference between R&D and innovation – Related reading

How your business can take advantage of GPT today

How AI is helping IT managers do their jobs better right now