Andreas Wallendahl, Chris Ward ~ Focus on the Dev: DevRel & DevEx Kauri

[Music] hello everybody so how many of you have got very enthusiastic about a developer tool gone to the website and found that the documentation doesn't work the tool doesn't work not more okay well you're obviously all working for projects yourself and then you just get bored and pissed off and then leave yeah it's a common experience so the topics of developer experience which is a kind of new emerging field and developer relations is about focusing on trying to make your project actually usable for developers and why well the more useable your project is the more developers will use it hopefully the better tools they will build and hopefully more end users and that is something that the blockchain space needs let's be blunt so if we were making a better tool chain all the way down maybe we would have more end users in the long run too so in this presentation we're going to focus on some of the other things you could and should be doing around building a tool to make it actually nice for a developer to use obviously we're going to cover a lot just in overview we're gonna I think probably every one of these subjects could be a separate presentation so if you want to talk more detail about anything that we talked about here then please come up to our booth and we're happy to talk endlessly about any of these subjects since some of the things we're going to talk about everything from community management to promoting your project to developers to focusing on developer experience which is not just documentation but a lot of documentation communicating what you're doing and then measuring if it's actually being successful in the first place is also important and with that I'm gonna hand over to andreas for the first part hi first I'm just gonna set some of the context on the web 3e kosis because communities in web 3 are a little bit different to communities in web 2 several projects are just dealing with developers particularly developer tools but even some developer tools are creating a user and token ecosystem on top of that which requires a little bit of extra neurons and Zeppelin would be one example of that as well so this is what many of us think our web 3 communities look like it's an even balance of developers token holders and users but often the way it ends up looking is we've got a much smaller pool of developers who aren't necessarily users or token holders a slightly hopefully bigger group of users and a lot of token holders if you started off with the token launch and that brings in some extra nuance so in the past year obviously given crypto winter the value decline has made it a little bit harder to manage that portion of the community and we're gonna talk a little bit later about tactics especially communication tactics to differentiate between your audiences and then we're gonna focus on the kind of one of the most productive audiences that you can have which is your developer community because they can contribute your actual code base they are your first users if you have developer tools and can be your biggest advocates as well end-users right now there have been some challenges around active users especially on onboarding and awareness in the overall community looking ahead initiatives like UX are gonna be more and more important so it's good to see the this year there are more sponsors who are actually focused on that area and not just not just the the the back-end or middleware and another thing to do with end-users is obviously celebrate them learn from 6:00 for campaigns and share those with other communities so there's this one great group which I'll give a shout out to which is called community of communities and it's got a lot of the community managers and developer relation leads within the web 3 ecosystem and they will open source their knowledge to each other and share best practices for example successful or ambassador programs and so on then the community which this talk is really focused around is the developer community in the etherium community we have an extremely positive atmosphere especially around events like this which are focused on bitterling we are of the perspective that let's not just focus on building for the sake of building but wanna coin this time of solving solving so you need to be solving a problem for your community and then focus on the developer relations and getting it into more hands more people's hands right and a key component and I've done a lot of interviews with developer community leads within the etherium ecosystem one big learning here is just the hyper focused on the metrics so that you're getting feedback loops of what's working with your community so overall what can you help your project there are a few key areas here so first there's developer relations which is really helping helping developers find you helping developers use you then it gets into developer experience which is really making reference documentation extremely accessible and efficient having different types of content which achieve different goals with the developer which Chris will speak more about community that's a lot of sharing successes sharing what people have built with whatever you've put out there developer tools SDKs if it's your own chain whatever it might be developer marketing which is actually bringing more people in and getting more awareness and then strategy and metrics which is how we can tell if we're being successful through all of those efforts above right so one of the things we like to do a calorie is spend a lot of time learning from what's worked well in web 2 and what can we apply to web 3 developer communities and you see very different models by different projects right so on the kind of more engaged side you've got Google or Twilio or slack who have teams of 20 to 30 or even more developer advocates evangelists relations on the other end that it can just be an open-source tool with no if you don't have the resources no official developer relations team right or it can be more informal and you see this happening a lot in the etherium community with more meme based communities more informal interactions just interacting through geta and so on and then partnerships can also be super effective in web 2 like stripe for example is really good at this right you see you see stripe on a lot of other [Music] portals or developer resources so also from our interviews with a lot of dev rel leads in the etherium community there are a few key what to do so if you have a technical can have a technical community manager who can actually answer the questions at the low level really engage people help them when they have questions and foster that conversation so that it's not just putting things out there and expecting people to build on it and it's helpful that it's not always the core developers who are doing that because it's it's more important for them to build and focus on building then second if you're still pre-product no point in spent sponsoring an event like this we heard it time and time again a lot of teams especially ICO teams feel like they've wasted a lot of money on sponsoring big events before they could actually get a test now a tool a beta whatever it might be in developers hands and then third focus on key metrics and it's really important to also iterate experiment figure out what is resonating with your users what's working for them and then adjust write and monterrey of Zepplin actually has a really good quote always be skeptical of your metric because you're not seeing the full picture so you need to go beyond the metric and actually speak to the users the developers get that feedback build it into the product roadmap right and then I'll hand over now to Chris who's gonna speak more about the developer experience and exactly how you can build it out Thanks I hopefully I'm going to upset a few developers in the room now and that's the kind of the point let's see so I mean we all know what user experience is it's making something that's usable for your end users and developer experience has been an emerging field this sort of DX field I guess the past couple of years there's even conferences that cover this now kind of crosses over technical writing and documentation but also a few other fields and to be blunt we have where were often putting our presence on the web the web doesn't just have to be texts we can actually do a lot more to bring developers into a project so there's there's gonna be a lot of things behind these bullet points so let's dig in a bit so for the the sort of click Beatty start I'm gonna start with the three double use the who what on the why this is a bit of a cliche but this is very important to think about in the first place who is looking at your tool what are they trying to do and why are they trying to do it and bear in mind that if you're so I actually use I'm gonna I've been doing technical writing and develop relations work in mostly in kind of more traditional shall we say open-source community so I have a one of my I think one of the examples of a company that does this not necessarily the best but well to cope with different user groups is docker I'm guessing if most developers in the room know docker you don't have to know it but it's a very technical tool but it also helps people who run projects who run businesses etc so if you look through their communication you will see that at a very top level it just explains to people why it's useful at a kind of second-tier we'll talk about um technically the benefits it's going to bring to you and then at the developer level it will explain how to get started how to get something running so this is the same very technical project but with three different levels of communication so this is important the the who what and why will be different at different levels if you are just a tool posted on github that's a JavaScript library or something like that then probably most of it's gonna be one user base but if it's a tool that you want to kind of be more widely adopted into enterprise or company users then there are also people who sign checks and make business decisions who also want to understand it but in a different way so the the person that you're aiming at will change in different places and hopefully if you are doing your business planning in a proper way you've already answered a lot of these questions at some point but it also counts to the developers too okay and then assume nothing is gonna be the one that I really think if you want to remember something and write write it down to take home it's gonna be this one we all know this we all kind of know that we should assume nothing but actually this probably goes a lot deeper than we may think so firstly every time you release a new version of a tool test it on vanilla machines to see if those dependencies that you think every developer must have installed hmm actually do they so always test on vanilla machines to see if the steps really work for someone just starting out and likewise the developer community is becoming more diverse now and this is a good thing but this also means they're not everybody that is looking at your tool comes from the same the same education background as you the same knowledge background as you so again don't assume that just because you know a piece of knowledge and how something should be done that everybody knows that just it sometimes gets I know it can get a little tedious to begin with because you just think I'm just repeating myself a lot but it will really help everybody in the long run and get the actual I mean the the overall positive of doing all these steps in the long run is less support calls and less support tweets and telegram chats and all these sorts of things which free you up time to do other things so all these steps will help you focus on what you actually want to be doing anyway okay the next point I'm going to drill into is refining your concepts um I personally believe and I am a a wordsmith so I'm gonna be maybe have a little bit more sort of experience of doing this but I actually really think that every project no matter how complicated you think it is can be explained in an elevator pitch like a this is a sort of startup term for a three minute pitch when you're in an elevator with with someone and I would challenge you that if you think that's not the case then find someone who can help you because really if everything can be abstracted to very broad general terms and of course you're losing a lot of detail but that can come later and this helps you then answer these questions at the top in that the people who just want to have a rough idea of what it is in a few seconds will get their idea that person who wants to dig into a bit more detail gets their idea in etc etc so really work on refining those concepts and I'm gonna come into a little bit more detail about how you could try to do that in a minute the the next point is onboarding so not every tool needs onboarding onboarding is kind of the concept of maybe you need to create an account I mean in our space it's things like keys which is still difficult and we're still figuring that out but a lot of developer tool companies have quite good onboarding experiences so I'm gonna refer to some web 2.0 examples because they're probably it's probably easier right now for them to do this and then you can think how you could apply this in in our ecosystem so for example you can create the tutorial that has a getting started piece of code zipped up in an archive file pre-populated with all their user access details commented throughout the code so someone can read the code C code comments follow along the documentation and they have something nice and in sync that they get to play with immediately whilst also looking at the instructions for example there's also a tool called pusher which is a messaging JavaScript messaging tool they have a very nice onboarding where you actually could go to the website create something in your terminal and the website starts sending your terminal messages it's small it's simple but instantly you're getting feedback into this is doing something and it brings someone in straightaway and a lot of this feeds into the assumed nothing - if it takes someone 20 minutes of pain playing around with dependencies and conflicts and timeout issues then you've lost them I'm sorry and finally this this sort of leads nicely into the last point is that Doc's can't fix everything if your tool is slow buggy badly architected not well tested there's only so much you can fix that in documentation and maybe it's time to actually think about fixing the code first I know it's a much more long process than just writing about it but it's also a good point I think that the creator of Perl said that the I can remove exact quote so I'm probably gonna butcher this but the the best tool is something where someone doesn't have to look at the code and it's kind of the reverse of this in that if your tool is really usable they shouldn't need to look at the docs you know somewhere in the middle okay so what what can be documentation and as I go through each of these and explain why these might be useful I'm also going to remind you that I said a few slides ago not all documentation has to be text we can have video we can have gifts we can have interactive playgrounds like jsfiddle and things like that docker as I mentioned earlier is a wonderful tool for in the background spinning up an environment that someone reading your documentation could interact with when they're done that's taken away and the next person who comes along has the same thing obviously it takes time to set this stuff up but if you're focused on your users and this is all good in the long run so the the words that we use to kind of divide these types of documentation and not necessarily set in stone it's more about what they're trying to do so getting started is getting started introduction a very quick easy couple of minutes overview that pretty much anybody could follow have something working at the end of it and then think hey I like this I don't look further or hey no this isn't what I was looking for probably actually the hardest one to do because getting it right is quite difficult then we have our reference Docs this might be API documentation it might be SDK code it might be just protocol reference what the reference is is it's kind of like laying out the toolkit this is a hammer you use it to hit things this is a saw you use it to cut things and in the getting started is like here's how you hammer a nail and saw some wood to build a shed a kind of thing explanation and guides sort of cross over a little bit in terms of explaining to people some common scenarios where they might want to build these tools together to achieve something if you have a JavaScript library then it may be integrating it with react for example things like that and structure is an important one in many ways in that I also hate to disappoint you and this is a talk I do a lot with technical writers is you spend all this time writing your content and not everyone reads it no one has anyone ever read documentation from start to finish no you you look around you jump around you google you search you come back etc etc so never assume that people are following things from start to finish always make sure there are jump off points between important things that people need to know and this also goes down to the page good HTML structure and good markdown or restructured text structure whatever you using to create the documentation is important to not only for a person reading a page but also for search engines so bear that in mind your readers are not all humans they are also robots finally on kind of actually the the content the actual more detailed content of the documentation this is something that I do entire workshops on so trying to cover it in one slide is pretty difficult but I'm happy to go into more detail with you if you want consistency is important a lot of these things are small changes but every small change you make especially if you are writing in English for example which may not be your first language to a reader who also is reading in their second language every little thing you can do to make the experience of reading simpler and less of a kind of mental strain will help so if you decide that you use the term framework instead of library stick to framework things like this just use the same terms repeatedly language is a very big subject but there's a lot of small things you can do that I'm happy to share that a very quick fix is to improve the reading experience and I will drop some words here for you to look into things like active versus passive voice things like reducing future tense this is all like grammar nerdery but I'm happy to go into more detail and there are tools to help you with this you don't even have to know what you're doing so and secondly keep it short and keep it on point there's a great quote that is misquoted to many many people if I had more time I'd have written a shorter letter writing on point and short is hard a waffling endlessly is much easier as I'm doing right now I think keep on point people just want to come to your documentation achieve something and leave they don't care how smart you are and how long you've been building something they just want to use it and bear that in mind so with that I will pass back to Andres kind of looping back to the overall communication strategy and this is where we think about audience a lot right and being quite selective of channels so a lot of the feedback that we've gotten through the web 3 community managers is for investors telegram and website is the best so most investors are used to using telegram just keep them where go to them create a channel for them where they're used to being and then the website can answer more evergreen questions then for end users blogs which look a little bit more like there's more activity coming because it you see the dates of the new postings and so on a helpful website for content which is going to persist for a longer time and then events actually interacting with the end users having a two-way conversation super-important developers keep again similar to ambassadors go to where developers are github get a forums are far more effective communications channels so things like discourse have proven to be much more effective than things like discord or slack or telegram because in a forum you actually have that thread which persists rather than having to scroll up a thousand messages to find something which is long long gone right and then almost a more persistent version of forums in a better version which can be more curated is knowledge basis and that's also where carriers focused and it's enabling the community to not just contribute so you can have multiple contributors the burden isn't just on you as the core developer you can contribute and so can the community but many people can also collaborate on curation as well organizing it into structures which are easily readable going back to Chris's point then almost one of the most forgotten but most important areas of community and developer relations is measuring the impact how do you know if you're actually having success and it depends on where you are in your project lifecycle if it's just starting out and you've just got something out there which you want people to know about the top of the funnel is the most important and that's awareness there are many ways to understand awareness it can be kind of if you've got content on the web it's gonna be monthly uniques if it's a tool which you've made available open source it might be things like github stars or a number of people watching matt Reaper acquisition is people who are taking the next step beyond awareness so either sign ups or downloads installs whatever it might be make sure that you're tracking them and seeing how they change on a week to week or monthly basis then activation how much engagement are you getting from those users are they downloading the next release or are they installing the next release are they making contributions to your repo if it's an open-source reaper something which a lot of the strongest projects in this base track carefully is things like issues because that means you know that people are working with your code and they're they're actually helping you out by identifying issues and PRS of course then retention what's continued use of the platform this can be really hard to measure especially in web 3 when we don't have API keys but there are there are some people who are working on init of innovative ways to test this one of the most basic things that we can do is just look at number of interactions with the smart contracts because that is on chain and ready available right then in some cases it's gonna be revenue from transaction fees from subscription whatever it might be that's definitely a part of the funnel and then referral how many people are linking back to you how many people are writing about how to use your tools your your SDK whatever it might be that's a really good way about understanding ok someone liked this library they wrote a tutorial about how to use it in a certain context and then posted that that's a really good referral and then finally product taking all of the feedback you're getting at different points refining the product and having that positive feedback loop then when we think about building the team and the dev rel team there are a few different skill sets that you can look for in the person that you're hiring and the general wisdom is to pick 2 out of 5 because unicorns don't exist and if you need all five then maybe you need three people but public speaking can be an important component of devrel it's working on things like awareness it can also be working on things like education to improve engagement if you release a new feature tell people about it so that they can use that new feature beyond just the core tech right technical writing and tutorials is a much more cost efficient way of improving awareness and engagement because that content persists especially if it's indexed appropriately and cross posted to multiple places and that's something which we're happy to talk to you more about then community building and people skills these are online communities in-person communities equally important and can be weighted more heavily in one direction or another depending on what you're doing and then events organizing your own events truffle just had truffle corn I had a lot of sponsors are here sponsoring at Denver because this is a great way to get in touch with users developers and then people who actually build stuff they can contribute they can mock up a quick demo they can make it come alive for other developers and inspire them and have more creativity and that goes to the last type of content which Chris was talking about which is guides sometimes also called tutorials or and demos are super important there so in summary think about who your users are differentiate those communications and build an engagement plan around that that type of user build holistic teams but don't expect unicorns then if you are building a community collaborate with other community managers and also give back if something worked really well let people know how you did it so that they can replicate that and so that we can bring more developers into the web 3 ecosystem together and then learning from web to Kendall who's also on the carey team is going to be giving a talk at FCC which is all about learnings from web 2.0 and how we can apply that to web 3 another really good web resource for that is dev rel dotnet they've got tons of great content and then always remember dev rel DX don't forget about it it'll remain on the side stage for a long time but it's one of the most important things that you can do to get good engagement from your community and really ensure usage so thank you everyone I think we can take one or two questions or just come and see us at the booth I don't know if there is a question there's a microphone at the front otherwise we are running a little bit wrong perfect thank you for listening come say aye we're at the Kerri booth which is just at the top of the stairs