"I want every engineer at Qonto to be legitimately proud of the systems they’re responsible for."

I became an engineer because math was fun and because the French education system pushes people who enjoy the company of numbers, just like me, toward engineering careers.

At first, programming was just another way to solve puzzles. When I graduated, I realized I could rebrand it as software engineering and turn my hobby into my job.

Fifteen years later, contributing to open-source projects is still a hobby, when I can make time for it — with three kids, this is harder than it used to be.

After an internship at Zonbu, a Silicon Valley start-up, I felt the need to get a better understanding of business. I joined Polyconseil, a telecom & media consulting company with a successful spin-off, Wifirst. There, I didn’t do consulting and I didn’t do a spin-off. However, I managed an emerging software engineering practice. Along the way, I became a Django core developer.

Five years later, I wanted to explore a broader range of skills. I became the CTO of Oscaro, the e-commerce leader for spare auto parts in France.

Then, I felt ready to start my own business. I created a consultancy around Python and Django. Getting my first client through inbound marketing on Twitter and then getting my first invoice paid felt great: I had bootstrapped a business!

Shortly thereafter, I co-founded Otherwise, an InsurTech start-up. We were making insurance more simple, transparent, fair, and human by creating communities and by redistributing fees that didn’t compensate damages.

In 2017, my first boss reached out to me and asked me to manage an engineering department at CANAL+, where he was the CTO. The group was undergoing major changes and there was a bit of turnover. I’m always in for a good management challenge! I spent the next three years shaping new management practices in the data, digital, and IT teams. We optimized how we worked together and with all business stakeholders.

And today the story repeats itself: someone I managed in my very first team, who now works at Qonto, asked me if I would be interested in managing him again… 👀

That was an easy decision! I joined because Steve, Alex, and other Qontoers thought I was qualified to lead our Tech team. It would be a shame to pass on a great opportunity in one of the most successful start-up in France right now. 🚀

I felt immediately at home with the culture at Qonto. When Steve, Alex, and other managers talk about Qonto’s values — Ambition, Teamwork, Mastery, Integrity — it’s clear that they’re living by these values and that’s why they’re succeeding.

Furthermore, they organize their work in a very conscious way, applying models to understand and optimize everything they’re doing. Much of what I do in my professional life, I learnt on the job, so I tend to rely on intuition rather than models. I saw how much room for improvement lay ahead with a more structured approach.

Finally, in my previous experiences, I swinged between innovating in new businesses and getting management experience with larger teams. Qonto is the perfect opportunity to do both at the same time. That’s a great fit!

The hiring process was impressively well organized, all the more since Qonto doesn’t hire CTOs regularly — at least I hope not in the near future. 😅

I noticed two striking demonstrations of professionalism:

• Every interviewer was familiar with what I had discussed with previous interviewers and knew exactly what they wanted to test. That’s serious discipline.
• Throughout the process, I was getting regular feedback on where I was doing well, where I wasn’t, and what was still in doubt.

It really felt like Qonto wanted me to succeed, if I could.

When your future manager gives you fantastic feedback even before he hires you, this bodes well. I hope I can live by the same standard now that I’m conducting the interviews!

For the anecdote… after the fit interviews with my future team — when we hire managers, they interview with their would-be team — Steve explained they’d found me a bit pushy. Then, after a second of silence, he added: “You’re outspoken. You must wield this carefully. That said, if the team hadn’t given this feedback, I would have stopped the process there.”

Apologies, folks — we had only one chance to meet for the first time, that was over a visio call, and I did what I had to do.

The whole process happened during the lockdown. Many people ask me what it was like to sign for a job at a company where I’d never met anyone in real life. Well, for me, that wasn’t a big deal. All I remember is some idle speculation about how tall were the people I was talking to. Probably my experience in open-source communities helped, as most interactions are in writing with people I’ll never meet.

The first part of the job is figuring out the job. 😀

Also it’s very likely to change quickly as Qonto grows.

Let’s go for the fundamentals. The Tech team contributes to providing a great service to Qonto customers by designing, building, documenting, testing, and operating complex systems with a high level of reliability and security. Easy?

Perhaps easier said than done, but I have a guideline: it all comes down to growing the team.

By “growing the team”, I don’t mean “adding more people” — it’s much more than that:

1. Boosting individual performance - Help each team member become the best version of themselves. Once that’s done, start over and help them become the next best version. The Qonto Way gives a framework. Managers can lean upon this framework to grow the skills of their team.
2. Catalyzing collective performance - A collection of smart individuals achieves great results only when they organize efficiently to complement each other. This doesn’t happen by itself. As Qonto and its Tech team scale quickly, I need to ensure that our organization, processes and tools remain efficient.
3. Building up the team - More than adding people, it’s about welcoming the right people. They will reinforce the culture, live by the values, and ultimately make their team greater than the sum of its members. This is why we have a carefully designed hiring process.

If we do this correctly, I’m confident that the team will be empowered to make the right calls and build rock-solid tech.

Then I can choose where I want to move the needle, get into the details, and coach the team.

Scaling. Scaling, too. Did I mention scaling? 😉

We’re fortunate to have strong technical foundations. We aren’t busy putting out fires. Our scaling challenges are more about operational excellence than fixing technical problems.

Currently, the Qonto tech stack involves about thirty systems. We split them primarily by business domains. As we grow, we get more strict about enforcing separation of concerns between domains. We also account for some technical requirements. For example, the card payment authorization system is a dedicated service because it has specific high availability requirements.

Evolving towards a more maintainable and reliable architecture is certainly our greatest challenge, as this requires creating consensus around a target and aligning an ever growing team on this vision.

Besides, per Conway’s law, our technical architecture is bound to take the shape of our organizational structure. As a consequence, we can’t decouple growing our systems from growing our team. Doing so separately is already quite demanding. Doing both at the same time is even more challenging and definitely exciting!

There’s also challenges around our reliance on third-parties for some aspects of our operations. For example, initially, we relied on a third-party core banking system. In 2018, we started to build our own. One year later, it was ready and we started managing customer accounts there. This was a huge project.

We have other projects on the same scale ahead of us. We must decide carefully when’s the right time to start them. Then we must take them to completion on time, or else we have a massive impact on the roadmap.

The last challenge I’d like to mention is quality. There’s a bit of a paradox here. While everyone agrees that our quality is quite good, engineers are still challenging the quality of what they’re producing. In itself, this isn’t surprising for a young company where engineers have high standards. It seems amenable to objective discussion.

However, our lean processes depend on everyone ensuring quality at every step, so quality is a diffuse responsibility. No one is dedicated to quality assurance. There’s no single place for discussing quality. Resolving the paradox requires aligning everyone’s definitions and expectations.

If I asked you to guess, you’d get it mostly right. This makes it easy for newcomers to familiarize with our organization.

We have cross-functional teams (CFTs) covering each major area of our business. Most CFTs are permanent because they focus on a core business need like registration, transfers, cards, or the ledger. Some CFTs are created specifically for a project and have a shorter lifespan. However, we value team stability, so we’d rather ask an existing CFT to take care of a project than create a CFT for less than nine months. Every quarter, we adjust the CFT structure to our product roadmap.

A CFT includes one or two product managers, a backend developers team, and a frontend developers team. All backend team Leads report to a Head of backend; ditto for frontend. This helps maintain consistent practices across CFTs.

Currently, mobile is still a single team because we don’t have enough iOS and Android developers to staff each CFT. We’ll discuss extending the CFT structure to mobile when they’ve grown enough for this to make sense.

Operations and security are also separate teams, as most of their activity is transversal.

First and foremost, we’re distancing ourselves from agile. Heresy! This requires a bit of explaining.

We have three concerns with “mainstream agile” — think of scrum and similar techniques, which most tech companies practice with varying degrees of discipline and maturity:

• Sprints are fundamentally a greedy algorithm. They get you to a local optimum. It’s unclear that you can reliably reach a global optimum with this technique, nor that you can reliably take the fastest route to get to the optimum.
• Iterations are often misused to cover mistakes and avoid hard discussions. We’d rather think of iterations as “rework”, which fits into the general category of “waste”. Putting effort in upfront planning is hard but saves a lot of time downstream.
• Agile tends to break down when you need to coordinate multiple teams. In our experience, techniques for scaling agile such as scrum of scrums or SAFe tend to degenerate into a bureaucracy held together by an army of agile coaches, at the expense of empowerment and velocity.

Don’t get me wrong — when I mention upfront planning, I’m not going for the disaster of the V-cycle. Of course we’re slicing the work in small chunks and we’re formalizing frequent opportunities for discussion between product and tech. We’re just structuring this process for maximum efficiency and minimal waste.

Compounding our sins, we aren’t even looking for what comes after agile. On the contrary, we’re going back to what agile stemmed from, that is, lean.

You can look at our blog posts about the Qonto Way to learn more.

Another singularity stems from being a Fintech. Mistakes tend to be slightly more costly than in many other lines of business. The “how bad would that be” scale goes up to “billion euro mistake”. Of course, we organize accordingly. We have plenty of structural, technical, and human safeguards to prevent mistakes from happening, as well as tight regulation.

I got used to “terabytes per second” as a reasonable unit of network throughput in my previous job. I assume I’ll get used to “billion euro” as a reasonable unit of financial responsibility in this one!

We’re looking for people who share our vision to build the leading finance management solution for SMEs in Europe, making it easier for millions of businesses to thrive, and who can help make it happen.

We have positions open across a broad range of Tech skills: backend, frontend, mobile, operations, and security.

For the next quarter, my focus will be on:

• Backend developers - Our ideal candidate has FinTech experience, knows one of our two main backend languages and is willing to learn the other. Our core banking systems are written in Go. Customer facing APIs and other internal systems are built with Ruby on Rails.
• Engineering managers - As we hire more developers and create more CFTs, we need engineering managers to lead them. Sometimes, we have good internal candidates that we can promote. Else, we look for the right external candidate. We have management positions open in almost every domain.

If you’ve been looking for “engineering done right”, look no more.

Strap in and we’ll turn you into the next best version of yourself. 🙃