Philippe Noël

We raised our Series A a few months ago. When we did, we were a headcount of 4. We're now 6, and I'm working to grow the team to around eight or nine.

What we’ve found is that successfully building devtools or infra isn’t a function of scaling massive teams with sprawling departments. Instead, you want to stay small and focused, recruiting the people who care about what’s being built and are the best in their respective fields. Why? Because our audience is discerning.

We’re not a typical SaaS tool, like a sales product. Those probably should scale early, even if it means a few bugs along the way. Their audience is forgiving. Ours isn’t. Devs will onboard, kick the tires, and jump ship if they detect any non-trivial problems. If a sales tool breaks, a few deals might get delayed. If an infra product breaks, the entire application can fail.

Meticulously-built devtools have a history of succeeding in the end game. They scale slower at first, working closely with a handful of design partners on their way to a version 1.0. Then, they hit an inflection point and take the world by storm. Elasticsearch, Snowflake, ClickHouse and MongoDB all followed this very trajectory. In recent days, Neon, a database that made huge strides towards a truly serverless Postgres, sold for $1B despite being early in its growth curve. There’s a long-term value in top-tier products, and top-tier products are built by a small group of truly exceptional and motivated people.

So, how do you hire the best? That’s the hard part. You can’t just wave money around and expect the best people to flock towards you—a few weeks ago, Sam Altman poked fun at how Meta is (unsuccessfully) trying to poach OpenAI engineers for $100M starting-bonus. Rather, building a talented team is about earning the respect of the maisons in the field.

At ParadeDB, we've seen success on three venues: (a) conferences, (b) GitHub light stalking, and (c) publishing content.

1. Recently, I spoke at Microsoft's Postgres conference called POSETTE. You can find my talk here. Conferences are a great way to share our work, build credibility, and meet phenomenal engineers. I regularly meet people who have watched one of my talks, and I often share my CMU DB seminar with prospective candidates when doing outreach. It's proven to be an invaluable way to showcase our work to future hires. It might not be the most scalable strategy—there are only so many database conferences—but given our gradual and piecemeal hiring pace, it’s a fairly decent option.
2. Then there’s GitHub stalking, and despite the slightly nefarious name, it’s a fair and transparent way to find talent. Especially in the world of open-source, GitHub is a window into who is contributing what. Most projects, despite having tens or hundreds of contributors, are often really only built by the top ~5 or so contributors. These top performers are the people we need at ParadeDB. Unsurprisingly, they are hard to convince and highly sought-after. Accordingly, we need a way to stand out and communicate why we’re cool.
3. Which brings me to the final strategy: content. We write about our problems. And we have a lot of problems. Writing technical content forces us to think critically about our product while opening the conversation to the community. Content has already proven effective at hiring— Stu joined us after reading our post on block storage. Technical content is a window into how much we care about the product’s quality and precision. Talented people look for places where the calibre of engineering matches theirs, and great technical content is perhaps the single best way to demonstrate our standards.

In devtools, the best product is usually the one that wins. As a result, we need these rockstar developers. It’s not a matter of ego (at least, I’d hope not). It’s a necessity: we’re reconciling two diametrically different things: Postgres and Elasticsearch. Our engineering time isn’t spent installing packages, building integrations, or refactoring SQL queries—it’s optimizing how we lay data out on disk and 100X-ing our write throughput. These are problems we’ve repeatedly overcome strictly because our engineers are amazing.

Hiring is hard. I'm still learning how to do it, but here are the two principles that are working for us so far:

1. Hang out where the top engineers in your space hang out, whether in real life (conferences) or online (GitHub repos).
2. Show them you're one of them by sharing what you’re building, be it through conference talks or write-ups. If you aren't one of them yet, become one. The best developers want to work with the best.

If you’re hiring in the devtool/infra space, I hope this was helpful. Likewise, I’d love to hear what’s worked for you.

I used to believe that solving coding challenges was the most rewarding part of building a technical product. As satisfying as that is, I may have found something even more fulfilling: witnessing complete strangers turn into collaborators, simply because they believe in the mission.

ParadeDB is now almost two years old. In 2023, Ming and I started it as an open-source database that brings BM25 full-text search and fast analytics support to Postgres. We saw how often Postgres users ran into limitations when building with Elasticsearch: denormalization, lack of JOINs, operational headaches. Our goal was to create a PostgreSQL-native alternative.

We didn’t know exactly what to expect. This is our first serious open-source project together. We chose the model to simplify developer adoption and to shorten the feedback cycle. At the time, we didn’t realize that it would also encourage community contributions—and not just for trivial nits. To call it a happy surprise would be an understatement.

Over time, I’ve given a lot of thought to why the community has welcomed us so openly and why so many smart, busy people have made time to contribute. Perhaps it’s just the problem that we’re working on, but I suspect other traits of ParadeDB have helped. Here are a few things that I think have worked:

• Be genuine. We spent our first year focused on helping people, not selling to them. That mindset centred our community interactions around feedback and adoption. In short, early users felt welcomed. Ming and I used to tell ourselves, “Before we try to sell this product, we need to be sure it is valuable. So we’ll open-source our code and talk about it publicly, until a few companies reach out to adopt it. Only then will we feel we have earned the right to explore selling it.”

• Work hard. People respect effort, even when the product is not yet complete. I believe our users and design partners doubled down on their support despite encountering bugs after observing how quickly we responded to patch them.

• Be transparent. Closed-source software companies often promise features that don’t exist yet. In open source, users can simply read your code. There’s no point in misrepresenting the truth. We found that being open about what works and what doesn't (yet) encourages trust. In turn, it fostered a community willing to help fill in the gaps.

• Be reachable. We try to respond to every user within 24 hours and follow ParadeDB mentions across social platforms. Many users have been surprised to see me reply directly to their posts or questions, which makes future communication that much easier. In other words, even if the product has temporary deficits, compensate for them with support and service.

• Be intellectually honest. From day one, we’ve said our goal is to build a sustainable open-source business on top of ParadeDB. That means being thoughtful about choices like licensing. Unfortunately, today, some companies use open source as a marketing trick—their code is open source, but buried behind deceivingly constrained licensing terms. Instead, if your product is open source, then choose a license that’s already beloved by the community. That’s why we chose AGPL.

• Prioritize quality over quantity for content. Last year, we published six blog posts. That’s it. Each one had something meaningful to say. This year, we want to write more, but only because we’re encountering more interesting problems as the database evolves. In short, we don’t want to chase volume and instead strictly focus on things that are intellectually interesting to us.

• Work on something people already like. People love Postgres. It has a passionate user base that wants to see it get better. When Postgres has deficits, the community is more likely to say “how do we fix this?” instead of “should we start over?” In a way, Postgres is the “Linux of databases”. It’s free, extensible, open-source. This has created a fervent and dedicated community, and by working to make Postgres better, we benefit from that existing goodwill. In short, people root for us because they already care about the foundation we’re building on.

• Position against something people know and dislike. Elasticsearch is widely used, but its limitations are well known. By offering an alternative that addresses familiar pain points, we’re able to connect quickly with a broad audience. Said bluntly, the enemy of my enemy is my ally.

• Work on something you’re passionate about. Passion is contagious. Every day, we wake up and are excited to work on ParadeDB. We’re excited to engage with the people adopting it. That energy is reciprocated: people are drawn in by others’ passion and appreciate the work.

A thank you to everyone who has contributed. You’ve made ParadeDB better. If you're curious and would like to get involved, check out our README or some of our latest issues! And if you want to contribute full-time, we're hiring.