How to Build a Vibrant Developer Ecosystem by Sam Flamini

all right testing this sounds like it's working all right so I was just giving the cue that I can I can start here which I I appreciate um I'm glad we got the technical difficulties all sorted out but today uh what I'm super excited to talk to you about is building developer communities so my name's Sam uh we'll we'll get into my background in a couple slides here but I lead developer experience at Super fluid and uh before I get into all of the nitty-gritty of building developer communities I want to just paint a scenario right and this is definitely not you if you're sponsoring eat Denver but just hypothetically speaking maybe maybe it is you in a past event right let's imagine you're building a really cool protocol right because we're all building Cool Tech right you're building a really cool piece of technology and you're sponsoring eat Denver right or maybe this is a past event um and you're really excited because you've paid 20K Plus in travel expenses and sponsorship fees and and you're putting up a bunch of money in bounties and you tell everyone how pumped you are because you're so thrilled to see what hackers are going to build on top of your Tech and you tell your whole team who you sent here to be prepared because it's going to be super intense you're going to get lots of questions because the whole entire event is going to be clamoring to building but on top of your technology and then you go you come to eat Denver you go to a hackathon and nothing happens right the hackathon Flop is a real thing it happens it's happened to me before it's happened to other uh protocols that might be here before um and typically this is what it looks like you hope for 30 submissions and you get three and in reality two of them are just like figma files uh that just show a mock-up but don't actually use your technology underneath the hood and when you go and ask for feedback from developers and what it was like to build on top of your stack they give you feedback that your doc sucked and you just get ripped to shreds uh so this is no fun this has happened to a lot of people that are in my position that lead devrel teams uh and you know there are ways to to mitigate against this but the lesson here is that it's not enough to build awesome tools right we all think that our protocol or our project is the coolest thing ever right but you need people to know about them and you need to make using them a great experience so who am I okay so I I lead developer experience in superfluid which is a cool protocol I'll give a little highlight of what it is in a second but I'm a self-taught developer so I know what it's like to come to a new space and learn everything from the ground up uh and I also host uh the devs do something podcast which is a technical show for engineers in web3 and it's super fluid we have had again we've had hackathon flaps before so we're not perfect and we're still learning but we've had over 600 projects built on us in the last year and a half and teams building on top of superfluid have raised uh over eight figures in Venture Capital money and grant funding so I've learned a lot in the developer relations developer Community uh trenches and I'm still learning like I said I know the feeling of sponsoring a hackathon and not going the way that I wanted it to uh and like it's not fun right so you know my job is made a little bit easier because superfluid is a cool protocol right it's fun uh it doesn't make it that hard to get excited about it because we let you do cool things like stream money like you're seeing here um but we've had to learn a lot to get people actually building on top of our stack right it's not automatic just because people see a cool thing that they're going to build on it right you have to compete for attention and you have to make building on top of your protocol a good experience so today I'll share some of the things that I've learned over the last couple of years about building developer communities and making it so that people do build on top of your protocol [Music] but before I get into some of more of the details like why do we build developer communities like why do developer relations roles even exist in the first place right well the reality is that if your technology matters to people and you're building a a piece of technology that's meant to be consumed or used by Developers the the Holy Grail is having your technology be critical to other people's businesses and other people's lives right think about ethereum like we're all here because we like ethereum right ethereum matters to us that is why we're here right so this is this is the goal right it's to get technology your technology to matter to people and the the tangible output of this I think is is twofold right so what does actual success look like well on one hand you want to build an ecosystem of brand new companies and projects that use your technology and then you also want to support Integrations between your technology and things that already exist right so in terms of tangible examples one web two example is twilio twilio is a developer platform they helped enable new applications like uber and Lyft presenting push notifications and now literally anything that uses SMS notifications probably uses twilio or something very very similar to twilio uh for their their product a web 3 example again the perfect one is ethereum because it's enabled a brand new set of applications right super powerful Primitives like uniswap maker ens all this cool stuff cool stuff that you probably built and in the end we want ethereum to be integrated with other things in the world right so maybe ethereum is used as a global settlement layer right and maybe it's used in non-financial use cases in other areas of the web beyond our uh our bubble here in web3 so if that's the goal right developer relations is the function within companies in web3 that help like actually make this happen right so I like to think about developer relations like as the as two sides of the same coin right there's the dev side and the Rel side of devrel so on the developer side uh this looks a lot like engineering and you have to become kind of a product manager in this process right so this is building libraries uh apis documentation tooling smart contracts Maybe and then on the relation side you have things like tutorials videos podcasts meetups this stuff looks a lot more like marketing but it absolutely cannot feel like marketing because you're dealing with engineers and developers who they just they don't respond very well to things that feel like traditional sales or marketing collateral right so we'll get into that later but the thing to note is that great developer experience seems are good at both of these things right they have good apis and they have really really good tutorials and Community Builders on their team let's talk about the dev side here first right one thing that I want to call out is that building tools templates and examples that other Engineers can use to make it easy to build on top of your your technology is an extremely high leverage activity right these things might be used this code might be used by hundreds maybe even thousands of teams who then might build products that go on to serve millions of people so think about like all those resources on like the ethereum.org homepage so many developers see those things and and use all of the resources there to then go on and build other really amazing projects like the unit swaps or makers of the world right so these are really really high leverage things and because of that you need to think like a product manager when building developer products like this so what does this mean well the first thing to to highlight is that your docs are your most valuable product in my opinion um to build really good docs and other developer products you need to also understand different developer personas that might want to use your technology and then you also should be mindful of your abstractions You're Building into your sdks and your libraries and your tooling and we'll get into all of these but this is a bit of an unrelated statement that I really like when it comes to docs this is Elon Musk on Tesla autopilot and he says that they view all user input as error now Tesla autopilot is a long way from actually achieving this but I I respect the mindset and what I would what I would challenge you and this is what I challenge myself to do for your Docs view all developer questions as error so the whole lineup of questions that come into your Discord or maybe that end up on stack Overflow view all those questions and sort and sources of confusion as error within your docs now obviously this is like a really really high bar and no matter how good your dogs are you're still going to get developer questions I might even do this myself right it's easier for me to maybe ask you just a high level question than it is to go through and read all your docs but it's a useful frame uh with which you can view your documentation and it makes them better right you should think that every single minute spent making your docs better is worth hours potentially of answering individual one-off questions right it's a much higher leverage activity and the other thing to highlight here that's kind of a recent development but gpg3 and co-pilot mean that learning syntax is less important right so you have to have all the little syntactical details about how your sdks work and how your smart contracts work inside of your documentation but like you know I can plug a line of code into GPT gpt3 or chat GPT and get a decent explanation of how that individual piece of code works or just have it generate Syntax for me however really good explanations are still critical for you to take ownership over creating right and to to do that you need to keep in mind that your product is going to have to be explained differently depending on the audience which means that you need to define those different developer personas that might show up uh to your documentation so this is how we think about it right this is a case study uh with what we've done at Super fluid but what we do is we segment by skill level actually we have beginner intermediate and gigabrain sort of tracks you can go through in our docs and then we also think about it by role or intent right so is this person just going as an indie Dev to a hackathon to try to win some prize money are they a developer like a senior senior engineer at a potential integration partner for potential integration between super fluid and some existing Tech or are they like a future founder or an entrepreneur right and we think about these different personas when it comes to our documentation to make sure that each individual one of these Journeys uh is a high quality journey and one that's useful so some other considerations when it comes to building Dev tools and docs is the first one is to be mindful of your abstractions right so too little abstractions uh inside of your apis or libraries might mean that you lose beginners if you're trying to you know get some beginner to build on top of your technology and you're asking them to like decode or work with bytes and stuff like it's not probably going to go very well because you're going to lose people but on the other hand if you have too many abstractions so so much so that you frustrate intermediate or Advanced developers because you try to hide the details too much uh you might turn those devs off and stifle Innovation by trying to hide how your underlying technology actually works right so keep that in mind the other thing is to avoid what what I call the mid-wit Trap of SDK and API development right so on the uh far right and far left sides of the bell curve uh both of those individuals both are Jedi and our far left Bell curved person I want you to keep it simple right simple apis simple sdks don't do too much but our Midwood here in the middle wants to put every single potential use case into the sdks it's Little Helpers and stuff and make your SDK gigantic and Bloated and you should try to avoid that I have not been perfect about this in the past but I'm learning I'm a reformed midwit here or at least trying to be and uh you know this is something for you to keep in mind as well okay so that's the dev side what about the relation side right how do we think about this well I I mentioned earlier you can't Market to developers right you have to pique their curiosity instead right and that's how I feel too right if I'm looking at your technology I don't want you to like throw a sales collateral at me I want you to just you know capture my interest right so what we'll go through is what doesn't work here what does work here and some good content examples this is kind of an art form it's difficult to give you like uh do this do this do this right because it requires some feel but I'll try to give you some good examples here so what doesn't work again anything that like is a traditional software demo or something that feels like an Enterprise SAS company is selling you on something it's not going to work developers are going to see it from a mile away they're going to turn off and run the other direction right it's unfortunate but it's just true and I kind of get it right as someone who's a developer myself and the other thing doesn't work is anything that feels like Shilling right we're all kind of guilty of Shilling in web3 right uh and Shilling is difficult because it's tough to give it a definition but it's kind of like this I think Supreme Court judge in the US like a few decades ago who in a case on pornography said you know he might not be able to Define pornography but he knows it when he sees it well I can't Define chilling but I know Shilling when I see it and you probably do too so don't show uh and the other thing that's a little more subtle is you really don't want to convince people to build on top of your technology when it doesn't make sense for them if some new developer comes up to you with a hackathon and tells you their project idea and you try to like you know contort their idea so it's such that it includes your technology and their idea right even when it doesn't really make sense you know it might get them to go back to their table and start looking you up and and thinking about integrating you into their project but eventually they're going to realize that you basically just tried to show them on your technology and didn't really listen to them and what they wanted to build so sometimes like the most persuasive thing you can do in an event like a hackathon is to be honest about what your technology is not good for right it's uh it you know people respect honesty developers have very very good BS filters they detect honesty better than most people so it's worth keeping this in mind how about it does work well for for us and for me like we just really try to focus on education just pure education even if it's not directly related to your technology right so this little thing in the bottom right here this devs do something logo this is a podcast that we run that has a it has a goal it's its goal is to be the best technical podcast in all of web 3. and yeah it's a big goal but that's not necessarily like uh you know it's not the same as saying I want everyone in web 3 to like build on superfluid it's saying something different it's saying let me just give to the entire community and we'll we'll get something out of it right well the first thing we get out of it is it is it allows us to introduce brilliant devs to superfluid which are the guests that we have on and the second thing is we have a monopoly on ad space so at least we can take the ad space right people are used to ads and podcasts and and this kind of stuff you know it's worked so far right it's gotten good feedback it's introduced people to superfluid and I enjoy doing it so subtle plug go check out devs do something if you like technical podcasts another thing that works is just creating really interesting examples and proofs of concept right this seems like it's an obvious one but just stay up to date with popular Technologies uh stay up to date with some of the trends and new narratives in the space like ZK stuff like account abstraction and try to if it's possible try to build something that incorporates the new narratives and new interesting Technologies with what you're doing it tends to help right what you want to do is you want to uh you want to nerd snipe right uh this is you on the Left Right your ammo are just really interesting pieces of technology that are ideally integrated with what you're doing right it can be anything from like low level solidity stuff uh to ZK stuff to interesting AI stuff to even like low-level language stuff like Huff is pretty big and ideally you know this with this is your ammo your useful interesting technology content you get really high quality devs to build on top of your stack the final thing that really works uh at least I think this is the final thing I have in there that really works is to create superstars in your developer community so you have to make people that continually build on you feel really special so we do this through things like live streams I make like little short videos highlighting certain projects and people like it right it's just us genuinely trying to put other people on a pedestal and making them kind of the heroes within our community for just building cool stuff right this is something that other developers see take note of and they think oh you know what these guys actually care about the developers in their Community maybe I'll go do something there too so another recommendation from us okay so this is one of my final sections here but this is all around spending money on developer experience and if you're someone here who uh is in charge of a p l at a protocol or something like that you've raised money and you're in charge of allocating it you know that a lot of people in the space spend a lot of money on their developer community and trying to grow it so the challenge here though is that you can't just throw money in your community and hope for good outcomes uh you you really get out what you put in on a uh on an effort basis and also on like uh work smarter not harder basis as well right so if you're gonna go sponsor things like hackathons and throw 30k at a hackathon right you have to be really uh uh specific about how you do this right you're looking for high quality co-sponsors at that event uh and you're looking for organizations like each Global like defolio like eat Denver that also put out good content and run good events of their own right you should ask yourself what kind of community this particular hackathon is going to attract and make sure that that audience is going to also want to build on top of your technology otherwise you might be in the hackathon Flop scenario that I open with here right so you don't want to do that at the hackathon right again if you're going to spend tens of thousands of dollars coming to something like this you should prepare right you should prepare some ideas for people to hack on right a common failure mode is everyone gets so excited about the things that you know that everyone says the things that I'm most excited people to build on my technology are the things that I haven't even thought of yet and that might be true the coolest things might not even be in your own mind yet but you have to see the community with some ideas it's really really important to do that um we do this uh and it also helps people like if you give them ideas and they can easily stack on top of other sponsors Technologies because you know let's face it if you're coming to hackathon it's kind of nice to win prize money and devs like to pry stack that's just what they like to do and the final thing and this goes without being said this uh is kind of obvious but be as friendly as possible to every developer you meet like you can make a lasting impression and honestly change the trajectory of people's careers if you just really uh try to inspire them and make them feel good about what they're doing and their own path so keep for that in mind the last thing I'll say here on spending money on your developer Community is consider building your own distribution right so it's super flu what we've started to do is invest in building out our own hackathon system that we run in addition to coming to different events like this one so what the superfluid wave pool is is it's something we we've tried out that's actually worked pretty well so far it's a continuous ongoing hackathon where we give out between 5K and 15K monthly prizes and we usually bring in a couple of co-sponsors every month where the co-sponsor puts up one one or two k and uh you know we were able to kind of cross-pollinate in different communities by doing that and it's working so far right we want our community to always have something useful to do so we've had interesting uh Chrome extension applications come out on super fluid nice front end stuff uh even stuff that's been integrated into existing Dows has come out of that so it's been kind of cool to watch and the the cool thing about this and why I'm so happy about it and actually the person that deserves most of the credit is someone named Sunny who's not here yet but Sunny if you're watching this you deserve the credit for killing it on the wave pool with superfluid but the advantage here is that we can't always fly around the world air sponsor every event right we don't have infinite resources but the cool thing about the wave pool is that right now someone somewhere is building something on super fluid so you should consider this like consider trying to find ways for you community to always be building something on top of your technology uh it can it can again it can make your effort go a lot further and just give you a lot more leverage in every single action you take for your community and again very very very small plug for the super fluid wave pool if you want to co-sponsor a wave let me know that's all I'll say um but okay as we wrap up here um let's recap some common devro failure modes that I've experienced and I'm uh I'm guilty of leading us into every once in a while and that I also see out in the in the broader web free community and then I'll just kind of recap what success looks like and we'll we'll move on from there but common failure modes what are they the first one is to recap throwing money at your community and just hoping for the best another one is not seeding your community with ideas and really high quality examples the third one is not taking a product manager's approach to your developer products a fourth one is doing too much low leverage work so like doing things such as only answering all your Discord questions and not fixing your Docs but on the other end it's not being willing to do low leverage work that's also a failure mode if you're not willing to be the person that stays up till 2am at a hackathon I think you're leaving really good relationships uh and potential like really loyal community members on the table right and you should remember what success looks like so what does success looks like you want a thriving community of developers who tell their friends their bosses their teammates about your product you want devs to help other devs within your community you want engineers in your community to build Integrations between your products and their own products and then you also want them to launch brand new businesses and successful projects of their own on top of your stack so that's all I have for you today again I'm I'm still learning if you want to go hang out I'll go stand over there somewhere after this this uh this ends and we can talk shop but uh get in touch with me on Twitter at esplanet5 hit me up in Discord if you want if that's your thing um and yeah I really appreciate you all being here today thank you [Applause]