Creating your devrel strategy has to start with an understanding of where you are now. In the last post, I began talking about creating a situational analysis using the COOL framework.
Here we look at the first O: organisation.
Just as we did in the last post with your competitors and the ecosystem around your tool, you must learn as much as you can about your own company.
First up — and this should happen before you take a developer relations role at the company — you need to be sure that the fundamentals are right.
As a developer advocate, your main asset is your credibility. When a company hires you, you’re loaning them that credibility. So you’ve got to be certain that:
If you feel broadly comfortable with being a public face of that company, then that’s a good start.
Again, early on you must determine what the role means to the organisation and whether that suits you.
Broadly, it seems that most organisations want their developer relations teams to do one or more of the following:
As early as you can — ideally during the interview process — you need to learn precisely what the organisation expects of your role. Don’t just take your hiring manager’s word for it, either. In the fluid environment of a start-up, expectations can change rapidly: if you can, learn also what the CEO and board expect.
Of course, it’s not just management that you need to get on side.
If you’re new to developer advocacy, you should probably take a seat before you read this next part: some of the biggest threats to your success will come from inside your own organisation.
It’s not just the soft stuff, either. You’re probably prepared for a bug-ridden release, a cringeworthy marketing campaign or an outspoken engineer who half-heartedly flames a new contributor in reply to a pull request.
At some point in your career, you’ll come across at least one person who somehow works against you. Perhaps they see devrel as a waste of time or maybe they consider the things you do as part of their team’s remit. Either way, prepare yourself to fight for budget, influence and recognition.
Devrel is a fun and meaningful career but it’s new so sometimes you’ll need to fight for relevance.
Next up we’ll tackle the third and fourth parts of the COOL analysis: openness and legacy.
Photo by Nadja Schnetzler. CC-BY-2.0, some rights reserved.
Jamie Wittenberg from Major League Hacking discusses the various ways in which your documentation can lose new developers in this talk from DevRelCon San Francisco 2019.
Write for us