Why developer relations programmes fail
This one's from Mike Stowe, and was presented at DevRelCon 2016.
Intro
Mike works in devrel and marketing at Mulesoft. This gives him a unique point of view from two teams that sometimes have opposing views.
Most DevRel programmes fail to reach their potential. A lot of them just fail, and it's not because they don't hit certain metrics.
Developer relations is hard work
Developer relations is about building community trust, and trust takes time. It's far more than just blogging and going to events. The return on your investment is slow - you usually don’t see the results of your work until 6 months afterwards. However, it pays off in the long run:
Once you’ve established trust, developers can be some of the hardest working, most loyal advocates you’ll ever have
Their desire to grow in their field, share technologies and change the world is unparalleled.
If your technology is great, they will be at the front line singing it’s praises
Building trust isn't just an external task. Marketing and sales are the two most powerful departments within an organisation usually. They make money for the company and pay our paycheck. It takes time to build trust not only with the community, but our own internal teams
Not having a unified vision
Everyone wants a DevRel program for different reasons. You can’t please everyone, but you need to make sure the right people are happy. Find out who your key stakeholders are and focus your program around what they think is important for the business. In general, DevRel needs to report to the same person as Developer Marketing. If there are two different managers, it almost never works. (@mheap's note: if you don't have developer marketing, that's a whole other problem to solve)
Not having a unified vision means:
Teams have different overall goals
Lack of communication and understanding
Teams work against each other
Developer community interests not a priority
Conflict within teams becomes palpable externally
This is not just a people problem
Not setup for success
Have a single source of truth of conflicts. Who’s your decision maker?
Not understanding DevRel
Developer relations is still fairly new, and most people have no clue what it is. It's a combination of lots of things. It's tech support, it's talent and recruitment, it's sales and it's marketing. It's about selling your product to a certain demographic (and making sure their views are heard within the company too. Relationships go both ways)
Developer relations is about developing relations
You can't focus on a short term return on investment. The meat of a DevRel program comes from the long-term increase in adoption and leads to long tail revenue.
Taking resources for granted
DevRel is hard work. The average lifespan of a developer evangelist is 9-12 months, which considering that it takes 6 months to a year for someone to ramp up means that you're not getting much out of the average evangelist.
Travel is fun at first, but in the long run it's exhausting. These are the people representing your company when they travel, so look after them. Watch for signs of burn out, make them take time off and force time in lieu for travel.
Evangelists are like race horses, they’ll run hard but they’ll run themselves to death
Valuing leads over relationships
There’s a reason we call it developer relationships and not developer marketing. There's a very subtle difference between DevRel and developer marketing, but it's an important one.
Leads are people who you want to do something
Relationships are people who value you, and want to do things for you
Leads are easy and have instant ROI. Scan a badge at an event and you have an email. They’re like bottle rockets, easy to set off but they don't get that far. Relationships are hard, but are like diesel engines - they just keep on giving.
Keep in mind that developers are sales and marketing adverse. If you try to sell to them or take advantage of them they’ll know it, and that’s dangerous when you consider how loyal most developers are (especially when they side with your competition). Developers know they have a particular set of skills, but what they want is to be recognised and valued by others
What you can do:
Don’t try to sell or market to developers
Instead, engage them and find out where they stand and what they liked/don’t like about your company
Listen to all feedback - be slow to defend your product
Let them know you value their feedback and their contribution to the community - recognise their work and their efforts
Keep them involved
Inability to segment markets
What works for one person/group may not work for another. You can look at other DevRel programs, but remember that your product is different to other companies.
Unless developers are your primary customers, your current marketing isn’t going to work. Need to find a new message and tone for them.
What does work:
Forget about “marketing” to developers
Take time to understand developers that are already using your product
Lean on them to help build developer messaging and build a community
Work to empower those in marketing and creative to better understand your developers and how to utilise this new messaging
Whilst developers are usually introverted, they’re highly social and love community
By letting them become leaders in building the community, you’re telling them that you recognise their value
Professionalism gaps
Know your audience. Don't turn up to a developer event in a suit, and don't turn up to a business event in a t-shirt and shorts. If your perceived level of professionalism doesn't gel with what the customer is expecting, they're highly unlikely to engage with you.
Conclusion
Developer relations is hard. It's different in every company, but there is some consistency there. Make sure there's a unified vision for what you want to offer to developers. Don't try and market to them. Instead get them involved, ask for feedback, recognise their work and efforts. Build a community around them and lean on them to help build your developer messaging.