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.
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:
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.
Thanks to Ming Ying and Eric Ridge for reading drafts of this.
]]>