Developer Relations  🔗 **Source:** [Developer Relations]() ## Highlights - Part I: Develop a Common Understanding Chapter 1:​ What Is Developer Relations?​ Chapter 2:​ Where Does Developer Relations Fit?​ Chapter 3:​ The Origin of Developer Relations and the Rise of the Developer Chapter 4:​ The Value of the Developer Economy Part II: Key Differentiators Chapter 5:​ The Audience:​ Developers Chapter 6:​ Developers As Decision Makers Chapter 7:​ Developer First and Developer Plus Chapter 8:​ Business Models and Monetization Strategies Chapter 9:​ Developer Products Part III: Alignment on Goals Chapter 10:​ Company Goals and Alignment Chapter 11:​ Program Goals Part IV: Go-to-Market Chapter 12:​ Developer Segmentation Chapter 13:​ Developer Personas Chapter 14:​ Messaging Chapter 15:​ The Developer Journey Chapter 16 :​ Discover Chapter 17:​ Developer Experience Chapter 18:​ Evaluate Chapter 19:​ Learn Chapter 20:​ Build Chapter 21:​ Scale Chapter 22:​ Developer Marketing Chapter 23:​ Events Chapter 24:​ Sales Chapter 25:​ Community Part V: Managing and Growing Your Program Chapter 26:​ Metrics Chapter 27:​ Team Chapter 28:​ Program Phasing Chapter 29:​ Epilogue Index - In general, practitioners in the field have agreed on “Developer Relations,” shortened to “DevRel,” as the all-encompassing term. This term includes developer marketing, developer evangelism, developer advocacy, developer support, Developer Experience, developer education, developer success, developer community relations, and the management of developer programs. - Developer Relations is both: The professional practice of engaging with developers as the primary user of a product, generally outside of one’s own company2. The program or set of activities within an organization that interact with Developers on their journey with your product and company. - DX. It is the equivalent of User Experience (UX) where the user of your product is a developer. DX includes their interactions with your product, developer hub, and documentation as they learn and begin to build. - Note: Developer experience is the process of evaluating how developers interact with your products. - Developer Marketing is the set of outreach activities designed to create awareness as developers discover and evaluate your product and program. - Note: Want developers to find your products and services? Marketing that is specific to developers comes into play. - Developer Education, also referred to as DevEd , is critical to the adoption of your product. You will need to provide a comprehensive set of content and learning resources in a variety of formats. - Note: Technical documentation writing is part of DevEd. It takes more skills to consider what training devs would need related to your products - Developer Success provides support to developers as they go from trialing your product to building a full-blown commercially scaled product. As a functional role, Developer Success varies and may overlap with product, engineering, sales, support, and your community team. - Note: Beyond answering support forum questions, developer success can include ongoing outreach as continue training developers about new features, additional integrations, and continuing in the journey as developers - Critically, a tree cannot exist without its trunk and roots, analogous to a successful program being predicated on a vibrant community . The whole point of your program is to engage, serve, and nurture your community. This is what your success will be built upon. Without a healthy, sustainable community, you have little chance of success. - Note: DevRel is a community of developers - If you come from a product background, understanding your target customers’ needs and designing a compelling product experience for them is the norm. - Note: The target customers are developers. They are especially particular about what they want or need and demand exceptional quality of service. - If you come from an engineering background, you might think marketing, or heaven forbid, sales, is something you have no interest in at all and that it couldn’t possibly be related to anything to do with developers. - Note: DevRel includes marketing to developers. - you come from a marketing background, much of what you see in a typical Developer Relations program will look very similar to traditional marketing and sales efforts in either B2B (business-to-business) or B2C (business-to-consumer) companies. - Note: Developers may not respond to traditional marketing methods well. - Talking directly to your customers and potential customers in a direct, friendly, nonsales, noncorporate way and amplifying and showcasing your customers’ work, achievements, and community contributions are not exclusive to any one business model. - Note: Building rapport via transparent relationships is more important than sales. - What is important is to have a good understanding of which functional areas influence Developer Relations to aid and tune your strategy, discussions, decision-making, and relationships within your organization. - Note: DevRel encompasses quite a few areas. Pick an area to focus on. - One role that DevRel plays is as a critical liaison between the company and the external community of developers it serves. This community may include influencers, prospective customers, active customers, previous customers, partners, and even media. - Note: Developer Relations advocate internally for the customer, and their own jobs. They also coordinate externally with influencers, media, and customers at all stages in the journey. - In her book,3 Mary Thengvall attributes this quote to Ewan Davis: “To the community, I represent the company To the company, I represent the community I must have both of their interests in mind at all times” - 1 – Your primary target audience is developers. - 2 – Your strategy and tactics are designed to change developer behavior. - Fine-tuning your Developer Experience to remove friction at all stages is critical to your success. - 3 – Your internal definition of success is predicated on developers. - In Part II, we’ll look at what differentiates DevRel and why it requires changes to both your strategy and tactics. The key differentiators of DevRel we’ll review in this part include: The target audience and developers as decision makers. Categorizing the organizations pursuing a Developer Relations strategy – Developer First and Developer Plus. The Developer Relations business model – Business to Developer, or B2D, and its variations. The types of developer products. - We are not sure any group of individuals “likes’’ to be marketed to; still, this truism is very relevant to developers. - Respect the differences between traditional marketing and marketing to developers. You can’t inherit regular marketing practices because developers are different. Tone of voice is crucial, avoid embellishments and provide context for what the tool is and can do. And focus on use cases to give your developer product a chance to succeed. —Anthony Fabbricino - Whether it is their nature or schooling, developers tend to be logical and systematic thinkers who value efficiency and optimization. They are critical thinkers, crave data, and have little tolerance for those who masquerade as “one of them,” but don’t really speak their language or understand their issues. - Err on the side of being factual about your product in your messaging (see more in the chapter on messaging). There is freedom for your communications to be much more technical and specific than traditional mainstream marketing. Less fluff, more substance. Have developers review your messaging for accuracy and tone before you make it public to avoid potential problems. See an example of clumsy marketing to developers in Figure 5-4. - Motivation, experience, passions, and types of education combine to vary a developer’s ability to create. Think about what you can provide to entice developers to engage their imagination and passion with you and your product. Focus on the desired outcomes, not activities. It’s about “the art of the possible” – what developers can build with your product. Developers aren’t all highly creative, and they can’t read minds, so help them by painting a picture of what is possible and what is practical for specific industries or verticals with learning resources like use cases and showcase projects. - Provide developers with the means to “see” quickly how your product works by offering code samples, quickstarts, or getting started guides in your documentation (more on this in Chapter 17). Peer reviews, recommendations, and showcase projects will be far more compelling than any marketing speak you can create. Developers want to be the first to know, but not necessarily the first to try. Incent early adopters to take the plunge. And recognize community members who lead the way for others – and they’ll keep doing it. Provide more self-service options like sign up for free, no credit card entry required, free credits to encourage immediate experimentation, etc. - Who Makes the Decision? - Consider the developer organization’s structure and context : Is it a one-person band, is it a startup, a small agency, or a large enterprise? - Consider your product’s context : How widely will it impact the organization and the products it is developing? Is it a tool an individual contributor would choose to use (say, a text editor), or is it a more strategic component that would integrate into a mission-critical application that can only have 00.001% downtime each year? - An Initiator – The person who begins the process by raising awareness internally. This could range from a developer who found your product via a Google search to an internal purchasing or procurement person responsible for sourcing the organization’s technology needs. - A Technical decision maker – The person who evaluates the technical aspects, such as compatibility with existing resources and the fit with the company’s technical strategy, security, reliability, and so on. This could range from a technical lead on the development team, a Product Manager, someone in DevOps, or the company’s CTO. - A Business decision maker/budget holder – The person who evaluates the commercial aspects including pricing, business model, and return on investment and gives approval to make the purchase. This could be the founding team at a startup, a CFO, a specialist procurement person, or C-level management. - Influencers – The people who may not have explicit decision-making authority but can influence the overall decision. This is usually internal developers who have tried your product firsthand and so are in the best position to provide input. - An Approver – The person who makes a final yes/no decision. This can vary widely depending on the organization’s size and structure. - Who has the need for our product or understands its benefits? Is it the coder, is it the product manager responsible for monetization, or someone else? Make a clear technical and business case available to the DDMU, customized to their specific situation and context. Deliver this through customer presentations, product fact sheets, whitepapers, references in analyst research reports, case studies, example apps, etc. - Who will implement our product? This could be a coder, a QA specialist, DevOps, data analyst, customer support, integration specialist, etc. To this group, emphasize ease of use and implementation through documentation, forum support, quickstart guides, and example code. Offer practical support like hosting an internal hackathon to get the company’s developers hands-on with your tech. - Who is the ultimate decision maker? Is it the individual developer, a team manager, a CTO? They need to see the summary and outcome of the business and tech cases – the combination of the why and the how. The following can be the most persuasive for the decision maker: testimonials, case studies, cost-benefit analysis, and quantified ROIs. - Developer First (Dev First) companies create and sell products specifically designed to be used by developers. - Note: Dev First companies offer products and services intended to be implemented by developers. - Dev First go-to-market strategy is aimed at a bottom-up approach in considering developers not only as the main user of their product but as the main decision maker in the buying process of their product. - Note: Dev First companies include developers as the main decision makers. - Developer Plus (Dev Plus) companies’ primary market is selling products or services for businesses or consumers. In addition, they also have products available to developers, which they believe benefits their strategy in some way. - Note: Dev Plus companies are those who have products and services for a wider audience, with developers including a subset of that. - DevRelBook.com. - The business model for Developer Relations is called “Business to Developer” or B2D. - Tags: favorite - It’s not about selling a finished product; rather, component pieces or tools are offered with the promise that something could be created. - Note: Lego sells kits to builders, expecting them to develop pieces into a final project. - A component or tool is created by the organization. There is marketing to create awareness, but the marketing isn’t focused on pushing a finished product. It is centered around inspiring developers in how the component can be combined with other technologies to create or enhance a different product. The priority of DevRel is to remove any friction that would stop or delay the developer’s success in adopting the components. - Note: Rather thank focusing on how developers can use our tool, we focus instead on the needs of developers, showcasing what they are building. We focus on understanding developers needs. - Here, learning resources like blogs, case studies, and even tweets can all serve to inspire developers and show what’s possible with your product. However, these must be backed by resources like technical documentation and code samples which provide the instructions on which bricks to use and how they snap together, crucial to enabling developers to embellish on your basic blueprints. - Note: Personable and informal resources are great, but secondary to official documentation. - define: Your customer’s major jobs to be done. The pains they face when trying to accomplish their jobs to be done. The gains they perceive by getting their jobs done. While mapping your products and services, how they solve pain points and how they increase benefits and drive better outcomes. - Do consider that developers love to see your product road map , as it gives them confidence that you have thought about future development, you plan to be around for a while, and they have the opportunity to provide feedback on it. - Note: Look for the product roadmaps. Developers love to see the direction of your organization and know what’s in it for them. - Understanding your company’s direction and setting program goals that link your activities to the things that are important to your company while demonstrating DevRel value can be hard. - Note: Look over your company’s goals and demonstrate how DevRel will benefit those goals. - In Developer Plus companies , the environment can vary enormously, but always be aware that your activity is likely not viewed as core to the business. Therefore, your job is to educate your stakeholders to ensure you have the air cover you need to flourish. Find ways to connect your endeavors to the core goals and priorities of your department and the company. - Note: Developers as customers may not be the primary function of my role. As such, I need to continually elevate the value proposition of my own role, and developers as our customers. - Your program will be under constant scrutiny, and disruption and distraction could be hiding around the corner, even when things seem to be going well. - Being armed with data and other evidence to show your impact is your best friend in these situations. - What is the purpose of your developer program? What do you want your developer program to achieve? What value will it bring to your organization? What value will it bring to the developers you want to serve? - Unfortunately, most companies hope for instant results from their DevRel Programs, not realizing that it’s a longer-term play of 3-5 years. They don’t invest that long and thus have problems with gaining momentum and adoption. - Note: Growing a successful DevRel program can take several years. - To contribute to the company’s revenue by growing the size and reach of our program To increase our reputation with developers and/or become a thought leader in our field To remove the friction in our Developer Experience To lower our support costs while improving the support experience To improve and speed up the feedback loop for product enhancements and new product development To gain knowledge and expertise in running a developer program - Some of the variables to be aware of that will influence your goals and planning include: Corporate goals Number of products you must support Number of staff on the DevRel team Skill set of the DevRel team Where DevRel sits in an organization Whether you are a Dev First or Dev Plus company The business and pricing models of the DevRel products Is the Developer program a cost center or profit center Timing of any corporate announcements or expectations Geographical considerations, like product availability or localization Age of your program Status/age of your products (new to the market or sunsetting) Status of competitive products Your program budget - At least one of your program goals should show how the developer program is contributing value to the business. - your high-level objectives are Awareness , Activation , Engagement , and Retention - To effectively reach developers, you must first understand several things about them: Their motivation – Why do they do what they do? Their skill set – What tools and resources do they currently use, and what gaps do they have? Their goals – What do they want to achieve? Their mindset – How do they evaluate and make decisions? The demands on their time – Where and how do they need support? Their limiting factors – Skills, budget, existing infrastructure choices? The demands on their attention – Who are you competing with for mindshare? - segment your developer targets. The four filters are: 1. Technical (product focused)   2. User (developer focused)   3. Organization (customer organization/use case focused)   4. Market (industry vertical and geography focused) - Is the segment relevant to our business?   2. Is it a large enough segment?   3. Is it a valuable enough segment?   4. Can we target this segment based on our resources? - Personas make it easier for everyone, whether you are creating your product and documentation or writing your messaging. The more specific you can be, the easier your job gets - Name (ensure these are representive of different cultures, ages, and genders) Photo Job title/type of developer Type of company and industry where they work Type of technical skills they have What they are working on and for who (use case) Type of experience they have relevant to your product Their particular issues and pain points as developers Their level of decision influence Where they look for information about new developer products Their awareness of your company and product Their particular interest in your product (what will it help them solve) Pricing thresholds if applicable - What type of product is being offered? What does it do? How does it make a developer’s life easier or better? Why should a developer use it? Why should a developer choose it over competitive offers? - As a note, developers tend to respond better to a voice that is down to earth and not too corporate. You may find that your company’s corporate voice is different from the voice you use with your developers. - In addition to developers, elements of your messaging will likely need to target executives or other decision makers as they are often required to support or approve the adoption of your product, especially if your segmentation has identified larger and more complex organizations as opportunities. - Separating developer-centric and stakeholder-centric messaging and marketing is sensible. - If you map your messaging to the developers’ stage in your developer journey, you can be more focused and relevant. - Tone and voice (as discussed earlier) Heroes, halos, and stories Keywords – Features Keywords – Benefits Differentiation Key statements - Ask Your Community for Feedback You’ll find most developers are very willing to provide feedback. All you have to do is ask them and provide a method for them to respond. Gathering feedback can happen through: Your support channels – Set up a channel for feedback, and monitor your channels/forums for comments. Survey your community through online survey forms. Talk to them at events by deliberately asking them – How are we doing? What can we do better? Host regular Office Hours for them to ask questions. Host developer focus groups. Review your support tickets. - Friction Logging/Friction Audits Friction logging is the process of actually walking through the developer journey to audit its effectiveness. The goal is to “step into the shoes” of your target developer. - Journey Data Evaluation and Measurement It’s essential that you have set up your Developer Hub and product with data collection and analytics mechanisms - What are you offering? Is it compatible with their existing technology stack? Is it a tool that could solve their current problem? Are you credible? Has anyone else used it? - Internal touchpoints are those which you can directly control, or affect, to increase awareness and discovery, such as: Search engines – SEO and paid advertising. Content marketing – including social media, blogs, newsletters, webinars, etc. Your own events. - External touchpoints are those which you don’t wholly control, but can influence indirectly to help grow your reputation, such as: Blog posts or articles that someone else has written that mention your products. Public relations activity leading to press coverage. Analyst relations activity leading to favorable positioning in research reports. Product search sites like Product Hunt, G2, etc. Online developer communities and resources. Events run by others, where your own people or people independent of you are discussing your product. These interactions take place face to face or online and in different formats like conferences, meetups, hackathons, and more. A referral from a friend/colleague. - online developer communities, programming sites, and platforms, such as Slack, Discord, Subreddits, Stack Overflow, GitHub, Code Project, and many others. - Where they land on your website must be a key focus of your developer journey. - developer.yourcompany.com or yourcompany.com/developer – These are standard formats for URLs to developer hubs, which many developers directly type into their browser bar or search engine. - Developer Experience (DX) is the experience developers have when they interact with your product and documentation. - DevRel professionals are there to advocate for the developer in a number of ways: Act as an information valve (Figure 2-3) educating developers about the product and any changes to it in a timely manner and bringing developer feedback to the product team. Work with the product team on the development and use of personas, so everyone is creating for the same user types. Your internal developers can then base their user stories around the personas for which the DX is being designed. Encourage the product team to measure the developer journey inside the tool/product to identify areas of friction. Ensure the requirements of your developer community are front and center when discussing product road maps to ensure those needs are being met. This can also include identifying potential “breaking changes” and what the community must do to avoid or prepare for them (e.g., download updates, switch to a new API version, perform a set of migration steps, etc.). Research and keep up to date with community and market trends to help advance and improve your DX. Consult with the product team to ensure they understand what DX encompasses and that there is buy-in from the management level. - you ensure that the content is up to date – this is critical. Nothing undermines confidence in your offering or builds frustration faster than out-of-date or inaccurate docs. - Note: Maintaining current documentation is a high priority for developer users. - Often, the job of creating the documentation falls on the engineers that created the product. They need to be involved; after all, they know the product best. However, being the closest to the product can also be a major disadvantage. - Note: Are engineers good at technical document writing? They want top-notch technical documents, but may not have the mindset for creating these. - have a technical writer or team of technical writers. These writers are often part of the Developer Education team, who work in conjunction with the product and engineering teams to build the documentation. - Note: Technical writers synthesize the information from developers into quality current documents. - Evaluate Touchpoints and Developer Education Resources - Product Pages - Documentation Landing Page - FAQs - Use Cases and Case Studies - Use cases illustrate common uses of your product, giving the developer an idea of what is possible and what kind of problems your product can solve. - Case studies, on the other hand, describe a real-world solution implemented by one of your customers using your product. - Don’t be afraid to actively seek dialogue with new and existing customers – the answers to their questions will be there to help others with the same issue further down the line. - The term “webinars ” covers a number of different formats, from the traditional playback of a prerecorded presentation + live Q&A session through to live streams of coding on platforms like YouTube and Twitch. - We saw Forums in the earlier Evaluate stage, and they continue to play an even larger role in Learn. Developers will look for answers to particular issues as they start getting hands-on with your product. - Note: How are developers wanting to ask questions? Do they know about our forums? Is that what they want to use? - additional learning resources including ebooks, whitepapers, video tutorials, podcasts, games, project submissions, and other types of content. Many programs have a dedicated learning resources section of their developer hub where these extra resources can be found. - Office hours are where you set aside time for developers to ask you questions directly. - To supplement the self-learning style approach of the content outlined earlier, you may want to consider formal training programs. - Note: What formalized training programs do we envision as part of the corporate brand? - A key element found in many of today’s technology offerings is their “extensions” – the components that allow for integration and customization, expand functionality, and provide extensibility. - Note: Extensions translate well to smaller plugins that add additional functionality within WordPress. What would be an extension in terms of hosting sites. - A sandbox is an environment that accurately reflects your live environment. Common examples include test servers with fake data, downloadable containers and virtual machines, interactive “playgrounds,” console windows embedded in your docs, etc. - Note: Sandbox sites are a powerful way to help care guides and support staff have a place to get quickly set up. They are also a great way for developer customers to test our environment. - Often found toward the end of your docs’ table of contents, reference guides are those invaluable topics which provide detailed information about technical specifications, APIs, architectural details, etc. - Publish and maintain a changelog . As we have stressed throughout, having simple, clean, and accurate documentation is one of the key ingredients to success with developers. - Note: Consider the change log to be more than personal revision notes about submitting PRs. It is a public facing area. - Be clear and upfront with your hours of support coverage. Set expectations on your average response time by defining this up front, as it helps to defuse frustration in this increasingly “on-demand” world. - Note: Clearly community SLAs and how developers can elevate their support requests beyond user level. - Typically, your product docs, quickstart guides, and code samples are all oriented toward a developer who needs to understand a specific method to achieve a stated goal. Now storytelling comes to the fore, explaining how your technologies fit into the big picture, sharing new ways of working, and defining best practices. - Note: Quick starts and docs both have their place. Consider making both areas available to devs. - SLAs, or service-level agreements, are one example of performance that is stated and measured and agreed upon between you and your customer and may be monitored by an Ops team. - Note: What is your own service level agreement? - Your developer’s success is attached to your longevity, and any changes you make will directly affect them. Therefore, it’s incumbent on you to let your customers know where your product is heading through sharing your product road map. - Note: Showing a public roadmap and that you match the delivery expected helps build trust and rapport with developers. - Tags: favorite - Case studies are the stories of the developers that have created something meaningful with your products. - Note: What are meaningful things developers have created with your product? Showcase that. - Look for opportunities to build meaningful relationships with them via events and parties – make them feel part of a larger positive movement. - Note: Create a community of developers. Provide a sense of belonging. - Ambassador Programs , sometimes called Champion Programs, are a way to recognize, empower, and reward community members that go the extra mile in promoting and supporting your program. - Note: Offer value to developers that are part of your community with ambassador programs. - Partner Programs vary but typically represent a new channel to market that would not be possible without the partnership. - Note: Partnership programs at GoDaddy Pro could look like reseller accounts possibly. - Finally, you may create a certification program for your product. - Note: What would be a developer specific certification? - All of the developer marketing tactics are typically designed to achieve one of three things: Create awareness Create leads and ultimately revenue Build relationships by nurturing prospects and existing customers - Every organization is different, but the “front end” of the Developer Hub is often the responsibility of marketing. The “back end” of the hub, which houses the Developer “Console” or “Dashboard,” the actual tool, and usually includes the functionality behind product registration and login, falls into the realm of Developer Experience and the product teams - Note: Front of site often falls to marketing. Partner closely on the messaging for front of site. Logged in training and resources are the work of developer experience staff. - It can be increasingly difficult to separate business and personal on individuals’ social media channels, so it is vital that social media training is provided to all members of staff, regardless if they are in a customer-facing role. Like it or not, you are all representing your employer 24/7, 365 days a year. - Note: DevRel is being an influencer and leveraging personal brand while working with the employer. - There is a broad range of content formats including case studies, product fact sheets, brochures, whitepapers, webinars, presentations, newsletters, blog posts, podcasts, and videos in various formats. Depending on the maturity of your organization and the resources at your disposal, you may have to prioritize where to focus your efforts. - Configuring email nurture campaigns can be effective to remain at the front of your developer’s mind, giving that little bit of inspiration and nudge to action, ultimately turning them into a customer or more active user. - Note: Drip campaigns that nurture developers implementing your product can lead to success. - The developer completes an event registration form. An associated nurture campaign could share relevant content in the run-up to the event and reminders to attend, and then post event send content and materials used in the event, and then signpost what to explore next. - A developer registers for your product. This could trigger a series of nurture emails that provide links to the quickstart guides, docs, use cases, and inspirational content of what others have built with the same product. - A developer has registered for your product, but after a predetermined amount of time and/or activity on their account, they are tagged as dormant or have failed to complete onboarding. This could trigger a campaign to attempt to reengage them and probe for any issues they may have encountered. Those emails could include similar content to the preceding example, plus links to support or FAQ content, or a short survey to understand what has happened. - One of the more effective marketing strategies we have used is becoming an active member of other developer communities relevant to your audience. - Note: Make a daily habit of joining the community where developers are. - They are visible – internally and externally. Many can be delivered on small budgets within a short time frame. They often don’t require complex organizational buy-in compared to launching a new product (except for creating your own large conference, of course). For a corporate, you are perhaps excited by the feeling of positively positioning your brand as edgy and community centric. If you are worried about falling behind your competition, you feel compelled to “keep up with the Joneses.” - Be clear on why you want to attend an event: Learn – About the topic, the community, the organizers, the venue, scout competitors, and network. Speak – Keynote, panel, etc., to showcase your technology and thought leadership. Educate – Demo or workshop. Presence – Run your own booth or be part of a partner’s booth. Sponsor – Which in addition to brand association will likely include many if not all of the preceding options. - Is the event credible? - Is it our audience? - Can we properly represent ourselves? - Tags: discard - Can we resource it? - Budget – - Pre-event promotion - Pick your team - Create an event plan - Create your perfect product demo - Steal the show with a stand-out booth – - Treat each event as a separate marketing campaign – - Arrive early and test EVERYTHING - Promote your attendance and content on the event hashtags - Lead capture at the event - Gather feedback - Organize activities outside the event - Follow-up – - Repackage and recycle any content created at the event - Run an internal debrief with a self-reflective event report - Tags: favorite - tips for online events: Provide direction that you and your team will follow about how you will appear on camera regarding the level of appearance, tone, dress, room setting, any virtual background image, etc. Be sure any presentation you do will be recorded and that you will have access to use it or refer to it in postmarketing activities and for self-reflection on your performance. Confirm access to your virtual booth and your marketing assets (logos, marketing collateral, demos, downloadable content, etc.) before and during the event. Test, test, test – if you can. Some online event platforms can be complex to use or may not have features or final results you were expecting. Confirm the technical specifications of the marketing assets you’ll use, like logos, banners, and copy length, in advance to ensure your presence looks as professional as possible. Be well staffed. You and your team will need to work hard at an online event to capture attention. Someone will need to monitor the virtual booth at all times and spend time in event chat channels and associated social media channels driving engagement. Time zones can make this challenging. Look for opportunities to provide blog content to the organizers for posting on their site pre- and post-event for additional attention. Assure the quality of your connection and equipment like camera, mics, and lighting before the event. Always start with a clear agenda of your talk to ensure the audience is aware of what is coming up. This helps combat them straying to their email or allows them to dip back in at points they find most relevant. As there is a lower bar to attend an online event (e.g., no travel requirement, typically free or low-cost tickets, etc.), we have found that the audience can be different from what you expect. Ask qualifying questions at the start of your talk like “Who has heard of…”, “How many of you are…”, “How experienced are you with…” to ensure that your content matches the crowd, and you can adjust on the fly. Don’t rely on slide visuals in the same way you would for an in-person event – recognize that many people leave online events streaming in the background, only listening to the audio as they multitask on other things. Ask questions, take polls, and use similar techniques to engage your audience . Make your online events shorter than their equivalent in-person version. There are just too many distractions, and no one wants to be stuck staring at a screen for hours on end. Aim for a maximum of two hours and three or fewer speakers. Consider the best channels and tools to reach your audience. There are a growing number of specialist online event platforms (e.g., Hopin, BigMarker, vFairs, etc.), online meeting tools (e.g., Zoom, Google Meet, Microsoft Teams, etc.), and content platforms (YouTube, Facebook Live, Twitch, Clubhouse, etc.). Ensure you are recording your event and making it available for full replay and/or edited sessions. - Be clear on why you are running a hackathon - Check your expectations - A hackathon is a technical event with coding - Be mindful of constraints of time that the teams are working under - Do not expect to get any IP or own any of the output - Share your details in a timely manner - Provide focus and context – - Benefits of formalizing and taking responsibility for a community may include: Attracting new users Retaining existing users Increasing engagement with and between current users Enhancing product support Gaining new product or feature ideas Enhancing brand reputation - A community can expand on the capacity of your team.   2. A community brings their own authentic experience with your product, free of any corporate bias you may intentionally or unintentionally bring. This is especially beneficial in identifying use cases your team would probably never think of.   3. Developers trust their peers, so make great advocates for your product. - Here are some community metrics to consider: Referral programs – Are your biggest fans advocating and recruiting more people into the community? Do your active community members have lower churn and higher lifetime value vs. standard users? How many community members support other members on your owned properties or external properties like Stack Overflow and Reddit? Are you recognizing and encouraging this behavior? Are your GitHub repos growing? How many feature requests/contributions are coming from your community? Are you recognizing and encouraging this behavior and implementing their suggestions? Are community members contributing to positive brand sentiment or amplifying your messaging? - These developers plus other relevant job titles like product managers, solutions architects, and others make up the community at large. - Even though they are not actively participating, passive contributors still benefit from lurking and absorbing information and tips from others as they learn about your product and become active users. - Note: Passive contributors, those who lurk, are likely the ones with the strongest opinions in opposition to the product. They may be reluctant yet. - Active contributors regularly contribute in a variety of ways (see Figure 25-2). They likely answer questions regularly in the various channels where people seek help, and they attend your webinars or other events. - Note: Active contributors participate in a variety of ways. Forums, events, and more. - These individuals float on either side based on their current situation, interests, or time availability. They can be product users or not. You may have heard from them once, or they have spikes of activity, and then go quiet. - Note: There are people in between being active and passive contributors. - A successful community requires you to create a culture of openness and respect where people feel comfortable contributing and where you accept criticism and feedback graciously. A formal community also requires Community Guidelines5 and a Code of Conduct that determines how individuals contribute and set behavioral expectations. - Note: Creating Code of Conduct is the beginning phase of a community. - Gamification is often the first thing that comes to mind when managing a community. Gamification is used to encourage individuals to contribute, to gain peer recognition through badges or titles and earn tangible rewards, like T-shirts, gift cards, dinners, etc. The in-between group is often the most engaged with a gamification model and most influenced by it. - Note: Keep community fun. Give rewards and prizes for participation. - As you build your community, it’s important to reward those that participate, as a strong preference over gamification. Random acts of kindness help recognize and reward individuals and demonstrate you appreciate and invest in your community. - Note: Express gratitude and elevate others for their participation. - There are two key differences with Open Source communities: 1. Open Source communities have implicit trust in the product as they can see the code and understand how it works.   2. Contributions to open source add clear value to both the project and the contributing individuals. For example, developers are often asked about their open source contributions in job interviews, so having a track record of contributions provides an advantage. A clear win-win for both parties. - When properly aligned and clarified, metrics allow you to: Clearly communicate priorities and motivate your teams Measure progress toward your goals and objectives Forecast if those goals and objectives can be reached Make improvements to your strategy and tactics Demonstrate to the team and company as a whole how Developer Relations contributes to the overall business Negotiate resources for next year - Community metrics measure the health of your community – how your program interacts with it, supports it, and vice versa. - To achieve clarity, each of your metrics should include: The end goal (what do you want to achieve) The target (the number) The time frame (by when will you achieve it) The source used to report the number - Tags: favorite - At the program level, you are going to want to identify and track metrics that align to the four Developer Relations objectives of: 1. Awareness   2. Activation   3. Engagement   4. Retention - Community Metrics can be gathered with quantitative data, for instance: The number of questions/mentions on Stack Overflow The percentage of answered/unanswered questions on Stack Overflow The number of GitHub project starts The number of forks for company-hosted GitHub projects or projects that use a product library as a dependency The number of community-answered questions in your Forum The number of Stack Overflow or GitHub activities vs. your competitors’ stats The number of content pieces written by a community member - They can also be measured by qualitative data such as asking your developers direct questions either informally or with a formal survey to find out: Product reviews Overall company, program, or product sentiment, including NPS scoring2 Tool usage - You should also understand the value of your community by analyzing the data to find out: Churn rates of community members vs. noncommunity members Lifetime value of active community members vs. active users Referrals by active community members - Ask, “So what?” after every metric - Tags: favorite - Ask, “What do I adjust?” - There are three dangerous signals to watch out for: 1. Self-perpetuating the myth that DevRel is hard to measure.   2. DevRel practitioners acting like having targets applied to their work will somehow stifle their creativity or dampen the impact of their work.   3. DevRel practitioners who believe they need to constantly invent new metrics and new terminology. - Often, we hear it is this variety of tasks that makes DevRel such an appealing and exciting career choice. We struggle to think of another role that gives you such a wide scope of activities and influence. You operate across the organization, are involved in all the facets of bringing a product to market, and have the opportunity to engage and interact with customers (the developers) out in the field. - There is no doubt this can be a high-pressure role. It’s challenging to perform such a dynamic role, understanding how to prioritize and project-manage everything that is expected. Being the “face” of the company out in the wild can be highly rewarding if your company and product are seen as cool and valuable. However, if there are issues, you become the scapegoat when things are not going well. There is the pressure to “perform” on stage via public speaking and perhaps live coding, and added to all of that is the fatigue of travel to attend the events all around the world. Compounding this is the fact that many DevRel professionals are early in their careers (27% have less than two years of experience, and 47% less than five years). Additionally, as there is no formal training for DevRel, 82% learn their role on the job.1 - The Support and Success teams spend time answering internal and external forum questions and may also spend one-on-one time with customers. They liaise directly with the product team to prioritize support tickets and feed developer requests back into the company. - Specialist event professionals are skilled in a number of key areas: Which events do our target audience attend? What is the reputation of certain events and organizers? What is a realistic level of sponsorship and handling of negotiations? Ensuring your brand is represented in the right way. Handling the planning and logistics around booths, merchandise, etc. Handling staff rotas to ensure the right staff are attending. Developing a strategy to drive engagement and leads. Reporting on the return on investment post event. - Developer Education (DevEd) is a critical component of Developer Relations. There is a growing school of thought that DevEd is now the primary DevRel function over Developer Advocacy, perhaps driven by the impact of COVID-19. - You will need specific digital marketing specialists that focus on SEO, PPC, and online advertising to build awareness and traffic to your DevRel activities. You will also need a web team. - once your community gets large enough, it requires more management of community-based activities, events, rewards, ambassadors, etc. Having a dedicated person for the community becomes necessary. Larger programs may split online and offline community management responsibilities. - Tags: favorite - One of the challenges with DevRel has been career paths have a reputation of having a glass ceiling as seniority increases. We’ve heard of engineers who move to DevRel, then aren’t able to find their way back to engineering to progress. There are also Developer Advocates who often don’t see an advancement path into other departments. These may be symptomatic of several factors, such as: The “jack of all trades” approach to DevRel can mean DevRel people may not have the deep expertise to progress from an individual contributor (IC) role to another department. Because DevRel teams tend to be fairly small in the majority of organizations and DevRel people are pretty independent and self-starting, people management opportunities are limited; thus, DevRel people struggle to move onto roles requiring line management experience. The limited knowledge of DevRel roles and expertise, outside of DevRel circles. - DevRel professionals tend to be scrappy and creative by nature. Unlocking internal opportunities by building strong ties and demonstrating why their “asks” are essential for the company is crucial. - A great way to identify potential DevRel talent is to spend time in the communities you wish to target. There you can scout for individuals that have the technical skills you require and stand out from the crowd. - Note: While networking with developers as customers, keep a close eye out for developers that may be great DevRel sorts. - The Developer Relations team goes far beyond hiring a Developer Advocate and is broader in scope than hiring one person to run it all. From the start, your program will rely on collaboration between other departments and then will start to add specialists to help you scale. - Tags: favorite - Within the framework, there are two categories of influences that determine the extent to which a program matures, shown on the axes, as follows: Increasing authority, credibility, and impact axis - Increasing budget and complexity axis - the five maturity stages for a DevRel Program are: 0 – Ground Zero 1 – Improvised stage 2 – Establishment stage 3 – Growth stage 4 – Scale stage - Maturity Stage 0 1. PRODUCT: 1 (likely alpha)   2. DEVREL PROGRAM: 0   3. DEDICATED DEVREL STAFF: 0   4. DEVREL STRATEGY: None   5. BUDGET: $0   6. INTERNAL AWARENESS & ALIGNMENT: None   7. DEVELOPER OUTREACH: None   8. DEVELOPER EDUCATION & DEVEX: None   9. METRICS: None   10. DEVELOPER COMMUNITY: None - Maturity Stage 1 1. PRODUCT: 1 (likely beta)   2. DEVREL PROGRAM: 0   3. DEDICATED DEVREL STAFF: 0, 1–3 enthusiasts   4. DEVREL STRATEGY: None   5. BUDGET: $0   6. INTERNAL AWARENESS & ALIGNMENT: Limited   7. DEVELOPER OUTREACH: Ad hoc   8. DEVELOPER EDUCATION & DEVEX: Basic   9. METRICS: Informal   10. DEVELOPER COMMUNITY: <1000 - Maturity Stage 2 1. PRODUCT: 1 (full release)   2. DEVREL PROGRAM: Infancy   3. DEDICATED DEVREL STAFF: 1–5   4. DEVREL STRATEGY: A plan for a plan   5. BUDGET: < $50k   6. INTERNAL AWARENESS & ALIGNMENT: Growing   7. DEVELOPER OUTREACH: Testing in limited channels   8. DEVELOPER EDUCATION & DEVEX: Basic   9. METRICS: Basic   10. DEVELOPER COMMUNITY: < 5000 - Maturity Stage 3 1. PRODUCT: < 5   2. DEVREL PROGRAM: 1   3. DEDICATED DEVREL STAFF: < 10, growing   4. DEVREL STRATEGY: Yes   5. BUDGET: < $1m   6. INTERNAL AWARENESS & ALIGNMENT: Improving   7. DEVELOPER OUTREACH: Formalized   8. DEVELOPER EDUCATION & DEVEX: Improving and expanding   9. METRICS: Good   10. DEVELOPER COMMUNITY: < 10,000 with contributors - Maturity Stage 4 1. PRODUCT: Multiple   2. DEVREL PROGRAM: 1 or more   3. DEDICATED DEVREL STAFF: > 10, growing   4. DEVREL STRATEGY: Yes   5. BUDGET: > $1m   6. INTERNAL AWARENESS & ALIGNMENT: High   7. DEVELOPER OUTREACH: Sophisticated   8. DEVELOPER EDUCATION & DEVEX: Comprehensive   9. METRICS: Comprehensive and impactful on business   10. DEVELOPER COMMUNITY: > 50,000  with active contributors - Understand your immediate priorities, allowing you to focus and not get distracted by everything else you might be tempted to do. Provide the structure and, along with the book, tools to create and articulate your plan for moving forward. Be more structured in your investment requests to your stakeholders as you prepare to transition into the next maturity phase. Recognize and celebrate your progress as you graduate from previous phases. Offer the best program to serve your community! - All of the frameworks have been made available via the book’s GitHub repository, or visit us at www.devrelbook.com. Use them and adapt them to your needs. - Part I: Develop a Common Understanding Chapter 1:​ What Is Developer Relations?​ Chapter 2:​ Where Does Developer Relations Fit?​ Chapter 3:​ The Origin of Developer Relations and the Rise of the Developer Chapter 4:​ The Value of the Developer Economy Part II: Key Differentiators Chapter 5:​ The Audience:​ Developers Chapter 6:​ Developers As Decision Makers Chapter 7:​ Developer First and Developer Plus Chapter 8:​ Business Models and Monetization Strategies Chapter 9:​ Developer Products Part III: Alignment on Goals Chapter 10:​ Company Goals and Alignment Chapter 11:​ Program Goals Part IV: Go-to-Market Chapter 12:​ Developer Segmentation Chapter 13:​ Developer Personas Chapter 14:​ Messaging Chapter 15:​ The Developer Journey Chapter 16 :​ Discover Chapter 17:​ Developer Experience Chapter 18:​ Evaluate Chapter 19:​ Learn Chapter 20:​ Build Chapter 21:​ Scale Chapter 22:​ Developer Marketing Chapter 23:​ Events Chapter 24:​ Sales Chapter 25:​ Community Part V: Managing and Growing Your Program Chapter 26:​ Metrics Chapter 27:​ Team Chapter 28:​ Program Phasing Chapter 29:​ Epilogue Correction to:​ Developer Relations Index