A framework to build a successful developer marketing program for your business.
Read the full talk script in a much nicer format: http://jdb.io/scoop-talk
Hello and thank you for coming. It’s a pleasure to be here and I’m really thrilled to have the opportunity to speak to you all today about a topic that I’m very passionate about, marketing to developers.
The inspiration for this talk was a repeated interest among friends and colleagues about what it is that I actually do. I found that the more I tried to explain the approach to my work, the more I would find patterns. This talk is a collection of those patterns. It’s a mental model and framework you can use to build a successful developer marketing program for your business.
It’s based on over a decade of experience: first as a developer, then as a community leader, and ultimately as a professional marketer focused on platforms and developer tools.
I wouldn’t be so bold as to say this is the only way to approach marketing to developers, but it is one way. It helps teams know what is in and out of bounds and draws them towards creating scalable programs.Here’s a quick overview of what we’re going to be talking about today.
First, I’ll share a bit about myself to give you insight into why I care about marketing to developers.
Then, we’ll go over some required fundamentals to nail down before you start marketing.
We’ll go through a high level process overview, team organization, and measuring success.
After the overview, we’ll dig into each of the five steps in the process with examples.
Before we finish, I’ll share some great resources for further reading.
We’ve got a lot to cover, so let’s get started.I’ll share just a little bit about me. My name is John Britton and I’m the Senior Director of Developer Marketing at GitHub.
I’m also a full-time nomad which means that I’ve moved to a new country every two to three months since 2011. When people inevitably ask about my favorite place, I tell them that Shimokitazawa is the best neighborhood in the world.
I’ve been at GitHub for the past five years. I started when the company was around 100 employees and have seen it grow to nearly 700 today.
GitHub is the world’s largest developer community. Founded in 2008 there are over 25 million developers and 60 million projects.I think it’s relevant to share a bit about how I got into developer marketing.
I was into web development from a young age. I worked for a few different companies (in ecommerce, gaming, and publishing) as a developer and I also ran a web hosting and consulting shop for a while as well with a friend.
In 2010 I moved to New York City and faced a lot of difficulty breaking into the tech scene there. I applied for a ton of development jobs, but I just wasn’t able to get hired.
I found a job description for a “Developer Evangelist” at an unknown company, “Twilio.” The job required travel and teaching people about technology. It seemed like the perfect gig for me, except for the fact that it was a marketing role and I had no marketing experience. I also, to put it lightly, didn’t have much appreciation for marketing. I was more in the camp of “if you build it, they will come.”
I joined Twilio as employee number 13 and quickly learned the value of marketing. I experienced first-hand that it was possible to do marketing in a way that people don’t just not hate, but that they actively love.
I took what I learned at Twilio with me to GitHub and I’ve refined the practice over time.So, enough about me. You’re here because you want to hear about marketing to developers.
Before you embark on your marketing journey, you need three things:
A totally solid product
A clearly defined audience
A money making business
If you don’t have these three things you should hold off on your efforts to market to developers and instead focus on what you’re missing.Even the most charismatic marketer can’t sell a second rate product.
This is especially true when your customer is a highly intelligent developer. They can detect and reject poor quality products alarmingly efficiently.
Bringing a poor quality developer product to market will hurt you in the long run. So please, don't start marketing your product to developers until you know you’ve got something great.
You want developers to love your product and tell all their friends about how awesome it is. You can’t afford to start with a tarnished reputation.If you’ve got a solid product, the next step is to understand who your audience is.
In my experience, most developer products can be classified into two broad categories: tools and platforms.
Tools: Tools include things that developers need to use to get their work done. From IDEs to build systems, the defining characteristic of a developer tool is that it helps the developer accomplish a task but it’s ancillary to the developer’s end goal.
As an example, GitHub is a developer tool. It’s integral to the software development workflow but it generally does not become part of the developer’s end product.
Platforms: Platforms on the other hand, are anything that a developer uses and integrates into their end product. Platforms often take the form of APIs, SDKs, web services, and markets. The defining characteristic here is that platforms are integrated into what developers produce.
GitHub is also a platform, we provide an API to extend our functionality and we also have a market where developers can sell apps.
It’s quite common to see developer platforms for consumer products. Yelp has an API, for example. GitHub is similar in that we have a developer platform on top of a consumer product. It’s unique in that it just so happens that the consumers in our case are also developers.
Your audience is highly dependent upon if your product is a tool or a platform.To justify the effort we’ll expend in marketing to developers, it’s imperative to understand how the business makes money.
To do so, we’ll examine two similar but distinct aspects of where the money comes from in the business: pricing and billing.
Pricing: Price is what the user sees before they purchase. How much does the product or service cost? Most pricing falls into one of three categories: free, cost based, or value based.
Free is easy to understand, there’s no direct charge to use the product as revenue comes from another source like advertising. Cost based pricing means that you take your costs of providing the product or service and add a markup. It’s common when the product is a commodity like web storage or data processing. Value based pricing generally provides much higher margins and is based on the value the customer realizes by having their problem solved.
Billing: Your billing model determines how the user pays. Common billing models are the one-time purchase, metered billing, and periodic billing.
App stores commonly employ one-time purchases. Services that have fixed costs attached to usage often use metered billing so that customers only pay for what they use. Lastly, there’s periodic billing which gives rise to metrics like annual recurring revenue. Periodic billing just means that the customer pays repeatedly on a specified schedule.
Understanding pricing and billing is important in determining how your work results in positive impact for the business.You’ve got a solid product, a clearly defined audience, and a money making business. You’re ready to start marketing to developers.
Next, we’ll take a high level look at our framework for developer marketing.
We’ll review the five-stage process for planning your work, learn how to specialize as our team grows, and see how to measure our success.It’s easy to feel overwhelmed with work when you’re getting started marketing a developer product. This is a simple five step process for determining what work is important to do and in what order. It starts with support and works up to creating scalable programs.
Support: Support is fundamental to success. When you’re just starting out, talk to your users and see where they’re having trouble. They will tell you what you need to do next.
Content: On the basis of the patterns you find from supporting your developers, some obvious content needs will arise. Make the content your users need to reduce support. Repeat the process and core messaging will begin to emerge.
Outreach: Once you’ve got a small library of content you’ll have a much better idea of what you’re trying to say and the best ways to say it. You’re now ready to start doing outbound activities most frequently associated with Developer Relations.
Operations: You’re humming along, supporting users, making content, and doing outreach actives to bolster your userbase. Now’s the time to be introspective and optimize your team for success by documenting process and creating tools.
Programs: Last, when you find there’s one thing your team is doing over and over that’s working very well. Give it a name, a website, and brand it as a program to pour fuel on the fire.It’s totally possible for one person to do everything from support to launching a program given enough time, but if you’re lucky enough to have a team it makes sense to specialize.
I believe that everyone on the team should do a bit of everything to be fully connected with developers and that’s especially true for supporting developers and creating content since they’re both so fundamental to developing your outreach strategy and building successful programs.
When you do specialize, I recommend splitting the team across three roles:
Developer Advocate: specialized by region and working on outreach activities across all your programs. These folks should be highly technical and teaching oriented.
Community Operations: specialized by skill and working on reducing friction across all programs and team activities.
Program Manager: specialized by audience and the owner of a single or very small number of programs. Good program managers have been in the shoes of their audience members before.
There’s also room for career progression here. Someone can start on the team a bit more junior in Community Operations, grow into a Developer Advocate role and then settle in to run a program that they built so they don't burn out.It’s important to be able to measure success. Not only to justify your existence to the business, but more importantly so that you work on impactful things.
There are three core metrics that you can use to measure the success of your programs:
Quality: Measured as Net Promoter Score across a specific audience.
Net Promoter Score (NPS), for folks who are not familiar, asks customers to rate a product on a scale of zero to ten, where zero to six are “detractors”, seven and eight are “passives”, and only nine and ten are “promoters. To calculate NPS, you subtract the percentage of detractors from the percentage of promoters and you will end up with a score from -100 to 100. NPS is useful because it’s objective and can be compared over time and across products. To me, the delta in NPS over time is more important than the absolute score.
Quantity: The absolute number of program members. It’s often useful to look at the number of new program members over a regular time interval.
Activity: The engagement level of your program members. There’s some desirable behavior we want program members to have and we measure how often each person engages as activity.
The power of these metrics is when you have all three together. Having a huge number of engaged and satisfied developers is what you want.Within the team, we call this the SCOOP framework, and just like a good software framework it was extracted rather than invented. We didn’t set out to build the optimal developer marketing process, instead we looked back at our experience and pulled out the things that worked well and organized them into a logical framework for the team.
This is how our team has been working for a long time and it’s also how we train new members when they join. The framework has five key activities that build as you progress, starting with supporting developers and working up to building scalable programs.
Let’s take a look at an example program that was created using this process.The GitHub Student Developer Pack is a collection of the best developer tools, made available to students for free. The program launched in 2014 and I’m very proud of it’s success. On over a million occasions since launch, a student has received free access to an otherwise paid developer tool through the program.
Let’s step through the process and see how it came to be.
I started at GitHub as “Education Liaison,” in 2012.
The first thing I did when I joined was take over all inbound support email from anyone who self-identified as a student or a teacher.
I’d help them with account resets, give them advice on the best way to use pull requests in their courses and answer all kinds of questions.
It was an eye-opening experience. I was able to see that there was a huge demand for GitHub in the education sector, I found that cost was the main barrier to entry for students who wanted to use GitHub, teachers were afraid of being left behind, and they wanted their students to have experience with real world tools.With that learning, we made a basic landing page for GitHub Education, wrote some simple teaching guides, and showed students how they could use GitHub for homework without getting in trouble for sharing their code.
Now we were armed to answer the most common support queries with a link. We got more new questions, including some about teaching large courses and our opinions on computer science education.
We worked with our most passionate fans to write case studies and we discovered our core messaging: “Student developers need experience with real world tools.”
Armed with a powerful message, we were able to begin proactive outreach. We knew what our audience needed to hear in order to get them interested in our product.
It wasn’t “use Git because it’s superior to Subversion” or “GitHub is better for collaborating on software than using Dropbox.”
Instead, we made GitHub free for students and teachers and worked every outbound channel we had to say “Student developers need experience with real world tools and GitHub can help.”The message resonated with our audience and we were drowning in demand. Up to this point, most of our process was manual. We had gone from 5-10 students a week writing in about GitHub to 50-100 per day. It was totally unsustainable.
We focused inward to optimize our approach so that we could keep up and support even more growth. I built some internal tools to automate our processes for granting students and teachers free access to GitHub. We documented our team processes and we standardized our involvement with on campus hackathons by partnering with Major League Hacking.After some pretty intense work, the automation and team processes gave us space to breathe.
We had found a pattern that was working really well, but it didn’t have a name. Sure there was a landing page with some basic info, but there was no way to talk about it or share it with others.
I had an insight that other developer focused companies likely wanted to help students in a similar way, and I knew from experience that it takes a lot of work to support. We approached around a dozen companies and built partnerships so that they could provide students free access to their tools through our program.
We named the program the GitHub Student Developer Pack. Now that the program exists, the company understands it, the audience understands it, and we’re able to point to a thing and say “look it’s real.” It continues to pay dividends daily, with a pretty constant operational workload.So that’s the SCOOP framework, let’s look at some tactics and examples for each step. My goal is for you to walk away with actionable ways to improve your developer marketing programs.Support is everything you do to be there for your developers. I wouldn’t be overstating it to say that it’s the most important thing we do, help developers solve problems. After all, developer products make money because they help people solve problems.
As it relates to developer products, support is especially important because our products are usually complex and require specialized knowledge. It’s easy to get stuck, and developers who get stuck with no help leave.
Support is an inbound process and no matter the channel, be it via email, social media, or in person, your customers are literally coming to you and telling you what they want, where they’re having problems, what you’re doing wrong, and what to do about it.
I’m a developer and I’m also, as my wife says, a master complainer. I think it’s a trait common to most of us who build things. It’s not just that we make noise when something doesn’t work. We include loads of detail and suggest solutions too.
You need to listen to what developers tell you. Everyone on the team needs to listen. This is the most important signal you have.
It’s pretty straight-forward. Document official support channels and prioritize support as the most important thing in your daily work. If all you do is provide amazing support to your developers, you’re way ahead of the competition.
In my experience there are some consistent techniques that work no matter the product.
Think about the last time you were surprised by the level of support you received from a company. It probably made you feel pretty great. That’s the outcome we’re after when we talk about surprising and delighting developers.
Going above and beyond will help you win the hearts and minds of developers. This is the definition of “low hanging fruit” it’s not hard to do at all and it has a huge payoff. It’s also the right thing to do.
As all great developers, I make a habit of writing bugs. Don’t kid yourself, you do it too. One particular bug I wrote caused a few dozen of our users to get thousands of emails in a matter of minutes.
I’d be pretty upset if any of you emailed me thousands of times, so as you could imagine, these fine folks weren’t too fond of me. They wrote in and we quickly fixed the issue but I felt really bad. That could have been the end of it and everyone would have gone on slightly annoyed.
However I took the opportunity to make the most of the situation. I wrote a personal email to apologize, fessing-up to my supreme bug writing skills. In the message, I offered a GitHub shirt and some stickers to get back in their good graces. The response I received changed the tone of the conversation and ultimately turned out to be a net positive interaction for everyone involved.
One developer even invited me to email any time, as long as there is swag.
In every situation, always aim to surprise and delight.Another tried and true technique we really love is feature lists, which means keeping track of who wants what and telling them about it when it happens.
As you’re supporting developers you will see patterns. You’ll hear the same requests time and time again. That’s valuable data that not only informs what you should be working on, but also helps you build an audience.
When someone asks for something that you think might happen in the future, add them to the appropriate feature list. That could be a google form or a label in your helpdesk software. The format doesn’t really matter, you just need to be able to find the right people when the time comes.
As developers we’ve all had to work around missing functionality, it’s not pretty and nobody likes to maintain it. I love the feeling when a new feature replaces my nasty workaround. I’d love it even more if I found out immediately when the new feature was released.
I was getting flooded with requests from teachers who needed a way to keep student work private on GitHub. We kept a feature list of these teachers and when we launched GitHub Classroom, which solves their problem, we had a captive audience on day one.
With feature lists we can bring the joy of solved problems to developers in need, and do it at scale to boot. As a bonus, you get an on-demand group of people who care about your product so much they’ll help you test things out and be really excited for the opportunity.
Keep feature lists for a captive audience at every launch.The last support technique I’ll mention is to “speak like a human.” Developers are people first and they want to feel heard and understood. There’s nothing worse than being caught in a robotic loop when there’s a thorny issue. Put yourself in their shoes, understand their situation, and don’t be afraid to engage at a personal level.
It’s a common instinct to want to hide behind the brand when supporting users, especially when they have problems. Angry people are scary. You might think of yourself as the first line of defense but you’re actually the host of the party. Welcome questions and all types of feedback. Don’t be shy to connect over shared experiences.
We hire experts, they use human names, and aren’t afraid to share their own ideas.
Normally, in conversation, the goal is to keep communication flowing, not wrap it up as quickly as possible. So we don’t emphasize time to resolution, instead we emphasize quality and time to reply.
I talk about this example all the time, there’s an app I love called Arq. It’s a backup tool that can store data on any cloud service, totally encrypted. It’s super simple to use and feature rich. It’s also built by a single person named Stefan, who personally answers all support emails.
I’ve written in at least a dozen times with feature requests and he always writes back with his take on the idea and an open mind to hear more from me. I feel heard, appreciated, and like I’m making good use of my time. He’s gone on to build some of the things I’ve requested and he even told me about them when they became available.
To sum it up, speak like a human to engage on a personal level and get even more out of your support interactions.
Helping your developers is the most important thing you can do. The next step beyond support is to address developer needs in a scalable way. As a by-product of supporting developers you will find patterns that map to what kinds of content you need to produce. Let's look at some techniques for making successful content.Producing content — be it blog posts, screencasts, tutorials, or documentation — helps you speak to your audience at scale.
It’s important as a way to save time and spread your ideas. Would you rather answer the same question one on one over and over, hundreds of times per year, or invest a little more time up front and answer the question once and for all?
I hate writing and making great content requires writing. Even videos start with written scripts. It’s difficult for me as I’m sure it is for many of you. But I do it anyway because I understand writing things down means we can reach more people and it saves time in the long run.
Think about the most successful piece of content your team has produced. It probably got you new customers, attention on the internet, people talking about your product, new recruits for the team, or even more.
Every time you publish new content, you’re creating a way to be discovered, catching a problem before it reaches support, and developing core messaging that will resonate.
The goal is to help your ideas spread by helping developers help themselves. It’s hard to do well and it requires intention.
Here are some techniques to help you create great content.The second time someone asks the same question, I tell myself to “put a URL on it.” Write it down and post it somewhere publicly so that it’s easy to find with search. If you can, put it in the path of the developers who are most likely to need it.
My colleague, Ben Balter, is the one who is always telling everyone to write everything down and give it a URL. He practices what he preaches and writes at length to document things both internal and external to the company. Because he writes things down, he’s seen as an authority on a number of subjects and people reference his work constantly.
As another example, look at Fred Wilson, a partner of the prominent venture capital firm Union Square Ventures. He writes daily on his blog, AVC.com. I’m sure he’s an incredibly busy person, but somehow he finds the time to put a url on the things that people most want to know from him.
Put a URL on it to give an idea a concrete reference point. It will increase your reach by orders of magnitude and makes it possible to discover and share your content.Making content is chaos, you need structure to succeed. Structure means patterns for your content to follow and process for your team to find inspiration, prioritize, and deliver content consistently.
This means that your team doesn’t produce content. They produce case studies, code tutorials, step-by-step guides, thematic blog series, documentation. It’s not nebulous, it’s specific which means you don’t have to start from scratch every time. There’s a format, a place to put it, and a process to follow.
We hear a lot from folks who want to understand how open source works. They want to use open source in their companies, share their own code, and contribute to projects but they just don’t know how.
We used the guide pattern to break down this huge educational problem into manageable parts. We published a small collection of open source guides that explain the fundamentals of participating in open source. After a successful initial publication the team is motivated to create more guides and it’s easy for them to follow the same pattern.
Define structure for your content and process so it’s easy to make the next piece.
It’s clear that creating great content is a big investment and it would be a shame to spend so much time without maximizing it’s use. From the start of content creation, design every piece to be used in as many ways as possible and for as long as possible.
Recently Mike McQuaid from our open source team wrote a piece on managing large numbers of GitHub notifications. To start, as you might expect, we published it on the GitHub Blog and shared via our social networks.
But we took it further, we know this is super useful content for our power users, many of whom are open source maintainers. To make sure they got the message, we summarized the post into three main bullet points and emailed them about it with a link.
That’s sufficient and you may be doing similar. We designed the piece in such a way that we can take it a step further and schedule regular promotions into the future and include the post in the onboarding email series for members of our open source maintainer program.
To get the maximum value out of the content you work so hard to make, design for reuse.Creating great content will help developers help themselves, resulting in a lighter support load and freeing you up to focus on the next thing. Do it well, and do it often. The process will help you figure out what’s most important to say and how to best say it. The result will be refined core messaging.
Once you’re able to provide a great support experience and you have created a small library of content you will be ready to take your message to the masses through outreach.Outreach is bringing the best message you have to the most specific audience you can. Your best message is the message that solves a problem for your particular audience. That means in general to prefer engaging with a small room of people with a tightly focused interest over a stadium full of totally random people to make the biggest impact.
By this point, you will have developed an understanding of where your biggest opportunities to reach new audiences are and the most appropriate messages for those audiences.
We go out into the field to reach new developers and generate demand for our product. Through community involvement, speaking engagements, teaching workshops, and campaigns we’re making ourselves accessible, building reputation, and strengthening our brand.
Here are some techniques to make your outreach more impactful.When your product solves a problem for a particular kind of developer, find where they hang out and go there. Become part of their community by contributing in ways they would appreciate.
Common rallying points include in-person events, online communities, schools, and professional associations. This is your opportunity to share your message with a highly specialized audience that needs the solution your developer product delivers. There’s no better way to reach such a targeted audience. You can’t make these people come to you, you have to go to them and be one of them.
Remember the core message from GitHub Education, “student developers need experience with real world tools.” Computer science teachers are the audience we need to reach to get GitHub in the hands of more people learning to code.
We go to our audience. Every year, the Association for Computing Machinery organizes a conference for Computer Science Educators and over 2,000 influential university professors attend.
There’s no other opportunity to interact with such a large number of computer science teachers anywhere else. We’re coming up on our fifth year attending, and each year we expand our involvement. It’s the highest ROI event we do for this audience.
Go to your audience to show and tell them how your developer product solves their problem.It can also make sense to create a space for developers to gather. When you do, it’s important to be an excellent host. I like to say to be the living room. That means that we create a space, invite the right people to the party, provide for their basic needs, and make it about them. It’s our job to make sure the right people meet and that we smooth out any rough interactions. This technique works great for developer events and online communities.
GitHub is the home of open source and it’s our responsibility to help project maintainers overcome the unique challenges they face as they become more popular. We wanted to have an easy way to interact with the most engaged open source maintainers on GitHub so we opened two complimentary venues.
Online, there’s an invite only community for open source maintainers and in the real world we host an event series called Maintainerati. In both cases, we created a space and invited the right people. Online, their basic needs are simple, someone from GitHub to talk to and a bit of structure for what is on-topic. At the in-person events, we provide food and an unconference framework. Beyond that, we let the guests decide where to go.
Be the living room to create spaces for your developers.
I see a lot of developer product companies do things just because others do, without a strong understanding of why. Don’t be one of those companies. Don’t follow the crowd.
One of the biggest trends I’d encourage you to scrutinize is sponsoring, attending, and speaking at hackathons. So much of company involvement in hackathons is reactionary. An organizer requests sponsorship or a workshop presentation, the team deliberates, confirms, and then travels out of town to give a 45 minute workshop. The payoff just isn’t there in many cases.
To be clear, I’m not saying you should never participate in hackathons, we definitely do. What I am saying is that it’s hard to be effective when you are reactionary. You need to do things because of business motivations, not because someone asked you to.
The best way to avoid following the crowd is to be proactive and experiment. Understand your goal, brainstorm some ideas, and try out new things in a lightweight way so you don’t need to limit yourself to things others have done before you.
My favorite successful experiment is Hacktoberfest. A couple years back we partnered with DigitalOcean to run a month long fall-themed campaign to get people into open source. We didn’t really know what to expect, but it was a smashing success with thousands of people contributing to open source as a result.
Experiment to discover impactful outreach activities, don’t follow the crowd.Outreach will help you grow your developer audience and feed back into the whole process again. Your support load will increase, you’ll see new patterns in what developers are asking for, which will inform what content you create. Ultimately you’ll find new audience segments to go after with your well developed messaging.
Now it’s time to be introspective and focus on optimizing your team and process.By this point you’ll be juggling a lot of different activities and facing at least a few bottlenecks on your team. You probably know what the most inefficient parts of your work are and you probably hate doing them.
Operations is creating process for your team with intention to increase efficiency, accuracy, and consistency. Although it’s focused internally, success in operations will have impact that your customers will notice. As you do support, content, and outreach work, you will repeat yourself and our goal in operations is to eliminate duplication and reduce friction for the team.
For us, one really tedious activity that we know is high value is distributing swag. We distribute hundreds of thousands, if not millions of Octocat stickers per year along with lots of other goodies like shirts, mugs, and cheat sheets. We know folks love receiving this stuff. They are banging down our door to get it and when they do they wear it with pride.
The process for ordering swag was ad-hoc and time consuming to complete. Each order took multiple emails with the recipient and close to 5 minutes of manual data entry. To solve the problem we built an internal app to handle ordering swag. It made a complicated process simple and accessible to everyone, just enter an address and click send.
Here are some techniques that will bring order and consistency to your team.Checklists are powerful. They force you to check your work as you go and lift the mental burden of needing to remember everything. Checklists will make your team more efficient, more accurate, and consistent. They serve as functional documentation of your core business processes.
With checklists you free the team from a single point of failure. Rather than having one person who knows how to do a task, with a checklist, the whole team can do it. Checklists also provide a place for you to fix your team process when you find problems. Did you end up at event without the necessary materials? Add it to the checklist.
I have lots of checklists for different things, but I especially love the event checklist because it’s so easy to forget to do something over the course of the several months leading up to an event. It includes things like booking travel, shipping swag, applying to the CfP, and writing an event retrospective to share with the team and company.
Make checklists for every activity your team does regularly.Sometimes the checklists you write will be for things that can be automated. Invest the time to automate. That could mean using an existing off the shelf tool or building something specifically for your team. We are developers, after all. We can build the things that we need to do our jobs better.
We’ve automated a bunch of small processes within the team:
Part of our hosted event checklist is to make sure that the event is added to our website. Rather than open a pull request to a static page on the site for each event, which would be tedious, we opted to write a simple tool that displays events from a shared calendar.
We make a practice of talking to developers one on one to gather feedback, which necessitates scheduling meetings with them. Rather than playing email ping pong, our team uses an off-the-shelf tool to manage availability and let people book time with us.
GitHub has an amazing unlimited time off policy, but as a team we set some standards for giving notice before taking holiday time. In addition to documenting expectations for the team, we added some automation to notify everyone via Slack when new vacations are scheduled.
These may seem like small things, but they’re all really helpful to us and they're done by the robots.As much as we love our checklists and automation, things change in the business and within the team. It’s important not to become attached to your process and tools. Keep an open mind and refactor your process when needed.
In the early days of GitHub, it was company policy that we would pay for anyone in the company to travel to any developer conference anytime they were accepted to speak. I loved that the process for speaking was simple and to the point. We valued having employees at the front of the room and we wanted that to happen as often as possible.
It worked really well for a long time, but once we reached a certain size it became excessive. As much as employees loved the benefit and it helped our brand, we needed to refactor the process.
Now, we have a clear delineation between professional development benefits and representing the company. There’s a generous limit for professional development and travel to represent the company is unlimited provided there’s a business need.
Don’t fall in love with your process and tools, you will need to refactor them.Through operations you can become more productive and improve the quality of your work. Creating process with intention will relieve pressure on your team. And if you can, why not have robots do the work for you?
Some of your processes and automation may have the potential to do even more for your developers. Let’s talk about how to tie it all together.The last step in our framework is programs. Many teams don’t even consider programs and they’re missing an opportunity to get massive payoff for a reasonable investment.
Programs connect your core message with a concrete action for your audience. They take all the work you’ve been doing and bundle it up into a logical package.
Programs are real, they’re the things your customer can point to, talk about, share, and engage with. They’re awesome because you are able to invest time up front just once and you get to win the same way over and over.
When I worked at Twilio, we had a program called the Twilio Fund. The fund connected Twilio developers with investors so that they could get the capital they needed to grow their Twilio based businesses. It took the message “you can build a great business on Twilio” and gave developers a concrete action to take, “get funding for your business.”
This idea might be new so let’s look at some tactics that are common to great programs.
Invitations to irrelevant events, partnership requests, and sponsorship opportunities are just a few of the many distractions we face every day. With the right programs, you can divert distractions into something useful for your business.
There was a time when I would receive 5-10 emails per week from student developers asking me to sponsor their school hackathons. While I really wanted to help them all out, I knew it frequently wasn’t a good use time or money. We created a sponsorship checklist to evaluate the opportunities. After iterating it became really simple: Is this the first time this school has had a hackathon? If yes, sponsor. If no, pass.
You see, we had a core message “Students need technology communities at their schools,” and we followed a process that agrees with that. Ultimately we turned that process into a program when we launched the First Time Event Grant in partnership with Major League Hacking.
I’m happy to report, that we’ve now supported over 100 first time student hackathons. We set the terms of the program up front and shared it with student leaders to get them to create technology communities on their campuses. The program has been wildly successful and it has only cost us $1,000 per event. That’s not to say $100k isn’t a lot of money. But we were able to turn distracting sponsorship requests into an impactful program for a fraction of the cost of sponsoring them all.
Now when student developers contact us, we can point them to the program and avoid deliberation, planning, and whole lot of other work.
Create programs that divert distractions into something useful.The basic premise of running programs is that you do the work once, and then you benefit from the pattern over and over again. For that to work, you must plan for scale. You don’t want to build a program where you’d be afraid to have mass uptake. You should want as many people as possible to participate in your programs.
Any program that requires a one to one manual process is going to be in danger of having scaling problems. That doesn’t mean that your programs must be fully automated from the start, just that you should have a plan for how to operate the program as your audience grows.
I know from experience with the Student Developer Pack that programs can attract huge numbers of developers. In designing the program we planned for mass uptake by automating nearly every step of the process but we didn’t plan well for the bits that couldn’t be automated.
We had huge interest from day one and it created a mountain of work that we had to dig out from. Later, we updated the program and created an operational plan that allowed us to get help externally as needed.
Plan for scale so you don’t end up buried under a mountain of work.Your programs don’t need to be elaborate. They just need to help you achieve your goals at scale, so keep it simple.
One problem we faced with the growing number of developer events was that we found it near impossible to engage without attending. We needed a way to interact with attendees without flying out every time.
Almost by accident, my colleague Scott Sanicki created a simple and really fun game that we use as part of our events program now. It helps us connect with attendees even when we’re not able to be there in person. At every event we are part of, the organizer makes sure to share details about GitHub and also announces an Octocat drawing contest.
Now developers show off their artistic abilities by sharing their rendition of the Octocat on Twitter and tagging it with “#MyOctocat.” It’s super simple, our audience loves it, and it gives us a chance to participate from afar. It’s so popular that we’ve seen events that we’re not associated with join in on the fun.
It’s possible to build programs and keep it simple.Aren’t they beautiful?Always be on the lookout for opportunities to bundle your work together. You can create something concrete to point developers to so that they take a desirable action.
Discovering the right program to create isn’t easy, it takes time, and it will be a lot of work. But it’s work that’s worth doing, because programs give you ever increasing payoff for little to no work after you create them.So that’s the SCOOP framework. Start with support and work your way up to programs. It’s progressive rather than sequential, so once you start on each stage, you don’t stop doing the things that came before.The last thing I have to share is some recommended reading. These three books have had an outsized impact on the way that I think about marketing to developers and I highly recommend you check them out. They’re all required reading for our team.
Made to Stick: On my first day at Twilio, Danielle Morrill handed me Made to Stick and told me that it was to be my manual of style. Following the tactics outlined in that book led me to create the Twilio live coding demo.
Traction: Traction outlines 20 some odd different techniques for acquiring customer growth. What I really like about the book is that for each technique they provide an example company that used that technique as their primary growth strategy. It’s great to help you get your creative juices flowing.
Platform Revolution: Platform Revolution is a recent addition to my recommended reading list. I found it to be a good catalog of common platform design, growth, and strategy patterns.That’s everything folks. I really hope that you’ve enjoyed the talk and that you’ve learned something that you can put to use in your work.
Feel free to take a photo of this slide for your reference.
I used this talk as a forcing function for a side project. I’ve been a little shy about the details, but I’m working on pulling all this material along with a lot more examples together as a book. If you’re interested in hearing more as I make progress, you can sign up for email updates.
And lastly, GitHub is hiring across the board. My team is hiring developer advocates in the US, Europe, and Japan. We’re also hiring application engineers and product designers to collaborate with on building out our programs.
If you’re interested in any of these jobs you can check out our site or feel free to get in contact with me directly.
Thank you very much.
johndbritton
oracle4engineer
microcms
mode86
htsuruo
vividtone
marikashiotsuki
x_ttyszk
minorun365
hankehly
taishin
ciniml
jeffersonlam
samlambert
zakiyama
kastner
dotmariusz
philnash
yeseniaperezcruz
philhawksworth
geoffreycrofte
rocio
destraynor
holman