Content (articles, tutorials, videos) is one of the best ways to scale your Developer Relations program. Once content is published it can be consumed by developers any time, anywhere in the world. You are no longer limited to just the local developers coming to a hands-on workshop (of course hands-on workshops have other benefits, but that’s for another blog post). Here are some of the recent blog posts I published that cover content creating and publishing.
The model says that to influence someone to do something, you have just two levers:
- Motivation – how much someone wants to do something
- Ability – how easy it is to do the thing
The third component
- Prompts – is a call to action, trigger or cue for a behavior to happen
So, could this model be applied to developers? Let’s look at each component and see how it can be applied to Developer Relations.
So what can motivate developers? Here is a list of motivations:
- Solving a (challenging) problem (at work or a personal project)
- Giving back to community. For example, contributing to an open source project
- Career growth, personal growth, learning
Ability is how easy it is to do something. I think ability has a strong connection to Developer Relations. We (Developer Advocates) always strive to make things easier for developers. A big part of this is making our documentation, tutorials, videos, guides and everything else easy to follow and complete.
In June at DevRelCon in San Francisco, Steve Pousty gave an excellent talk called The Kick Ass Curve for developer relations. I recommend you watch the talk, one of the themes from Steve’s talk was that we need to make things easier for developers so they can become successful, and fast.
A prompt is a call to action, trigger or cue for a behavior to happen. In the context of Developer Relations, a call to action can be a hands-on workshop that a developer can attend, or an online event. It could also be a friend recommending the technology. It can also be an interesting and easy to follow step by step tutorial that you saw in an email newsletter, an interesting blog post, article or an interesting tweet. All these prompts can lead to: “hey, I want to try this”.
Looking at the Fogg Behavior Model, we want to stay above the green Action line. Staying above the line means a developer is motivated, and it is easy for her to complete something and the prompted has worked. I believe most developers are very motivated. Where we can make a bigger difference is in the Ability. To make developers successful, we need to strive to make things easier such as produce high quality documentation.
There are probably other ways to apply this to Developer Relations (or I might be complete off, hey, who knows). Would love to know what you think, please leave any feedback in comments.
If you want to learn more about the Fogg Behavior Model, you can pre-order BJ’s forthcoming book, Tiny Habits: The Small Changes that Change Everything. For the first time ever, BJ explains the Behavior Model in depth for a global audience. tinyhabits.com/book.
I recently subscribed to #saashackers daily newsletter. Every morning you get a short SaaS growth case study in your inbox. It’s a quick 3-4 minute read that I recommend you try.
Today’s email talked about Mailchimp and how they got to $400 million in revenue from just 550 employees.
What caught my eye was this image and the text that followed:
text after the picture:
They are selling an outcome, not features.
They are selling the thing people actually want, not their software.
Whether you are a direct to consumer brand with 50,000 customers or a mommy blogger with 1,000 subscribers, you want:
- To build relationships with your customers
- To increase sign up (by 250%)
You don’t (necessarily) want:
- Email templates
- CMS integrations
And this has a very close connection to Developer Relations (or Developer Marketing).
We should be sharing outcomes and results, not features. We should be showing people how to solve problems, not our software.
I’m sure most of you know this but I think it’s worth mentioning. I personally tend to forget about this (sometimes) and also it’s much easier to talk about features than benefits.
Most of you probably also said: “wait.. this is not new at all” 🤦♀️🤦♂️
You are absolutely correct 🤩
Adam DuVander has created and shared this wonderful page: Share Knowledge, Not Features: The Secret of Marketing to Developers is to Not Use Marketing. It’s Developer Relations classic and my favorite Developer Relations resource. I highly recommend you read and bookmark this page. Adam explains that we should be sharing knowledge, not features.
So, let’s try to share outcomes, results, problem solving and knowledge, not features✌️
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 👏.
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.
You will learn about the following content ideas:
- Notes or summary from a conference, meetup
- Event in 10 pictures
- Links to series of articles
- Links to previous month video recordings
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.
There are many web sites where you can publish content. This is just a short list of web sites:
- Medium (plus various Medium publications)
- Devada (formerly Dzone)
- LinkedIn (Publishing platform)
- Personal blog
- Work blog
- and many others…
I attended DevRelCon in San Francisco on June 6-7. It was a superb event, with great speakers and awesome community. The following are my notes (not complete sentences) and pictures from the event.
Being Better At Developer Relations with Kathy Sierra’s ‘The Kick Ass Curve’
Steve Pousty (CrunchyData)
- Steve’s talk focused on how to be better at Developer Relations. Steve demonstrated this concept using Kathy Sierra’s “The Kick Ass Curve”
- You can find his slides here
- DevRel goal
- 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
- 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 Code Patterns
- A Code Pattern is
- 360-degree of the solution
- Code on GitHub
- Architecture/flow diagram
- Video, tutorial
- Helping developers solve problems quickly
- 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
- In-person events, community events and community support
- 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
- Call for Code
- Invite 22 million developers to solve disaster preparedness problems
- Engage developers outside IBM’s core (enterprise dev.)
- Ask them to help with solutions to help with disaster preparedness
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.