Many organizations are experiencing rapid change around their IT departments. IT is under pressure to contribute more to the business, to adopt more agile processes, to adapt to Cloud computing, to do Big Data, to move to continuous delivery and so on. Why is this series of changes regarded as separate from innovation and the innovation platform? And what can we learn from it to inform “regular” innovation?
Perhaps the scariest and most profound aspect of IT transformation lies in the latest round of methodological innovation - continuous delivery (or sometimes referred to as continuous deployment – there is a difference).
In continuous delivery paradigms companies release updates to their infrastructure or products in a continuous stream, sometimes as often as every few minutes, but more usually on a daily basis. In continuous deployment the decision to deploy updates to code is automated. It requires well ironed routines because there is no human intervention in the decision process at the point of release.
Therein lies a very basic mismatch in many companies. Rapid, automated innovation processes, very complex, difficult adaptation to an innovation culture.
It doesn’t necessarily exist in pioneer companies like Netflix – Netflix consists of 80% engineering staff and its current objective is to scale a business that used to be built around mailing out DVDs into one that can deploy streaming video to any device ,anywhere in the world. That means it is very IT focused.
Nonetheless these ideas – continuous delivery, continuous deployment and the automation that lies behind it – are themselves serious process innovations that all innovation managers need to think about. If change can be done like this, why isn’t it done like this everywhere in all cases of product development?
Increasingly companies will be integrating software into their products, as well as trying to integrate some form of external ecosystem support (often via an API). They are in the area of business where continuous delivery is a source of competitive advantage, whether they like it or not.
So, on one side of the innovation divide IT is often a self-learning, self-teaching organization with strong links out to the broader community of IT professionals, often in open source projects or in forums like those hosted at Stack Overflow or open development programs like those hosted at GitHub.
On the other side of this divide we have regular innovation, which can be a long process of eliciting new ideas, assessing their validity, trying out a subset, adapting decision processes to allow some of these to graduate to higher levels of investment, hosting jury panels to get outside-in perspectives, and so on.
Nobody can doubt that this side of the divide is important. It’s vital. It's innovation! And going forward it will hurt companies that cannot accelerate innovation because consumers are being schooled into expecting continuous improvements. So why can’t it be done faster?
There are several answers. In my semi-regular conversations with Colin Nelson and Tim Woods here at HYPE, the feedback I get is that deploying HYPE is often an important first step for companies in uncovering their own business innovation cultures – teams in Japan might see innovation differently from teams in Boston or London or Frankfurt. Those differences need ironing out before the internal crowd really gets to work.
Sorry but that is just too long-winded. Companies will struggle to build a prosperous future if they cannot accelerate beyond this phase 1 innovation behaviour very quickly.
In IT there is good and bad innovation, highly developed and sadly under-developed innovation too. While IT at its best is now highly innovative, let’s not forget that the past twenty years have been regressive for IT. There have been instances like Microsoft’s global control of the web browser, as it dominated through Internet Explorer, that retarded innovation. ERP systems created more accurate reporting but they also felt like a deadweight on many organizations. The three-yearly SharePoint update literally halted some company’s innovation in its tracks.
But let’s recognize some advantages that IT can draw on and that innovation professionals can emulate:
- The open source community
- Real critique
- Serious delegation.
Open source is beneficial to IT because it both saves on resources and it cycles the need for learning and new knowledge dissemination in software development. Perhaps its biggest long-term benefit derives from this phenomenal achievement of a self-sustaining, self-learning community. As business increasingly relies on adaptive knowledge, this community is an exceptional, unprecedented resource.
Real critique – within that community criticism of code is routine. You cannot code in a public space unless you can take criticism. This adds to the refinement of a learning community.
Serious delegation – open source projects elect committers who are responsible for running the mechanism that gets code out of development and into production. Committers have to reflect the voluntary nature of open source at the same time as be persuasive about the disciplines of the profession. Code has to be good.
These three dimensions alone give software advantages that the innovation community might not even realize it lacks. To be in a real open learning community, to be critical of each other’s efforts we refine our capabilities, to have real responsibility for committing innovation to the product line without too much ado from above. If companies can’t cogenerate these communities or capitalize on those that are already out there in some form, they are going to stay in the domain of periodic new product launches. It won’t be enough.