Understanding your organisation before creating your plan

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.

Loaning your credibility

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:

• the product and surrounding service are good
• the people behind the product are good.

If you feel broadly comfortable with being a public face of that company, then that’s a good start.

Aligning expectations

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:

• build awareness and adoption among developers
• strengthen relations with a mature developer community
• take part in the sales process as a technical pre-sales resource.

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.

Friends yet to be made

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.

What’s next

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.