Constraints

Recently, I was chatting to a product developer for a large retail bank. She had two very insightful observations about innovation in banks (and I guess many other firms).

First, she said, "Well, Tom [not his real name] the CEO, was very excited and fully behind the idea of innovation, but the middle managers were a real problem." She went on to detail how they had blocked, rejected and made implementation difficult.

This shows the importance of a culture that embraces change on a more fundamental level than mere 'lip service'. Contrast this with Toyota where change and innovation are somehow 'built-in'.
Second, she observed, "Then the IT is a real stumbling block. No matter how good the innovation is, we have to be scheduled into the next release cycle and that means our time to market is far too long."

This practical problem is as serious an impediment as the cultural issues. Perhaps it is even the cause of some of the negative experiences of the middle managers. In banks, the technology is the product. Poor technology architectures inhibit change and the introduction of innovations.

Most banks are in a similar position with a large investment in product specific packaged applications. These count against bringing in new products and services as they often need a new product-specific application that requires extensive integration into the existing environment. Alternatively, they cause a replacement of an existing monolithic application. In either event these result in multi-year roll-out plans.

Even those that build most of their applications, have built layers of complexity on top of layers of complexity. This makes each change incrementally longer. A large financial clearing house, recently quoted five days of testing for every day of coding!

There is a major opportunity when banks' product development can move at anything approaching Internet speed.