Building a Thriving Developer Community by Sam Flamini | Devcon Bogotá

foreign [Music] so today's talk is going to be on building a thriving developer community so I'm Sam uh 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 like actual content here I want to paint a scenario right let's say that you're building a really cool protocol or piece of technology right you're you're targeting developers you're building this platform right 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 then 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 uh let's say you get three submissions two of them are figma files uh 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 like the bottom line is 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 so who am I I help lead developer experience it's super fluid uh superfood's a protocol that enables real-time finance and money streaming right if you're curious about super fluid check us out at superflu.finance there's lots of good stuff there uh I'm a reformed SAS 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 the crypto rabbit hole and uh here I am so at superfluid I also host the devs do something podcast which is a technical podcast for engineers in web3 and at superfluid we've had over 300 projects built on superfluid in the last 12 months or so if you go back further it's more like five or six hundred um we have teams building on superfood that have raised eight figures in grant money slash Venture money and you know it it looks like your community is doing well right obviously we have a long way to go you know in our eyes but I've learned a lot in the devrel 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 uh 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 my job easier but I've still had to learn a lot and we've had to learn a lot of superfluid so today I will share some of those lessons so if 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 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 what does succeeding with the developer Community really mean like what's the output right and I 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 or your protocol and existing Solutions and applications today right so a good web 2 example is twilio they've enabled new applications like uber and Lyft and 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 in the on the back end and the obvious web3 example is ethereum right so uh unit swap maker ens all the existence of those apps makes the ethereum ecosystem more valuable right it makes ether more valuable actually and the on the other on the other hand the integration bit for ethereum is is to help if 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 if that's what we want when we create a developer ecosystem and that's 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 uh and it really has become a kind of very important discipline in web3 right and what I like to do is break devrel out into the dev and the real side right so on the developer side this is your libraries your apis your docs your tooling even your smart contracts if your 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 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 you know for those of you that are technical it's probably obvious um the key thing to keep in mind as a devrel person or as someone who's building out 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 superfood 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 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 going to 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 on the side of docs right there's this quote that Elon has on Tesla autopilot that they they view it 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 right obviously you're still going to get questions no matter how good your docs are and 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 that really wasn't the right mindset to take right because all the question answering although it's useful right if you ask a question someone's Discord and they don't answer you you're going to feel like you know they don't care about you right so we still do value answering questions 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 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 uh so Patrick Collins you guys might you guys might know who Patrick Collins is he's a great developer experience person in the chain link ecosystem that I've I've learned a lot from him uh what he actually does is if someone asks a question to him in their Discord he will like 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 a Discord and the reason why that's so smart is that every question you answer in Discord just stays there right Discord like it's it's really hard to like go research like 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 while you sleep answering questions like you can't do that in your sleep unless you're you have some kind of powers that I don't know about um so okay with that being said how do you maximize the utility of all your docs and developer tooling right how do you how do you think about this well you you need to start by identifying developer personas right so a case study on this would be with super fluid 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 assessing by skill level right so you have your beginners you have your intermediate and you have your gigabytes right and we also segment by the role or intent right so come to hackathons right they're just hackathon devs or Indie devs company just hack and have fun uh you also have developers at integration Partners like people that might go Champion to their boss that uh they you know their company should do superfood 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 beginner 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 I want to build smart contracts with super fluid and then our tutorials and examples we have a Zero to Hero series and we have very easy like dead simple beginner examples on the front end in react okay so that's that's like the beginner segment for intermediate devs we have our reference docs right you know if you're an intermediate Dev you know what you're doing you're you're happy to just go literally like look into the reference docs and find the functions you need we also have advanced guides for some of the more advanced features of superfood 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 typescript support right on top of that we have a developer console which is helpful for like getting data from the subgraph and in terms of tutorials and examples we have more fully fledged example applications that can take you end to end building a a more full product right you can see test Suites all the stuff 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 the entrepreneurial types can find something to actually try to build uh we have this super fluid 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 and end user product or or thing that can actually become a business right some other considerations right when it comes to developer tooling right one 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 your code base your docs and figure too many things out right you might lose beginners however if you try to to Shield a developer from the 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 going to 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 it super fluid is that naming really matters right uh protocol Engineers sometimes like to throw really uh crazy names in their contracts that don't make a whole lot of sense uh so you should think about this uh 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 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 we're blind to how much context they have right uh 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 uh people that actually become founders of 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 want to go back to zero you want to you want to 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 your stuff moving further into the devrel stuff one thing that you have to keep in mind that 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 going to go through what I've seen doesn't really work when it comes to marketing developers what I've seen does work and then you know we might talk a little bit more about being mindful of extreme 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 piece of marketing collateral uh 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 going to pay attention right and this kind of is looped in with anything that's feeling right so there's the the uh Supreme Court Justice quote about you know there's like a case on on pornography and somebody asked the 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 uh 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 your technology right so if some engineer comes up to me to hackathon and says hey Sam you know I've got this thing you know it does XYZ should I should I use super fluid to integrate with that right and if they tell me that XYZ is something that really makes no sense to integrate super fluid with and I try to sell them on why super fluid is a good thing to connect to their to their their project if they don't recognize it right away they're gonna figure it out when they when they start going through a docs in our code base and we 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 uh but Deborah people need to keep that in mind it's very very important so how about what does work well I I mean I think that focusing on education is really the right move right and not just education around 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 chain Dev YouTube channel that the chain link Community put out and another is a podcast we we launched a superfluid called devs do something so chained Dev they just do very general stuff like Patrick Collins does it he does very general uh just web3 tutorials and that builds a lot of credibility with with the chain link ecosystem and you know I think people know who Patrick is and they want to they want to go build on chain link because they know he's helped them a lot and he literally is always wearing the Chain Link T-Shirt right that's that's a good thing and then on our end with super fluid we launched this podcast called devs do something that is designed to just be purely helpful for engineers in the space we've had on just a lot of really good technical minds and we we don't really talk about streaming money or superfood stuff that much at all right all we do is we just talk through like what they 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 you know 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 your stack and your protocol is creating really interesting examples and proof of Concepts right so this might be obvious but one one thing to keep in mind is you know we're all playing a long game here I hope 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 one at one moment it's nfts at another moment it's defy right now we're hitting the stage of like zero knowledge stuff is like the the sexy thing and yeah rightfully so I hope people build good 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 in Foundry stay up to date with all the new ZK stuff and if you can create some kind of interesting integration between this 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 you don't and remember like I said a second ago you don't want to force anything but if there's a genuine integration you should you should build some proof of concept around that right it helps you stay in the conversation like I said and another 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 because you have something to say and it also makes people feel good right because it's just it's just a nice human thing to Spotlight someone and tell them they did a good job right especially if it's if it's true obviously so that's the dev and the real side another thing that I think is interesting to talk through is how to spend money in a 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 devrel team members I'm not going to go into how to hire deveral team members but in terms of getting money getting getting Roi out of the money you spend at hackathons and bounties uh you have to keep in mind 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 on this on this this L1 or this protocol will 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 to put it is that you really get out what you put in from an effort and and how thoughtful you are uh point of view right so when it comes to hackathons I'll head on hackathons first the selection of the hackathon you're going to do really matters right so you want to look for really you want to look for events that have really high quality co-sponsors uh and you want to look for organizations to 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 before you pay money to be at the hackathon what kind of community is this event going to attract and is that Community one that you want building on your on your on top of your protocol right or your technology in general two really good examples that are kind of the gold standard are youth Global and devfolio I love youth Global if you're a need Global person in here thank you for doing good work at good hackathons that's right so look for look for teams like that right it helps and then at the hackathon one thing that's counterintuitive is you should prepare a couple of ideas at least before the hackathon starts because you know we also 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 uh devs and hackathons like the stock price 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 hackathon so that's that's how to think about hackathons the other thing that we do at Super fluid 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 to get people to complete tasks is a little bit overrated you can crowdsource some good content and things but what we what we kind of like to use bounties for is to get Giga brains 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 that's a very important thing to note right again this is just kind of a regurgitation of what I just said um they're decent for crowdsourcing tutorials and educational content but again use them to get smart people looking at your technology all right so so to wrap up here right I want to go through a couple of devro failure modes right that I've experienced in mistakes that I've made mistakes that I see in the space uh just to just to give you something to walk away with and then I'll kind of recap and you know remind us all of what the goal is here so some several 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 uh 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 but 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 uh like you know like you don't care about them by not answering questions in your Discord um 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 uh 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 uh that help developers other developers in your community right they give back to you uh that build their Integrations uh 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 um so if you're interested in all this stuff I love talking shop on devrel things uh thank you all for for coming today get in touch with me on Twitter at esplanet5 I'm also in Discord it's Sam f superfluid with this little 0902 thing uh so yeah come say hi I'll be outside to answer questions if you guys have any questions or would you like to talk or meet up and thank you so much for for joining us today oh what one one more thing I have my my friend Yao in the audience we're gonna have we're gonna have a Deborah meet up tonight from six right yeah six to nine thirty from 6 30 to 9. all right so if you're interested in this stuff we have some cool devrel professionals and developer Community experts coming uh stop by say hi and uh we'll have a good time so thank you again [Applause]