Getting Started in Developer Advocacy

The field of Developer Relations is still relatively young. I first got into the field in 2007, after seven years in Technical Sales. As a sales guy, I started attending conferences to work the show floor (drum up sales). Then I started presenting, and was humbled by the feeling of being able to help people. When the opportunity came up to move from Sales to Developer Relations, I made the jump and never looked back.

Those first few years were very much figuring things out as I went. There were no developer relations books. Very few related blogs. You had to make it up as you went. Over time the strategies I formed became more and more tested. With that in mind, this is the first in a series about doing the work of a Developer Advocate.

Personal Brand

Your employer has a brand. That brand may be new, as a startup, or more than 100 years old, such as the case with my current employer, IBM. A good brand stands the test of time. It gives people a single point of focus with which to identify.

As an advocate, if you intend to do this as your long-term career, you must have a personal brand. This gives people a single point of focus for you, regardless of your current employer, or technology emphasis. Without a personal brand, you risk becoming obsolete as the technology landscape changes.

I have worked with countless technologies in my twenty (20) years of IT experience. My personal brand is what has allowed me to survive the shifts in my career from Java, to Flash, to Web Standards, to IoT. Without it, I would have had to start from scratch with each evolution.

The Long Tail

At the core of much of what follows is a business/statistics concept known as "the long tail." This term refers to a distribution of numbers. When you publish content, it will get the most views right up front. Over time, the number of views will taper off significantly.

Many marketers will focus on getting that distribution as close to the front, and as steep as possible. I would argue that for an advocate, the long tail is what really matters. The release schedules and timelines of your employer are not necessarily the project timelines of your audience. It may be a year or more before your audience finally gets a chance to implement new technologies. By minding the long tail, you are there when they need you.

Technical Writing

I do not know any developer advocates that do not write technical articles. Writing helps you codify your thoughts. Writing helps you become a better communicator. Writing expresses your personality. Writing supports the long tail. Get the point? You need to write technical content. That value to your personal brand must not be underestimated.

Blogging

When I started in developer relations, blogging was the main way to accomplish this task - and for my money, it is still the best approach. If you are starting out, you should invest in a vanity domain and attach a blog to it. Initially, you should aim to write something every week, but do not apologize if you cannot make it - it is after all, your blog.

1. Speed - There is no delay between when you have a thought and when you can publish that thought (other than the writing process itself). You do not have to get approval from any editorial source.
2. Tone - When you write for you, on your blog, the tone you establish in your head is yours. This helps surface who you are as a person. It puts your personality front-and-center.
3. Content - What you blog is yours. If you feel like writing an article about a movie you liked, you can do just that. And all the better - again, your personality is front-and-center.
4. Consistency - Let us be honest here, the days of working thirty (30) years for a single employer, and retiring with a pension, are pretty much over. If you change employers, you do not want to lose control over your content.
5. Insight - At the time of this writing, I can tell you exactly what the most popular content on my site is about. If I change employers, I still have that data.
6. People - I get to have a direct exchange with my readers in the comments. I get notified as soon as a comment arrives, can reply with how I feel, and learn about my regular readers.

Content Outlets

As you establish your voice and presence in a community, it is likely that you will eventually be asked to write technical content for other outlets. Usually the first place is your employers developer center, or engineering blog. You should absolutely do this.

• When you publish on an outlet other than your blog, you should also ask about being able to publish that same content on your own blog.
• You need to know who retains control over the content you write. Will you get regular reports of viewer statistics? Can you edit it to keep the content current?
• Seek out opportunities to have other outlets publish content from your blog. If you have content that is getting a lot of traction, other outlets will be interested in that content.

You might consider foregoing a blog and using an outlet such a Medium. Another popular outlet these days is LinkedIn articles. I am not against either of these, but they generally reflect more polished content. This means you may have to sacrifice on any number of those earlier points. These outlets should be considering an addition to your own blog.

Books

If you get a chance to write a book, you should strongly consider it. Having written a book on Adobe AIR, I can tell you that the workload is immense. You need to be prepared for the impact of this on your schedule.

Authoring a book puts an exclamation point on your personal brand. It is one of those things that not everybody has done, or even can do. You can hand them out at presentations, and attend signing opportunities. They make you more desirable as a speaker.

Every. Single. Day.

I know some advocates who publish blog content nearly every single day, and attend conferences only a few times per year. This is a perfectly acceptable approach to developer advocacy. If you find that you have that much content to share, and enjoy the writing process, then the may be the best fit for your personality - and that is great!

I have never encountered a developer relations team that does not value the advocate with a voracious appetite for publishing technical content.

Video

When I first started in developer relations, YouTube was just getting started (founded 2005). Since then, it has become a mainstream outlet for content of all kinds. You do not have to be a developer to know about YouTube. My daughter loves Minecraft videos. Cord cutters (those leaving cable providers behind) look to YouTube as a core alternative.

The power of video cannot be understated. As a Developer Advocate you should select a video content provider. Remember that not all video has to be of something you have done. If you see a cool demo at a booth at a conference, record and publish that. Take a few minutes to interview other conference speakers - maybe even over a beer.

Editing Video

Video takes considerably more time to produce. Generally speaking, you can expect to invest at least two minutes of editing time for every minute of run time. Then there is time to rehearse and record the material. A single five-minute video can easily take up an entire afternoon.

Authoring video content on a Mac is pretty easy these days. QuickTime is provided and can do screen recordings on the spot. If you are using an iOS device, you can even AirPlay into QuickTime to record screencasts of mobile applications you may develop or want to discuss.

Having spent fifteen (15) years at Adobe, I am partial to Adobe Premier Pro for editing. There are many alternatives to consider as well. Eventually, you should get comfortable with some video editing software. Putting fade-in/out transitions and titles in your videos help to make the content feel more professional.

Professional Editors

Some larger companies will even dedicate professionals (or budget) for this task, and have a specific outlet for video. You should get to know these people, and schedule regular time to sit down and capture your latest content. Consider the long tail of that content when deciding what to say, and how to say it.

Bloopers

Remember that your personal brand is important. I like to include outtakes/bloopers at the end of my videos. I do not always do this, but am always surprised by those that find, and comment, about them. These are your videos - let your personality shine.

Duration

I personally prefer to publish videos that are in the five to ten minute duration. I like this time because it keeps editing to a minimum. I also like this time because it is easily consumable. This timing also forces you to be very focused on what it is that you want to say. A rambling waste of time, or video of waiting for software to work (spinning up a server instance), is a sure way to discourage people from returning to your videos.

That being said, longer content is sometimes welcome as well. If you have permission to publish a video recording of you speaking, then your work is already done for you.

I also like to record my own videos of the core of my presentations - just the key demos. Sometimes these tell a story that take longer than ten (10) minutes. The long tail is applicable here. As years go by, and the technology landscape changes, my code may no longer run, but a video allows me to show the work I did in a functioning state.

Backup

I once knew an advocate, who went on to found and sell his own startup, that only ever presented videos of his demos. One time, his entire presentation was prerecorded - he just narrated each clip while on stage. Not everybody can pull this off, nor should they try, but there are some implications.

Everybody knows that conference Internet access is sometimes difficult to manage. Spending weeks getting ready for a presentation, only to have your demo go bust because the Internet was slow or non-existent, is a let down as much for your audience as it is for you. Having videos on hand shows your professionalism, and allows you to still deliver on what you promised conference attendees and organizers.

This also allows you to point to the video URL in your presentation. While more conferences record sessions these days, you never know the timeline or quality. Giving attendees of your talks a means to get access to your content on the spot is immensely valuable.

Social Media

As advocates, we are often the public face of our employers. In this role we are inherently social. Conference organizers will want to know who we are before they accept our abstracts. Attendees will research you to decide if they want to attend your talk.

Twitter

Twitter does not have the pull it once used to, but it is still a primary means for developers to connect. As a Developer Advocate, you should have a Twitter account. You should place your Twitter handle prominently on your slides, your blog, your videos, and any other place or means you use to publish content.

The content on your Twitter feed should not be dedicated only to content relating to your employer - this diminishes your personal brand. Be sure to post content relevant to who you are as a person.

One of the advocates I trained, takes his family to Disney parks on a regular basis. He posts content with a twist during the visits, which he calls "Dark Disney". I look forward to this content almost as much as I look forward to his technical posts.

Your employer may ask you to tweet certain content from time to time. They may even provide you with the blurb. Approach this with caution. If your stream is filled with nothing but content from or about your employer, than you will lose credibility with your audience. Trust is core to developer advocacy, and I cannot trust you to give me technical advice about technology if all you ever talk about is your employer.