Leaving Percona

After four years at Percona, I’m leaving to go work full-time over-time on Bayse Markets - a refreshing, culturally-native prediction market platform.

For an industry where four years feels like a lifetime, mine feels all too recent. I think that’s partly because of how long other people have stayed (there are so many people with 8+ years), and it’s probably one of the few non-big-tech orgs with that kind of tenure. It’s easy to spend four years in the same org without it feeling rote because the nature of the business and the products being worked on means you could rotate projects/roles without necessarily boring/burning out.

Percona is primarily a database services company, which means they are the company that database engineers at other companies call when they are at their wits’ end. Greasing the wheels of this service is PMM - the flagship product for monitoring databases used everywhere in the wild: by internal teams, by customers, and by the larger community. Hence, almost all the engineers are at Senior+ levels with diverse experience and war stories.

And yet, here I was, joining the PMM team with some backend experience, but at a time when my only major database experience was working on the MySQL query planner at MariaDB. I didn’t have much exposure to how actually large databases were run. Being in an environment like this—talking to customers, going up and down the “stack”—means you quickly realize when you’re facing imposter syndrome vs a legitimate skill issue. This time, it was the latter, which meant working to fix it as soon as I could.

I also learnt one of the most important lessons for large projects like this: pick a niche within, and get good at it. You’ll hardly find anyone with extensive enough coverage of all the areas (hard though, not impossible, because I did meet people like that, phew), but the more you know about one area, the easier it is to build mental models across the others.

The interesting thing about working on observability tools like PMM is the scale variance. You get the chance to work with 500MB databases, but also 500GB databases, and the kind of reasoning that exists between them. I think it’s a good thing; observing such contradicting worlds helps you stay grounded when making architecture decisions. At the very least, it helps resist the temptation to throw the same tools and strategies large orgs use at the smaller ones.

Culturally, one of my favorite things is what I think of as “bias for finishing”. I wrote about it some three years ago, and I still think it’s one of the most important ideas when working in a team, especially because it forces you to look beyond your nose immediate goal and see what the team should actually be achieving.

It’s also impressive how much open-source is “default”. I think it’s one of the few businesses that can afford to keep code open by default - which means this isn’t a lesson I will be carrying forward :(. On one hand, this exposes you to a lot more scrutiny (cue long threads about how we should do product telemetry) but on the other hand, there’s the occasional joy of having bug reports from users who have taken the time to understand the problematic code, how it affects them, and possible solutions.

There’s also the work-life balance - floating holidays, rolling vacation hours. This is one of those things I personally consider nice-to-have. I like to think I’m at a phase where there’s not much life to balance with work, but it’s liberating to know that it’s there when you’re in a crunch and need it. And boy, were there times it was a lifeline.

Looking back, there are so many people who helped make this work, including Holman, Mikun, Leke, Artem, Alex, and Nurlan. It takes a village, after all, and right now, I’m grateful for my own “village people”.