Portrait of an engineer on fire: Balthazar Rouberol

Every week, we publish an internal newsletter for engineers: the gazette. It contains various news, and also a portrait of an engineer. It’s a great way to get to know each other, as our team is growing.

As we heard good feedback from our two others interviews, we decided to transform those portraits into blog posts! Today we are interviewing Balthazar.

Where are you coming from Balthazar? Could you briefly explain what was your role in your previous position?

Hi! I’ve been professionally involved in telling computers what to do for about 10 years.

I started in 2012 as a Software Engineer in a small startup (that still exists despite my abysmal architectural choices) called Mapado, then worked in Edinburgh, as a consultant for the Scottish government for a while. I then spent the next 2 years at OVH, working on their container hosting platform, and finally spent the next 5 years at Datadog as an SRE, before joining Alan in August of 2022.

I joined the Datadog Datastore Reliability Team at its inception 6 months after joining: the idea was to have SREs solely focused on the commonly used datastores throughout the company, to provide a good level of reliability and support for them. I mainly focused on Kafka, which was the datastore ensuring the “real-time” component of Datadog. We had 2 SREs spending most of their time on the various Kafka clusters and associated tooling, while the number of clusters and the volume of data was growing exponentially. Our job was to make sure we were always able to absorb that growth to avoid being a bottleneck for the company.

I also took care of the many Zookeeper and Cassandra clusters powering large parts of the product, and the multi-year migration of all these datastores and tooling to Kubernetes, to allow Datadog to deploy its infrastructure on the big 3 clouds (AWS / GCP / Azure).

I then spent the last year leading the teams building the internal release platform (think “Beanstalk made by Datadog for Datadog”), powering the thousands of daily deployments.

What were you worried about when you applied?

I mostly spent my career in technical companies building technical products, where engineers are the majority, and where technical choices and limitations shape the product. Alan really works the other way around: the engineers are in minority, and product choices shape up the product.

This fundamental cultural difference made me question whether it would make sense for me to apply to Alan at all: I was worried that my past experience wasn’t going to be really helpful or relevant. I however decided to try despite these doubts, because I felt drawn to the “boring tech” culture Alan was advertising, after years of spent in the Bazaar that I felt was the containerization ecosystem.

Another source of worry was that I really needed to recharge my batteries before starting another job. The many years of being on-call at night, working in a stressful environment had left me tired, and borderline depressed. I needed to rest to avoid what felt like an unavoidable burnout, but I was afraid that I’d miss my opportunity at Alan by inducing such a delay in the recruiting process.

Finally, as I had spent half of my career in the same company, I was worried that I was going to bring too much Datadog culture with me. I had been really frustrated in the past by ex-Googlers being hired and immediately trying to-recreate the tooling they had known at Google, while looking at Datadog culture with a certain amount of condescension. I was worried that I was going to act (or be perceived) the same way at Alan.

How did you address those?

I had heard good things about the company and its internal cultures from colleagues, or ex-colleagues of Alaners, or even Alaners themselves, and decided to try anyway, as I had nothing to lose and everything to gain!

I read multiple engineering blog posts (please continue writing them, they really help!), to try to familiarize myself further with the culture.

During the interview process, I made sure to mention my situation and need to recharge to Maria Cvitkovic, and everyone proved very supportive. I can’t collectively thank you enough, as taking this time for myself was probably the best decision I have made in recent years.

Alan advertises a strong culture, of which Alaners are very proud and protective. I didn’t want to appear to commit a faux-pas and appear to dismiss that culture just because I came from a “bigger” company, so I made sure to focus on integrating and delivering value as fast as possible by applying the “show, don’t tell” principle. I was given the opportunity by the Developer Experience crew to apply my Datadog knowledge to improve our logging setup, and happily dove in. It allowed me to have a somewhat firm ground to stand on while ramping up on Alan’s documentation, culture, codebase and infrastructure.

What did you expect during your onboarding?

I expected to be kept busy, and well, I was! The first week was intense, with a lot of documentation to read, videos to watch. I expected the non-technical topics to be the most challenging (for example: how the French health system works, or what’s how an insurance company works), and again, I wasn’t disappointed, as I knew next to nothing about any of them.

What surprised you?

After a good 10 days of being buried under documentation, I suddenly found myself with a lot of “free” time that I could spend investigating the product itself, the different engineering teams, as well as the codebase.

What surprised me the most was the realization that I had no assigned engineering team, and that I was expected to find one. As my second week was during a cooldown and a hackathon occured during my third, I had a lot of time to observe what was happening within Alan, and I used that time to investigate the teams in which I saw myself working.

What are the main changes compared to your previous position?

The main one lies in how intentional the Alan culture is. Most of the companies I worked in had a pretty strong culture, but it was mostly ad-hoc and built on shared experiences. I can recall at least one moment in each company where I told myself that the culture was slowly dissolving due to a lack of intent and maintenance.

The second cultural difference lies with the product: Alan isn’t a technical product. It has to do with health (body and mental), insurance, human resources, evolving legislation and to an extent, politics. This means that engineers have a different role than in the previous companies I worked in: everything they do has to lead to an improvement of the user experience (the “delight”, as we call it). We are pushed to be scrappy, as we’re seen as an almost scarce resource. We can be pushed to change teams pretty regularly (depending on the company appetite or our own). That sense of rarity (for lack of a better word) is very new to me, and sometimes still feels a little alien.

I however can’t help feeling that with more than 500 employees and almost 100x times the customer base, engineers should feel more legitimate in sometimes pushing for their own delight when they are dealing with heavy toil and maintenance, to be able to better serve and delight our customers down the road.

One of the most important differences I have experienced as well is the way Alaners are empowered to make decisions. We’re not looking for consensus, we’re looking for strong challenges, strong opinions, and the ability for one person to make an informed choice. I have seen decisions “englued” in committees / subcommittees / never-ending meetings (mostly in my time in government), and the ability to make a choice quickly and revert if we realize we made a mistake is an absolute superpower.

Finally, the almost absence of meetings is liberating. I feel that I’m able to really focus on a hard problem for the first time in a long time.

What would you like to bring to Alan from your previous experiences?

The easy answer could be “Datadog knowledge”, and while that isn’t false per se, I hope I can bring more than that!

One of my main drives is knowledge sharing, and I hope to be able to do more of this (demos, brown bags, etc) in the future. My limited bandwidth makes live presentations hard right now, but fiber is coming! I saw it being installed in the street this week! In the meantime, I try to document what I work as much as possible, to share what I learn with anyone interested.

I have participated in helping a pretty large-scale company continue to grow, sometimes working on infrastructure, and sometimes on parts of the data model itself, and how it was physically stored and sharded in the database. I hope I can bring some of that knowledge to Alan as we envision serving millions of members in a couple of years.

And finally, I hope to bring enthusiasm, curiosity and a sense of pride to what we’re collectively building. In my experience, only a team proud of what they’re doing can build a really great product. It’s the extra bit of intention and care that can really give the project its soul. I humbly hope to participate in that.

Question from a colleague: I often see you making improvements on our infra. Do you follow what’s happening on bleeding edge infra stuff? Is there anything you’re excited about for the future?

I might disappoint you a little here: I’m much more technically conservative than most people realize. I often joke about the fact that the best computer is a Raspberry Pi, and is even better when powered off. Having worked in/with containerization platforms, I’m not particularly excited about Kubernetes and the associated frenzy anymore.

Truth is, I now need a lot of thinking before jumping on something new. I have seen projects absolutely derailed because hot new pieces of tech were very quickly adopted, causing immense user frustration down the road because tradeoffs hadn’t been really considered. I’ve come to believe that you shouldn’t bet on bleeding edge infra or tooling, except if that gives you a strong market advantage.

You have seen it though: I am excited about ARM chips being widely available, in enterprise clouds. They consume less energy, are generally faster, and have already driven a vast improvement in the consumer market (❤ M1 Macs ❤). I am excited by the ability to do more with less.

For the same reason, I’m excited by the work fly.io has been putting in replicated SQLite for example. I’m excited about CircuitPython, which allows us to do cool things (sorry about the shameless plug) with microcontrollers without having to write C. I’m excited about PostgreSQL becoming a very capable NoSQL store (for small documents), message queue and text search engine. Finally, I’m pretty excited about languages such as Zig or Nim, that I feel bring the expressiveness of Python, the fast compilation of Go and the memory safety of Rust (with the easy distribution of the last 2).

These days, I’m excited about “digital frugality” much more than by the bleeding edge. Sorry to be such an ardéchois killjoy.

And allow me to take the last question quite literally: I’m excited to be a dad for the first time in 3 months!