I’ve given 2 talks in the last 6 months about building developer communities, and I’ve received good feedback each time. So, I’ve decided to take this talk and put it into blog post format. This is what I’ve learned in the last couple of years about building developer communities.

If you prefer to watch or listen, you can find a recording of V1 of this talk here:

Prelude: So You’ve Sponsored a Hackathon…

Say you’re building a developer product or platform and you’ve decided to sponsor a hackathon.

You’ve committed $20k+ in sponsorship fees for the event and agreed to pay out another $10k in prizes for teams who build on top of your technology. You flew your team thousands of miles to attend, and they’re primed and ready. You told them to buckle up for an intense weekend because you expect a ton of inbound developer questions. You have high hopes.

Then..

Nothing happens.

Or maybe something happens: you get just a couple of submissions that incorporated your technology, but two of them are just Figma files mocking up a potential solution. Maybe you also get some developer feedback along with your submissions, but people are highly critical of your docs and tell you they have no idea what your product does.

Building Developer Distribution is Hard

The hackathon flop is a real thing. It’s happened to me, and it’s happened to other people I’ve met. It’s proof that it’s not enough to build powerful products – even when building for developers. You need people to know about them and make using them a great experience.

This post will go beyond just getting good results at hackathons. I’m going to lay out nearly everything I’ve learned so far about building a thriving developer community, and how the Developer Relations function works to make this happen.

Who Is This Post For?

This post is going to be most relevant to you if you’re building a product or platform that is meant for software engineers. This could be an API product, a developer tool, an open source project, or crypto protocol. This article will have a web3/crypto slant to it, but it should apply to any of the aforementioned categories as well.

At Superfluid (where I work), we’ve had over 600 projects built on our technology in the last 2 years, and projects building on top of Superfluid have raised 8 figures in venture funding. Some of what I’ll talk about in this post I’ve learned firsthand through working in the field, and other things I’ve picked up from the founding team at Superfluid and other developer relations leaders in crypto/web3. My life is made easier by the fact that we’re building really cool tech at Superfluid (which you can learn more about here), but I’ve still had to learn quite a lot to make progress.

Why Build a Developer Community?

Your goal is to make your technology matter to the engineers that you’re building for. If you can do this, you win. And I don’t mean ‘matter’ in the casual sense. You’re trying to build a community that has members who go on to build multi-billion dollar companies on top of your product and where people are so passionate about what you’ve built that they regularly fly around the world to attend developer meetups about your technology. I even had a dev in our community send me a bottle of whiskey thanking us for what we’ve built and our support at a hackathon. This what you’re aiming for.

In terms of tangible business output you’re looking for 2 things:

1) Brand new, valuable companies that are built on top of your technology.

2) Integrations between your technology & existing, successful products

How valuable #1 and #2 are to you will vary depending on your business model. Let’s look at some examples: Twilio & Ethereum.

Twilio is a massively successful developer product. They’ve enabled new companies like AirBnB & Uber to thrive by using their platform. Rather than building their own push notifications infrastructure, these companies can stand on the shoulders of Twilio instead. Twilio has also been successful in selling existing organizations on using what they’ve built. Many companies outside of the core Silicon Valley startup ecosystem use Twilio for push & SMS notifications.

Ethereum has enabled the creation of many multi billion dollar projects such as MakerDAO, ENS, and Uniswap. The Ethereum developer community is one of the most engaged & passionate tech ecosystems in the world. People fly around the world (often multiple times per year) to attend Ethereum events like Devcon and ETH Denver, and many people have quit their jobs to go build things on top of Ethereum. In the future, the Ethereum community hopes that other areas of finance & the internet choose to integrate both Ethereum itself and products built on top of Ethereum to make existing products better, but this will still take some time (:

One thing to note about the Twilio example: I’m sure that the success of startups building on Twilio provided additional credibility for the Twilio sales team when they later approached larger, more established businesses about integrations. Helping to foster a community of early stage companies built on top of your technology may take time to pay off, but your effort in helping these teams is a bit like angel investing. Many may fail, but the ones that succeed can really drive the success of your business.

What is Developer Relations?

This is the discipline that is responsible for the creation of a thriving developer community. It has two sides: the developer side & the relations side.

The dev half of DevRel looks a lot like engineering. It involves building APIs, SDKs, docs, libraries, etc. You need to treat this like you would any other product/engineering function. You need to PM your developer products!

The relations side looks a lot like marketing, but it absolutely cannot feel like marketing. It includes things like tutorials, videos, workshops, podcasts, meetups, etc. Great developer experience teams are competent with both sides of DevRel.

The Dev In DevRel

Building tools, templates, and examples for developers is an extremely high leverage activity. The examples you build might be seen and used by thousands of engineers, who might go on to use them to build products for millions of people. I see the patterns I’ve used in our example code in many of the high level projects built on top of Superfluid, and in nearly all of the hackathon projects built on top of the protocol. If I were to tweak that code slightly to make it just a bit cleaner or more efficient, it will have ripple effects that spread far beyond myself and into the experiences that end users will have when they use products built by our community.

This is why you need to treat your developer facing tooling & examples like every other product you build. While Fortune 500 companies and the likes of Stripe & Twilio understand this, I see many startups and early stage businesses take a haphazard approach to their APIs, docs, and examples. Again, you should consider how high leverage these activities are. You should put good engineering minds on your developer products, and even consider rotating staff engineers through your developer experience team for a week. This might improve the quality of developer products you produce, while also giving your core engineering team some much needed perspective about what it’s like to use the technology that they’re building.

Your documentation is your most valuable developer product. Elon says that they view ‘all user input as error’ at Tesla. Similarly, you should view all developer questions as error when it comes to your docs. This is aspirational – you’ll get questions no matter how good your docs are – but it’s a useful state of mind to get into. Every minute improving your docs is worth an hour of answering questions on Stack Overflow or Discord.

One other thing to keep in mind when it comes to your docs is that Github CoPilot, ChatGPT, and other LLMs have made remembering syntax a breeze. My hypothesis is that over time, people will be less and less likely to come to your docs to find or remember syntax, and more likely to come to your docs to find good explanations of how your technology works.

When it comes to explaining how your product works, you should keep in mind that the optimal explanation will vary depending on the audience. This is why you should work to define your product’s different developer personas, and create the optimal experience for the top 2-3 personas that you expect to come to your docs. Creating ‘personas’ is something that marketing teams are highly familiar with – this is essentially doing customer segmentation like a good brand builder would do, but for an engineering audience. At Superfluid, we like to segment things by developer skill level & role/intent. Internally, we have far more detail on each developer persona, but here’s how we look at things from a high level POV.

Segmentation 1: By skill level

• Beginner
• Intermediate
• Gigabrain

Segmentation 2: By Role/Intent

• Hackathon/Indy dev
• Developer at current or potential integration partner
• Future founder/entrepreneur building a new product

We then make sure that we have tooling & documentation that makes sense for developers at each one of these stages, and we also keep in mind that devs may flow back and forth between them. Today’s hackathon dev may one day get a job at a company that we would love to integrate with, and an engineer at an integration partner may eventually leave to go build their own product on top of us later. We make sure that we have docs, tooling, and tutorials/examples that have the ability to meet each of these roles & skill levels where they are.

As an example, we have each of the following within our docs (notice how each persona is served)

• Quickstart Page: for beginners or devs building at a hackathon
• Reference Docs: for intermediate/advanced developers
• Integration Guides by Use Case: for engineers building Superfluid into their existing workflow
• A Library of Project/Business Ideas Based on Superfluid: for future founders

Other Considerations for Your Dev Tooling

1) Be mindful of your abstractions. If you build in too few abstractions, you’ll lose beginners and intermediate developers who want to build on top of your product quickly. You don’t want to require someone to go through a ton of work before having their first ‘aha’ moment. However, if you build in too many layers of abstraction, you’ll likely frustrate more advanced developers, confuse people as to how your product actually works under the hood, and maybe even constrain innovation. I find that teams building more complex products have the hardest time choosing the optimal amount of abstractions to build into their tooling. Point #2 might aid in your decision making process.

2) Keep it simple. If you’re not sure whether or not to add in one more edge case to your SDK or whether to add an additional layer of abstraction, the answer is probably no. Someone I know calls this the “midwit trap of API development.” If someone requests that you build an edge case into your SDK or tooling, let them implement this on their own for personal use. Adding in extra functionality to manage edge cases or enabling teams to have ‘more than one way’ to do something has a cost associated with it: you’re requiring devs to make more decisions about how they should use your product.

3) Be mindful of assumed context. When you talk to engineers about how their technology works, they tend to be worse than you’d expect at explaining it to newcomers. It’s my observation that the most common reason for this is that these engineers are blind to how much context they have about what they’re currently working on. And it makes sense – a good engineer spends their days immersed in the details of their particular system. They’re pushing the limits. To explain something well to an outsider (even a technically competent outsider) requires them to go all the way back down to first principles to meet the outside individual at their level, which tends to be something that engineers don’t like doing very much.

So be mindful of this assumed context in your tutorials or documentation. Avoid saying things like ‘simply’ or ‘just’ in your docs too. Things might seem ‘simple’ to you that require more prerequisite knowledge than you remember. One way to guard against this is to do user interviews with people building on top of your tech for the first time. We’ve also done ‘docs audits’ with engineers we know in the space. The first couple of times we did it, we were surprised at where new engineers were tripped up (regardless of competence level).

Advanced Class Stuff – Use AI for Even More Leverage

If you want to operate on the cutting edge, you can try to make use of ChatGPT and OpenAI’s APIs to automate a portion of your developer support. Projects like Yearn.Finance have already experimented with this, and I’ve built little GPT-3 wrappers that will explain your code for you.

It’s unclear whether or not these systems will actually work, because we still don’t know how to make LLMs say true things reliably. Unfortunately, ChatGPT typically won’t tell you when it doesn’t know the answer to your question (instead it just hallucinates one for you). I am optimistic though that through some combination of fine tuning and proper prompting (perhaps combined with some indexing) we’ll get close to automating low level dev support with LLMs.

Developer Relations

The other half of DevRel looks a lot like marketing, but it cannot feel like marketing. You can’t be caught ‘shilling’ your product.

What is shilling? I don’t know, but I know it when I see it. And so do you.

Traditional sales demos or sales collateral is doomed to fail. Devs can smell it from a mile away, and it turns them off. You need to approach marketing to engineers obliquely by focusing on piquing developer curiosity. In simpler terms: you need to be nerdsniping.

What is nerdsniping? Well, I’m not sure that there’s an official definition, but I tend to see it as building, curating, or demo’ing extremely impressive (read: complex) engineering achievements. You can also perform effective nerdsniping by providing great educational material or useful tools.

The other thing that helps is aggressive honesty. If a developer approaches you at an event and proposes a system or project idea that isn’t a good use case for your technology, you need to be extremely honest about that. If you’re nonchalant about it or act like it might be a decent use case, it might persuade the dev to go look into your product, but they’re going to realize pretty quickly that you were bullshitting them. Engineers have some of the greatest BS filters in the world, and any hint of dishonesty can cause you to lose credibility with them forever.

In my experience, you can win a lot of technical folks over by just saying ‘I don’t know’ when you don’t know. The standard salesperson game of just saying nice sounding things for the sake of social cohesion doesn’t work very well with engineers. Sometimes, the most persuasive thing you can do when trying to get a dev to build on top of your technology is to tell them what not to build with your product. I’ve occasionally told people that their hackathon project ideas are bad uses of Superfluid (because it was true), and they went back and changed their entire idea into something that was a good match for our tech. It sounds simple, but honesty goes a long way.

Good Content Examples

In our case, the most successful ‘content’ we’ve made for developers has been generic developer education content. For example, we produce a weekly podcast called Devs Do Something that seeks to be the best technical podcast for engineers in web3.

We’re not talking about our product on every show. In fact almost every episode has been either adjacent to or separate from what we’re building. But running the podcast allows us to talk to elite engineers (because they come on as guests), and we have a monopoly on ad space (:

Other good examples of dev content will depend on the makeup of your particular technology subculture, but in crypto “gas optimization” and low level EVM content does pretty well because most devs want to understand how things work at the lowest levels. Patrick Collins & Nader Dabit also do an excellent job with their Youtube channels putting out general developer education content. In the front end world, people like Kent C Dodds are good, and in ML, people like Andrej Karpathy, Jeremy Howard, and Andrew Ng are all great.

It’s really all about sharing valuable educational content. The examples I just gave aren’t necessarily from ‘companies’ but I’d challenge businesses who are focused on acquiring developers as users to put out more general education content. You’ll build credibility with your key audience, and devs who find your content valuable will discover your product as a result of your work. They’re going to trust you more, and be more likely to use your product as opposed to your competitors’.

Spending Money on Developer Experience

This is a topic that I see very, very few people talk about. Maybe it’s because, at least in crypto, teams are spending a TON of money on building their developer communities. It’s also hard to quantify what true ROI looks like (though I would point you back to what we discussed earlier in this post: that your output is new, high value products built on top of your technology & integrations between your technology and existing products).

How is DevX spend typically allocated? In no particular order…

1) Events (Hackathons & Meetups)

2) Bounty programs (this could be bug bounties or just community bounties)

3) Developer relations team members

Let’s go through these categories and talk through how you can get more out of your spend in each of these areas.

Events

In web3, most money spent on events goes toward hackathons. Some teams also do things like sponsor meetups and hacker houses, but I don’t have much experience doing either of these things so I won’t cover them for now. I have a lot of experience sponsoring hackathons though.

How do you get the most out of a hackathon?

Well, the state that we want to avoid is the hackathon flop scenario I outlined earlier. I can’t reveal the exact process we go through at Superfluid because it is our secret sauce after all (😄), but I can give you some high level pointers.

1) Hackathon selection matters.

You need to make sure that the events you sponsor are of high quality. There are quite a few hackathon organizations that will happily take your money despite running a disorganized process & attracting relatively few developers to work on your technology. You’re looking for organizations that put out good developer content of their own who have a track record of success (in web3, ETHGlobal and Devfolio are both good organizations). You also want to ask yourself: what kind of developer community will this particular event attract? For example, if you’re an AI tooling company, don’t sponsor an event that’s meant for React developers. If you’re an Ethereum scaling solution, you probably wouldn’t get much out of a Cosmos branded hackathon. This may seem obvious, but your day to day choices may have more subtleties for you to consider. Hackathons are very expensive and you should do your diligence.

2) Running the hackathon is not a hands-off process.

You should be extremely active at hackathons. Before the event, you should consider preparing ideas for devs to build on. If you’re building infrastructure, it’s tempting to sit back and say what you say to VCs: that “the most exciting projects built on our tech are the things we haven’t seen yet.” Sure, this may be true, but devs have a lot of options in terms of sponsors to build on, and you should make their lives easier by providing a sense of direction. Pro tip: make sure your ideas integrate well with other sponsors because hackathon participants like to “prize stack” (i.e. work as many sponsor technologies into their project as possible to win as much prize money as possible).

3) Consider building your own distribution.

At Superfluid, we started running a monthly continuous hackathon that never ends. We call it the ‘Wave Pool’ and see it as a way to build our own hackathon distribution. We’ve learned a lot about how to run hackathons properly, and have used this to build a successful process of our our. We’ve averaged roughly 15 high quality submissions per month from developers around the globe. This is amazing for us because we don’t have the time or the resources to fly around the world to every hackathon. We’re also attracting new project submissions without the need to pay travel costs or sponsorship fees, so the ROI is quite high in comparison to other events. The beauty of this is that someone, somewhere is building on top of our technology right now, and that’s cool to know.

Bounties

Some teams try to use bounties to get their community to do actual, proper work. If this works for you, dear reader, then congratulations. We do this occasionally, but it’s somewhat rare. The problem with bounties is that it’s tough for an outsider to come up to speed quickly enough on your technology to make high value contributions in a short amount of time.

So our strategy for bounties has been to use them to get gigabrains looking at our repo. We haven’t done that good of a job with this to date, but I think that it’s still helped. We see bounties as a tool for increasing community engagement more than we do for outsourcing high quality work. If you want quality work done via bounties, then you’ll need a team member to actively project manage the process and provide feedback as to whether or not it’s been completed to spec. If you have the resources for this – amazing. Otherwise, consider using bounties to just get your community moving instead.

Your DevRel Team

Building a devrel team is something I’m still fairly new to, but I’ll give you some examples of models that I’ve seen work.

1) The Team of Generalists: This type of DevRel team is made up of a few developer advocates who all have similar skillsets. There is a fair amount of redundancy here though, and it breaks Thiel’s law of having each team member be differentiated in responsibility and skillset. If you choose this model, you should attempt to clearly carve out separate work streams for each team member so that they don’t have the same responsibilities.

2) The Team of (Mostly) Specialists: In some cases, teams like to have some DevRel team members focused on technical work, and other members focused on the ‘relations’ side of developer relations. This can work, but I would at least try to make sure that each half of the team has at least a baseline skill level in the other half. Your ‘relations’ team members should still be technical and actively up-skilling on the technical side, and your ‘developer’ team members should show their faces at meetups or hackathons, etc.

3) Lean Team, with Part Time Help: Some teams opt to keep the internal devrel team very light, and rely on part time contractors & ambassadors for other work. This model usually takes the form of ‘ambassadors’ focusing mostly on being present at in person events that the main team can’t get to, or perhaps creating additional dev content as the equivalent of developer ‘influencers.’ Some people, like Nader Dabit, is a proponent of a similar model. He says he likes to ‘contract out his weaknesses.’ This just may mean that he’s better at managing bounty style work than myself, but in any case it seems that he likes this model of ‘Lean Team + Part time Help.’

Failure Modes & Remembering What Success Looks Like

What are the most common failure modes I see in DevRel?

1) Throwing money at your community and hoping for the best

2) Not seeding your community with high quality ideas and examples they can start with

3) Not taking a PM style approach to developer products

4) Doing too much low leverage work

5) Not being willing to do any low leverage work

Points 1-3 are some that we’ve talked about at length. But what do I mean by #4 and #5? Well, leverage has been something I’ve brought up a few times in this post, and it’s something you should think a lot about. How can you do more with less? How can you get code, media, or collaborators to help you deliver value for your community while you sleep?

You can do it through content, good code examples, and maybe through AI tooling (provided that it continues to improve). Another good example of this is something that Patrick Collins does – he takes every inbound question he gets, creates a question on stack overflow, and answers it there. What does this do? It creates a paper trail for the question. Next time someone has that question, they can ask Stack Overflow (or ideally, just ask Google once that question is indexed), and boom, future Patrick doesn’t need to answer it any more.

While this kind of high leverage work is critical, you can also fail by being unwilling to do the things that don’t scale. Are you willing to be the person who stays at the hackathon venue until 3am on Sunday morning? Do you answer every developer question that comes into your Discord, or do you leave people on read for forever? These things are hard. But great communities are built by these endless, hard, 1 to 1 community interactions.

Remember that, if you can successfully bootstrap a developer community, there’s a huge reward for doing so. It will make it far more likely that your product will succeed, and you’ll build a fabulous set of relationships of your own if you do it right. You’ll make friends & sometimes change peoples’ lives by supporting them at critical junctures in their career. From a practical POV though, a successful developer community is one filled with engineers who:

1)Tell their friends, bosses, and teammates about your product

2) Help other devs within your community (without you even needing to be there)

3) Build integrations between your product and existing products

4) Launch new businesses and projects of their own that are enabled by your technology.

If you look up and see this, you’re winning. Your technology matters to people. And that’s what this is all about.

I’m still learning. If you saw anything here that you disagree with, or if you have ideas that may allow me to build on my understanding of how to build a developer community, let me know!

Cheers & good luck.

-Sam