1. Library
  2. Arrow Icon
  3. Breadcrumbs and Carrots: Optimizing Developer Onboarding
  • Product
AUG 2, 2018 - 46 MIN

Breadcrumbs and Carrots: Optimizing Developer Onboarding


In this Heavybit Speaker Series presentation, Brian Douglas, GitHub developer advocate explains how to effectively onboard developers to your service, product or platform.

  • Introduction
  • Breadcrumbs and Carrots: Optimizing Developer Onboarding
    • Direct Vs Channel
    • Developer Onboarding Framework
    • Netlify At A Glance
    • Qualifying Developers
    • Channels At A Glance
    • Encourage & Teach
    • Deploying With Netlify
    • Testing Twilio
    • Deploying With GitHub
    • From Zero To Sixty
    • The Fullstack Tutorial
    • Reference Materials
    • Lessons Learned
  • Q&A
    • Measuring Task Performance Time
    • Impact Of Open Source
    • Onboarding Finish Line
    • Recommendations For Multiple Projects
    • Controlling Onboarding
    • Successful Community Engagement


Who's excited to talk about onboarding? Awesome. You're in the right place. I'm going to talk about optimizing developer onboarding. As Malia mentioned, I worked at a Heavybit company and had a lot of experience in thinking about this as a developer, and now as a developer advocate.

I put a lot of thought in this talk. I'm very recent to GitHub, in the last 90 days, 3 months. I thought it through. It's a lot of the conversation I've had internally at GitHub about the onboarding experience for our developers. It got me thinking.

Developers are here because they found you.

They found your product, or you did a lot of work, or the marketing team did a lot of work to expose your product somewhere.

They've already qualified themselves. They've figured out, possibly, that your tool can work. Our jobs are really just trying to string a bunch of "yesses" into our products. That way, people can move on and start shipping.

Before I go directly into the actual talk, I want to talk about an onboarding experience that I had with my son. My son is 4 years old and he's really into LEGOs. This model is a LEGO we got him for Christmas. If you notice the box, it's ages 5 to 12. He's below the mark for who is supposed to use this, but that doesn't matter because he's really, really inundated with LEGOs. LEGO does a really good job.

I saw a documentary on Netflix over the weekend, so part of the reason why I threw the slide in there is because I was thinking of the onboarding experience for LEGO. Documentary is called, The Toys That Made Us. Is anybody familiar with that documentary? It's on Netflix. It's probably going to show up in your recommendations soon, so just get ready for it. Definitely watch the LEGO version.

LEGO has been around for a long time. They originally got their start with building wooden toys during a time when we couldn't make metal toys in Europe. They went to market with building an opposite toy that everybody was doing and came into fame with these little bricks that you can combine and put together.

What's cool about LEGO is they have stores. When I bring my son to the LEGO store and he picks out a LEGO, I bring him to a certain section of the wall and I tell him, "You can pick anything from this section," usually the section that's $20 dollars or under. We stay away from the Star Wars side for obvious reasons. That's pretty pricey.

But what's cool about this is that he can look at the box as a 4 year old who can't read, and look at the box and say, "I want to pick a LEGO that's interesting to me. Something that I would be excited to work on with my dad, or sometimes my mom," if I'm not around. She always beats me to the punch, where they buy LEGOs. I'm working on that.

So, this is the pizza van. My son is very interested in trucks and vans, and cars, and any of those nature. He is also really interested in pizza. Right off the bat, he's already qualified himself to say, "This is the LEGO for me. I don't have this at home, I want to build a pizza van at home." He can also get the idea of, really briefly, what sort of things he can build with it. One, he's got a van. The other cool bonus is that he could build a pizza delivery bike as well and deliver those pizzas. Or, those 1x1 LEGO flat pieces.

He can qualify himself.

He pretty much qualified himself into building this LEGO. The other cool part about this is LEGOs comes with really nice onboarding instructions. Right off the bat, you could check out to see what you might build. You could flip over the box to see everything within that piece and those themes. You can also see what is in there, if there's something that might go with this, or even grab from the store before you leave. You can figure that out.

For example, that set is about 14 bucks. So if we had a budget of 25 bucks we can find something close to 10 bucks within that theme. I really like LEGO too, as well. It's because you don't ever get lost with LEGO. Who makes LEGO? Am I speaking to a bunch of experts?

Have you guys ever built IKEA furniture? It's the same concept. IKEA does this very well as well. You have the first step which shows you what might be in the box, how many counts of screws that should be in there. As far as LEGOs, how many pieces. 4x1s, 1x4s, 2x4s. Then each step has one more piece that you add onto it.

So there's a puzzle that's to be made. What my son likes to do is smash the LEGOs, and we can always start from step number 256, or 25, or whatever and we can build this thing. And we can be really proud of what we've done.

I wanted to talk about LEGOs because I want you guys to think about your product and what sort of path your developers have to onboard onto your product. If there are things missing, things that could be clearer. I'll talk about my personal experience as well, but I'll talk about what I really talk about, which is myself.

I'm Brian Douglas, I mentioned that as well. I'm @bdougieYO on Twitter. I started my career as a developer, specifically with Netlify I was a developer for a good year, working on the front end UI of that product. I was asking a lot of questions. We were a team of 5 at the time when I started so all the questions I had to answer. Then I migrated because I kept answering and asking questions about our product.

I became a developer advocate because I was really excited about the product.

I originally started as a customer and then joined the team as an employee. Now I'm super excited to work on the front end UI and technologies. So, I'm a developer advocate, previously at Netlify and now I'm at GitHub.

GitHub is unique, because you guys are probably thinking what sort of advocacy GitHub needs. They own source control repositories, at least in this bubble which we call the Bay Area in Silicon Valley. But there's a lot of needs that GitHub is trying to push on.

Breadcrumbs and Carrots: Optimizing Developer Onboarding

I specifically focused on integrations within the marketplace. I am building an entire "infrastructure," or program, to onboard developers to build their own integration. A lot of tools that are represented in this room could potentially be an integration.

I see some companies that have integration on GitHub. All these tools that we're talking about represent developer tools. These tools are really good at onboarding developers. Because if you don't have developers for your tool then you have no one to use your products.

Direct vs. Channel

It's very important that we think through as far as what we're giving the developer, what we're bringing them onto our platform for and what are the different ways we can get them engaged. The title of this talk is about carrots and bread crumbs. I wanted to find that real quick.

"Carrots" would be more like, you're leading your developer directly on your platform. Leading them through the sign up flow, onboarding through there. Some information, the post sign up flow, if there's some sort of "Getting Started" guide. Is that serviced somewhere once you've signed up? Or is that serviced before you signed up? What process is at work for your tool?

"Breadcrumbs" would be more of the channel. These things are off platform, these are things that can be developed through community. I'll talk about that in a moment, but first I want to lay out the framework. I'm going to go through a lot of examples of companies that are developer tools that are doing stuff good.

Developer Onboarding Framework

I'm going to really focus on the positives, and I'll tell you why in a moment, but first, the framework for our discussion in our talks. Think about your questions as well. Messaging, first touch. That's number one.

Two is going to be around speed and success, we're going to talk about how fast you can deploy your thing. And then three is going to be met reference materials. That's going to look in the form of these three questions. We'll go through each title. If you didn't get each one yet, we'll go through each one of them slowly, and each company.

These questions are really the questions that I was asking myself when I was working in the UI at Netlify, all the time. One being, "How easy is it for someone to get an idea what your product is?" It was something that, as someone who was a customer first of a product, and also a developer, I had a different lens of what people should think of our product.

I think everybody at Netlify hit a pinnacle point of like, "We get it. Why don't they get it?" We had to step back and be like, "Oh. It's because we don't know how to talk to our developers." That's where I became the one-man-show of developer relations at Netlify as an advocate.

Second thing, which is one of the things I've really enjoyed about Netlify, and I do enjoy at GitHub as well. How long did it take to go from zero, you had just figured out what this product is, to deploying or shipping? The focus feature of your product, how long does that take? Is it seconds? Is it minutes? Is it hours? Is it days? Is it weeks?

I like to reference this one. The crypto-currency space, like wallets and stuff like that, and Bitcoin. A lot of that stuff, when you get on these platforms it takes a week for you to get registered and confirmed. A week is a long time for someone to sign up and request access to your program and then a week later, two weeks later they remember, "Oh yeah. I signed up for this thing. I'm no longer excited about that."

That's something at Netlify I really worked hard to make sure that we solved that problem really early on. I do a couple of talks about that, how me and my designer developed our sign up flow. Those are out there in the wild. You can ask me about those later.

And then finally, how easy is it to find reference examples of someone using your product? If I'm a Ruby developer, is there a Ruby example? If I'm a JavaScript developer, can I even write anything in this?

Is this going to be anything useful to me?

It's good to have examples out there in the wild for people to find, as well as on your platform. I go through all of that. Because we're going to focus on the first section, which is Messaging and First Touch.

I've discovered what your product is. You're selling widgets, or you're deploying APIs, or whatever you like to do at your companies. You're trying to ship and focus. How easy is it to figure out what your product is, just from first look? Go into your marketing page, your home page, your not sign-in page. What does it look like?

Netlify At A Glance

I'm going to talk about Netlify because I spent a good amount of time on there. They recently just shipped a new marketing site that came out a couple of months ago. I spent a lot of time answering questions and giving my feedback on this, and then I left, and then they shipped it. This is what it looks like.

I think it does a really good job of relaying exactly what Netlify is trying to do. So, my first question is, "What is Netlify?" Right here highlighted is exactly what Netlify is. Netlify builds, deploys and manages modern web projects. Right off the bat if I build/manage web projects, whatever those might be, then I might have qualified myself and said, "This is what I need to do. Click that green button that says Get Started for Free."

They also have a nice little step. We went back and forth on where to put this. Above the fold, below the fold. It's not UI but it gives you the three step process of what happens once you've signed up. It might be a little bit small. Hopefully you guys get the slides after or before, or if you're sitting close enough you can see.

One is going to be selecting your git repositories. GitHub, Bitbucket, GitLab. More than likely you're a part of one of those tools. Right then you've qualified yourself and said, "I'm using one of these tools for source control," so I might have qualified myself and said, "Netlify is something for me."

We have actual command line tools that you can select from like Jekyll, and Yarn and NPM. Off the bat we're helping you qualify yourself and say, "If you're familiar with these tools you should be using Netlify." Then finally we have a deploy process.

At Netlify, they're really trying to hark on the point that they deploy projects and that you eventually can manage them and do some other things. Post log in they have other breadcrumbs that I won't talk about, of steps that you could learn off platform and on platform of how to use the product. New feature releases happen on product and you get nice little things called DocBlocks.

I'm going into a little more detail than I wanted to. I'm going to mention as well, this is also clear for marketers but not as clear for developers, you want to have a clear call to action.

If you want someone to sign up, have the sign up button above the fold.

Not below, down the stream so someone has to scroll and read all the information. Like, "I saw Netlify on Hacker News," "I saw a blog post," "I saw an awesome @bdougieYO talk somewhere, I want to go to that site and just click 'Log in' and then figure out on my own." I am really bad at logging in with things and trying to figure out on my own.

I hardly go to support to figure things out. I feel like I should be smart enough as a developer who has done this for quite a few years, I should be smart enough to be able to figure out what this product is and how I can use it. If I can't do it on my own, sometimes I'll just take myself out of the product.

Which happened to me with Netlify, originally as a customer, years ago when they first started. I deployed my first site but I could I couldn't really tap into all the new features because there wasn't a clear content around it. I spent a good year as a customer and deploying a site auto-magically and never returning to the platform, because I didn't know how to do anything besides use the Netlify.com site.

Qualifying Developers

So my concern and something that all your potential customers and developers are coming to your site is, "Am I qualified to use this?" You should very clearly answer those questions. One thing you should also think about too, which is not pictured. You should also identify what your ideal developer is.

For a long time my name kept coming up as the ideal developer. I was a serial deployer of new projects all the time. I was trigger happy on new projects, I always tried new technologies on a regular basis, and that's what we wanted at Netlify because we wanted to build a bigger user base.

We had to be a bigger user base and more than just specifically Jekyll builders, or specifically React developers. We had to also cater to some of the legacy developers for front end code as well. So identify that, and then identify if those persons will qualify themselves out or in to your product. We want more things that help that too.

We put these, it's a marketing term we call "moose heads,", which you guys might be familiar with. I wasn't familiar with this until my designer said it out loud and I was confused what he meant. Essentially, a bunch of companies that represent our customer base. We want to put those there.

Some of those companies are a representation of where other companies want to be.

If we put those companies, the goal is hopefully get companies and developers that represent those companies to also come and sign up. This was super helpful, because I did a lot. As developer advocate I was out in the field speaking on a regular basis and essentially doing pre-sales out in the field.

I was able to point to our moose heads and if those potential customers who approached me at a meetup or a conference match that spectrum, or checkboxes, then I could just easily forward their email over to somebody else so I didn't have to deal with them. Now, let me get off the Netlify train for a bit. I'll bring them up a bit.

I just want to bring up really quickly Twilio as well, who does a really good job of initial first glance. I won't show their actual dot com marketing site because I think it's pretty self-explanatory. It's almost to the T. Moose heads, examples.

They have code on their site as well which helps qualify people, "I can use this code somewhere." It might be JavaScript. I could switch over to Ruby. What they do after you've signed up, and a lot of companies should be doing, is they give you right up front and center in the dashboard is "Getting Started."

I've heard for years, and it's ironic because I used Twilio years ago and I had an account. I couldn't figure out what my log in was so I logged in again. I've used Twilio for an actual legit project. I heard so much about how Twilio you can send a text message directly from the documentation.

So what I did is I logged in and right in the "Getting Started" block in the dashboard, I sent a text message and it was a pretty great experience. I was directed directly to that point.

This direct onboarding should be in your mindset.

I'll just cite Netlify one more time. Once you logged in to Netlify you were presented with a blank screen. More than likely if you knew what you were doing you would just go ahead and deploy a site. We built something, and I'll talk about it in a moment. I'm jumping ahead a little bit. We built the onboarding flow to identify some of the examples of what you would want to do at Netlify.

Channels At A Glance

We did something very similar. So far I've talked about just the carrots. The direct, on platform. I'm going to talk about the channel stuff as well. Channel is going to be programming language communities, frameworks, conferences, tutorials, etc. Anything off platform. CLIs is another one that's really popular as well.

A lot of people have a UI, but they also leverage to CLIs pretty heavily mainly just due to bandwidth. So if you have a smaller team it might make more sense to focus on your CLI and then hire a front-end developer later. My first introduction to GitHub was not on GitHub.com. It was on this cool little site called "Try Git," tryGit.io and tryGitHub.io. With these two little tools someone told me git was the thing you should do with managing your source code.

I was told, so I went there. Outside in the channel someone told me, "Go to this site." It wasn't a GitHub site. Eventually I learned what git was. I figured out what source control was and I was able to eventually know what I was doing. What's cool about this is, this is not GitHub. This is Code School, if you're familiar with Code School.

Code School got bought by Pluralsight which literally just went public a couple of weeks ago. Good for them. Actually, great for them. I don't know how the story goes, but either GitHub approached them or Code School approached them. They had this curriculum. GitHub sponsored it. So now GitHub's name shows up on this tutorial, looks like they did all the work.

This is a really, really good onboard experience for new people to GitHub. It also helps qualify potential GitHub users, because GitHub really is a power tool. It's a tool that people were using for years and GitHub came in and basically put a whole UI and interface on top of it.

That's been their go-to market strategy by adding a UI to this power tool. When people get to GitHub.com they can figure out, "Maybe this is not where I need to be," and then it could get pointed or redirected to a page like this, out in the channel where someone can teach.

Speaking of channels, I want to go back to my son real quick as well. The only reason my son is really into LEGO is because of these two movies. LEGO Movie came out the year he was born. Coincidentally my son's name is Emmett. The main LEGO guy in the movie, his name is Emmett. So he really connected with that. That's his go-to movie, and because it's his go-to movie he likes LEGO.

He's premature, he's only 4. He's below the limit of regular LEGOs. But he likes it, and LEGO's been the introduction to Batman for him because we don't let him watch Batman and superhero movies yet. Because they are a tad bit violent. You guys parent the way you want, but we don't let him watch that. But LEGO is a really good introduction to those characters.

And because of that, now he wants LEGO and he wants LEGO all the time. And it's really approachable for him. He also loves watching Twitch as well. He watches all the LEGO games as well. The ones that have no commentary. Again, you guys parent the way you like to parent. Which is really cool.

I had a very similar experience too. I was told I had an idea for a startup years ago. This is why I code. Someone told me, "Use Ruby on Rails. It's the easiest way to get started." I was like, "OK, whatever. You tell me whatever it's supposed to be, so I'm going to use Ruby on Rails." Rails is cool because it's one way to do everything, for the most part.

At the time, about 4 or 5 years ago, it was the one way to learn the Michael Hartl tutorial which is directly on a Rail site. Which is not on GitHub, it's not on Heroku, which is the other place I was told to deploy. I was given one specific channel of how to deploy my site, and host and do source control from my Ruby on Rails site. You guys are more likely familiar with Heroku.

But years ago this is what the site looked like. So as a brand new developer this is what I was introduced to. This is pretty daunting, because I quickly qualified myself out of this product. It was not something I knew what was going on. But what was cool is with the Rails tutorial, this is what I was presented. It's small, but essentially these are just a couple lines of code of logging into Heroku, which then brings you to the site.

And then you go back to the command line and continue on your way to push to Heroku. My interaction with Heroku was never on Heroku.com. Other than my one time downloading the Heroku CLI and then also making sure I had my keys and stuff like that proper. Now, this is a good and bad, something you want to think about.

Every interaction was off platform in the CLI and then I would have to leverage other portions of the channel.

So when I needed to do email and I had to do a sync-er add on, then I would go to Heroku to enable my sync-er add on. Or else I would try to figure out how to get a command line, which I failed miserably. I had to go to the documentation in dot com to see that. But these are all interesting use cases of off platform and on platform, all things that you should probably think about. These are all really successful.

Encourage & Teach

Consider your first message and your first look of your product, and identify whether or not you're using descriptive copy. All the content on Netlify and on Twilio pushes you. Twilio says literally, "Get Started." So if you're confused about what happened, what you did last weekend. If it happens to be a week between you signing up and doing this. Then you have this script of copy pushing you towards actually deploying or using your first feature on that product.

Encourage usage as well. What's really cool is having some sort of, don't go too crazy, but having some sort of in product chat. Or documentation, or bubbles. A lot of companies will just do, "Hey, you signed up but she never did 'X,' or you never did step 2, or step 3." Sometimes that will come through an email. Use your best judgment.

The companies I've worked at, we've had some issues on how noisy we were. So you always want to gauge. But I think what's really important, just talk to your customers. Talk to successful use cases. If you have a @bdougieYO that is on your team, identify that and find out what your ideal developer is so you can cater to that. And then finding leverage.

This is my first point. Leverage the channel to teach and qualify developers. If someone's not up to par to use your product, then you need to find the channel for them to go to. You don't want to disqualify people from your product if they can be a user in 3 to 6 months, or even a weekend of just a little bit of reading.

Deploying With Netlify

Second point is "Speed to Success." How fast does it take from you to see the product and to deploy it? This is my favorite part about Netlify because it takes literally seconds to deploy a Netlify site. I have a .gif that times. Obviously I'm experienced using Netlify so I know what buttons to click.

Once you've logged in, you're presented with this "Connect to your GitHub Repo." I use GitLab or Bitbucket as well, but you should probably use GitHub. I recommended that. You point to your repository and then you click this big fat "deploy" button. We have heuristics to identify based on your code. You should use these build commands.

And we just missed it, I should have stopped it, but it was 22 seconds it took. So imagine someone who's never seen Netlify, just times that by 3 or 4.

That's around a minute of someone's first look into the product.

And this was the first project that our designer and I worked on, which is the onboard flow. Which is great.

And again I mentioned I have a whole other talk about this somewhere on YouTube. You can definitely check that out, about how we work together as a designer and developer. But that's amazing. We have seconds to deployment. Now we can go to market and say, "You can use whatever you want but this will take you only seconds to do." And then we can add the value on what else you can do.

I was able to take this idea of deploying the seconds, and create these things called deploy templates. Every time I had an idea, or we had a new feature, I could create a template. We lifted this directly from the port of Heroku.

They had these buttons you can put in your repo or put out in the wild. And you just click the button, and you can clone, and push, and deploy that site. So we did the same thing with Netlify, which worked very well.

Deploying templates was a great way for me to create a bunch of content. I could do full-on tutorials, screencasts. And before I do the screencast tutorial I could mention, "By the way. Just click this button, deploy your template, and you're good to go." This is an example of my restaurant template. I'll zoom in real quick to the actual deploy button which is on the GitHub README as well.

Because we had templates we could talk to product marketers or just marketing in general, and then we unleashed an entire market which was designers just from the strategy as well. So it was awesome and one of the proudest things I did.

I'm spending a lot of time on this but, you can definitely check that out. I do have a YouTube screencast of me going through the process of building your own restaurant website, and how I use a deploy template. It's also exposed in blogs as well.

Testing Twilio

Twilio, another one. My first time into Twilio I sent a text message to myself just from copying/pasting code directly from the documentation. From the "Getting Started." That was a good feeling. I was able to walk away with a text message. Not too big, but the fact that I can have an interaction with an API I had never seen or touched very often was pretty good. Now these are all direct.

So I'm going to talk about channel real quick, which I quickly passed by. GitHub's focus really is around the developer and source control. So we have two different products. We have a dot com, which is what most of us are using in the room. And then we have a marketplace, which is a way for companies and developer tools and also developers who build integrations on the GitHub platform to service to other developers.

So we have this marketplace. It just went over a year, so marketplace has been around for a year. We don't do a ton of promoting around it. We had a lot of internal things we had to fix to make it work but now we're going full bore on this. We have me to promote this as well. My whole role is to get more marketplace integrations and help developers build proper GitHub apps on a GitHub platform.

Deploying with GitHub

A lot of people do a lot of stuff like that. The question is, "How fast can I deploy an app to GitHub?" If I had integration, if I created a cool tool, I'm looking at Apollo's team over here. They have Apollo Bot which is a GitHub integration where they can enable open source maintainers or collaborators to have features within their repo. So that's an integration that would normally take another user, or another admin to do stuff.

They could just enable this bot to do all those sorts of things. And the way they built that actual bot was through Probot. This is my "Deploy to Netlify" button for GitHub. We have "Create Probot" app which is mirrored right off of "Create React App." And you can literally deploy a GitHub integration within a handful of minutes. We're not talking seconds, but at least within 10 to 15 minutes you can have an integration at GitHub which is pretty awesome.

So that's more of the channel. This is an open source project which was started by a GitHub employee and taken away by the community. It's got its own legs and it's become a really good opportunity for us to talk about something else at GitHub, outside in the channel. A couple key takeaways from this section is faster onboarding is always going to lead to better engagement.

From Zero to Sixty

The faster someone can walk away with something that they're proud of, something they've used, deploying sites or Heroku. That's a good feeling that I got originally. Identify what your customers come back and say, "This was great. It was a great experience.". If you're not getting a lot of customers coming back and saying, "This was a great experience," then you might have to do some digging and do some interviews in figuring that out.

Also, identify the way to package and embrace the channel. If you could package an idea or a feature and then put that on Medium as a post or tutorial, or enable your users to write that sort of content, that's another way to unlock onboarding in the channel and even adopt users as well. This seems obvious, but it doesn't seem obvious. Again as a developer I wasn't really thinking through a lot of things. You want to give developers the reasons to return to the dashboard, return to your product.

Finally, the last section is all about reference materials. I'll go quickly, not too much content on this. But again this is like referencing what your product looks like before they adopt your product. So, develop it at GitHub.com. This is the second half. This is not GitHub.com, this is API integrations. All that content, GraphQL is another thing.

GitHub's newest version of GraphQL is on this page, and within this page you have different ideas and workflows and quick-starts of how to use GraphQL. And then here we've got embedded our GraphQL explorer. This is a cool experience. This is an experience that Stripe does very well, where you use your keys within the documentation.

With the GraphQL explorer you sign in to GitHub, and you could access your GitHub content and GraphQL and explore what that looks like. On top of that we've got lab.GitHub.com, which it's very new. It's within a month old but this is direct learning of how to use GitHub on GitHub.com. You just essentially just sign in, it opens up a repo for you and it tugs you along.

So if there's some content that you don't quite understand. Open source, pull request. This is all stuff that more than likely goes over my head.

This doesn't go over my head, but the onboarding experience for that sort of thing goes over my head because I've been doing it for so long.

So we built a tool to redirect users to learn how to do some of the basics again. Apollo, Prisma. They have their channel started by Graphcool. Prisma is GraphQL. GraphQL is a newer way to interface with your database. Which you guys are all familiar with, for the most part.

I think a lot of us in the room represent companies from that. The problem with GraphQL is it's a new technology. The barrier to entry is literally education. You have to constantly teach developers how to use GraphQL on a regular basis.

The Fullstack Tutorial

What's cool is HowtoGraphQL.org is a thing. It's a channel. It's a channel for companies like Apollo and Prisma to surface their curriculum and encourage users to contribute back to it of how to use GraphQL. It's almost like it's not a bait and switch, but you have to educate your users on how to use the product.

If they have qualified themselves and they're on Prisma.org. Or dot com or io, I'm not sure which one it is but you'll figure it out. Actually it's Prisma.qo, I think. Anyway. They can qualify themselves saying, "I don't know how to use this." They can go to the documentation and they'll kickback out to here. Like, "You should learn the basics of how to GraphQL. This is an awesome tool. It's a great way to learn some of the more advanced features as well."

It's a great way to say, "I know you've gotten this far. You already know how to use this thing. But we shipped a new feature, why don't you go to our documentation or training? And if you're an expert, contribute back.". You're creating a circle of developers now excited about contributing back. It's also a really good way to source talent as well. Source talent from people who contribute back to their documentation.

The other cool thing is that you walk away with the product too. This is the Hacker News clone that you can build from that.

I have a usable product that I can use to understand what I just did.

The quick summary of what we just talked about. I didn't talk about SEO, but a lot of these channel efforts are helped and leveraged through SEO.

So consider what terms people are typing into your search bar and the documentation. We did this at Netlify. We used Algolia for search. Or, we did. I did. But we found out what were the top terms that people were searching for and we wrote content around that. Or we enabled users to write content around those different search terms.

Reference Materials

Like, "How do I get PHP into the Netlify?" Well, technically you can't. But you can migrate your WordPress site over to a JAMstack philosophy. So, summarizing this entire thing. One, how easy is it to find what your product is? Is that identified from your marketing page, or do you have to use something in the channel for that?

Two, how long does it take from getting from zero to deploying your product, or using your product, at least? And how easy is it to find references to your product? Because more than likely developers are there because they know they should be there, but if they don't know what they did or how they got there, then obviously we need to circle back and figure out what's going on there.

Lessons Learned

Just keep it simple. Part of that documentary is they talk about the LEGO system and how simple the LEGO system is. When you have bricks, everything is a 2x2 brick, 2x4. Every single LEGO guy is 4 bricks high. And that's a standard. When you have that system and everything fits in that system, it helps.

When you identify, "OK. We have a channel. Let's get content to the channel to find a system of how to get people to there." So if there are breadcrumbs that you can lead people to there. Or if there are carrots, you want to lead people from those breadcrumbs or from the channel or from Google searches. Figure out what that is, identify your persona, and then everything's pretty much golden. Hopefully.

I do run a program called developer.github.com/program. It's the GitHub developer program soon to be renamed. And I also want to give a shout out to Cristiano Betta. A lot of this content I sourced from his YouTube videos. He did a talk about the seven deadly sins of developer onboarding.

I tried to steer it more positive, because he has a super negative video. So if you want to see the dirt of what everybody's doing, including GitHub, definitely check that out. He also does a really cool one about GitHub. He does another one for Twilio as well as Heroku. Check out his videos. He does not have nearly as much views as the level of content that is there.

I'm Brian Douglas, I'm @bdougieYO on Twitter, and I'll be around to answer questions. So I think we'll pass the mic around.


Measuring Task Performance Time

I started at Netlify specifically when we were five. We weren't getting too crazy about it, we were just literally logging in and then asking people. We did user testing, that's a lot easier. You could spend a lot of time over-optimizing and adding a bunch of widgets and Marketo and logs and stuff. That's great, and if you have the bandwidth to do it I'd definitely recommend it.

But literally, just sit next to a developer and log in. I didn't repeat the question, but it was all about whether or not we put metrics in there. I think everybody heard that. And how we measure zero to deploying. Someone I sat next to at Netlify, her partner was a game developer. Game developers don't use git. It's not a thing they use very often, it's very low in the numbers. They are very in the poor for us.

And Netlify is built on top of git. The best features come through logging in through GitHub. So what she did, and to answer your question, she literally sat with her partner and had them deploy a site and see how painful it was. Because for one, they didn't have a proper GitHub repository. And then she can report back. She was the head of all documentation at Netlify, so it was very useful for her. Me, I just talked to a lot of people. I was always out and asking questions, and asking people what they like and what they didn't like.

Impact Of Open Source

The question is, "How does open source influence things like the channel and documentation, and stuff like that?" That's a great question that I literally just had with Johannes, who's out in the back from Prisma.

It's an interesting solution. It's new. We have a lot of companies who are building their entire companies on top of open source and having access to developer talent that way. Electron at GitHub is doing a really good job of doing community first efforts. Instead of onboarding people to "good first issue" within the repo, they're not onboarding people through there. They don't push people there. They push people to their Slack community.

So that way you can get to know the community first, because then you get a better quality of issues that are developed. Documentation help are usually developed by people showing up in Slack community and saying, "I'm interested in this thing. When do you guys meet?" And then they also have a meeting on a bi-weekly basis where they meet the community.

I know Apollo does that with Apollo Day and stuff like that, and you guys have open source days. It's just really involving the community. And not all of your decisions is also important. Very recently there was a company who put GitHub on blast. This is being recorded, but hopefully this is going to come off.

They put us on blast because they're open source as well, and their biggest gripe was the fact that issues were open. So they were taking all the support requests through issues. I would say that's probably not a good idea, and you should use something proper. Like, any other support tool that's out there.

It's mainly just trying to limit the amount of noise that comes in by redirecting people into a place where you can actually limit the noise.

GitHub now has issue templates, so if issues is a problem and you have a bunch of issues that you don't know how to manage, or you don't have PMs that can do that sort of thing. Create an issue template. It's a brand new feature within the last month.

Create templates, so that way people can only bring 4 different types of complaints. And redirect them to another channel, like the Slack team, or some sort of channel in Slack to say, "Hey, I'm interested. I need help. I don't know how this onboarding works," or, "You should improve this in some different way."

Onboarding Finish Line

I would honestly say, and this is my opinion. Onboarding never ends. Because when is your product done? When are you done shipping something? You're never done shipping unless your product is either deprecated or in the life, and hopefully if you're still accelerating or you're part of Heavybit or you're still a startup, you're still working towards growth.

So onboarding shouldn't end. For all the time I was at Netlify, every time we shipped a new feature people were blown away. Like, "I didn't think you could do this with something as simple as Netlify. Now you could do it." And then that was another story to our onboarding that we had added on to that. As far as Netlify, we engage everybody. We had this dashboard at Netlify and everybody would sign onto the dashboard and it was very un-useful.

We had a lot of customer interviews to figure out like, "What are the top things you do to come back to Netlify?" And we put all those things right there in front of you when you first log in. So that's one thing we did. And then exposing new features, we started all these hero cards and DocBlocks and things that introduce you and say, "I know you haven't logged in since the date we shipped this thing. Here's more information about the thing we shipped."

And then that this goes away after they see it the first time, and then they'll just see it in the wild hopefully. And what I did a lot of, was I engaged a community to write content around my feature because I got to the point where it felt weird selling Netlify so hard. So I would just encourage other people in the community to write about our new features.

The newest feature we had, which is functions, which also came out after I left. I wrote all this content about how to use it and then I looked at it, and I was like, "This is really sales-y." So I didn't ship it. And then I left to go to GitHub. We put a bunch of ear worms in a bunch of customers that were going to use it and we had them write the content.

It's just a constant cycle of reintroducing people about what's new.

To answer your question even more, that you didn't ask. When I first started at GitHub, a developer advocate, the first thing someone said was, "Why are you a developer at GitHub? They don't ship anything new. They haven't shipped anything new in forever." And that's a marketing problem for GitHub.

But it's also a problem because we aren't resurfacing new features and stuff like that. Within the last 6 months I've been there, they've literally started doing a way better job of showing stuff off. It's not great, but they're trying to get more engagement on the GitHub.com features.

Recommendations For Multiple Projects

What I've been doing is just engage the community I know. When I first started at Netlify I engaged a React community because I've been using React for a couple of years before I joined.

All my content was around React. Which was a good thing because React really got a lot bigger when I started. Go to what you know first internally, and then outsource through the community what you don't know. Things that you don't have the time or the bandwidth for.

Netlify is getting really big in the Vue, part of some of my efforts. Mainly just interest but we are also tapping into the Vue community to say, "We need more examples and content tutorials around Vue. We know you're using Netlify because before GDPR we could see it." But anyway, because of that we just engaged that community and just leveraged it.

Be okay to not be the expert in every single thing, because you can't.

Unless you're into it which is huge. Maybe figure it out internally in the company. Which at GitHub, I have a counterpart. I'm based in North America. Developer advocacy all around. I have counterpart in Europe. Everything that extends, not in San Francisco, but North America.

My counterpart is really good in server C++, like all that sort of things. Like Rust, I don't touch that. So now we have a nice balance of like, "Oh, you can talk to that community. I could talk to this community, and now we balance each other." It would be really weird if we all were in the same community. Because then we're just over calibrated for that partnership really, is where it's at.

Controlling Onboarding

One, you could buy the company. Now we have the money. That's always helpful. But two, it's just constant engagement. Ironically, my co-worker who also works for developer advocacy was also a partner when I was at Netlify. It's ironic. It's a small world, this DevRel space. But he approached me to do some content with Netlify and we were in the process of making it work until GitHub hired both of us.

Which is awesome but also stinks for those two companies. We were partnering, and their onboarding workflow did not work with Netlify. So we got into the process of them shipping new features that catered to our experience. We happened to be a bigger company so we were able to do that. Another company that comes to mind. I do a podcast I did mention called JAMstack Radio, and one of the podcast episodes we had a tool called Shifter.

Their whole tool is basically take your WordPress site and ship it to a site that's JAMstack ready, or Netlify ready. And they were not ready to partner with Netlify or even have that integration. But we waited, and we helped them along, and we supported them with the little bit of dev talent that we could. I think GitHub internally does a lot of that as well.

Just recently at Microsoft Build they announced the Checks API, which is a brand new endpoint API that you can use for your integrations. And they did a lot of handholding with Microsoft. As much as I could say, there was a lot of work between two companies to make that work. The onboarding flow of getting App Center to work with GitHub had some push and pull as part of it. Partnership is your answer.

Successful Community Engagement

One, attaching ourselves to the React community right off the bat as if I was hiring and got funded, was very helpful. Because we were able to be experts in getting React apps up and running. At the time, people were doing really weird stuff in GitHub and GitHub pages to get front end sites. It took a lot of hacking.

You had to go to Heroku and pay either zero or seven dollars a month. It was only two choices. Technically, it was seven dollars a month if you had a real app. So we would attach ourselves in that community. The other thing is what I mentioned with the deployed templates. With Netlify it was almost too easy to learn how to do a certain technology, build a template, and then go to market with that template as a developer advocate and engage that community.

If you don't have proper DevRel, maybe look into doing that. I was the sole marketer DevRel person out in the field contacting people doing support requests and stuff like that. I was the expert for front end tooling for Netlify. And since I built a bunch of templates, that made it a little easy. We went to React Rally, obviously one of the biggest React conferences that's not React-con. Well, React-con, I'm not even sure if it's still around.

But React Rally is around. We went there, we set up a table, we had stickers and then we had an iPad that said "Deploy your first Gatsby site to Netlify." So that way, you just walk up there, scan your phone and it deploys a site. And then we give away a Nintendo Switch. We had unreal engagement on that because we had a Switch. It was a thing I crafted called "Switch to Netlify" promotion.

And where normally people have little tchotchkes and stuff like that. We could have did all that, but what we really wanted you to walk away with was, "I got an account on Netlify." Also, pre-GDPR days. Now we can't do that in Europe. But we were able to get people an account to Netlify, and then we are able to have them with something tangible like a Gatsby site. Which at the moment was like pre 1.0. Or no, it was post 1.0. So everybody was super interested in that specific technology.

And we just road that rocket ship of Gatsby. And now they're a company, which is insane. Like Howl and the Netlify crew. They're really partnered with what they're doing. Everything new around that, and even another Heavybit company which is Contentful. Now there's Contentful, Gatsby, Netlify starter kits and that's super successful. Now that I'm not there, they don't have me as DevRel.

I wasn't holding the entire company afloat. But now they can engage that community to go to market, so that they can focus on things like Vue. Or whatever the next new thing is, or the old thing, to support that community.

Thank you.