About me

Born in 🇫🇷, living in 🇩🇪.

Software engineer with experience building B2B / Enterprise SaaS products in HR-tech (think shifts scheduling, absence management, payroll, workforce engagement, etc).

What I like about what I do

I love solving “boring” business problems. Very often, there’s a very concrete problem to be solved and my role is to unpeel various layers of complexity and ambiguity up to a point that my colleagues and I are confident into implementing the solution. The various layers of complexity could be finding the answers to any or all of the following:

• Why do customers have this problem? What have they tried to solve it?
• Why do we, as a company, want to solve that problem?
• How much of the problem do we want to solve? Why?
• By when do we need to have the problem solved? Why?

What I don’t like about what I do

• Long hours, sitting, in the dark 🌚

Collaboration Style

• I’m a HUGE believer of making it AS EASY AS POSSIBLE for my interlocutor to digest whatever information I’m sharing. For example, if I’m building a feature, I’m making a before and after video explaining the WHY and WHAT of this feature and HOW it will impact customers.
• I always address an issue after having put some thoughts on how to solve it so as to exercise my brain and save my colleagues time.
• Threaded asynchronous communication is 👌. Writing forces thinking and self-reflection. It’s also self-documenting, transparent, easily shareable and trackable.
• Happy to jump on a call but I would consider it the exception rather than the rule. When I’m not able to put something in writing and want to jump on a call, it feels as if my thought weren’t structured enough and I’d be relying on someone else to structure them.
• I much prefer oversharing than undersharing. I try to structure my writing so that the gist of it can be picked up very easily (by adding a TLDR; or structuring what I’m writing into titled sections) while still giving the opportunity to dive deeper 🤿 .
• If something can be shared asynchronously now instead of synchronously later, it should be shared now. This is because I value information traveling fast / knowledge sharing.
• I absolutely despise receiving orders and conversely, I never ever give orders at work; always strong suggestions or include “we” when talking. I like the “we” as it emphasise the team and IMHO better reflect reality: the customer doesn’t care who does the job, as long as the job is done, thus WE must deliver.