I had an interesting conversation with one banker this week. They work for a bank that is interested in blockchain use cases (aren’t we all) and have been tasked to create a proof of concept. All well and good. Then the challenge kicked in. Who wants to work on the proof of concept?
The team leader decided a good place to start would be in the commercial bank around trade finance but the head of trade finance in the commercial bank said that they didn’t see why this was of interest to them. The conversation went something like:
Team Leader: Blockchain is hot and can save you millions, increase profits and efficiency, differentiate the bank and help you to win awards for innovation in trade finance.
Head of Trade Finance: Sounds good. Show me the numbers.
Team Leader: What numbers?
Head of Trade Finance: The plan that demonstrates how this will save me millions, increase profits and win awards.
Team Leader: Urmm. Well we don’t have any because this is a proof of concept.
Head of Trade Finance: What’s a proof of concept?
Team Leader: Well just that. An experiment to prove that the concept will work in your part of the business.
Head of Trade Finance: What? You want to experiment in my part of the business?
Team Leader: Yes.
Head of Trade Finance: Well fork off and come back when you have some numbers. You’re not messing about with experiments in my business.
Oh dear. Not to be defeated, the team leader thought: ok, we need a proof of concept so let’s go talk to the development team, and off they went to the Head of Engineering.
Team Leader: Hi. We believe that blockchain protocol can save the bank millions, increase efficiency and make the bank better.
Head of Engineering: So?
Team Leader: Well, I was wondering if you would work with us to demonstrate that this promise is true.
Head of Engineering: What would that involve?
Team Leader: Well, we were thinking that if you could give us a small team of developers we could create a proof of concept to take to the commercial bank and prove the promise.
Head of Engineering: Why?
Team Leader: Why what?
Head of Engineering: Why would I give you some of my developers?
Team Leader: Urmmm … for the good of the bank.
Head of Engineering: It may be good for the bank, but what about my costs.
Team Leader: Well, it would only be for a while.
Head of Engineering: No. Tell you what. When you find a company has proven the concept, developed the software, made it available and has proven robustness, then we’ll take a look at it. Our job is to keep the bank running and buy in software where it makes sense, not to develop new software internally that’s just based on a promise.
The lament of the blockchain team leader rang bells, as I’ve heard it elsewhere. In fact, one bank recently said to me that they no longer were looking at blockchain as that’s R3’s job, which is why they joined the consortia. I was surprised, as R3 are not looking at every blockchain use case and start-up blockchain company out there, but more involved in developing a bank-consortia owned blockchain themselves.
It also demonstrates the lack of motivation of line of business heads and owner of resources based upon incorrect bonuses and incentivisation. If a Senior Vice President has his or her bonus based upon profits, revenues and customer and staff satisfaction, as most do, then they will have zero interest in technological developments. In fact, that’s why so many bank leaders have zero technology focus, or knowledge, as it turns out.
Only 3% of CEOs of leading banks have any professional technology experience;
Only 6% of board directors overall have any professional technology experience;
40% of banks have no board members with any professional technology experience in their career.
If banks are truly technology companies, systems integrators and software houses – as some bank leaders claim – then they not only need more technology leadership at the helm, but better organisation to atop technologies.
By way of example, if 20 percent of the line of business leaders’ bonus pot was tied to demonstrable innovation in technology through at least one project that proves decreased costs and/or increased revenues, then the conversations above might have been different.