About
I work at a pace that lasts. So do the teams I build.
Peak performance lasts about three days. Eight-plus years in the engine room and the lead chair taught me to build for margins instead: teams that move fast, hold up under real constraints, and don't quietly fall apart.
I started in backend and infrastructure, and the deeper I went, the more I noticed the problems I cared about most weren't technical. Why does a brilliant team ship slowly? Why does a great engineer go quiet? Why does the word "compliance" turn confident builders into nervous box-tickers?
These days I lead software for a medical-device company, in a domain where the stakes are real and the rules are not optional. Before that I led an engineering team through an acquisition and a platform migration under a hard deadline, and before that I was the CTO who insourced a codebase and built the cloud architecture from nothing. That first CTO chapter ended in a burnout: the expensive way to learn what running past your margins costs, and why I build teams with margins now. The thread through all of it: take something messy and complex and structure it into something a team can actually execute.
The record
Where I've done the job.
Head of Software
Medical-device company building software for organ-transplant care. I run engineering, DevOps and data under ISO 13485, IEC 62304 and the EU MDR.
Engineering Manager · Senior Backend
Medical-device company: an FDA-approved sleep headband, then the sleep clinic we built around it. My first time inside device process, following it rather than owning it. Grew from senior backend into leading the team, then took it through the company's acquisition and a cloud platform migration on a deadline the next funding round depended on.
CTO
Joined at the earliest stage. Took ownership of the codebase, built the cloud architecture from scratch, and shipped the products the business built its name on.
Backend · Web · Data
Custom business software, e-commerce, real-time data. The technical base I lead from.
The full history lives on LinkedIn.
Why health
The stakes are real, and real stakes focus everyone. Health is the one field where shipping faster and being more careful both matter at the same time. I find that clarifying rather than stressful.
What medical devices taught me
At Dreem I only saw the edge of it. As a backend engineer and then a manager I followed the process; writing it was someone else's job. Okeiro is where I had to own it: risk analysis before code, a software requirements spec that says what the product must do before anyone builds it, a trace from each requirement down to the test that proves it, all of it under ISO 13485 and IEC 62304.
Nobody warns you what that does to a team's week. "Done" stops meaning merged and starts meaning verified and recorded. You can't ship now and tidy the evidence later, because the evidence is part of the product. So a good chunk of the job is telling apart the rigor that keeps people safe from the ritual someone added years ago to feel safe.
Teams who treat all of it as paperwork at the end hate their week and still sweat the audit. Teams who build it into how they work get an audit that's mostly a printout. Same rules, opposite experience. Getting a team from the first one to the second is most of what I do.
Why the human part
I'm good with engineers. I listen more than I talk, and people tell me true things: the things they won't say to whoever signs their offer letter. For years I assumed the technical work was the hard part of this job. The human puzzles were, the whole time. A team that trusts its leadership will outrun a more talented team that doesn't, and I've watched it happen from both sides.
Outside client work I'm part of GoodEworkers, a group of engineers bringing solid tools and calmer ways of working to organizations that can't afford drama: nonprofits, hospitals, the fragile and the essential.
I'm based in Lyon and work fully remote, warm and informal, first names, plain words. I'd rather tell you the honest thing than the polished thing.