I wrote a bit about “What is a Developer Advocate?” back in October in the article Introducing the Rackspace Developer Relations Group and open cloud SDKs. Not a whole lot of time has passed since then but my thinking on it has evolved and I missed a number of things in that first pass. I’d like to take another crack at it and I still get asked this question often enough that it’s always fresh in my mind.
Definition
A developer advocate is someone who’s primary responsibility is to make it easy for developers to use a platform. In my case, I’m trying to make it easy for developers to use OpenStack and the Rackspace Open Cloud. I view the role as having a foundation of three pillars: development, advocacy, and community.
Development
I’m a software developer. I know when a platform isn’t as easy to use as it could be and how to improve it. You need to know the craft and have the respect of your peers. Without that the rest is moot. This is especially true in the meritocracy of open source. I think that’s why you don’t hear much demand for “technology evangelists” anymore. If you can’t speak to developers because you aren’t one of us, your arguments will fall on deaf ears. Naturally this involves all of the usual development activities like architecture, design, implementation, testing, and debugging. The product of this includes tools that make it easier to use your platform like SDKs, examples code, command line interfaces, and IDE plugins.
I contribute to open source. In an increasingly web service API driven world, the tools built on those APIs are often open source. I think it’s a natural fit. The tools are geared towards dev and ops and we need them to be open source so we can figure out just what the heck they’re doing when things go sideways. Working with open source communities and commercial organizations can be a bit tricky. Personally I’m walking the line between jclouds, OpenStack, and Rackspace. Hopefully, most of the time your goals will align but sometimes it’s just a matter of balancing the priorities between the differing concerns. Always remember to stay humble, helpful, and honest. The product of this includes helping other developers contribute, code reviews, having an opinion on community matters, and helping out in ways beyond your immediate concerns.
I’m a technical writer. I also stress documentation as a key developer advocate activity. Documentation is often done by developers but it’s particularly important to this role. When trying out your platform for the first time, the first place most developers are going to start is the docs. If you’re trying to make your platform easy to use then those “Getting Started” style docs had better be clear and concise. This will be one of the first experiences a developer has with your platform and you want them get on board smoothly. The product of this includes getting started guides, reference documentation, and detailed API docs.
Advocacy
I represent third-party software developers. We’re out there trying to build the platforms and tools that people love to use, make developers productive, and make it worthwhile for them to invest time in learning our platform. When building this stuff, sometimes it’s easy to lose sight of the forest for the trees. Which is to say, we can lose sight of the very developers we’re building this platform for, if we get too focused on the details of the technologies. We need to keep the needs of the third-party developers foremost in our minds at all times to prevent that.
I represent my company, Rackspace, and its core values. Public speaking is definitely a requirement for the role. You need to be able to comfortably get up in front of an audience and let them know why your platform and its ecosystem are the best place to invest their time and effort. Focus on the benefits to them. My preference is to give workshops where you can get developers writing some code, doing something useful with the platform, and really demonstrating its ability. This goes back to the developer half of developer advocate. The product of this includes presentations, workshops, and demos.
I help lead technological change. It’s rare that a platform exists in isolation. Typically there are competing platforms all vying for market dominance. You’ll need to come up with strategy and tactics to encourage the adoption of your platform. To find out how well that adoption is going you’ll need metrics. This is a much broader issue for your organization so you’ll want to focus on the metrics important to your group, namely the adoption of the tools you’ve developed and what affects that. I’ve really only just started working as a developer advocate so I haven’t done much strategizing yet. I suspect it goes pretty deep and if you follow it all the way down, you’ll probably wind up in a different role within your organization. The product of this includes plans, metrics, and reading, lots of reading to keep up with the developments in your platform space.
Community
I engage with the development community. Beyond the conferences you need to find other ways to reach out to developers. I think blogging and trying to write well is core to this. A lot has been written (one of my favourites) about the importance of writing for developers so I won’t rehash it. Then of course there are updates to GitHub, Twitter, LinkedIn, Google+, DZone, or whatever social media/code outlet might be relevant to your platform. However you choose to broadcast information, it needs to have a mechanism for feedback. We are beholden to developers and need to be able to get feedback from them. The product of this includes blog posts, comments, tweets, and other social media updates.
I help developers. As you’re making your platform easy to use there are going to be some rough spots. There are going to be occasions when you don’t get it right the first time. One of the first indications of problematic areas will be developers asking for help about some aspect of your platform. You need to be subscribed to the right issue trackers, forums, and Q&A sites like StackOverflow to catch these questions. You don’t necessarily need to answer the question right away. Give the community a chance to help itself. But be aware of the questions and examine each one to see if it points to an underlying or obscured issue. The Developer Support Handbook is a good book on the topic. The product of this includes answers and some deep thought about what the questions mean.
I keep developers up-to-date with what’s going on with our platform. I consider this to be important enough to warrant its own point, separate from engagement and help. It’s critical that you be able to keep developers current with respect to changes to your platform. I wrote about this in Keep Up-To-Date With Changes To The Rackspace APIs so I won’t go over it again here. The product of this includes API updates via RSS/Atom, email, Twitter, or what have you.
I host/sponsor/attend community events like meetups, user groups, and hackathons. Delivering presentations at conferences is great but I find conferences can sometimes get impersonal. Smaller groups are much more intimate and you can deliver highly relevant information tailored to that group. It’s more of a grassroots approach and has a significantly different feel than conferences so I include it here under Community. Even so, the product of this is similar and includes presentations, workshops, and demos.
I try to be as transparent as possible in all of the work that I do. All of this community activity translates into transparency. From the stream of GitHub activity to blog posts, tweets and events, it should be abundantly clear what I’m up to. Personally I find it more interesting to work out in the open like this rather than behind closed doors. If developers can see exactly what you’re doing to improve your platform for them, they can trust you because there’s simply nothing hidden.
All of these activities help build a community around your platform. This is crucial as a community can make or break your platform. Having a thriving community can also make it easier to use as there will be far more help to go around than you or your team could possibly provide. This will help you scale as your community achieves self-sufficiency.
What a Developer Advocate is Not
Because the role touches on so many aspects, it’s easy to get diverted from the primary responsibility so it’s worthwhile to mention what a developer advocate is not. A developer advocate is not training, marketing, sales, or support. We work closely with the development community so other groups will naturally come to us for help and advice. Go ahead and help and advise them but just don’t go too far off course. You can’t let that distract you from making your platform easy to use for developers.
Coda
The Developer Advocate and the Developer Relations Group sits at that pivotal point between developers and the platform. As anyone who has developed software or done design for any length of time can tell you, it’s difficult to make something easy to use. It’s also something that’s absolutely necessary. Making your platform easy to use is the most important thing you can do to drive developer adoption.
This is my take on what it means to be a developer advocate. It’s been bouncing around in my head for the past few months and it’s good to get it out. Writing it all out like this makes me fully realize just how challenging and expansive the role can be. However, it’s not like you’re doing this stuff all at once (although occasionally you are). With the help of a great team and the support of management, it’s definitely doable.
If you’re a developer advocate, I’d love to hear what you think! Did I miss the mark on anything or miss something completely? How would you break the definition down?
If you’re a developer, what do you expect from your developer advocates?
