More on this book
Kindle Notes & Highlights
The Business Value of Developer Relations: How and Why Technical Communities Are Key To Your Success
Read between
February 12 - July 10, 2022
In order for the DevRel team to succeed, however, they must be fully supported by the company. From having a clear set of business goals and expectations to having the right tools for the job, they need to know that their work is seen as valuable and is therefore not only allowed but actively encouraged by the stakeholders in their company.
Table of Contents Part I: What Is the Value of a Technical Community? Chapter 1: An Introduction to Community Establish the (Flexible) Boundaries Why Do You Want a Community? What Do You Hope to Accomplish with a Community? Who Makes Up Your Community? Which Segment of The Community Do You Want to Focus on First? So, Do You Need a Developer Relations Team? Be Willing to Make Changes Chapter 2: Selling Community to Your Company Gathering of the Stakeholders What Are You Trying to Accomplish? Your Version May Vary Setting Expectations Trouble in Paradise All Aboard Chapter 3: Keeping a
...more
This highlight has been truncated due to consecutive passage length restrictions.
A group of people who not only share common principles, but also develop and share practices that help individuals in the group thrive
Without a diverse group of customers, you’ll wind up with biased feedback, which at best can result in a product that doesn’t meet the needs of particular customers and at worst can actively offend the community you’re trying to interact with.
Diversity in feedback and workforce brings a more robust product and community to market.
Each of these questions ties into a concrete business value that aligns with a company goal: reducing churn, having a better product roadmap, reducing customer acquisition cost, recruiting employees, and more. The real question isn’t whether DevRel is capable of contributing value, but which particular value it should focus on at this point in time.
Giving yourself an all-inclusive view of community is great, but it can cause problems when your team is suddenly tasked with reaching “anyone and everyone who could possibly use or is already using our product.”
Narrowing down to an area of focus matters for our jobs and goals.
Why do you want a community? What do you hope to accomplish with a community? Who makes up your community? Which segment of that community do you want to focus on first?
Do you actually need a Developer Relations team to accomplish those goals?
your why drives how you will interact with your community.
the question isn’t whether you’re choosing to create a community or not, but whether you choose to be an active participant in fostering the community that already exists.
your why determines how you choose to interact with this community.
The why doesn’t have to be quantitative metrics—it can be abstract—but it should be aligned with the organization’s goals and explain the purpose behind each community-related endeavor at the company.
Metrics are always wanted, but not always the best indicator on community management or performance
what sets a community apart from a group of customers.
it’s difficult to have a true community without having folks who want to develop and share practices that help others thrive.
True communities have a desire to help each other, whether through contributing to open source SDKs, example code, and documentation or by mentoring other community members.
narrow it down to your primary community: the one that will have the most impact on and benefit for the company, and your secondary community: those on the outskirts who dip their toes into the deeper community issues on occasion.
What problems can you solve? What tools can you build? How can you make their experience better? Why is someone choosing to leave your tool and pursue another option? Even these “exit interviews” can be valuable learning experiences.
A successful product is one that can appeal to developers through its ease of use, attractiveness of the tool, and “stickiness” of the community—and simultaneously win over decision makers with pricing, business solutions, and practicality.
Regardless of whether you’re building an established community of customers or simply engaging a particular market segment, connecting with your customers on a regular basis to make sure you’re on the right path is essential.
the “need” for Developer Relations depends on the company-defined goals: maybe you’re trying to break into a new geographic region or connect to your community beyond the confines of cubicles and desks, or perhaps your goal is simply to build brand awareness. Before committing to a Developer Relations team, make sure you have a clear understanding of the objective.
the primary goal of Developer Relations is not lead generation.
the Developer Relations team should never carry a quota related to a particular number of leads or the amount of money they’ve contributed to the pipeline. The second that any developer community realizes your Developer Relations team simply wants them to sign on the dotted line, you’ve lost credibility with them.
Developer Relations is both the very top and very bottom of the funnel—responsible for brand awareness as well as for making sure customers are taken care of.
DevRel is the people building the train tracks. Marketing builds the train station. Engineering builds the train. Sales drives the train home. It's essential to have each part or the train goes nowhere.
Who outside of your immediate department is involved with the project? What team may be affected by the project’s outcome? Who gains (or loses) from the success of the DevRel team? Can you clearly identify the benefit of this relationship for the DevRel team? If your relationship with this stakeholder improves, does it positively impact your team?
Are you looking to build a community of people who are drawn together solely because of your product?
Are you looking to improve the Developer Experience?
Are you looking to help your company more clearly communicate with your developer audience?
Using the open source community as a way to stay connected to the rest of the customer base can be helpful, as they may be inclined to quickly build out features they’re waiting for rather than wait for the company to implement them.
There’s a fine line between being the advisors and experts regarding the community and being relied on or crucial to every project. This is where documentation is key. As you’re gathering data (whether quantitative or qualitative), make sure it’s being communicated back to the relevant stakeholders so they can make their own decisions regarding messaging, training, and positioning.
It matters that my input is received, but that I am not personally responsible for every facet beyond that.
Having a Developer Advocate embedded in the local community (even if the product isn’t open source) can make a tremendous difference in everything from closing large deals to negotiating conference sponsorships to general brand awareness.
in addition to building relationships with the community, it’s our job to inspire, encourage, and excite the company about the community.
Developers hate being marketed to, and they have an incredibly sensitive awareness meter (or BS meter) for when they’re being pandered to. 2. If a company is genuine in its outreach and actually cares about the community in obvious, quantifiable ways, it can build a large following on social media sites and use it as a valuable platform to promote their product.
Interesting news or ongoing studies Important developments in related areas Relevant events and/or calls for papers (also known as CFPs — the open calls that conference organizers put out to find speakers for events). Community members who have received accolades for their work Potential partnerships Problem areas that your company might be able to solve with a new feature (quick wins—more about these in Chapter 4) Ways to elevate the developer community that is active in or around the languages your product is built in, the technologies you use, or the topics your product falls into (for
...more
Looking for what topic is most important to your biggest customers? Create a list for the developers at that company. Interested in a big-picture look at the technology landscape? Pop over to your list of technology thought leaders. Want to know what your competitors are doing? Take a look at that particular (likely private) list. Hoping to find some retweetable content for a slow Twitter afternoon? Have a list of your company’s developers and another of your top community members on hand to see what’s new and interesting to them.
The ongoing relationship that develops between your social media manager and your Developer Relations team will benefit the entire company. The social media manager will learn the best accounts to follow in order to gain insight into the community, which then benefits the Developer Relations team, who can use that information to strike up conversations with community members, who will feed more information and resources into the conversation, which can then be handed back over to your Product and Engineering teams, who will then take the information into account when determining priorities and
...more
Changelog Work with Product to craft tweets about changes that have occurred, which are posted in the weekly changelog. When patches are made, pull requests accepted, and new versions released to the client libraries, schedule three to five tweets about the changes.
I can start sharing updates from plugins, themes, hosting, and more. Demos about what has changed or is possible
Announcements and operations changes to the API When these occur, work with the person driving the overall communication to make sure the tweets are accurate and correctly represent the change. Schedule three to five tweets (depending on the timeline), increasingly in “pay attention!” mode, until the date when the change is made.
Events When our name goes up on an event site for a sponsorship, schedule around five tweets about the conference and our sponsorship between now and the date of the event. Find the Twitter account and hashtag for the event and follow it. Add the conference Twitter account to the private list of upcoming events so we c...
This highlight has been truncated due to consecutive passage length restrictions.
Set out a basic template with writing prompts. For example: What’s the problem you’re trying to solve? How did you discover the problem? Why is this interesting to other people? How did you solve the problem? How can other people relate to it? Don’t worry about the tone and grammar. First focus on telling a story. Remember, done is better than perfect. There’s always room for edits and rewrites down the road, but getting a first draft down so that you have something to work with is essential.
Dev.to12 is a perfect example of a syndication site that benefits the community as well as the company. With its ability to use canonical links to attribute any traffic back to the original website, you can benefit from the page views and resulting Google-fu while also taking advantage of the fantastic community of curious and engaged developers.
you’ll want your Developer Relations team to continue to foster their own community. After all, their network is a large part of the reason why you hired them—when you hire them, you automatically acquire their following. However, if they begin to neglect that following, you lose some of the value they can provide for your company.
What’s going well? What’s going poorly? What should you be doing differently?
Those who measure things with their brain are looking for the raw data: the number of pull requests on your GitHub repos, the number of engagements on Twitter. This is a quantifiable way to point to the health of the community and, therefore, the value that your team is contributing. Those who measure with their gut have an overall impression of the community’s needs and the right (or wrong) thing to do based on time spent talking with them day in and day out. It’s not a quantifiable thing per se, but it’s no less valid of a measurement and should be taken with the same consideration,
...more
Ideally I’d like to have stats for both quantifiable and intuitive metrics
A large part of the reason why DevRel teams are created is because we have a unique set of skills that allow us to communicate with Marketing, Product, Engineering, and Sales, as well as our community of developers.
going through the hashtag soon after your talk, you can often see which tweets are a direct result of your talk. Collecting these tweets into a Twitter Moment offers you an easy way to reference them down the road, as well as publicly showcase your involvement in a particular event, which can be a nice bump for your personal brand.
Types of people in attendance Geographic demographics Types of developers (front end or back end, specific language preferences, and so on) Job titles (managers, individual contributors, or C-suite or VPs) Sponsor interactions (did people spend a good amount of time in the expo hall?) Caliber of talks (sessions as well as keynotes) Overarching themes from the sessions or hallway track General impression of the conference
Business Development/Partnerships: A potential company to integrate with or list as mutual partners Marketing: A customer to feature in a case study or a community member who’s willing to write a blog post about an interesting way that they’ve used your product to solve a problem Product: A customer who’s willing to give extensive feedback about a new feature or who’s interested in beta testing features before they’re released Engineering: Someone who’s stumbled on a particularly hard-to-solve bug and is willing to help Engineering get to the bottom of it
“An anecdote is nothing more than a short story about something. But anecdote has become an epithet. “That’s just anecdotal” is a common way of dismissing qualitative data. . . . It’s just an anecdote when told in isolation and heard by amateurs. But I’m a professional anecdote collector. If you know how to listen, systematically collect, and rigorously analyze anecdotes, the patterns revealed are windows into what’s going on in the world. It’s true that to the untrained ear, an anecdote is just a casual story, perhaps amusing, perhaps not. But to the professionally trained and attuned ear, an
...more
Once you’ve convinced developers to sign up for an account, you have a limited amount of time to show them the value of your product. No one wants to spend a lot of time or effort setting up and learning a product that might not even do what it claims.
