Approaching DevRel as an educator

Kassian: Like you said, I'm Kassian. I am a developer, sorry, developer advocate at CloudFlare. I do a lot of hardware, so that is me playing a base. You can kind of see it up here too. It lights up the colour of the note that it's playing, and I was playing that in Paris last week at js, so I do a lot of hardware with JavaScript, hence the name Node botanist. I am agender and I am intersex, and I can talk about that later at karaoke if you want. I use they. They're them pronouns.

I am an author as well as an iot addict. I've written two books under my premar name, which is Cassandra Perch. I am now Cassie and Ner Run. Long story for those of you want to talk about that of karaoke as well. I've also been doing Devra for five years. Before that I did a lot of developer education and I did a lot of work for Girls Who code Women who Code, and I worked for a small company called KU and taught classes.

So there are a lot of similarities between dore and teaching and of course there are some differences as well, but there's a ridiculous amount of similarity between teaching a class and writing a content programme for a developer relations team. And so I'm going to kind of talk about the similarities and differences and how we can leverage those in order to create content. Then it really invites our users to learn more, not just about our product, but about the technologies surrounding our product. So the similarities with teaching in a formal setting is that the topic is set in advance. When you set out to write a video script or write a blog post, you have a topic set in advance. You have a objective in mind. It's for instance, if you're doing OAuth, you can say this is JWTs 1 0 1. You can set these topics in advance when you write a talk.

There are many ways to learn, much like when you think in a classroom setting, you think of auditory learners, visual learners, et cetera. There are many ways to learn in the real world and we have to take that into account where we're writing content for developer relations and then questions, questions and questions. Not only do we need to take user questions into account, we need to make sure that our users can ask us questions and have the channels available to ask us those questions because they're extremely important. So like I mentioned with the topic being set in advance, the users have a good idea what they're setting out to learn. They don't just wander onto the internet and think, oh, what am I going to learn about today? It's like, no, I need to learn about this particular protocol because I'm doing this particular project or I need to learn about this particular technology or stack because I'm going to be doing a project in it.

And for each piece of content, you can set prerequisites and a general level of knowledge for finishing that piece of content. You can say, look, if you don't know what server list is yet, this piece may not be for you. You can say prerequisites involved, instal, react on your computer and make sure that's all set up and instal nodes. You can kind of set those prerequisites in advance. The different ways to learn require us to create many different kinds of content. It's not just written content anymore. With the internet being as amazing as it is, we've now got video, we've got webinars, we've got streaming. We've got all sorts of different ways to engage our audience in ways that allow us to educate them.

We want to engage with as many learning styles as possible because we want our users to be able to benefit from our content in ways that allow them to then go on to use the product.

You want your contact to have a cohesive style and message across mediums. This is something that I see a lot of with companies that have larger developer experience teams. They kind of create content as they go and they lack a cohesive message or lack a cohesive sort of theme or even some branding issues can go with this. So when you think about content from an education perspective, when you think about a curricula or a syllabus, you have a general theme in which you're going to teach this class and each particular topic and each particular lesson can go under that overarching theme. You want to think about it the same way when you're doing developer relations content.

So users will always have questions and that's great. We need their questions, we want their questions. You want to know what those questions are and you want to respond to them as quickly as possible, and that can be a little tricky and that's because of the differences between teaching in a formal setting and doing educational developer relation content. It's much harder for users to engage you directly when they're reading a blog post or they're watching a YouTube video. It's much harder for them to be able to ask questions. They can't just raise their hand and stop in the middle of the context and ask the question. And so not only is it harder for them to ask questions, it can be harder to answer those questions because you get a question about a video you made two years ago and it's about something in the middle of the video, you might find yourself rewatching the whole thing just to remember what you were doing so that you can answer the question.

The way we deal with questions is a lot different in developer relations content than it is in education. In a formal setting, your users will come from an extremely broad range of skill sets, time commitments, and levels. So when you run a class as a teacher, you can say, look, you need to know this, this, and this to be in this course. You will learn this, this and this, and it will take this amount of time. We'll be doing two one hour sessions a week for however many weeks. You can't do that obviously with developer relations. You have to kind of accommodate yourself to the amount of time and the skill level that your users are coming to you with. One metric that I find really important in developer relations content is what I call the time to first hello world, which is extremely important for a lot of products because so a lot of times you'll have users who have a lunch break to explore your product, and so if your time to first hello world is longer than that lunch break, they'll probably lose interest and not come back or just not have enough time to come back.

So we have to accommodate ourselves to those time levels, to those skill levels and to those interests. The other thing is your students won't come in batches. I've noticed when I've taught developers in groups, they help each other out. They will catch each other up. Even in small groups, they'll kind of form little pods. That doesn't happen when someone's reading a blog post. They don't know who to reach out to for help, they don't know who to turn to, and usually they're on their own. So the difficulty with user engagement is that users engage with your content directly and with you indirectly, if at all, and if they do engage with you indirectly, it tends to be a synchronous in nature.

It's either a Twitter mention or an email or something like that. You rarely get that unless you open the channels on purpose. You rarely get that direct communication with your users and you certainly almost always have to deal with it asynchronously and out of the context of the original in piece of information that the user has consumed.

Users don't always know how to communicate questions or feedback. Sometimes they just get an error and they don't know what that error is for and they don't have time to figure out what that error is for, and all they have time to do is copy the error, paste it into your GitHub issues or stack overflow and say what's wrong with it? They don't necessarily have time to research it, and we as developer relations engineers have to be able to accommodate that and have to be able to deal with that because those are users, those are just as valid users as the users who are able to research and are able to figure out what's going on in their own the spectrum of user skill and time. You'll have users ranging from brand new to development in general to full knowledge, and they just want to know what this one API calls argument order is or what the particular argument name is.

They'll need to know how to get them where they're going without getting in their way and without leaving them lost. So those are two different scenarios. When you have a power user who just wants to find out the name of an argument, you don't want to get in their way with a bunch of tutorial popups that push the API documentation below the fold, that's going to irritate those users. On the other hand, if you've got a brand new user and you just dump them right into the documentation with no other content or access to other content, they're going to be lost. They're going to be like, okay, I kind of know what an API is, but I don't know what this API does and oh off an O off and oh no, what am I doing? So you don't want to leave them lost. Your content needs to be navigable regardless of skill level.

Your content needs to be navigable, and I don't just mean your documentation, I mean your content as a whole. If you make a video for your product, people need to be able to find it other than searching YouTube for your product, you need to have ways to connect your content online, and there's lovely ways to do that to prevent content from going to waste. First of all, because if you take all this time to make this content and then no one is able to access it, what have you done with your time really? And also you want that to be navigable so that your users can explore your product more freely and also possibly find features that they didn't know you had that they were looking for or find benefits that your competitor doesn't have that you have. There are a lot of different reasons that making all of your content navigable is extremely important, and I don't just mean the docs.

So how do you use the similarities of education to your benefit? You want to create content that engages different ways of learning, and that's part of the fun part I think, of creating content is finding new and fun ways to make content. If you've ever done streaming for developer relations work, it can be a lot of fun and it can really, you can communicate with your users and answer their questions in real time with what you're doing. It's really fun if you haven't done it yet. I stream hardware and software on my own time for JavaScript robotics, and it's so much fun to be able to answer people's questions in real time and deal with that in a certain way. And it's also really great to engage kinesthetic learners by creating tutorials, things that they can get their hands into, things that they can try and build and break, and that's how they're going to learn.

It's fun to create videos for audio and visual learners. So you want to create these different types of content, not just written and not just videos even. You want to go outside of that box. You want to keep your documentation and your content centred around your product, but you also want to reach out to technologies related to your product. This is more of a marketing strategy than it is about education. No one's going to look up your API specifically because they want to learn about a technology. They're going to look up a technology and then find your company. So this is a completely different scenario and that's why you want to write videos, write content that is not branded, that is focused on technologies around it that happens to link back to your product and bring those users in.

It's also important from an educational standpoint because when you're reading a textbook, if it comes up to a subject that could use more explanation but isn't inside the scope of that book, what do you see?

You see a footnote, that footnote goes to another book or it goes to a piece of reading on the internet or it goes to somewhere else. Another piece of content that you can use to expand your knowledge. So writing videos about technologies that surround your product also help your users learn because if they're missing a basic piece of their context in order to use their product, if you've created something that will help them game that context, they will be more likely to use your product and they will be less likely to go off of your content, go off of your page and then have to find their way back. You want to consider common pitfalls and questions in order to prepare that information in advance. Partially because of the way users cannot synchronously ask you questions or users have trouble finding ways to ask you questions, you want to prepare common questions.

One thing I like to do is I like to hand over a product tutorial to someone who's never used the product before and see what they ask, see what they have to say and kind of build in the answers to common questions and pitfalls in advance, but you can only do so much to be fair. So the refresher for the main types of learners, there are lots of different types of learners, but these are the three that I say the most of auditory, which is hearing visual site and kinesthetic, which means I want to build it and break it, and that's how I learn. I personally am kinesthetic, highly kinesthetic. I can't for math, for instance, if I'm not doing the types of math problems that I'm supposed to be doing, I'm not going to learn it. I have to break it and do it wrong a hundred times before I can start to do it right.

But anyways, everyone's a different type of learner, so creating content that engages all you've got, your usuals, your written docs, your tutorials, your videos. Again, you should reach out, do streaming, do webinars. Twilio has Twilio Quest, which is a game which is really fun and great for kinesthetic learners who want to try something and build it and build it fast. So there are a lot of different ways to create really fun content that can be fun to make too. If you're looking for a way to spice up your content creation, start making something that you hadn't tried before, moving into related technologies, it pulls the users into trying to learn about related tech towards your product. They may not know you exist, but if they see a video of yours for related technology that, because for instance, let's talk about OAuth and auth Zero, right?

If you're trying to implement OAuth in your own programme, I'm sorry, and also you're looking up how to do OAuth and you might run across an auth zero video about how to do a particular piece of OAuth, then you find auth zero and then you think to yourself, oh, I don't need to implement OAuth. There's this product that will do it for me. There's a really interesting chain and it can work the other way too. Like I mentioned before, say you're using auth zero and you're like, okay, but what do I do with this J jwt? What is it? What can I do with it? What does it stand for? They need that information about JW T so you have that information available to your users and your product will be easier to use, creating a better developer experience.

I find that creating technology videos for related technologies help me keep a good eye on the changing tech around our product.

Tech is always changing constantly, and it's one of the ways that I've found that's the best for me to keep up with what's going on is by creating related technology videos to the product that I'm working with because I have to learn it so that I can create the content, right? It's a really handy tool to have as a developer relations person, so protecting questions and pitfalls. You want to make sure in your non real-time content to conclude the answers to common questions, how common, it's kind of a wibbly wobbly. You kind of have to go by ear or go by eye on how many common questions in pitfalls, whether to include a footnote or whether to include the answer directly in the post or video or whatever you're looking at, but you want to be cognizant of when you do that and how you do that and why you're doing it.

You want to add them in a way that don't block your power users, but give your new users a path to follow. Know when to use a footnote or a link to another piece of content versus adding another paragraph to explain a basic concept in an advanced article. Know when to do that, and unfortunately, the best way to do it is to just kind of get an eye for it, an ear for it, and just try it with people who have not used your product and people who have used your product for a long time and ask 'em. That's something I found a lot of people don't do and try it. It's fun.

Make sure to keep these up to date, and I know that's a very common statement is to keep your content up to date, but really make sure to keep your content up to date. I would rather have no content than outdated content because it can really confuse new users and it can really upset power users if say you change your API and they're using the old API and you get a bunch of angry tweets at three in the mornings, they're in a different time zone. That's fun. You do the work to keep your content relevant. That's part of our jobs. That's how we do this is we have to keep our content message in a relevant sphere to where developers are looking in order to make sure that we're helping our users use the technologies that then sell our products. So how to navigate the differences. Find as many ways as you can to allow users to contact you in direct A manner as possible.

You create experiences that allow power users to jump ahead and you make sure that the time your first hello world is as short as possible to get new users in the right place quickly.

So finding ways to engage your users, create open spaces for users to contact you. GitHub, slack message boards, drop ice GitHub. Make sure to allow your users to contact you. Yes, it's still asynchronous and yes, it's still not the best way, but it's still something. And so you want to make that prominent and you want to make that one of your first things your users see is you have feedback. Do you have questions? Sure, it feels like no one clicks the feedback links, but people do click the feedback links. If people do file GitHub issues, and sure it's not everybody, but it's going to be a heck of a lot fewer if your GitHub issues aren't findable, if your GitHub repositories aren't available.

See how users solve each other's problems. Look up stack overflow questions. Look up on the internet, how to solve common problems with your product and see how they solve each other's products problems and let that advise your content.

If you see a lot of your users, you're posting stack overflow questions or answers or comments about a specific topic, even if it's just a related technology, maybe it's time to make a piece of content about that related technology or maybe it's time to update the content around the problem that's being had. Create power users in your community and enable them. It's absolutely worth the extra time to do this. It makes them feel better. It causes them to help solve other people's problems, and it really just feels good to connect with your community and have a group of people that you can say, Hey, we're about to release this new feature. What do you think of it? What do you think about this content that we're releasing around it? Having that pool of power users is a super great tool and it's a symbiotic relationship.

You're taking the time to empower them, but they are also a valuable resource for you because they have shown that they are willing to listen and willing to give feedback so you can use that feedback and use that time that they're willing to put into your product.

Building a cohesive experience for your content means keeping a goal in mind that each piece of content fits into, you want to have a cohesive experience and you want to have a full experience. So that goes into the related technologies thing. Your documentation and your content should not look like a line of here's where you start with our product and here's where you end with our product. It's here's where you start with our product and here's the technologies related around the start of our product and here's the middle, and here's some more technologies that are related to our product. And then as we get to the end, there's fewer related technologies as you get into each niche, but there might be some forks, things like that. So you want that cohesive idea. You don't want to just create content for the sake of creating content.

You want to create a content plan around your product and then move forward from that. You want to build paths. You want to think about the happy path for each individual user, not literally each individual user, but create personas and think, what is the happy path for someone who's just started development and wants to use my API? What is the happy path for an expert who just wants to look up a piece of reference? What is the sad path for a new user? When do they get stuck? When do they get lost? Curate and actively hone your paths and overall vision regularly in order to avoid a tangled jungle of mess and videos and code and very angry users.

It takes a lot of work to curate a lot of content, but that is what is necessary, especially when you think from an educator's perspective.

Educators spend a lot of their time when they're not actively in the classroom training and honing their context, refiguring out, okay, what do children need to learn? What do adults need to learn to be able to do this or function in this capacity? They are honing their knowledge, they're updating their information, especially teachers in fields such as science where we're learning new things regularly. You have to be that same person. You have to look at your content and go, okay, is this outdated? Am I using an outdated specification here? Is it time to refresh this post? Is it time to refresh this video?

It takes work, but it's worth it.

So all that leads up to building content that invites users to learn. Never leave your users hanging. Always have another piece of content to consume, even if it's not yours. Always have something to give them to say, okay, here's what's next. Even if it's not yours, have real calls to action, not just sign up for our newsletter. I'm sick of seeing sign up for your newsletter. I'm probably already signed up for your newsletter and I'm probably not going to sign up. Again.

Make yourself available to users for feedback. Make a Stack overflow account. I know, I know. I'm aware. I don't like it either, but make yourself a stack overflow account. Make yourself a Reddit account. Make yourself readily available to your users. Open up your Twitter.

Yes, that sucks. If you're a non-white male, I'm aware, and if you do need to close it for self-care, please do.

But in general, for DevRel work, I try to be as open as possible, but I understand that's not necessarily possible for everybody in this room because sometimes harassment is a thing actually all the time. Harassment is a thing, sometimes harassment is a thing for you. So give users projects to explore, tear apart and modify. Treat demos like Legos. Make the modular and easy to dissect and easy to augment. Give a user a box made of Legos and say, okay, this is our product and this is how, this is the basic use case. And then they go, oh, cool. I could add a tower here and I could add a moat here and I can add an alligator piece.

Those are always cool, and then I've got this new app, and you're like, great. That's exactly what we're looking for here. Post that new app onto our documentation so that other people can tear it apart and make new things. So you want to encourage repositories of demos that solve many common user problems, and you want to encourage users contributing to your docs, open source, your docs. There are very few scenarios I can think of where open sourcing your docs is not a good idea. Very few. So open source your docs and allow users to contribute to them. You'll find a lot of typos that you missed.

So I'll give you an example. I would say this is tooting my own horn, but it's not. I actually didn't do this. It's the company I'm for, but the developer experience team actually built out the CloudFlare workers documentation, and I want to show you what I mean when I say happy paths, things like that. So on our left here, we've got everything from tutorials to reference. So if I'm a power user and I just want to know kv and I just want to know what web standards are available to me, I can just click through and get that content quickly. However, if I'm new, one of the first things you see is our template gallery right after the quick start, of course, but the template gallery, I'm really proud of. So this is all of the possible, not all literally, but as many of the possible scenarios that new users could face that want to write a worker as possible in a copy and pastable format.

And I literally mean we can just click to copy and paste it into our worker. We've even got what are called boilerplates, if I can scroll down here, which basically this uses our CLI tool. You just copy the CLI tool into your terminal hit run and you have the project and you can run it. The other thing I love about the snippets and the boilerplates is underneath each you've got a learn more.

So that one's a little bit sparse. Lemme go to one that's a little bit more robust. There's router, we'll learn more is good with router. So this is a tutorial around our router. We've got more information about how the code works. We've also got a link to the GitHub right there, so you can go see this, what the, of course this breaks. Now lemme try the other GitHub link. Oh, it's not there.

Oh, right. I just clicked this GitHub link. Okay, so it goes to the code. So all of our templates are open source as well, so you can fork this and mess with it. You can also demo it on the website. So if you want to see how the worker works in real time, so giving users as much capability as possible and getting out of the way of power users, I think the CloudFlare documentation does a pretty good job of that.

And then we always have a new piece of content for you to explore, even if it's not necessarily ours. And again, we just get out of the way of the folks who need to just look up a particular API reference or look up a particular Wrangler command. So I have a brief aside, if there are any hiring managers in this room, I need you to hire someone different from you. I don't care if it's gender or sexuality or race or something. I need you to hire someone different from you. And if you make the joke of well cast, that would mean you hiring a cshe white man. I might just break the code of conduct. I get it.

I know what you mean. A lot of people are different from cshe white men, but what I mean is there are an awful lot of problems with diversity in DevRel and in tech in general. And so if you are a hiring manager, and I call it a challenge because I know it's a challenge, it is hard to find someone different from you and hire them. It is hard to find someone from a minority group or a different sexuality or a different gender identity. I don't care. Do it anyway. So yeah, thanks.

You don't have to applaud for that. That's just basic human decency. So that QR code leads to the GitHub repository that contains the slides. I didn't have any code for this presentation, so it just has the slides. I'll also tweet out a link to the slides, Carl Sagan, and I think you're awesome. I can be found in node botanist. That is my Twitter handle, my GitHub handle, my LinkedIn handle, my everything handle, and you can email me@kascloudflare. com.

If you have any questions about CloudFlare stuff, you can get my personal email from me if you want to email me about not CloudFlare stuff. So I think I'm way under time, but you know what, that's cool. You get a few minutes back in your day. So you know what, thank you so much and have a great day.