The first step in building a developer relations strategy is understanding where you are now.
If you were a traditional marketer, this is where you’d do a situation analysis. Most likely that would take the form of a five Cs analysis:
As Developer Advocates we are interested in many of the same things but perhaps with different emphases. So rather than five Cs, we’re going to analyse our situation with COOL:
Yes, I feel some shame at coining a corny new acronym but, I swear, it just came out that way.
If we consider community in a fairly broad sense, then it lets us look at where your project sits in the wider world, including:
It’s unlikely that your project stands alone. Even a teleportation system written in Go with a ReactJS front-end would have competitors: walking, cars, planes and staying at home being amongst them.
First up you need to identify your project’s competitors. Make a list of any tool, service or software that either:
Your marketing colleagues will perform a similar analysis so that they can position against those competitors. For us, the criteria we analyse are a little different to what might interest the marketing team but it’s still all about giving us the understanding we need to position ourselves credibly.
For each competing project, and your own, make a list of:
Pretty quickly, you’ll recognise two or three of the following:
Take the time to learn what your competitors are doing in developer relations: attend their meet-ups, join their forums, read their blog posts, follow their advocates and engineers on Twitter, and most importantly of all: try their stuff.
Install their code or sign-up for their API and make something. Make something that gives you a visceral understanding of what a developer experiences when working with that project and take plenty of notes.
Understanding your competition is mostly about preparing yourself to position against them. It’s not too hard to infer a company’s intentions and strategy from its actions. Once you know what everyone’s up to, and how they’re perceived, you can incorporate that in your plan.
Understanding your non-competitor ecosystem is a little less clear-cut. Your relationship with an open source project that repackages your own, for example, isn’t as straightforward as your relationship with a competitor. Often you’ll find yourself dealing with individuals whose intentions aren’t easy to divine. Similarly, instead of positioning against members of your ecosystem, you’re looking for ways to co-operate even though some of your aims might not quite line up.
Your project falls in the middle of an ecosystem that features:
All parts of the ecosystem have a role in the success of your project but the particular balance of upstream, sibling and downstream will be specific to your project.
Just as you did with your project’s competitors, you should draw up a list of projects and organisations in your ecosystem and categorise them according to:
Next, for each ecosystem project you should identify:
Community, in the context of a software project, can mean a lot of different things.
If you’re from an open source background, that might sound like nonsense. Of course, you’re thinking, community can only exist around an open source project.
Then you meet a marketer who has been working with BI tools for the past decade. He tells you that he knows all about community. Community, to him, is a purely passive thing. His community is made up of business analysts. Their meet-ups are mid-afternoon in swanky hotel conference rooms where everyone is in smart business dress. They expect a sales pitch or, perhaps, high level tips on how to get more out of the expensive BI tool that brings them together.
Although we’re focusing on developer community, you should be prepared that not everyone understands what that means.
At this stage you need to learn two things:
Once you understand what your colleagues, executives and investors mean by community then you can begin either to shape your thinking to include their needs or begin planning to adjust their view of what developer community should mean for your project.
Next, you need to evaluate what developer community, if any, already exists for your project. Broadly, you’ll find it to be in one of five life-stages:
As someone new to the community, whatever stage of life it’s in, you should take note of the internet’s most important maxim: lurk first. You need to gauge the culture and sentiment of the community before you try to do anything other than introduce yourself.
If your tool is hugely popular with government sector 9-to-5 Java developers, you might wanna hold off on that order for 1,000 t-shirts featuring an obscure Hitchhiker’s Guide to the Galaxy reference.
That’s not just a throw-away joke: you’ll get a strong indication of culture by understanding the language, framework and operating systems preferences of the developers using your tool. Speak to your colleagues in pre-sales to find out what customers are doing, look at language-specific driver download stats, trawl GitHub, search blogs and watch Twitter.
Once you have that basis, hang out in the places your developers hang out. Maybe that’s IRC, maybe it’s a .NET meet-up.
Of course, the culture of your company will also have some effect on the culture of your community.
In the next post we’ll look at organisation and how you as a Developer Advocate put your reputation on the line each time you take a new job.
Can you make good release notes by collating your commit messages? Eva Parish argues not.
Can negative feedback from customer satisfaction surveys have a positive impact on your developer experience?