5 Questions for Antoine Sauvage, CTO of Ovrsea
I’ve been working with Ovrsea for over a year on software quality issues, spending 8 to 10 days a month with them. More than once, the company’s culture has made a positive impression on me: a culture of technical excellence, marked by humility. That’s why I wanted to share their approach with you. And what better way to do that than to let Antoine, Ovrsea’s CTO, speak for himself?
How did the idea of seeking technical support come about?
We’ve long had a culture of training, which is an integral part of our value proposition as employers. Among other things, we hire young developers when we see potential, and we help train them. As a result, our turnover is very low: just one departure since Ovrsea was founded five years ago, out of a tech team of 15 people. But beyond the desire to improve, I felt the need to explore blind spots. By that I mean verifying that we’re moving toward a certain state of the art—and, above all, doing so continuously. Always going further. So I was looking for an experienced outside perspective that could provide us with feedback while helping us grow.
What reservations did you have before starting the program?
I had plenty! A lot of questions, in any case. The main one was about ROI. First of all, how do you measure it, and when does it actually show up in the quality of the code, given that there’s some inertia: it takes time for individual progress to happen, and then more time for that progress to translate into the codebase. And then there’s the opportunity cost of hiring an external coach: for the same budget, I could hire a full-time senior developer. Wouldn’t that be better? The other issue is that I was looking for someone capable of truly guiding us on our production code. I didn’t want it to remain theoretical—doing coding exercises is fine, but ultimately it has to translate into the production code.
Are these reservations still relevant today?
No, clearly the time we spent together helped answer those questions. In fact, I felt reassured three months after the coaching began. As for ROI, I know I can’t put a specific number on it, but I’ve noticed that we’re maintaining a steady pace of delivery even as the team grows (Editor’s note: +50% in one year) and we tackle increasingly complex features. That wasn’t a given, and it’s a sign that our code has good scalability. From a qualitative perspective, I can also clearly see the teams’ commitment, their enthusiasm, and the joy they take in making progress. We have a genuine culture of learning, self-reflection, and transparency, and your guidance really contributes to that.
What accounts for this ability of the code to evolve?
In practical terms, the most significant contribution of the coaching over the past few months has been hexagonal architecture. It has allowed us to take a major step forward in structuring our code by clarifying the nature of dependencies. It’s radical; it’s crystal clear. As a result, we’ve gotten into the habit of writing the domain first—using Test-Driven Development while we’re at it. Today, it’s a pattern we’ve mastered well, and it has spread throughout the entire tech team. The more senior members set the framework for the more junior ones. That’s where we see that coaching has real effects on production code—it’s not just theory.
Have you “made it”?
No! Thinking we’ve “arrived” would mean we’ve missed something. I hope the coaching never ends, because there’s always room for improvement. Even the most senior team members can keep growing, and Ovrsea’s mission is to train everyone. Having an outside perspective is invaluable. In fact, the deeper we dig, the more opportunities for improvement we see. It can be a bit overwhelming at times, but that doesn’t detract from the quality of the code today. In particular, we want to make progress on the front end and bring more consistency to it. The hexagonal architecture should help with that, too. But for me, what’s really positive is that we’re able to evolve the codebase by making the old and the new coexist. We’re able to carry out all the migrations continuously, so to speak. There’s always a library we want to phase out, a pattern we want to standardize. All of this happens as we go along, without a big bang.
Can you see why I love working with them?