Working in a corporate it is common to hear the call for innovation. Businesses know that an important part of their success in the market place is to be able to innovate. Yet all too often, these organisations find it increasingly difficult to innovate. By thinking about evolutionary processes or about systems it is possible to offer some possible, albeit unsubstantiated, reasons for the difficulties, and some possible remedies.
Let’s start by considering a timelapse view of a business concern.
The concern starts out small, maybe a handful of people. The group includes a number of people with varied skills. The business builds up assets, which includes mechanisms, processes and networks that enable their business. But, because there is no precedent for how to implement solutions the wild west prevails. Many options are tried quickly. Some options are clear non-starters, and are dispelled with good humour. Some show potential, and some see earlier success.
In short, this group of people is innovating. They are rapidly and fluidly trying out different options, traversing a search space of potential and they are applying an objective function (a combination of market success and internal acceptance to the group).
The business thrives and grows.
At this point, the business starts to bring in new talent and to expand the number of people. But with more people there is more noise. The processes of general spit-balling and exploration begins to feel like an undue overhead. The owners begin to be concerned about the expenditure.
A natural inflection point is reached. A new drive for efficiency is introduced. The full force of the industrial revolution is unleashed. Processes are standardised.
Initially this standardisation pays dividends. The organisation is streamlined in its ability to execute and deliver on strategic ideas. New business processes and mechanisms are delivered in record time. And at this point, the organisation marvels at its own success (to broadly quote The Matrix), and it institutionalises the role of standardisation.
Standardisation becomes paramount in the way that the organisational system works. All new undertakings must proceed according to standard. When any new element is needed, it must first be distilled into a standard, and then mandated throughout the organisation.
All the while, the business continues to grow and develop, but there is this uneasy growing feeling that something has been forgotten or lost.
At the same time, there is the increasing awareness that new progress seems to take longer and longer. The institutionalised view that the time can be improved through greater efficiency is repeatedly brought to the fore. There are attempts to increase standardisation. Additionally, there are attempts to cut costs by sourcing cheaper implementation staff, or outsourcing to lower bidders (with the view that any deviation in required quality will be caught by standardisation).
If organisations are lucky, then they only get stuck in this spiral at the point where there market share allows their growth to continue unabated, while they grapple with higher internal costs and time to market.
At this point we can consider taking a step back and applying systems thinking.
Maybe the drag on the ability to deliver new mechanisms and processes, for use by business, is actually linked to a negative feedback loop that standardisation can have on innovation.
That is, in short, maybe innovation is being stifled by standardisation.
Does this mean that standardisation should be completely eschewed.
No. Luckily systems thinking teaches us that healthy systems can contain multiple feedback loops, and that these can balance each other out.
That is, unchecked exploration and experimentation can lead to innovative ideas that can not be realised as pragmatic and usable assets. In order to balance this, it is useful to set a few standards in place e.g. have fun exploring new ideas, but remember that we need to pay the bills at the end of the month.
The problem is that the “standard” of budgetary sustainability was implicit in the start-up phase of the business. Anyone involved in the burgeoning stages knew tacitly that the business needed to bring in cash. As such, there was an imposed standard constraint on the innovative ideas, which is to say, all ideas were good, so long as they could bring in cash.
But, unchecked standardisation results in a system that has no options. There is no potential for exploration or experimentation. In short, any attempts to innovate are non-starters.
Often businesses will now react by running campaigns to attempt to encourage innovation. These are often combined with monetary incentives to innovate. Unfortunately, the monetary incentives can often illicit unintended consequences (but that is a line of thought for a future article).
Clearly a balance is needed between these counter acting processes. There needs to be a way to cultivate innovation while still seeing the benefits from standardisation.
A key insight here is to consider business organisations as collaborative systems. And in particular systems-of-systems. With this notion of hierarchy in mind it becomes possible to consider driving either innovation or standardisation at different levels within the system. That is, there might be value in allowing for innovation at particular levels, within the organisational system, that are distinct to levels at which standardisation is enforced (or strongly encouraged).
This notion relates to another concept from systems theory that highlights that systems can benefit from both competition and collaboration, but only when these feedback processes are being enacted at different scales (or levels of abstraction) within the system.
Now, as the reader, you might be thinking that the above sounds reasonable. But, without some more concrete options it would also be easy to dispel the above notions as hot air (especially because the author has not included any supporting references for this verbose opinion piece).
Switching gears, however, lets consider the act of developing large scale software systems for businesses. That is, software systems that embody the life blood of the business’s core processes.
Given this, how would we balance standardisation while cultivating innovation?
One approach would be to be careful about choose the system levels which should exhibit standardisation, and the system levels which should be encouraged to exhibit variance (as a result of exploration and innovation).
To be more clear, consider a distributed system that consists of the following separate hierarchical levels: application frontends, business evaluation, implementation teams, business logic backends, persistence mechanisms, build systems, infrastructural resources and, maybe one that is not seen as its own level, the interconnection mechanisms.
Now we can choose where the standardisation should be placed and where we would like to see innovation. For the levels that are to be standardised, we need to ensure that the standards are carried out with a high degree of clarity and quality so as to not create any friction. For the levels that would benefit from innovation, we need to ensure a high degree of autonomy so as to not unduly and prematurely restrict the search space and stifle creativity.
Now, the exact choice of which levels to allow to explore and which to standardise would depend on the organisation and the problem space. But in many cases there is benefit in facilitating collaboration between team members and between teams. As such, one should standardise the tooling for tracking work and communicating between teams and individuals. However, different teams are tackling different types of work, so there is value in exploring different modes for internal work.
Similarly, it is useful to be able to reuse computing services across the organisation, so it is often useful to standardise the mechanisms by which data is exchanged between services, while taking care to cover different use-cases (e.g. high throughput, asynchronous comms, box-car data transfer, streaming, synchronous exchanges etc.). However, again, different business components may benefit from different software implementation approaches, so there is often benefit in allowing a larger degree of variability in the implementation.
Note, variability in implementation should not be confused with variability in quality. So, again, the quality points can be standardised by setting SLAs on services and components. Additionally, quality can be controlled by standardising requirements for providing online system checks and telemetry.
Finally, business still need to meet shareholder expectations. As such, another standard that should be imposed is the need for linking implementation to business ROI models. This requires standardising how business defines strategic objectives and communicates the manner by which systems will be evaluated against their ability to support the bottom line.
One could go on for longer… and if you’ve read this far, you’re probably hoping that I don’t. But the key point is that organisations need to consider balancing innovation and standardisation. These are elements that can be applied together so long as there is consideration regarding the levels of the system that are being targeted and that these levels are reasonably causally disjoint when applying innovation versus standardisation.
Taking a systems approach to the organisational structure and design allows one to apply a complex mix of strategies, while still balancing the feedback loops in a manner that encourages progress within the organisation.