In the search of Holy Grail
I am currently in my fourth month on Anthemis’ fellowship programme and it feels like almost daily somebody asks: “so, what does it mean to be a fellow?” My answer continues to evolve as my fellowship progresses. When I started the programme, I was 100% focused on one specific idea, which had formed in my many years of consulting for banks. It was an idea which simply did not want to leave me. The fellowship was the perfect opportunity to focus on it, dig deeper, define the problem and its borders, refine the questions and, ultimately, get even closer to seeing a solution. What surprised me though was the process I went through, the unfolding of perspectives when one allows themselves the time and the openness to explore way beyond where the answers are expected to lay.
As I write this article, it is the week of Finovate in London. For the past five years I’ve attended this event religiously. I remember the excitement and awe I had watching the fast paced presentations the first time. “Surely this is the direction” I told myself. Surely, I continued, this is how doing banking would look like in five years. Five years have passed and banking does not look like this at all, at least not in UK.
Last week I’ve attended the Domain Driven Design Europe conference in Amsterdam, which could not have been more different from Finovate in content, rhythm, style, concerns. There were no demos even if the attendees probably built a big chunk of the software any one of us uses today. By comparison with any Fintech event I typically attend, the approach was almost philosophical. Creators of trends, ideas and ways of working in software engineering shared with younger generations their views of doing things better. Eric Evans encouraged us to think about time not in an additive way but as a game board where one moves forward but not always with the same velocity. Rebecca Wirfs-Brock gently took us on a journey through engineering heuristics discussing the properties of “things which have life” and how this applies to software. I could write much more on the Domain Driven Design (DDD) approach, which encourages engineers to really understand the domain they do development for e.g. banking and to go even further and be a “modern polymath” if one can walk the path.
This post is not about DDD though. It was rather brought about by being exposed through these events to a quick succession of contrasting approaches of solving problems in the world of FinTech. Banks, start-ups, software engineers, “fellows” like me who take time to think about this, don’t we all want to “solve problems”? Why though, I ask myself, have we not been very successful yet?
My feeling is that these communities rarely cross each other’s borders. There is a small number of bankers that have a strong understanding of the industry’s start-up market, trends and ways of working. There are still too few Fintech innovators who worked in a bank or in anything else than “digital”. There is even less cross-over between front-office and back-office in a bank. Between business and IT there is a chasm crossed only by consultants for which banks are charged hefty fees.
Banking is not a science, I know. One gets into it through being educated in other disciplines like finance or computer science or many others. Because it is almost never treated like a domain to be studied, it does not develop a language; it is not effective in defining its borders or articulating its ways of working, principles and functionalities. The back office for example, has the languages of accounting, risk and treasury and even these are not harmonised so people understand each other. To outsiders theirs is a common little understood language of back office. To “linguists” these languages are as different as Italian, French and Spanish — they are all Latin languages but you still need dictionaries between them. The lack of “dictionaries” for what is what in the world of banking creates problems when one tries to solve larger problems or when people from multiple disciplines come together. As we move towards front office, the language is that of digital development while branches remain probably the only places where customers can have an unscripted conversation.
Yes, banking is not a science and does not have laws as fundamental as the Laws of Thermodynamics but it is still in great need to be looked at with eyes that see patterns, principles and be defined and described for the benefit of both those who either tinker at the edges and of those who somehow manage to keep our existent banks working 24/7. After endless conversation during my fellowship with people from the world of banking it became even more obvious that we need to create the maps of our domain. This would be a collective effort but a necessary means of helping release much needed innovation in this domain. There is no one single start-up which will “disrupt” the field but I believe it is possible that more creative and technically astute individuals can address more significant problems, once they have an understanding how it works.
Bring your inner curious child to this arid domain, especially if you argue that it should look and feel seamless like a utility and it should make our lives easier, not harder. Put that curiosity to work and if you work in a bank learn about all the other domains you interact with. After you learn, teach. If you work in a start-up, you should write and teach too. Write what you learn at the interaction with banking. What you expect from them and you don’t have. Don’t limit yourself to saying that you want collaboration. Be precise. Chances are that if the message is clear enough and others ask for the same thing, it will be delivered, if not by a bank than by the next type of entity which will appear in financial services.
Also bring to the table the sharpest tools you have for system thinking and dealing with (artificially created) complexity. Chipping at the edges, as the innovation that has happened to date is not enough. There is a need to collectively extend our understanding of this domain and have a look beyond the visible part of the iceberg because that is the part that sinks ships.
I’m in search of the Holy Grail by asking for a more precise language of banking and for building a more rigorous, shared body of knowledge?
