Made by
Made by
Luke Kilpatrick
Luke Kilpatrick from Nutanix has been in dev rel since transitioning from web development to managing tech communities in 2007. In this talk from DevRelCon San Francisco 2019, Luke outlines key lessons from building a developer relations and marketing program following a company pivot from hardware to software.
So, who am I? I’ve been doing the dev rel thing really since about 2008. Actually, anyone here who remember Adobe user groups, anyone ever part of an Adobe user group in the back in the day?
Actually, Sid Maestre and I actually ran the Bay Area ColdFusion User Group together, and that’s kind of how I got my first taste. I was a developer, and I started running this user group, and I got a lot more enjoyment and passion out of being part of this user group.
And we created a bunch of other ones, transitioned my career, ended up going and working for VMware, and was running their sort of social media program. Dev rel wasn’t really a thing for them, but we were interactive with it.
And then I’ve kind of worked with Sencha, spent the last four years at Atlassian. And recently, last June, I joined Nutanix. Now, anyone here actually ever heard of Nutanix? Okay, we got, good.
Nutanix builds primarily, up until about a year and a half ago, two years ago, it was a hardware company, it was building on-prem enterprise cloud, is kind of what it does. Now, we’ve been transitioning into a software company. And when you transition into a software company, what do you need? Well, you generally want to start talking to developers if you’re trying to sell software.
So one of the things that we have of value at Nutanix is start with the why. Why do you need a developer program? Why should developers care about you? All that.
So when you’re first trying to get one off the ground or you’ve recognized a need, you really need to figure this out, and that’s one of the key parts. So, why do you need it?
So this is, I did some research. Anybody ever work with Developer Media, Code Pen, or sorry, Code Project? I got this number here, it’s called 34%. Any ideas what 34% might be? This scares the crap out of salespeople, which I truly enjoy doing.
34% is the number of opportunities dropped because of developer influence. So you’re losing a third of your sales because developers either say, “No.” We did a survey last November, so this is fairly recent data, we had a little bit under 1,000 developers say they reject software given to them by their management or team lead. Often, very often, or all the time, I wish they’d just give us the credit card so we can buy our own stuff.
This number here is why I’ve been able to justify to my management why we actually need to talk to developers. Because even though the developer doesn’t have the budget traditionally, although more and more are getting it, they have enormous influence in your company, and if they don’t adopt your product, especially as we go to a subscription world, they cancel the subscription and things go away, profits go down again and again. So that’s your sales justification of why developers matter.
So the other thing that I’ve found over my learnings is what are you trying to do, what type of developers are you trying to reach, what type of program are you building. And I haven’t seen a lot about this, this is a fairly new idea, came up with this for a chapter in the “Developer Marketing” guide that I was actually sponsoring from SlashData.
You got a couple of different areas where your developer programs live, and hopefully, yours fits into one of these. If yours doesn’t, please come talk to me. I’d be really interested to hear which one doesn’t.
So traditional developer marketing you see is, you know, a lot of people have got this, this is one of the oldest ways, is marketplaces, you produce an OS, you need to talk to developers to make software for your operating system, Apple’s App Store, Atlassian’s Marketplace, you know.
You’re going out to get your third parties to actually build stuff for your platform, very common. Either they’re building extensions to your product or they’re building stuff to run on it.
API consumers, this is where Nutanix lives, this is where a lot of your infrastructure lives. You have an API, you need to make your stuff talk to other stuff so it plays well in its ecosystem. Because no data center is completely homogenous all the way through. And even in that, you know, you still need your Microsoft product to talk to other Microsoft products, and vice versa.
For marketing tools for developers, this is an area that I have, this is probably the closest to the more traditional marketing. You have a tool, like Jira or GitHub or something like that, and you will actually need developers to buy and adopt it. And doing that, it’s a little more traditional marketing, but you’re marketing to developers.
And one of the biggest differences in marketing to developers compared to other more traditional marketing is developers don’t believe you. They have to try it. If they cannot get their hands on your product for free to actually muck with it, they don’t trust anything you’re telling. And I know this because I don’t trust anything unless I can kick the tires on it, too.
And last one, and this has come up more recently, but I think is a larger and larger area, is developers are required. So Contentful is a great example of that. Anyone here has heard of Contentful? I think Shai is in the back there somewhere.
Contentful is a really neat product. It’s a great CMS. Here’s the problem, there’s no front end on it. If you don’t have a developer, you can’t use the darn thing because there’s no way to get the code out of the back end.
So other examples of this would be Twilio. I think I was talking to Weavr… This is a very common thing, and this is where if you do not have a developer relations, developer marketing team, your product just flat-out fails.
And there are some areas at Nutanix, we’re getting that as well. But for the most part, open source projects also can fall into a couple of these different buckets as well, but that’s where I’ve been finding where your programs are.
So, okay, you’ve got these four buckets, you’ve figured out what your program is, now, how do you measure it? And this is where the primary difference between these projects are, is that your metrics for each one is different.
For Marketplace, if it’s a “for sale” marketplace, that’s easy. Does it make money or not? Are people buying stuff? Whereas API consumption, and this is a problem I have, is we make clusters that go on to DoD dark sites. That doesn’t phone home and tell us that someone’s using the API.
So we have no clue. And so, how do you find that out? And those early metrics is how you do it. This is also where it’s really important to have an executive champion for your team. Developer programs take anywhere from 6, 18, sometimes even 2 years to build, and it’s slow going.
The metrics aren’t going to show up, especially if you’re new. You need to make sure that you have a champion that understands you well enough to be able to say, “Don’t worry, it’s going to be okay.” And this is especially important as if you bite a big one and have an event or something fail miserably, which I’m going to get to.
So you want to get a few early metrics. You want to get some baseline stuff.
Other big thing that you really want to do quickly is when you come into a new company and starting a new program. Hopefully, you already have customers and people using your products. Talk to them, find out where their pain points are, talk to them on the phone, talk to them at events.
One of the big things that I just did is I actually hired a researcher, and we’re actually getting 30 to 40 of our customers on the phone and trying to get people that are both in the land of suck as well as the people that are being awesome, to reference our previous speaker, to get that information. And we’re going to share that both with engineering and internally so we know where we’re going.
So other thing you want to do is build your team, and building your team is critical.
And a lot of people are, “Well, let’s just go hire a bunch of evangelists, and we’ll go to a whole bunch of events. And great, okay, but here’s the problem, you’ve got all these people, but your docs suck.” So you’ve got a whole bunch of people that are excited to try your product, and then they can’t because your onboarding is horrible. So you got a cart before the horse there.
So my personal opinion, the most important hire that you can make when you start a program like this, bar none, is a phenomenal content writer, ideally who was a developer before, but you need someone that’s going to make you your best, first, get onboard tutorial, you need to make sure your API reference docs are great, you need blogs.
And you know, we have a site called developer.nutanix.com, we’re actually rebranding it to nutanix.dev. By the way, the .dev top-level domain is awesome, and I’m hoping more and more people adopt that, because I think it’s just so much easier to say than the developer.whatever.com. So nutanix.dev is going to be our new site.
And so getting somebody that really builds your portal is important. So your portal is your face to the world. If you do not have a good portal, then no one cares, you just don’t exist, you know.
And there’s varying quality. Who here is actually happy with all the documentation on their portal? Great, not a single hand, fantastic. Every portal can always be better, we’re always reiterating, you’re always doing great things with it, but there’s always that one part that doesn’t look great.
So you know, but things that you need to have is a great onboarding experience. The better you can make your onboarding experience, the faster you get people out of that valley of suck. And that’s key.
I really think blogs are important, because getting people to write blogs for it, especially a developer-focused blog, marketing sites, your .com site, that’s for people that buy, and I always say that, “This blog is for people that do.”
So people that actually have to use your products in a technical way, not marketing fluff, but this is where this blog is, you know, get the engineers and get the PMs writing about this, and this is one of the ways I’ve found actually to engage with PMs and get them involved so they actually care about this. Because they just wrote a blog post that got X number of views, and now they feel good.
So that’s a great way to do it. Other thing I highly recommend, and I know there’s always this temptation, “Let’s go roll our own CMS so we have a custom portal.” Unless you are a CSS company, please avoid that temptation, because after you go, nobody knows how to rebuild your developer portal.
Use WordPress for the front end. You can hook almost everything into it. It’s great. Something like that, use something that you can, that more people can know, and upgrade. And if you have a very specific language, use that specific language as blog software.
There’s lots of blog software out there, don’t go write your own. I know, I’ve been in three companies that wrote their own blog software.
So, great, you got a portal. Now, you need to get the word out. You need to do events.
Doing events is tough, because you’ve got a couple of options. You can go to meet-ups, you can go to, do your own conferences. There are so many different varieties, dude, hackathons, labs, things.
So this has been my experience. I find that, and I might get booed off the stage here, I find externally-facing hackathons suck. And where’s the tomato? Okay, no tomatoes.
Externally-facing hackathons suck because the code never gets used, it’s a bunch of people that are trying to struggle to learn what it is, and all they do is basically spend 12 to 24 hours or 48 hours in the valley of suck. And you know what, that’s not a fun time.
I much rather do people hands-on labs, so they learn your product, and then expand upon it. Now, that says, internal hackathons are phenomenal ways to build your product inside the company, and the dev rel team should be deeply involved in an internal hackathon.
At Atlassian, we had a thing called ShipIt, and it was great. There was more innovation that came out of that and products that came out of that. It was really the engine that drove the company.
And so internal hackathon is great, external-facing hackathons, it’s just a long time in woe and suck. So, that’s my opinion. We’ll go from there.
So, that was basically my thing. So I really like hands-on labs that actually get people with a test harness. So to do this, we did a tour. When I first came into the company, one of the things is I wanted to actually know our customers. So a tour is a really good way to do this.
We had this .NEXT On Tour that went to 11 different cities across North America in 5 weeks. At that point, I was a team of one, so I got a lot of mileage, including doing a day trip to Charlotte, North Carolina from here. That was two red-eyes, it was brutal.
But the whole thing about this is this is my “Hello, World!” This is actually a screenshot of what it is. This is an analytics framework for being able to manage your clusters. And that’s a really great tool, because this year, it’s now working with my API, and I teach people how to swap the different pieces out so they can play with your API.
The other advantage of this, this is a boss screen. I call this the boss screen or a wallboard screen, because after you’ve come to my lab, you can go back and show this to your boss and say, “Hey, boss, here is a great way to see what’s going on in your data center, and you don’t need access to my back end now to get your metrics that you need to report on.” So this is a really handy tool.
I highly encourage you first, prior to your onboarding, an analytics package or something that would get information out of whatever your thing is into a consumable way. It’s a really great first project so that it’s beyond that “Hello, World!”
So now, let’s talk about some train wrecks. So I gave you a little bit about my On Tour. It was great. I taught 400 people. We’re doing 90-minute labs.
Really, other big thing that’s really helpful, if you’re familiar with VDI or virtual desktop infrastructure, if you can do your labs with virtual desktop infrastructure, it makes your life so much easier. Because if you’re ever running a lab, setting up a dev environment is fun, right?
So if you eliminate that, where people just log into a computer through a web browser, you’re ready to go. Nutanix, small plug, we make a product called Frame that does this. It’s cheap. Give it a look because it makes running labs really, really easy.
So let me tell you a little story about London .NEXT. So .NEXT is Nutanix’s user conference. And user conference, these are people that are managing IT infrastructure at scale, and these are large G2K Fortune 500 companies coming in, and these are people that are spending all their days, you know, moving stuff around, making sure the loads don’t fail. So not a lot of developers, these are mostly admins.
So we did, my thought originally was we were going to go do this API Accelerator Lab, this lab that I just did all around the U.S., and we were just going to do a little bigger, expanded version of it for this. And we advertised that because we thought that was cool. Then I made my mistake. Who’s here heard of IoT? IoT is this great newfangled thing that’s really exciting and sexy, and we came up with this IoT product.
So we changed our program from being relevant to someone’s day-to-day to something that they kind of may care about somewhere two or three years down the road. And we thought this would be great so they’d spend all this day, we’re going to do a lab in the morning and then you’re going to do a hackathon after on the other side, and it’s going to be great because you’re going to learn all about this stuff. We had cameras for image recognition, you’re going to do machine learning, this is going to be great.
And it completely flopped. First up, we had the most complex hardware that we could possibly do. We shipped a cluster, a 4-node, $30,000 piece of network hardware infrastructure that sounded like a 747 taking off at the back of the room. We then wired it to 23 Intel NUC PCs to work as our edge devices. And then we hooked in cameras, and we had 100 of these little webcams that we thought were great.
Unfortunately, we didn’t plan for was that the Wi-Fi could only handle streams from 3 cameras for a 110-person event. Yeah, that didn’t work. And then, to top it off, it rained, because London rains occasionally. So out of the 110 people we had signed up, 46 walked in the door.
And then we asked, “So, okay, we’re going to do this. How many people in this room are actually developers that write code regularly?” I had two hands. So it just, and then on top of it, people were expecting one thing and they got the other.
So they just crucified us in the comments. People hated it. Learned a lot of lessons from this. Don’t change horses in midstream, really make sure you know your audience. And we got rated on a 5-point scale, and we ended with up 4 out of 5, 60% of it said it was 4 out of 5, and we only had 20 people at the end of the day.
The good news at the end of the day is, to boost our ratings, they all went home with a $900 NUC. So the 20 people that did stick for the whole thing actually did well.
I learned a lot with this, and we revamped it. We just did our last thing in a .NEXT in Anaheim about three weeks ago. We did a lot better. We did a pair of keynotes that were fantastically well received. We hired a guy named Jin Kim, who’s big in our field.
We did a customer panel, where people actually heard about who our customers were. And then we actually did hands-on labs, where people actually were able to self-direct. And we had really good people in it.
So we ran a more traditional developer conference, we took the feedback, and we ended up with a 90% rating out of it. So making that change, learning from the disaster is really good. But having your management understand that sometimes you have a disaster and that you can recover from it is pretty critically important.
So there’s sort of a nutshell of what I’ve been doing the last year of building this from scratch. It’s been exciting and lots of lessons learned. But you learn from your mistakes and you learn more from your successes. So don’t be too afraid of making them, just make sure that you record it, have really great post-mortems, and learn how to enhance it next time.
So thank you. Actually, one more, sorry. I wanted to leave one last quote. This is really what developer relations in my mind is all about.
We are empowered to make people more powerful. We are the conductors. We are trying to get people to build more and do more for their own benefit. So this quote, it really spoke to me for that, and I hope you guys take it and go from it. So, sorry, that was my last slide.