It’s not your imagination – there are a lot more gigs for developer relations professionals out there than they used to be. If you’re hiring for the role, you know the competition is fierce with more companies hiring more developer evangelists than ever before. The fine folks at Hoopy reported in one of the few regular quantitative views into the discipline that the number of devrel crews over 30 people grew 5x from 2018 to 2019.
If you’re into serving developers, you’ve got a wider array of choices than ever before. But finding a spot where you can do your best work has never been more difficult. Just because a company is developer facing doesn’t mean it is developer focused. Finding which ones have the folks you serve at heart is imperative for a fulfilling experience in this discipline.
With more companies hiring developer evangelists, it can become difficult to know which one has the gig you’ll absolutely love. Figuring that out comes down to one easy question you can answer before you even apply.
Who is your customer?
Way more important than the budget, team size, travel expectations, PTO policy, programming language, support model or even the product is the company’s business model. Whether or not that model will create an environment to do strong work as a developer evangelist can be boiled down to a single question: “who is your customer?”
If the answer is “software developers,” you’ve got a prime candidate to grow your career in service.
Having had my experience working and mentoring with companies approaching developers with wildly different products, those for whom the software developer was the primary customer were those were I was happiest. When the entire company is serving developers, not only is devrel properly resourced but it also benefits from infrastructure from around the company engineered to make their primary customer successful.
Your product engineering team is fixing bugs and releasing features based on what your developers say. Your support team is staffed with the right skills to give your developers a great customer experience. The rest of your marketing organization is releasing content and collateral that resonates with your developers’ sensibilities. Your internal tooling serves as a foundation for all of the teams to make your developers successful.
The alignment around the customer to the exclusivity of almost anything else is what makes a developer evangelism job most fulfilling.
But, [insert company] Is Sooo Cool!
A lot of pretty rad outfits sporting some legit awesome products have developer evangelism openings right now. Those gigs can look pretty tempting, particularly if they are at the edge of some new technological frontier.
But regardless if you’re fostering a developer community for a sleek and sexy consumer electronics product, an industry changing B2B platform, a massively adopted social network, or a blue chip household brand, doing developer relations when the developer isn’t the primary customer is just an endless string of disappointment.
Let’s say you’re looking at an opportunity for a company making a mindblowing set of mixed reality goggles that literally shoot electric rainbows in your eyes causing euphoric hallucination – we’ll call them “Rainbloggles.” Our Rainbloggles are going to have a Rainbloggle SDK (undoubtedly written in BloggleScript) for Rainbloggle developers to tailor exciting new Rainbloggle experiences that they can monetize in the Rainbloggle App Store. Hopefully a handful of these developers conjure up some killer apps for our Rainbloggles that were beyond the resources of our modest little startup to create, those killer apps cause more people to buy new Rainbloggles and that audience inspires more Rainbloggle developers to join the ecosystem. Bingo bongo, we got ourselves a Rainbloggle network effect that is flywheeling our little XR outfit to the stratosphere, all because of the spectacular foresight we had to bolt-on a developer go-to-market. Right?
In practice, the Rainbloggle developers are always going to take a backseat to the Rainbloggle users. Bugs in the SDK will always be at the bottom of the backlog underneath a mountain of user complaints. Developer program spend will get raided every time there is a new content release, trade show or publicity campaign. Minor changes to the documentation will require hours of cumbersome interdepartmental negotiation with all the various product, engineering, marketing and sales teams that have their tendrils into your website. Getting developer support will require endless panhandling in front of inattentive conference rooms.
Most insidiously, at some point because through your supernatural perseverance and commitment to serving the developer, one of them is going to have a breakout hit. That will be when the job is really going to suck.
That runaway success for your cherished developer will result in some heavily taxed short-term gain, but will almost certainly become a feature in the main product. That betrayal will reverberate throughout the entire community you built, cannibalizing your developer brand to eke out another 10-20% in consumer growth. Developers will never trust your company again. Blessfully though, they’ll still love you.
Every Company Has One Customer
The cold truth of business is that a company can really only have one customer. And when that customer is not the developer, the role of the developer evangelist will suffer from resource constraints, organizational support and – most importantly – fulfillment for you and the developers you serve.
The good news is the number of developer-focused companies is exploding every month. The growth of the business-to-developer model means not only has there never been more developer evangelism jobs, but there has never been more good developer evangelism jobs.
With such variety and red hot demand, staying at a devrel gig at a company that just doesn’t get it is not something you have to do any more. If you want to serve developers, you owe it to yourself to be surrounded by those who want to serve developers too.