The well and not so well run developer relations programs
There’s a safe invite-only place for developer relations professionals where I saw somebody asking what do they do if their employer doesn’t really know why the company has a devrel person, and what should that devrel person do.
Thing is, I can relate to this question and many of us in the industry can. It is actually quite common for companies both big and small to just hire an extravert programmer and put him/her under marketing or sales. And it mostly works, don’t get me wrong, but can be so much better for the employer, their developer community and the developer relations person altogether.
The text below reflects on what happens when your developer advocate is sort of the only one in your company who really cares about your developer relations.
Can you hire an evangelist to run the devrel for you?
I’ve spent ~11 years in the games industry, yet now that I have time to breathe out and talk to peers, it looks very similar all around. Like there’s a textbook somewhere that educates how to found a devrel program that you’re likely to want to deprioritize:
- Ship a developer focused product like an SDK;
- Struggle to market and support it;
- Eventually, hire 1 developer relations person to do everything;
- Move that person from marketing to engineering to sales and back at least once a year;
- Restart the program several times with new budgets and commitments;
- See your one and only devrel to fade off or quit;
- Deprioritize the initiative;
- Restart the whole process in a year or two.
No, this is not a personal story, but I can relate to it. Yes, I am being overly dramatic on purpose. No, I am not saying everyone is doing devrel wrong.
There are Googles, Amazons and Microsofts of this world who have full-fledged developer relations programs with dedicated devrel budgets, growth opportunities, training and apprentice programs. Unity Technologies, where I left a part of my heart and soul, is a notable example of a smaller company with a state of the art devrel program.
This long read lightly touches some of the established businesses who start developer relations initiatives without founding a sustainable dx program.
You have shipped an SDK! What’s next?
Let’s take a company that does something for mere mortals — a music streaming service, a book publishing service, — and then there’s a need to utilise the world’s developer community for marketing purposes or just because they can. So the company ships an API and subsequently a developer SDK. They polish the API docs and report the initiative done. After a while there’s a need to justify the costs, so the SDK engagement numbers become important upstairs and devrel comes up as a potential next step.
Now we’ll take a look at another company, who has a somewhat corporate B2B solution — payment, networking or alike. They have a nice boxed solution and lines of sales, marketing and support that deal with the customers. Then they decide to repackage a subset of their product for the startups and other hippies, but cannot justify the costs of using their main sales, marketing, and support machine. Hiring a devrel specialist appears a decent idea.
I can easily come up with more examples when an evident need to hire a devrel specialist emerges. More often than not it is that a company has a new initiative that is suddenly targeting the global developer market, yet their current sales, marketing and support channels don’t suite that new market well. Then HR gets a task to create a job ad to address the challenge.
Developer evangelist or an advocate, developer success manager, customer support engineer, technical account manager — all these job ads target extravert developers, who like supporting others more than writing code inside a peaceful environment of their soundproof headphones.
What can a developer relations program solve for you?
A developer relations program can solve marketing and support problems for a developer focused product. DX and devrel professionals can also be good at technical sales support, developer community management, technical writing and so-called internal evangelism. Ultimately, devrel people may be an invaluable asset to your product and legal teams because of their technical skills, immediate access to the customers and result oriented mindset.
Have you thought about the business problems you’d like to solve with devrel? Can you put down a sorted list, highlight the top 3 and narrow down the main KPI? So what would be the number, the figure, the chart to justify your investment in devrel compared to running the business using the existing processes?
Is it the number of API calls to your cloud? Is it the number of git clones of your open source repo? How do these numbers relate to your quarterly report?
The goal is to see how developer relations are not a cost but an opportunity for your company. But there’s a danger of devaluing your devrel program by attaching it to the sales numbers — those shall relate, but not be tied in. You can think, however, how much do you save by having your developer community do the first line support instead of having a team for it. Or how community created projects can be utilized for PR and presales purposes instead of allocating a team and budgets for creating them. Or think about your alpha and beta channels where your tech-savvy fans test your new features and report bugs. How much do you save on QA and UX/UI research?
But then developer relations specialists need support and buy-in from the whole organisation. They want to grow professionally and have financial and legal means to operate — sponsor something somewhere, to blog on company behalf, publish open source code, influence the product backlog… Your company has to enable the corresponding processes.
Is your developer advocate under marketing? Then do ensure he or she has access to the product engineering team, attends their scrum plannings, is empowered to report bugs and suggest features. Also, think about the growth path for your devrel person. Who does your developer advocate grow into under marketing? Or maybe you need someone less technical who’d want to grow under marketing and not under engineering?
Are you considering putting your DX program under engineering now? Fine, but would your devrel specialist eat on the engineering budgets for all kinds of sponsorships and other marketing and community purposes or would you somehow build a bridge for him/her into the marketing budgets? Also, think about the yearly review when you’re assessing the professional growth of your devrel engineer who spends probably half of his/her time supporting others and solving community and marketing problems. Does your career chart accommodate it?
Is this article 1001 problems and 0 solutions?
I am very bullish about the basics of developer relations when I am about to get a contract to found a program for somebody. I start asking painful questions about the reasons, the KPIs, whatifs and whatsnexts to check up on the attitude and do a reality check.
Sometimes it means I may lose a contract since the company decides to rethink their investment, sometimes the company decides to found a full dx program instead of hiring a devrel specialist and outsourcing the program design to me. But if you remember my last Medium long read, I care about the general health of the global developer relations community more than booking revenue.
And the reason for this long read of mine was to raise awareness of both opportunities and challenges of developer relations. Since it really can be both. And the job for developer relations professionals like me is to enable the opportunities and cope with the challenges.
Please make sure the director who your developer evangelist reports to reads this and schedules nice and honest 1-on-1 monthly meetings with him or her.
As always, your thoughts, feedback and questions are very welcome.
