Getting started in developer relations

illustrations illustrations illustrations illustrations illustrations illustrations illustrations
#Community #DevEx #DevRel #Apple
post-thumb
                   

Published on 21 October 2022 by Andrew Owen (3 minutes)

It may surprise you that the field of developer relations has been around for nearly 40 years at the time of writing. It started at Apple with Mike Boich and Guy Kawasaki on the Macintosh project. But it didn’t go mainstream until nearly 30 years later.

Apple had helped to define the personal computer market with the Apple II. Its killer app was VisiCalc, the first microcomputer spreadsheet. IBM watched as businesses rapidly adopted the Apple II, and its response in 1981 was the IBM PC. By the time the Mac launched in 1984, the IBM PC accounted for around 80 per cent of the PC market.

The Macintosh wasn’t compatible with software written for the Apple II or the IBM PC, and if it was going to be a success, it needed software. So the role of software evangelist was created at Apple to promote the Mac as a development platform. And it worked, because unlike other IBM PC alternatives that launched in the 1980s, the Mac is still around.

In this age of disruption, it’s widely recognized that if you want to get developers to use your products, what you need to offer them is the fastest route to developer success. The once popular Atari ST and Commodore Amiga are now remembered mainly as games machines, if they are remembered at all. You don’t want your product to go the same way.

When I was getting started as a developer advocate, I reached out to someone I’d met at an API conference for advice. They gave me three things they wished they’d heard when they were starting out:

  1. Recognize that you’re wearing, at minimum, two hats. Your developer hat, which should feel familiar-ish, because now you’re not just a developer. You’re also in Product/Marketing/Engineering/Sales, whichever org DevRel sits within at your company. When you accept that you have multiple roles, it will be easier to prioritize the different goals.
  2. Protect your developer time. People will want a lot more face time with you. You can give them face time, up to a limit. If all your time goes towards stakeholder meetings with other Product Managers, you won’t be writing code. You need to keep writing some code, to maintain your credibility.
  3. Your manager should be actively on your side. If not, tell them that’s what you need from them for you to do your job successfully. A supportive manager is very helpful overall, I will personally attest.

He also recommended Mary Thengvall’s book “The Business Value of Developer Relations”. And she recommends Jono Bacon’s “The Art of Community”. The former is also a great read if you’re planning to set up a DevRel department. The latter should be required reading for all community managers.

And now here’s a list of sites that I’ve personally found useful in my role as a developer advocate:

Blogs

Communities

Newsletters

Podcasts

Websites

YouTube

Image: Original by Kjokkenutstyr.