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.

Michael is a polyglot software engineer, committed to reducing complexity in systems and making them more predictable. Working with a variety of languages and tools, he shares his technical expertise to audiences all around the world at user groups and conferences. You can follow @mheap on Twitter

Thoughts on this post

Leave a comment?

Leave a Reply