What mattered last week — speed, speed, and more speed

Trade Finance, Insurance and B2B sectors are often described as slow industries. What are the keys to gaining speed in these industries?

Many processes in Trade Finance and Insurance, and B2B to a certain extent, involve a high number of steps, compliance checks, and internal verifications. Moreover, organizations in these industries have been built around processes. In fact, processes are so deeply established that few people across the organizations master the whole value chain: the process is like walls that hinder the individuals’ sight. As a result, these organizations seem to consist of a collection of local experts, where everyone knows inside out the step they are responsible for, but few have a detailed understanding of the overall architecture.

As a consequence, changing any small step within a process requires to consult several people, who are often out of their comfort zone in doing so, to check and cross check the feasibility and the impacts of the change. This results in extremely stable organizations — as expected from these industries. But in fact, they are so stable, that it hinders their ability to adapt, to innovate, and to reinvent themselves. Small change takes effect very slowly and with gigantic efforts. Radical change is quasi impossible.

Sometimes, organizations in these industries are described as very big boats, who are so slow to make turns. However a big boat is fundamentally a single consistent body, which does not entirely depict the nature of the resistance against change. In my opinion, these organizations rather look like giant squid: each of their sucker can prevent the entire body from moving, although the whole body of a giant squid is very flexible. But when it decides to hold to something, it really does, and it won’t let go. So it ends up moving at the speed of the thing it holds to.

Note that a giant squid is fast. In fact, it can swim fast, and it can walk on the bottom of the see. I can hide, and it can propel itself into impressive accelerations. How to make giant squids in Trade Finance, Insurance, and B2B sectors fast again? How to make the giant squid let go the thing it holds to, and move at its own speed again?

The need for speed is not different in these industries than others. Speed is a huge competitive advantage, and lack of speed a massive pain for newcomers and innovators. This is our daily focus at EHDA. It seems easy as we look like a small squid, swimming in the waters of giant squids. In fact, we are one arm of a giant squid, and we do everything we can so that all the arms swim efficiently together. We spend a lot of time getting the other arms to let go the thing they hold, one sucker at a time.

Why do we need speed exactly?

After spending most of last week pressing many EH colleagues and teams to solve questions fast, I am wondering why exactly we need speed. We need speed to achieve more, and better results. To swim into new waters. To test more ideas, and to launch faster the products or the evolutions resulting from the validated ideas. It is difficult to make the other arms of the giant squid want to achieve more — because often they have been designed to swim in a certain way, or worse, to hold to something and to not let it go. Speed, achieving more, is great for the overall organization, but has no direct benefit for each arm separately.

One of my lessons learnt of last week is that I need to better understand the value of speed for the EH teams I depend on. Often, when they start doing things at a different speed, following EHDA requests, it is a great step towards more collaboration, more innovation. But getting to this step is challenging. If we think of giant squids again, there are only two ways: either the arm spontaneously releases its suckers and lets go the thing it holds to, or the arm needs to be forced to let it go. Every sucker needs to understand and accept why speed is good for the giant squid — then each arm recovers his velocity, and in turn the squid know speed again.

Last week in particular, was a constant battle to keep speed, in an area that is usually so difficult for innovation: Legal. The more I dig into Legal questions, the more I see a parallel with Computer Science. For a given Computer Science problem, there are several code solutions, in several languages. For a given legal problem, there are also several possible legal architectures and contracts, in several jurisdictions. Not all jurisdictions may have an answer to the legal problem, and some legal problems have no solution in the existing jurisdictions. Just like Computer Science: not all languages can solve a particular problem, and some Computer Science problems have no solution yet in the available programming languages. One big difference can be noted: anyone can create a programming language, whereas not everyone can create a jurisdiction or modify one.

What I find interesting is that innovators naturally use programming languages that allow a maximal flexibility to test new ideas and take different angles at a given problem, while scaling up often needs to refactor the code into more stable / stable languages. The parallel with Legal raises the question: are there jurisdictions where to solve problems fast, before scaling to other more universal jurisdictions?

Finally, and that was one of the highlights of last week, whenever you find one colleague who has a detailed understanding of the overall architecture: after digging for days into a few legal questions, Frederic Biziere, a member of EH board, showed me a different way to address the same question, using a radically different architecture. This not only opens new perspectives to the question, it also unlocks possibilities to test potential solutions in relevant jurisdictions.