I got my first Developer Relations job writing developer documentation for Internet Explorer over ten years ago. Four years of those ten were spent writing documentation for Microsoft or Amazon Web Services and six have been spent spent as a developer evangelist or developer advocate at companies ranging from Amazon to a 46-person startup. Because the holistic view of docs and advocacy/evangelism only really blew up in the past few years, that sort of makes me an elder in the broader field. And I have some thoughts for people considering a career in Developer Evangelism/Advocacy.
Takeaway 1: Make sure there’s a product fit.
It feels like a lot of work to evaluate a product, and maybe there’s just not enough time/energy to do that for every one where you apply, but you have to be sure you are honestly enthusiastic about the product and the company’s mission before joining.
There have been interviews where I was initially excited about the role, but I either didn’t take the offer or withdrew my candidacy because I realized I couldn’t generate enough enthusiasm for the product to be a credible and honest advocate for it.
And for advocacy, understand that, for you, “the product” isn’t necessarily the product the company sells. It may be SDKs or tools that help developers create apps or integrations for your company’s product. I interviewed with a company last year where I loved the consumer product, but the developer product had some foundational choices I’d have to “learn to love” and once I really got past the 30k foot view, the things developers could do with it weren’t exciting me. I withdrew my candidacy.
Faking it until you make it is for duties that you believe are beyond your experience, not for genuinely being excited about your product and customers. Credibility is currency in this role.
If you’re not excited about the product, if you can’t say “this is awesome,” walk away.
Takeaway 2: Does the company understand what you’ll be doing?
Some execs think Developer Advocacy is going to come in and make the company suddenly respected in the industry by creating “thought leadership.”
Ask them whose thoughts they want you to lead. Ask them how they expect you to demonstrate ROI and what your KPIs will be.
If they don’t know, or their answer is hand-wavy, then they’re trying on Developer Advocacy for size and you don’t want to be a pair of pants on the fitting room floor in a few months.
Whenever I think of a company bringing in a Developer Advocate to establish thought leadership, I get this sense of Ed Gruberman asking his martial arts instructor how long it will take to learn patience.
Takeaway 3: Can the average developer achieve meaningful comprehension of the product without a huge investment?
In my opinion, the three ingredients to reach meaningful comprehension are a free tier/trial so they don’t have to pay to try it out, a sandbox where they can play, and clear guidance to get from zero to hero.
A free tier/trial really lets a developer get hands-on with the product, do a couple of self-paced workshops with it, and lasts long enough to do that on their own time. The AWS or Azure free tiers come to mind.
A sandbox is an example app or environment where the customer can try out your services/software:
- Without having to spend hours configuring it.
- Without having to put company confidential information on your servers.
- Without worrying that they’ll break, delete, or overwrite something important.
That might be a Docker file or virtual machine image that lets them spin up an instance to mess with locally, a notebook (like Jupyter), a Postman collection, a Github repository with a bootstrapping script, or even a REPL you host.
Clear guidance is a “Developer Evaluation Guide” which may be different than the one for Business Decision Makers (BDMs). It’s a set of exercises to take them through the features with just enough copy/paste so it doesn’t get tedious, but enough challenges to get them thinking about the problems they need to solve and how they solve them with your product.
This part should take less than half a day and have them leave informed, enthused, and enabled. It should be part of or complemented by documentation that doesn’t suck.
Not every product requires these exact three, but most need some version of them, and they’re crucial to the kinds of products I get excited about.
If the company isn’t serious about providing the right resources, either before you arrive or under your leadership, walk.
There were some other tips I wanted to include about onboarding, defending your time, and determining if the “impossible” you’re being asked to accomplish is really impossible, but those are general career advice I might discuss in another blog post. If you’re considering a career in Developer Advocacy, though, these are my top three. And if you have tips, please share them in the comments.