On July 29, 2019 I attended the SF DevRel meetup at MuleSoft. The meetup was held at the Salesforce Tower. Jordan Schuetz and Sabrina Marechal from MuleSoft gave an overview of MuleSoft’s Developer Relations program. The following are my notes and what I learned. Based on what I learned, MuleSoft has an excellent Developer Advocacy team and program 👏.
Sabrina is sharing how she built and mananges MuleSoft community
Nicolas is starting the meetup
Jordan is sharing contet strategy and metrics
Note: I highlighted (bold) their best approaches, in my opinion.
Content is usually one of the core components of most Developer Relations programs. Technical content such as tutorials, how-to’s, articles is a great way to scale your program. Previously I shared how one piece of content can help you create more content and also where to publish content. In this blog post I will share interesting content ideas that you may consider beyond the standard tutorial or a how-to.
There are plenty of web sites where you can publish content. But, what’s the best place? Well, I’m not a fan of “best” anything. Your “best” is up to you, what works for you, based on your requirements and will be different for everyone. In this blog post I will share my recommendations where to publish content and you can use them to decide (or not) where to publish.
I wanted to publish this article for some time and also because of recent controversy with Medium. You can read about it here and here.
There are many web sites where you can publish content. This is just a short list of web sites:
Make users happy and successful with your product/service
Get users to be awesome in the least possible time
Different companies can have different curves
Background knowledge and experience of users (don’t control)
Quality of documentation and teaching material (control)
The actual design of the product/API (control)
The size and helpfulness of your community
We often disagree with Product Managers and Engineers because PMs and Engineers think they are at a different place on the curve. PM and Engineers are familiar with the service/product and usually don’t experience “learning” about the service/product like outside developers
PMs on the curve
Engineers on the curve
Think about the audience (who you are targeting and how to get the pas the suck zone ASAP)
If we can’t get people out o the suck zone before they give up – we will never get them to experience power
Remember, when “talking” to others, to think about where they are on the curve
Use the curve when it helps, ignore it when it is doesn’t
At the end of March I attended the Evans Data Developer Relations Conference in San Mateo. Overall it was a great conference 🥑. I took notes and pictures and want to share them with you here. Just a heads up, these are my notes mostly in bulleted list format, of things that I think I heard and most are not complete sentences 🤷🏽♂️
Session: The Trifecta of Greater Good: Developer Advocacy in Practice via Code, Content, and Community.
Name: Willie Tejada
IBM Chief Developer Advocate Willie Tejada shared IBM’s approach to Developer Advocacy using the Code, Content and Community practice
Large collection of tutorial, blogs, how-to’s, videos
In-person events, community events and community support
Working with organizations such as Women Who Code
On marketing to developers
It’s not true that developers don’t want to be marketed to, they are simply very very educated “consumers”
Willie then gave an example of buying an expresso machine (such as Nespresso)
People will spend a disproportional amount of time learning about the machine and how it works. When they go to the store to buy it, if the sales person knows less than the buyer the buyer will be frustrated. We don’t like when we go to buy something and we know more about the product than the person selling it to us
Everyone can have Code/Content/Community strategy
For a very long time there were to main platform Java vs. .Net. Now it’s a single platform based on K8s
How do we engage a larger developer community, outside of enterprises
Online events is one of the best ways to scale your developer relations program. Online events such as webinars have been used for a long time to reach developers anywhere in the world. After a webinar, the video of the webinar can be shared and uploaded to YouTube (or any other web site). This allows developers to watch the recording who couldn’t attend it live and also by anyone else. Developers can watch it anywhere in the world, any time. And that’s exactly how a video allows you to scale.
This week I attended Evans Data Developer Relations Conference held in San Mateo. It was a great conference with great speakers. I took a lot of notes and will publish a separate blog post about the conference. For now, here are 10 pictures from the conference.
If you in Developer Relations space then hosting and speaking at events is probably a big part of your job.
There are of many type of events that developers go to: meetups, workshops, conferences, online meetups/webinars, Lunch & Learn events, panels and others.
Metrics is the holy grail in Developer Relations. One type of a metric that many companies track is the number of active developers on their platform. Similar metrics can be number of apps created, number services created, etc.
One metric for us is a number of active developers on the IBM Cloud platform. As you can image, that’s a metric for the larger Developer Advocacy organization at IBM and also company-wide. So we got a lot of help.
What is an active developer? Every company can define it differently but usually it’s a developer who registered for a cloud account and created a service (there is also a time window when the developer has to be active).
If you have been doing Developer Advocacy for some time, it’s very likely you heard this question:
“So, how does your solution compare to <insert_competitor_solution>”
This is probably not a question of if (if someone will ask but) but a question of when. This question can be asked at a conference, meetup, workshop, an online forum or even just via email.
There is no right or wrong answer here – as usually in developer advocacy. I want to share some guidelines I shared with my team on how to respond to this question.
Unless you have a deep knowledge of the competitor’s solution and can offer a constructive comparison, don’t offer a comparison. With so many different frameworks, libraries, tools, clouds – it’s not easy to have a strong understanding of how competitor’s products work.
Never bash the competition. It doesn’t make you look good and most likely damages your credibility, reputation and your company’s. It also damages any goodwill you had with the community. It shows weakness.