How did we ship our product to 3 new countries in 2 months?

Beginning in February we started working on the internationalization of our product. This article will give you some insights on how we managed to ship our product to Germany, Spain and Italy in less than two months.

It all started during a weekly strategy meeting in February.

• Guys, we need to open our product in Germany, Spain and Italy.
• Alright, when?
• By mid-April
• …

At this moment nobody really knew how that would be possible. We roughly estimated it to be at least a 6-month project. How could we ship a bank in three new countries in two months?

At Qonto, we strongly rely on a model called the Toyota Production System to align the whole company, to create teamwork and to ensure quality at each level (you can learn more about our model by reading this article). This model has an underlying philosophy that Jeffrey Liker revealed in his 2003 book called “The Toyota Way”. He synthesized it in this way:

As you can see the first basis of continuous improvement at Toyota (which strongly inspired Agile methodologies and tech companies all over the world) is the ability to set ambitious challenges and align the whole company around these challenges.

A famous example of this philosophy is the Shinkansen project. In 1964, Tokyo welcomed the Olympics for the first time in its history. In order to facilitate the commute between Japanese cities, the government decided to launch a very ambitious project: build a train in less than 5 years that could reach Tokyo from Osaka in 3 hours. At the time, this seemed impossible. But it was a challenge that could not be argued because this was a national target with a nation’s post-war pride on the line. Everybody had to get involved to tackle this challenge. Five years later, the Shinkansen was up and running.

At Qonto we believe in this philosophy. The company sets ambitious goals that can’t be argued because this is what needs to be done to become the company we want to be. We set incredibly challenging targets, we face the challenge, we tackle it. And this creates the best conditions for improvement and team involvement.

So, how did it work for our internationalization project?

A purely delivery challenge

First, we had to decide what needed to be done. We quickly agreed that we wanted to ship the exact same product we had in France to the new countries. The purpose was clear: learn from country specificities as soon as possible with real clients instead of making hypothesis on which feature would work in which country. Once we’ve made that choice, it became pretty clear that it was purely a delivery challenge: let’s take all our banking features to new countries.

Again, when it comes back to delivery, Toyota gives us a clear framework on how to ship quality fast. One of the two pillars of the Toyota Production System is called Just In Time. This is the art of shipping what a client wants, only what he wants and exactly when he wants it. One Piece Flow and Pulled Flow were the key of our velocity in that project.

Rule #1: Do not batch — slice and go one piece flow

Slice your work as much as possible

This might be the most important factor in helping us reach our target: we sliced our work as much as possible. It is impossible to handle the complexity of such a project unless you break it down into smaller pieces. Then, when we sliced our work and set multiple small targets, our engineers were able to intervene and react as soon as something happened instead of working alone in a tunnel for several weeks.

This is pretty basic: if you have a two-months project you’ll know that you are late after two months and it will be too late to react. If you have a daily target, you know if something is wrong within the day. With small targets you are able to see the problems happening right away and then trigger problem-solving on a daily basis. Therein lies the true power of continuous improvement–you set the conditions where the team knows as soon as possible if something goes wrong and you give the space and the means to solve the problem right away (to learn more about how we handle problem-solving at Qonto you can read this article). By doing so, the team will not only solve problems, but will also get better at seeing problems they were not aware of and will learn to solve them quicker. This dynamic leads to a daily improvement of the performance of the team, led by the team itself.

In our case, some functional blocks such as “an Italian user can register on Qonto” were sliced in more than 10 small targets! Not one of our targets needed more than 5 days of work to be reached. And of course we had daily sub-targets for each functional step. Thus, as soon as an engineer was blocked by something unusual or unpredicted, the team or lead were able to help and unblock the situation right away. For instance, it appeared quite immediately that our way of handling translations was a huge pain for the team. Instead of waiting for weeks before thinking about it, we were able to improve our translation standard from day 1, sharply increasing our efficiency in later developments.

Strictly follow the one-piece flow rule

Moreover, we did not believe that to finish our project on time we needed to start all the different parts of our project right away. Instead, we focused as many engineers as possible on the same step of our project at the same time, and we took each step one by one. By doing so we did not create any entropy and noise due to multiple projects running at the same time with isolated engineers working on the side in isolation.

Most of the time it is a real technical conception challenge to make sure that several engineers can work together on the same functional block–especially when you slice them as much as possible. But if you make this effort, in the end you will speed up your delivery in proportions you cannot imagine.

Most of the time, teams struggle to understand the value of one-piece flow before they experiment it. Indeed, the logic behind it might be a bit hard to grasp. The most convincing thing I ever saw on this subject is this short but powerful video:

Puzzling right? In our case it meant that for each functional step we asked our engineers to work by teams of two or three. And if a project was blocked (missing spec, unanticipated technical issue…), we did not start a new project but we focused everybody on unblocking the work in progress and resume the work. The general idea is to reduce stocks and WIP as much as possible. This principle sharply speeds up the delivery, increase teamwork and spread knowledge across the team.

Rule #2: Do not create stock — pull your flow

Finally, we constantly pulled our flow between our product team and our tech team. What it means is that we never created too much stock of features ready for development between the two teams (the opposite of the product team “pushing” stock to the tech team). Arbitrarily we decided to limit the stock to two functional blocks ready for development and then as soon as our stock was maxed out, our product team stopped working on shipping new specs. We did that because creating stock leads to two strong negative effects:

• It creates noise for the tech team: to do specs, product guys need to work with the devs and thus stop them from working on the feature they are currently focused on.
• It creates obsolescence. If you have stock (a spec for example) completed by product but waiting for devs, it could sit, waiting for a long time. Thus, you’ll have a strong probability to have an outdated spec at this moment because the knowledge is not the same, some new product decisions have been made that changed the scope of the spec. Then the tech team will start working on something only to stop after a few days because they realize it has to be reworked by the product team — and everybody loses a lot of time.

If you follow this rule, you will immediately improve the tech team focus and drastically reduce the number of reworks and time lost by your product managers and engineers. Plus, instead of pushing useless stock, the product team will be able to help the tech team shipping faster (QA as soon as the dev is done, be available if there is any specs modification to do…).

To enforce that, we used visual management that showed the flow of our features and clearly indicated when there was too much stock between the teams.

You can see that we have limited space for features ready for development. As soon as this space is full the product team stops working on new features. Instead, they focus on emptying the WIP.

Finally, this visual management is also a great “source of truth” when it comes to team synchronization. We use it each time we need to align people on the roadmap and on what are the next things to be done. The bottom-line is that this visual helps the teams with learning how to work together better.

Rule #3: create a strong team commitment

Last but not least, shipping such a project that fast cannot happen without a strongly committed team. This is something we created by doing three main things:

• Give a strong purpose by communicating in an open way the importance of the challenge (the user demands in these countries, the company MRR goal, the strategic necessity of going international for the company market cap…).
• Give them space to solve problems and think about how they could improve their way of working. Too often, under the pressure of shipping fast we forget to take time to do what really counts: solving problems.
• Do not use due-dates the wrong way. The due-dates are not a way to control a team and punish the team members if not reached. It is a simple way to see if everything is going well or if something unexpected happened and thus see room for improvement.

What was the result? Well, a dedicated team that was completely focused on achieving the seemingly impossible target and get the opportunity to be proud of tackling a real challenge.

This is how we managed to reach our target. Beginning in February, we set the goal to open Qonto to Italian, Spanish and German companies by Monday, 15th of April. The development was done on Friday, 13th of April. Just In Time.

On a more personal note, I want to take the occasion of writing this blog post to tell our team how proud I am of the accomplished work. We’ve learnt that shipping fast does not mean under thinking nor being stressed out. It’s just about good teamwork.

You want to tackle that kind of challenge? We are hiring! https://qonto.eu/en/careers