 All right, so today's talk is going to be on building a thriving developer community. So I'm Sam. You know a little bit about me from the intro there, but I'll get into who I am in a couple minutes. But first, before we get into actual content here, I want to paint a scenario. Let's say that you're building a really cool protocol or piece of technology. You're targeting developers. You're building this platform. And you just sponsored a hackathon because you've heard hackathons are a great way to engage developers, right? You've paid 10K in travel expenses and sponsorship expenses. You've told everyone how excited you are for hackers to build things you've never even seen before. And you've told your team to be ready because this weekend is going to be intense, right? It's going to be lots of questions, lots of developers. And you show up and nothing happens, right? The hackathon flop is a real thing, right? I've seen these talk to people in the community that have had this happen to them. Let's say you get three submissions. Two of them are Figma files that don't really actually use your tech. They're just mock-ups. And your docs get ripped to shreds by the people that you do engage with. And they tell you that they're not usable. It was all very confusing. And it's just bottom line. It just didn't go very well, right? And the key lesson here, I think, to take away is that it's not enough to build awesome tools, right? You need people to know about them, right? And you need to make using them a great experience. To whom I, I help lead developer experience at Superfluid. Superfluid's a protocol that enables real-time finance and money streaming, right? If you're curious about Superfluid, check us out at superfluid.finance. There's lots of good stuff there. I'm a reformed SaaS salesperson. So I used to sling B2B software. And I taught myself to code. I got really into the technical side of that business. I fell down the crypto rabbit hole. And here I am. So at Superfluid, I also host the Devs Do Something podcast, which is a technical podcast for engineers in Web 3. And at Superfluid, we've had over 300 projects built on Superfluid in the last 12 months or so. To go back further, it's more like five or 600. We have teams building on Superfluid that have raised eight figures in grant money slash venture money. And it looks like your community is doing well, right? Obviously, we have a long way to go in our eyes. But I've learned a lot in the Dev rel trenches, right? I've been to a lot of hackathons. I've talked to a lot of engineers in the space. And I'm still learning. But I know the feeling of sponsoring a hackathon and just not getting the results you wanted. I know the feeling of having your docs torn to shreds by developers who get frustrated, right? If you're in the audience here and you've done a hackathon and you've just started exploring some different technologies in the space, there's no doubt you've probably been frustrated by documentation at some point in your journey, right? And what's nice for me is that Superfluid is a cool protocol, right? It does cool stuff like this money streaming thing, so it makes my job easier. But I've still had to learn a lot and we've had to learn a lot at Superfluid. So today, I will share some of those lessons. So if we zoom out a little bit, right? I think it's worth asking why we even build developer communities in the first place? Like, why are these things useful to us? And the key thing here is that if your tech matters to people, you win, right? That's like the simple way of putting it, right? So, but what does actual success look like? Like, what does succeeding with the developer community really mean? Like, what's the output, right? And I like to define it as really two things, right? That will actually move the needle for you economically. And the first thing is an ecosystem of new and successful applications built on top of your tech. And the second thing is integrations between your technology, your protocol, and existing solutions and applications today, right? So a good web two example is Twilio. They've enabled new applications, like Uber and Lyft in Airbnb, and they've also integrated with a lot of existing applications, obviously, right? Everything that uses SMS, push notifications, those kinds of things, it's probably using Twilio or something like Twilio on the back end. And the obvious web three example is Ethereum, right? So Uniswap, Maker, ENS, all the existence of those apps makes the Ethereum ecosystem more valuable, right? It makes Ether more valuable, actually. And on the other hand, the integration bit for Ethereum is to help, I mean, I think some people have this vision at least, but it's to help Ethereum become a kind of global sediment layer for international finance and some of the other non-financial use cases might be examples of those integrations. So if those are our outputs, right? If that's what we want when we create a developer ecosystem and that's what we're looking to do, the discipline that creates this is developer relations, right? So you'll see a lot of DevRel people run around like myself. We tweet a lot. We make lots of videos. And it really has become a kind of very important discipline in web three, right? And what I like to do is break DevRel out into the Dev and the Rel side, right? So on the developer side, this is your libraries, your APIs, your docs, your tooling, even your smart contracts, if you're a protocol. It looks a lot like engineering. And a key thing that I think most teams get wrong is that they don't realize you need to product manage your developer products like you'd PM any other product, right? The other half of DevRel is the relation side. This is a very loud thing you guys all probably see, right? This is your tutorials, your videos, your meetups, your podcasts, all this stuff, right? It looks a lot like marketing, but it cannot feel like marketing, right? And we'll get into why that is in a second, but for those of you that are technical, it's probably obvious. The key thing to keep in mind as a DevRel person or as someone who's building on a DevRel function is that great developer experience teams have both, right? You need, like I said a couple slides ago, you need to have great tools that are really easy to use and you need people to know about them. Both are important. So how about the Dev and DevRel, right? How do we at Superfluid approach this? Well, I think the biggest thing that I've learned is you have to PM these products, right? You have to treat them like any other product and run the same kind of process, right? That most valuable product for a developer relations team is your docs, right? That's number one. Number two, in order to make good docs and other good developer tooling, you have to understand your developer personas. You have to really get into the minds of the people that are gonna come to your site and be using your stuff and make things for them. And the third thing that's a little more in the weeds on how to build individual good Dev tools and SDKs is to be mindful of your abstractions, right? So on the side of docs, right? There's this quote that Elon has on Tesla Autopilot that they view at Tesla all input as user error, right? So a loose analogy for your docs is to view all developer questions and every piece for confusion as a failure of your docs. Obviously, you're still gonna get questions no matter how good your docs are. I hope that's evident. If no one's asking questions, that's probably a bad sign, but it's a useful mindset, right? And the reason why it's a useful mindset is that it points you in the direction of higher leverage activities. So when I first started at Superfluid doing DevRel stuff, I would spend a lot of time answering questions. I was like building my self-esteem around how good I was at this job by like how fast I was at answering questions and how many questions I answered and all this stuff, right? And that really wasn't the right mindset to take, right? Because all of the question answering, although it's useful, right? If you ask a question and someone's discord and they don't answer you, you're gonna feel like, you know, they don't care about you, right? So we still do value answering questions and doing it quickly, but the higher leverage thing is to find patterns and spend time in your docs, making sure that people ideally don't even have to ask you, right? And if they do ask and you do have to give an answer, ideally you should send them a link to the answer and more information, right? I've seen, so Patrick Collins, you guys might know who Patrick Collins is. He's a great developer experience person in the chain link ecosystem that I've learned a lot from him. What he actually does is if someone asks a question to him in their discord, he will answer the question, he will create the question on Stack Overflow, answer the question on Stack Overflow, and then send a link to Stack Overflow in the discord. And the reason why that's so smart is that every question you answer in discord just stays there, right? Discord, it's really hard to go search in the discord search bar and find useful answers to questions. It really is difficult to do. So what Patrick is doing is he is adding more leverage to his activities, right? He's answering a question but creating a paper trail back to Stack Overflow, so ideally he doesn't have to be there and answer those questions every time, right? Docs work for you while you sleep, answering questions, you can't do that when you sleep unless you have some kind of powers that I don't know about. So okay, with that being said, how do you maximize the utility of all your docs and developer tooling, right? How do you think about this? Well, you need to start by identifying developer personas, right? So a case study on this would be with Superfluid and I'll walk you through what we've done, right? We have a few different ways of doing this but the two main ways are set by skill level, right? So you have your beginners, you have your intermediate and you have your gigabits, right? And we also segment by the role or intent, right? So come to hackathons, right? They're just hackathon devs or indie devs coming to just hack and have fun. You also have developers and integration partners, right? People that might go champion to their boss that their company should use Superfluid in the next product. And you also have, like especially if you're a developer ecosystem that wants full blown applications and companies to be built on top of your stack, you might have future founders or entrepreneurs looking at your stuff and you need to cater to them as well because those would be some of the most high value people you can interact with. So in our case for the beginners slash hackathon devs, right, I'll loop them together because there's a little bit of overlap here. But for our docs, we have a nice quick start page where it's like, go here, get what you need, get out, it's quick. For tooling, we have a simple JavaScript SDK to interact with our smart contracts. We also have very simple Solidity libraries. Wanna build smart contracts with Superfluid. And then in our tutorials and examples, we have a zero to hero series and we have very easy dead simple beginner examples on the front end and react, okay? So that's like the beginner segment. For intermediate devs, we have our reference docs, right? If you're an intermediate dev, you know what you're doing, you're happy to just go literally look into the reference docs and find the functions you need. We also have advanced guides for some of the more advanced features of Superfluid and the more powerful things you can do, all sorted by topic. And we also have in the tooling section that JavaScript SDK also has typings so that you can use the SDK with first class type script support, right? On top of that, we have a developer console which is helpful for getting data from the sub graph and in terms of tutorials and examples, we have more fully fledged example applications that can take you end to end building a more full product, right? You can see test suites, all the stuff that you need to actually build some kind of integration between Superfluid and what you're working on. And then for entrepreneurial devs, we have a library of ideas we'd love to see built, right? We try to seed the community with ideas so that the entrepreneurial types can find something to actually try to build. We have this Superfluid reactor program which is like a mini accelerator that we run to help people go from idea stage or like good proof of concept to actually raising money or getting a grant. And then in terms of tutorials and examples, we have a lot of primitives, right? Which you can think of them as like building blocks they can use within applications, build on top of them and then ideally ship an end user product or a thing that can actually become a business, right? Some other considerations, right? When it comes to developer tooling, right? One thing I like to think about is being mindful of how many abstractions you're putting into your SDKs and tooling, right? If you have too little abstractions, you know, you might be asking developers to come to your code base, your docs and figure too many things out, right? You might lose beginners. However, if you try to shield the developer from the tricky stuff too much, you lose the more advanced engineers that would be comfortable dealing with the bare metal and you even stifle innovation in the process as well because you're not gonna allow access to things that some really intelligent developer can make use of. And then finally, something we actually haven't done a pretty good job of with SuperPluid is that naming really matters, right? Protocol engineers sometimes like to throw really crazy names in their contracts that don't make a whole lot of sense. So you should think about this. You should think about this for your team. All right, so moving on to some of the more relations side of things, right? This is one thing leading into this that I think is important to keep in mind. And it's that most developers are not good at explaining their product to newcomers. So why is that? I think the reason is that most engineering types who are really, really good at shipping code and really, really good at building new features sometimes are blind to how much context they have, right? In order to really explain something to someone new at a hackathon or even an event like this, you have to be able to go back to first principles and explain things from the ground up, right? And people that become really good DevRel people, people that actually become founders of protocols and things, they have to get really good at this, right? Because you might have to explain the same thing over and over again. And honestly, I actually respect it. Like engineers are often working on pretty cutting-edge stuff. You don't always wanna go back to zero. You wanna push the boundaries and build something new. But it's worth keeping this in mind, right? And when it comes to the relations side of what you do and all your tutorials and all your examples and all your content, you have to keep that in mind, right? Don't assume too much context from new people coming to your stuff. Moving further into the DevRel stuff, one thing that you have to keep in mind many of you probably already know is that you can't market to developers, right? You need to peak curiosity instead, right? So we're gonna go through what I've seen doesn't really work. When it comes to marketing developers, what I've seen does work. And then we might talk a little bit more about being mindful of assumed context, but I wanted to lead with that because I think it was so important to hit you guys with that up front. So what doesn't work when marketing to developers? Well, anything that feels like a traditional demo or sales slash piece of marketing collateral does not work, right? Engineers can see it from a mile away. It will immediately turn them off. And even if you're giving them something really useful, they're not gonna pay attention, right? And this kind of is looped in with anything that's feeling, right? So there's the Supreme Court Justice quote about, you know, there's like a case on pornography and somebody has to judge like, well, how do you know what porn is? And he said, I don't know, but I can, I know it when I see it, right? It's the same thing with shielding, right? You know when you see it, so be careful of that. The other thing that I think is actually underappreciated is that you can really lose credibility with people if you try to mangle every use case into using your technology, right? So if some engineer comes up to me at Hackathon and says, hey, Sam, you know, I've got this thing, you know, it does XYZ, should I use Superfluid to integrate with that? All right, and if they tell me that XYZ is something that really makes no sense to integrate Superfluid with, and I try to sell them on why Superfluid's a good thing to connect to their project, if they don't recognize it right away, they're gonna figure it out when they start going through our docs and our code base, and you just lose credibility with people, right? So one of the most persuasive things you can do, in my opinion, is actually to be really upfront about when your technology doesn't make sense for you. Right? Interestingly, people will come back to you and find some reason to use your technology in a more interesting way, if you're honest with them, right? You just, you cannot be dishonest, especially to engineers. Engineers here, you have some of the greatest BS filters in the world, right? You should be proud of that, but DevRel people need to keep that in mind. It's very, very important. So how about what does work? Well, I mean, I think that focusing on education is really the right move, right? And that's just education on what you do, but general education, right? Even if it's just adjacent to what you're doing, right? So one example is this new ChainDev YouTube channel that the Chainlink community put out, and in other words, a podcast we launched to Superfluid called Devs Do Something. So ChainDev, they just do very general stuff, like Patrick Collins does it, he does very general, just web three tutorials, and that builds a lot of credibility with the Chainlink ecosystem. And I think people know who Patrick is, and they wanna go build on Chainlink because they know he's helped them a lot, and he literally is always wearing the Chainlink T-shirt, right? That's a good thing. And then on our end with Superfluid, we launched this podcast called Devs Do Something that is designed to just be purely helpful for engineers in this space. We've had on just a lot of really good technical minds, and we don't really talk about streaming money or Superfluid stuff that much at all. All we do is we just talk through what they're working on, we go through their favorite design patterns and examples, and it's worked, right? People like it. So that, those kinds of things will, your community will accrue value as a result of these kinds of things you do. Another thing that works, when it comes to being more specific to your stack and your protocol, is creating really interesting examples and proof of concepts, right? So this might be obvious, but one thing to keep in mind is we're all playing a long game here, hopefully, right? But the problem is that there are so many things that become hot and capture the attention of every engineer in the space, and they always want to work on them now, right? So the cycles go so fast, right? At one moment it's NFTs, at another moment it's DeFi, right now we're hitting this stage of like zero knowledge stuff is like the sexy thing and yeah, rightfully so. I hope people build good zero knowledge stuff. But what you can do is stay up to date with all this new stuff, right? Stay up to date with all the new features and foundry, stay up to date with all the new ZK stuff, and if you can create some kind of interesting integration between these new technologies that are hot and what you're working on, you can stay in the conversation, right? They don't have to be perfect solutions and remember like I said a second ago, you don't want to force anything, but if there's a genuine integration, you should build some proof of concept around that, right? It helps you stay in the conversation, like I said. And the one thing I really want to highlight is that you want to create superstars in your community, right? You want to make people feel really, really special, right? So this means promoting the projects that your community builds. It means hosting little like sessions and meetups where they can come in and share what they're working on to your broader community. You really want to highlight people, right? It gives you content, right? Cause you have something to say and it also makes people feel good, right? It's just a nice human thing to spotlight someone and tell them they did a good job, right? Especially if it's true, obviously. So that's the dev and the rail side. Another thing that I think is interesting to talk through is how to spend money in an intelligent way on developer acquisition, right? So all the hackathons you guys see, those are not cheap for sponsors, right? Those are very expensive. So I think it's worth keeping in mind how to actually do this right. So again, our industry spends so much money on developer acquisition. It matters to us. It's spent mostly on hackathons, bounties, and dev rel team members. I'm not gonna go into how to hire dev rel team members, but in terms of getting R.O.I. out of the money you spend at hackathons and bounties, you have to keep in mind that you cannot just throw money at your community and hope for a good outcome, right? There have been times I've been at events where someone from a protocol says, hey, if you build anything on this L1 to this protocol, we'll give you a 10K grant, right? They just start throwing money out like crazy because there has been a lot of money in the space to date, right? Unfortunately, that just doesn't really work, right? It can get you some growth immediately, but the way I like to put it is that you really get out what you put in from an effort and how thoughtful you are point of view, right? So when it comes to hackathons, I'll head on hackathons first. The selection of the hackathon you're gonna do really matters, right? So you wanna look for events that have really high quality co-sponsors and you wanna look for organizations that put out lots of good content and seem like they're on top of their stuff, right? You should ask yourself before you show up at a hackathon or before you pay money to be at the hackathon, what kind of community is this event gonna attract? And is that community one that you want building on top of your protocol, right? Or your technology in general? Two really good examples that are kind of the gold standard are ETH Global and Defolio. I love ETH Global. If you're an ETH Global person in here, thank you for doing good work at good hackathons. So look for teams like that, right? It helps. And then at the hackathon, one thing that's kind of intuitive is you should prepare a couple of ideas, at least before the hackathon starts because we all like to sit here and say, hey, we're just so excited for the applications no one's even thought of yet, right? And it's true that you will be surprised and people will build cool things on your tech stack, but people have two days here. They have a lot of things coming at them. Give them something to work with. Give them some idea to start with. It's really helpful. And ideally, those ideas integrate well with other sponsors. Devs at hackathons like to stack prices on top of each other. They look for ways to integrate multiple things. And it's worth keeping that in mind. And then obviously, you want to be friendly. Being friendly really matters, obviously, at hackathons. So that's how to think about hackathons. The other thing that we do at Superfluity is we think about bounties a little bit differently, right? So I think that when it comes to developer experience and building developer communities, using bounties, like individual bounties to get people to complete tasks is a little bit overrated. You can crowdsource some good content and things, but what we kind of like to use bounties for is to get gigabrains and really smart people looking at your code base. That's what you want, right? You want to have them looking at your technology. And ideally, they go out and they build something brand new as a result of seeing this, right? That's a very important thing to note, right? Again, this is just kind of a regurgitation of what I just said. They're decent for crowdsourcing tutorials and educational content, but again, use them to get smart people looking at your technology. All right, so to wrap up here, right? I want to go through a couple of DevRel failure modes, right? That I've experienced and mistakes that I've made and mistakes that I see in the space just to give you something to walk away with and then I'll kind of recap and remind us all of what the goal is here. So some DevRel common failure modes. Number one, trying to throw money at the problem, right? We talked about that. Number two, not seeding your community with enough interesting ideas and examples to work with, right? You can't have people, you can't expect people to read your mind, right? Giving them something to work on is sometimes very useful. Another three is adding or assuming too much content in your docs and tutorials, right? Meet developers where they are, understand those personas and you'll be much more successful. Four is doing way too much low leverage work, right? So that's me in the beginning, only answer is not really working on our docs, on the flip side, go too far there. You can only focus on high leverage work, right? And if you do that, you don't do the things that don't scale, meaning you make people feel like you don't care about them by not answering questions in your Discord and not staying, you know, for example, we stay up until 3 a.m. some nights at hackathons, right? That's not exactly high leverage, but it does help us build goodwill with the ecosystem, right, so be willing to do those things in addition to some of the higher leverage stuff. It's both important. And then finally, the thing I'll leave you with is to remember what success looks like here. I think, you know, we sometimes forget that. We just get in this cycle of just throwing money at hackathons and just, you know, going to all these conferences and things and we forget that success looks like a thriving community of developers who tell all their friends, their bosses, and other people they know about your product that help developers, other developers in your community, right, they give it back to you that build their integrations at their existing company or protocol between your stack and that ultimately launch businesses that are built using the technology you build, right? That's all the things that really matter. So if you're interested in all this stuff, I love talking shop on DevRelThings. Thank you all for coming today. Get in touch with me on Twitter at Esplendium5. I'm also in Discord at SamF Superfluid with this little 0902 thing. So yeah, come say hi. I'll be outside to answer questions. If you guys have any questions or would just like to talk or meet up and thank you so much for joining us today. Oh, one more thing. I have my friend Yao in the audience. We're gonna have a DevRel Meetup tonight from six, right Yao? Six to 9.30? Six, 30 to nine. All right, so if you're interested in this stuff, we have some cool DevRel professionals and developer community experts coming. Stop by, say hi, and we'll have a good time. So thank you again.