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—last week, 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.

Ming and I started ParadeDB a year ago. ParadeDB is an open-source database project that adds BM25 full-text search and fast analytics support to Postgres. We witnessed Postgres users be frustrated by Elastic's limitations (denormalization, lack of JOINs, operational challenges) and set to offer a SQL-native alternative.

ParadeDB is our first serious open-source project. We adopted this approach to facilitate developer adoption and shorten the feedback cycle. We now see regular community contributions, an unexpected but welcome side effect of building open-source.

I have spent a long time reflecting on why the community has welcomed us so openly and why so many intelligent, hardworking people have carved time out of their busy schedules to submit contributions to our project. I'm not an expert, but here are a few ideas I have honed for building momentum behind an open-source project.

• Be genuine. We spent our first year focused on helping people rather than selling them something. This made our early adopters feel welcomed and significantly increased feedback and adoption.

• Work hard. People respect hard work, even when it is clear the job is incomplete. I was surprised to see individual users and design partners double down on their support after facing bugs because of how quickly we acted on their feedback.

• Be transparent. Closed-source enterprise software companies often promise features that don't exist yet. It's hard to do this in the open source because users can quickly read your code and tell whether your promises are empty. We have found that the more transparent we are about the project's state, the more our community is supportive and willing to help build the missing pieces.

• Be reachable. We try to respond to users within 24 hours and follow ParadeDB-related keywords across popular social media platforms. Our users feel comfortable communicating with us and are often surprised to see me engage with their content directly.

• Be intellectually honest. From day one, we've made it clear that our goal is to build a sustainable open-source business on top of our project. We tried to be thoughtful and intentional in decisions like licensing and were pleasantly surprised by the community's reaction.

• Focus on quality over quantity when writing content. Last year, we wrote six blog posts. We found that only writing when we had something interesting to share led to higher awareness of our project than a high number of less exciting blog posts. We spent more time on each blog post but probably still invested less time than if we had gone for a higher number of posts, which is a nice side effect.

• Focus on providing value, not on promoting your project. We follow ParadeDB-related keywords and engage with users on related content. When we do, we try to provide value by answering questions and offering insights gained through our work. This leads to more interesting conversations that incentivize readers to look us up and discover ParadeDB organically.

• Work on something people already like. The love for Postgres is real, and by working to make Postgres better, we inherit this love. People root for our success, which motivates our team and encourages others to join the movement.

• Position yourself against something people know and dislike. Elasticsearch is a very popular technology, which makes its drawbacks well known. Its popularity helps us connect with a large audience familiar with the pain points we are solving. The enemy of my enemy is my ally, after all.

• Work on something you are passionate about. Passion is contagious. Every day, we wake up excited to work on ParadeDB and eager to engage with our community, who can feel our excitement. This is also one of the primary criteria we screen for when hiring.

Thanks to Ming Ying and Eric Ridge for reading drafts of this.