Developer Marketing and Relations  ## Metadata - Author: [[SlashData, Nicolas Sauvage, Andreas Constantinou, and Jo Stichbury]] | [[3. Resources/Authors/SlashData, Nicolas Sauvage, Andreas Constantinou, and Jo Stichbury|SlashData, Nicolas Sauvage, Andreas Constantinou, and Jo Stichbury]] - Full Title: Developer Marketing and Relations - Category: #books - Kindle: [Open in Kindle](https://www.amazon.com/dp/B07XM8GDD9) - Document Tags: [[DevRel]] ## Document Notes ## Highlights - How do you measure success and why does it matter? Tl;dr: Measuring success lets you: Understand what works, so you can do more of it Communicate successes and failures Justify your decisions Allocate resources effectively Track your progress Time travel (no, seriously) ([Location 241](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=241)) - developers want technology companies to spend more time and effort answering questions on forums, and less on organizing conferences. ([Location 254](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=254)) - measuring success lets you decide what, exactly, you should be doing, and how you should be doing it. ([Location 271](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=271)) - before knowing how to measure success, you need to know what you are going to measure. Before you even start to think about what to measure, you need to understand what you want to change. ([Location 275](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=275)) - understand what your business goals are. ([Location 279](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=279)) - Fundamentally, any commercial developer relations program lives and dies by its ability to increase usage. To increase usage by developers already engaged with the platform, or to attract new developers to the platform. ([Location 279](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=279)) - But what is it that you specifically want to achieve? Do you want to increase the frequency of usage for a specific product or API? Do you want to inform developers about an imminent major version and a potential breaking change? Preventing a decrease in usage is often easier than driving an increase, after all. Or do you simply want your developers to know that you’re thinking of them? ([Location 282](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=282)) - there are as many ways of segmenting your developer community as there are developers, and you can use many different data points to create your developer personas ([Location 321](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=321)) - Your marketeers want to know how well developers engage with the communications, messaging and campaigns. Your developer advocates might be trying to understand the community dynamics or particular pain points that developers face. Your product managers want to know which features are being used and what developers are requesting next. ([Location 340](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=340)) - Adoption rate - How many developers use a product or vendor Engagement rate - How often developers use a vendor’s resources Satisfaction score - What developers think about a product or its features Reasons for adoption or rejection - Why developers chose (or rejected) a product ([Location 355](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=355)) - When you are choosing a suite of KPIs to measure the success of your developer relations program – and we do recommend selecting a few – here are some things to keep in mind: Be realistic - this is where the groundwork of understanding the market, and your performance within it, helps you to select SMART objectives, with the emphasis here on ‘Achievable’ - what you can actually influence. Be considerate - and by that I mean, choose KPIs that are easy to understand. Be considerate to your colleagues by not hiding KPIs behind definitions and acronyms. Know your data - you want to choose KPIs that are sensitive to change, but not so sensitive that they fluctuate wildly. Choose KPIs that you can calculate with the data you have and remember that you can always get someone else to help ;-) Tell a story – keep in mind, you are trying to change behavior. You are trying to change not only developers’ behavior, but also your colleagues’ behavior. Telling a story is the most compelling way to bring someone round to your way of thinking. Choose KPIs which combine to tell a story and watch your team come together to make it come true. Think about the ramifications - we already know we are trying to change behavior, but what about any unexpected changes? Do the KPIs you have selected incentivize the right behavior amongst your team, or have you unwittingly created perverse incentives for a negative behavior change? ([Location 391](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=391)) - To keep your team aligned, you need to define what you want to achieve, and what success looks like. ([Location 430](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=430)) - the team needs a shared definition of where they are going and how they know when they have been successful. ([Location 451](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=451)) - “how does an experienced independent developer (‘Jerry’) approach DevOps?” and compared the answer with a different persona, such as a line developer in a larger company (‘Lana’). ([Location 466](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=466)) - developer personas provide an easy way for non-developers to understand this audience. ([Location 470](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=470)) - developers behave differently: they evaluate and trial products differently, they value and consume content differently, and they prefer a different sales model. ([Location 471](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=471)) - Market segmentation tends to be a quantitative, or data-driven, process using exhibited/measurable behaviors or traits. User personas tend to be a qualitative process, using internal personal drivers and motivations. ([Location 507](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=507)) - ‘Enterprise developers’ work for large corporations with 1k+ employees, with a focus on building internal applications and services; they are productivity-minded and trend towards proprietary technology stacks. ([Location 512](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=512)) - ‘Emerging developers’ work at startups and tend to be younger; they are very tech-forward and prefer building upon open stacks. ([Location 514](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=514)) - ‘Partner developers’ work at platform or service companies, building offerings that increase the productivity of their customers. ([Location 516](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=516)) - personas are more powerful than market segments for product and campaign creation, but market segmentation is more powerful in execution and measuring the success of what you take to market. ([Location 521](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=521)) - User roles are most commonly used by engineering groups to call out what job activity is using their product (e.g. ‘backend developer’, ‘web developer’, ‘mobile app developer’). ([Location 532](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=532)) - Industries (or ‘verticals’) tend to come into play when there are specific needs, requirements, or behaviors that play out in different types of business (e.g. manufacturing, government, education). ([Location 534](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=534)) - Programming languages is a pretty self-explanatory grouping ([Location 536](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=536)) - a persona is a fictional character with a backstory and their own journey to give them depth and to make them interesting to your readers, your engineering and business partners. ([Location 542](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=542)) - Basic Demographics: To make this person real, give them a name and create a composite of who they are using what you already know about your target developer audience, perhaps anchoring on someone you met at a recent event that you think well represents your user base: what is their age? Where do they live? Where do they work? ([Location 547](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=547)) - Customer Journey: Now dig in further on what you know about your developers (such as discussions, customers meetings, focus groups, or surveys): How does the developer’s world interface with your product or platform? What does their journey generally look like as they move through their world, and as they make contact with yours? ([Location 550](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=550)) - Motivations and aspirations: What drives this individual? Why do they do what they do? What motivates them? What inspires them? Who inspires them? Where do they want to go? ([Location 556](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=556)) - Pain points and fears: Again - go back to their drive, but from the opposite angle. What keeps them up at night? What do they dread? What do they fear? What are their blind-spots (known or unknown; professional or personal)? ([Location 558](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=558)) - Inflection points (adoption triggers): What are the major moments in their life as it relates to your offering? What moves them to the point of making a change? And what is the process for exploring that change? ([Location 562](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=562)) - break this out into at least three organizational ‘calls to action’ (‘CTAs’) - engineering, programs and offers, and marketing - to say “what you can do to help ‘Bob’” and provide 1-3 very clear and crisp CTAs on what we can do to help this developer to minimize their pain points and attain their aspirations. ([Location 564](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=564)) - Once you have your basic character story written out, then you’re ready to flesh it out with market trend data and facts. This helps you round out your persona and refine the portrait away from anecdotal stories, and ground your character in the real world. To do this, I turn to survey data and syndicated research that summarizes larger market trends around my audience. ([Location 568](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=568)) - Developers can, and often will, inhabit multiple personas ([Location 602](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=602)) - When our team engaged with agencies for marketing campaigns or content development, we included a simplified version of our target personas (10-12 slides of the larger deck). Initially, we did this because an agency wanted to know more about the audience, but this quickly became a best practice in our RFP process as it yielded much better campaign pitches on the first try. ([Location 640](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=640)) - First, we would do some qualitative testing on our messaging with small groups of developers to understand what they liked, or didn’t like, about our top-line developer messaging, both from a conceptual and wording point of view Second, we would also inquire about some of the broader concepts in our offering and probe for areas that either delighted the room or felt like we stepped on a landmine. Third, we adjusted the messaging for audience, potentially swapping messaging order or even sometimes one of the core messages with a brand new one. We would then go back and revisit our core messaging with the findings and evaluate if we needed to make any changes to the larger framework, as well. ([Location 662](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=662)) - How would they use developer personas in their work? What do they use today? What do they know about their target audience? If they had to group your audience into three groups, how would they do it? How do they measure success with the developer audience? Can they share their last business review on progress with their target audience(s)? ([Location 696](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=696)) - it’s critical to look at your existing customer segmentation, and how your company goes to market with your company’s market segments. ([Location 712](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=712)) - Visit them in their work environment. As you build out your personas, drop in and chat with your developer audience to ([Location 722](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=722)) - Talk to them at events. While you’re at a relevant event, hang out at your booth, or break your chains and walk the floor, introducing yourself and getting to know those around you. ([Location 727](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=727)) - 3 question gearbox: As you start to get to your groupings, see if you can define 3-5 characteristics that define that group. These characteristics would be the 3 survey questions that you place in a survey or event registration to understand which personas you’re reaching, or the messaging you want to test. ([Location 737](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=737)) - Granularity: You generally don’t want too many personas to represent your audience. ([Location 741](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=741)) - Test it: Lastly, build out a composite of your persona(s) and test it out with your stakeholders and with your work deliverables. ([Location 743](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=743)) - folks either adopt your work or it becomes shelf-ware, locked away in some file folder or abandoned on an island of misfit toys. ([Location 750](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=750)) - check it for unconscious bias and/or sample bias. ([Location 753](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=753)) - Always bring a growth mindset to your work and assume that everything you do should be reviewed annually to see if you’re still in touch with the market your developers represent. ([Location 760](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=760)) - As part of your marketing post-mortems (for events, campaigns, and releases), evaluate whether you landed your product with your target persona(s). ([Location 762](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=762)) - Stay out there with your audience, attending at least 2-3 developer events per year - and remember that your own events don’t count! ([Location 767](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=767)) - Finally, stay up on your industry trends and be sure that your team thoroughly reevaluates your personas every 2-3 years to see if your groupings still hold. ([Location 770](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=770)) - By continually checking the industry perspective, it helps prevent you from living in a bubble if your audience is getting more and more niche. ([Location 773](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=773)) - it’s essential to take an honest look at developer email marketing and ask tough questions, such as: Will the reader think we're trying to sell them something? Are we using a developer-driven approach? Are we pushing our products or services rather than creating value and trust? ([Location 807](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=807)) - our task in the Developer Marketing Team is to connect with and drive developers to adopt our products. ([Location 838](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=838)) - For nurture campaigns, all email sends are automated and are based on the actions a lead takes. To prepare for this flow, we had to map out the potential journey and actions we wanted leads to take. ([Location 883](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=883)) - A “unicorn” who understands both the developer audience and full-funnel marketing will be very hard to find! ([Location 937](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=937)) - it is also important to have people on your team who have a technical understanding. They don't have to be developers themselves, but they should know what they're talking about and understand what drives the developer community. ([Location 941](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=941)) - “ Who needs to sign off on this?” and “Who will your email marketing program impact within your company? ([Location 947](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=947)) - Developers are generally averse to the most common marketing techniques, especially sales-y lingo and jargon. For example, avoid words like “enhance,” “robust,” or “special”. In general, it’s best not to overuse adjectives when describing something. We've found that it's best to keep information short and sweet - be straightforward and informative. Clearly present your information and highlight key benefits. It's best to showcase your information in a problem > solution fashion. ([Location 963](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=963)) - To make email content relevant and helpful to our developer audience, we listened to our active developer database. Did they have feedback about our tools or messaging? Were the resources we sent them valuable? Through surveys, we were able to get their feedback and plan accordingly to make our emails more useful. ([Location 997](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=997)) - Developers, by their very nature, are builders who create things that are entirely new. And in the process of creating things that are new, they often use your services in ways that you didn’t anticipate and this is where community comes in. ([Location 1036](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1036)) - developer groups are one of the most fundamental components of a successful developer community. ([Location 1077](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1077)) - To be insiders, your community leaders need to understand your products, your roadmap (as much as you can share) and even understand why you are making the choices you are making. Show that you genuinely care about their success in all your interactions with them. ([Location 1165](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1165)) - Some of the community metrics we look at: Total number of community members & monthly growth Total developer groups, new groups added, and meetings per month Visits to our developer center & number of Trailhead badges earned Number of community events per year Number of social media followers & monthly engagement (likes, retweets, etc) NPS Score from quarterly surveys. ([Location 1228](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1228)) - “The Art of Community”: "a group of people that care about each other’s welfare". ([Location 1264](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1264)) - "Developer Portal". This is a place where many of the interactions amongst your community members may happen. ([Location 1266](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1266)) - there are three types of communication that occur within a developer community: One-to-Many Many-to-Many One-to-One ([Location 1270](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1270)) - It's also important that your own developers within your organization feel that the personas you are building resonate with them, and that your own developers could potentially identify with at least one of the personas you are putting together. ([Location 1332](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1332)) - As the developer gains more influence in the decision process and becomes the subject matter expert (SME) in terms of the latest tools and trends, it's important to build awareness of your products and services amongst developers. ([Location 1354](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1354)) - DIY (Do-it-Yourself) developer (either a hobbyist, student, or startup developer) may be going to your developer portal to explore the products, documentation, register, and start using your APIs or SDKs; the journey for an enterprise developer may have started with a business or product conversation with someone within your company. ([Location 1365](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1365)) - Enterprise Developer: The Enterprise Developer is the one working in the Engineering department of a large organization. ([Location 1381](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1381)) - Startup Developer: This developer could be the CTO of an early-stage startup, the head of Engineering or a software developer who wants to try the solution self-serve and will probably stay within the freemium tier of your tools and services for a while before moving to a paid tier. ([Location 1388](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1388)) - Hobbyist and Student Developer: This could be the enterprise developer or startup developer “at night” or after regular work hours working on their own projects. ([Location 1394](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1394)) - ensure developers feel welcomed into the community regardless of their level of experience. ([Location 1404](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1404)) - While some developers would prefer to just read the documentation and start coding away, others may prefer to go through tutorials, demos, sample code, and videos before starting their own projects. ([Location 1428](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1428)) - Prepare your materials in a way that you have something that allows everyone to get started with your solutions. This is not only important for first-time developers but also for developers that prefer to learn in different ways. As these developers gain more and more experience, you want to make sure they keep your tools and solutions top of mind for when they are working on their next project or building the next solution. ([Location 1434](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1434)) - once you have iterated on the personas and understand them well, and it is within your mandate to hire for the Developer Relations team, make an effort to look for candidates that reflect and mirror those inclusive personas you created. ([Location 1511](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1511)) - Building a Developer Marketing program is hard...where do you start? ([Location 1599](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1599)) - Start first by asking two questions to figure out what type of developer program you need to build. ([Location 1600](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1600)) - Who are you trying to reach? ([Location 1602](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1602)) - Are you building a marketplace where folks can sell apps or extensions to your products? Do you need integration developers that use your product and who need to write code to make it work with others? Is your product a tool to help developers do their job better? Do you want to reach the DevOps folks who will use your APIs to automate things? ([Location 1603](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1603)) - Why do you want to reach developers? ([Location 1608](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1608)) - Marketplace based developers - your company’s products are extensible and you want developers to help build out features that some but not all of your customers would use. ([Location 1616](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1616)) - API consumption - Your product has APIs that allow your products to interact with other products and to programatically accomplish tasks that users would use a GUI for. ([Location 1620](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1620)) - Developer tools - This type of Developer Marketing is closest to the more traditional marketing practices where the actual product is being bought by the developers. IDEs, Testing tools and other frameworks would be in this category. ([Location 1625](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1625)) - Developers are needed to use the product - Anything headless that requires development for adoption would be an example of this type of ecosystem. ([Location 1629](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1629)) - Once you have identified your target developers and the type of ecosystem you are building, you need to get support from above. Executive buy-in is critical because building a developer ecosystem is a slow process, taking a minimum of 18 months, if not several years, before you are able to show bottom line financial success. ([Location 1633](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1633)) - Spend the first 3-6 months establishing baseline numbers. ([Location 1638](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1638)) - find developers already using your products. ([Location 1640](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1640)) - technical content person, as we needed content to share before we could do anything else. ([Location 1647](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1647)) - you will fill the role of evangelist or advocate to start with, but to accelerate growth and success, you need someone else who can get out to industry events to share your product in a dedicated and visible way. ([Location 1650](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1650)) - Learn what your developers need from your portal, which in most cases will have, at a minimum, the following: Searchable API Reference documentation - typically this is created by your engineering team, although you may be responsible for publication. Developer blog - your blog should not be focused on marketing, but on using and experimenting with your products. Getting started - there should be a great big button that leads to a page with all the current information needed to get people up and running quickly, ideally within ten minutes or less. Labs or tutorials - while onboarding is the primary goal of developer marketing, having great tutorials on how to use different areas of your APIs, or other products, is vital. Contact system - you need some place for developers to reach out for help and give you feedback on things on the site, such as forums or a Slack channel.   Optional things your developer portal should ideally have: Code samples - Having a source controlled set of code samples and examples of the top 10 use cases for your API in your most common languages helps lots of folks solve their problem quickly. Community forums - Building a community is hard, you need a place where the crowd can hang out and discuss things, these should be moderated and monitored. Events page - Let people know where you are going to be next. Social media listing - learn where your community is, are they on Twitter? Reddit? Stackoverflow? Find that out and go participate with them. Make sure you have a CMS behind your portal, I recommend WordPress as it is flexible and it’s blog and page system are great - unless you are selling another platform using this will allow for flexibility and for the portal to live beyond your tenure. ([Location 1665](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1665)) - Hackathon - Everyone build a team, pick something to build and then show it off in competition at the end Coding Lab - Work through a series of labs with help in the room for when you get stuck Conference with Breakouts and Keynotes - Traditional trade show format, lots of listening on both sides, lowest risk. ([Location 1706](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1706)) - How do you reconcile many developer messages across one company, all targeted at the same audience, especially if they are not all in the same team? ([Location 1856](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1856)) - different groups within our company were producing different marketing outputs about different products, possibly offering conflicting or misaligned benefits that potentially targeted the same developer audience. The potential consequence to the company of this misalignment is that the audience, who is already sensitive to marketing that does not resonate with their needs, might react by tuning out the entire brand. How would we go about improving this and get to a successful state of aligned, resonant messaging for developer audiences? ([Location 1914](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1914)) - Establishing an internal council; discovering who talks to developers and listening to their needs ([Location 1918](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1918)) - one does not simply form a Developer Relations Council. ([Location 1932](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1932)) - Finding the correct stakeholders in those teams and getting them to respond to our inquiry sometimes turned out to be difficult, simply because people are busy. ([Location 1944](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1944)) - To both discover the right people to talk to AND to ensure a response, we needed executive-level support. ([Location 1947](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1947)) - In order to build, and continue to have, an effective Developer Relations Council, there had to be internal incentives to maintain a productive dialogue. We needed to answer the age-old marketing question when targeting any audience, internal or external: “What is in it for me?” To uncover these incentives for productive dialogue, we designed and implemented an internal survey that had two components: quantitative and qualitative. In the quantitative component, we asked how the teams were positioned to developers and where their perceived pain points were. In subsequent individual, qualitative interviews, we discovered background motivators, added additional detail to their survey responses, and explored why they had answered certain questions in surprising ways. ([Location 1959](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1959)) - “Do you have an interest in delivering content such as videos/developer newsletters/events featuring your product?” ([Location 1967](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=1967)) - Developer Relations Summit, ([Location 2002](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2002)) - Cap your number of attendees. ([Location 2003](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2003)) - Seats were assigned ([Location 2006](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2006)) - structured introductions. ([Location 2013](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2013)) - ideas were then presented to the attendees. ([Location 2025](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2025)) - The Developer Relations Summit accomplished two critical goals: 1. Prioritizing the importance of the workshop via executive sponsorship, and 2. Establishing buy-in from across the company to address problems, while benefiting from the solutions we designed together. ([Location 2037](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2037)) - open up attendance and participation to the Developer Relations Council to anyone in the company. ([Location 2078](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2078)) - passing on sales leads was never our forté because we usually did not attend events based on their lead generation potential. We went wherever passionate developers were found. Decision makers were someplace else. ([Location 2114](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2114)) - we knew the ecosystem and the ecosystem trusted us. ([Location 2119](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2119)) - What is the definition of developer relations? ([Location 2134](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2134)) - "Developer relations is what software companies call their marketing department." Others would beg to differ and insist that developer relations is a critical part of engineering and tech support. A third opinion may be that it is the role of developer relations to turn a technology platform into a viable platform business. But maybe they are all wrong and actually it is about selling technology products to engineers? Or is it all of the above? ([Location 2137](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2137)) - developers interact with products beyond their initial scope and build their own solutions. The ability to extend a product is what makes the difference between regular support, marketing or engineering groups on one hand and developer relations departments on the other. The moment developers start co-creating, they are not only customers but become participants and often partners, who are critical to the organization's success. ([Location 2141](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2141)) - Developer relations is about bridging between heterogeneous developer communities and technology engineering inside the actual company and is the interface that allows for true collaboration. ([Location 2163](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2163)) - If you structure a developer relations department, these communities are your most important resource, partner and audience. There are two parameters that govern how you're likely to interact with them: The accessibility of your company's technology. Can hobbyists successfully master and use it to create value? Or do they need to be experienced engineers? Your business priority. As I'll discuss in the next section, it makes a huge difference whether you're in it for the few or for the masses. You also need to consider the stage your technology has reached. Are you introducing something brand new to the market or is it an established framework that already has a strong community? ([Location 2179](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2179)) - Here we have a crucial difference between developer marketing and developer relations. The former creates a channel and tries to send information that hopefully leads to action to a defined audience. Developer relations, on the other hand, is about creating and growing social groups and their relationship with your business. And these groups are not bound by the events they show up at. They share an interest and a passion. ([Location 2191](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2191)) - Most companies stumble into the world of developer relations without even noticing. ([Location 2202](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2202)) - Developer advocate or community manager Developer advocates are normally engineers working part time or maybe even full time with external developer communities. Speaking at events, creating demonstrations, writing documentation or articles are all tasks that fall into this role’s typical profile. ([Location 2216](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2216)) - As such it may be responsible for a variety of tasks which usually overlap with fields such as Support, Marketing or PR:  Event organization Documentation (including sample code) Content creation (e.g. videos, walk-throughs, codelabs) Representation (in events, in PR settings, in media, as social media contact) Tech support Tech consulting Relationship management Engineering of bridge technologies (e.g. SDKs, Toolkits) … ([Location 2228](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2228)) - look at the work that is unique for developer relations:  Supporting communities of learning and practice Participating in the developer ecosystem  “Growing the cake” by supporting the larger developer ecosystem. ([Location 2247](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2247)) - Is your product new to the market so you are in need of a committed and active group of early adopters? Then your mapping will include other players and tactics as if you’d map out your activities and audience for a product ecosystem that is established and where you, say, plan to introduce an architectural change. No matter what you consider when mapping your audience, don’t forget to plan full circle. If you’re only planning to reach developers but do not consider a way for them to channel their feedback, then you’re considering only half of the equation. ([Location 2272](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2272)) - Communities - These programs are about scaling the kind of social groups that are also known as “communities of practice” ([Location 2301](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2301)) - Influencers - Every technology space has its recognized experts and opinion leaders. You want to work with them, you want to listen to their feedback and keep them on your side! ([Location 2306](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2306)) - Partners - A healthy tech ecosystem forms scalability partners that allow your developers or customers to build solutions faster or better. Think about agencies that implement your technology stack in key accounts, consider trainers who make a living enabling others to skill up. ([Location 2310](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2310)) - Developer relations is about relationships and relationships are built one way and one way only: through multiple in-person encounters that are used to build mutual trust. ([Location 2357](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2357)) - keeping promises and by staying in the game long term, not only just for the duration of a short transaction. ([Location 2359](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2359)) - Decide your product strategy. What type of developer interfaces do you have? Do you have an idea what an ideal developer engagement might look like? Do you want developers to work with you on your platform or rather extend it through defined APIs? Map your ecosystem. What are the players? Who is your audience? What parts of it are easier for you to reach? Which elements do you want to see growing? What is the level of resourcing you’re prepared to invest?  Now you should be able to identify a handful of key programs and their nature (1:few, 1:many, 1:few:many). If your team is large enough, consider your local presence as an alternative to a large centralized team. If you can have both, then maybe a headquarter team with supporting functions and distributed smaller teams in key markets can provide efficiency gains.  Now structure your teams. You have four general ways to distribute work (functional, audience-centric, product-centric, execution-centric) but it is always a compromise between efficiency and agility and between external focus and internal alignment. When you did your mappings in steps 1 and 2 you’ll have found some options present themselves as better than others.  Your developer relations department is neither marketing nor sales, so don’t consider outreach or adoption as the main metrics! Instead consider those such as community activity, community growth and contributions to your platform. Why? Because relationships and trust in your community are not expressed immediately in money but in self-initiated activities. Your organization will make money from your work down the road but it is a long term investment, not a short-term transaction. ([Location 2383](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2383)) - Non-product-oriented MOOCs ([Location 2517](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2517)) - Product learning. ([Location 2523](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2523)) - Free trials and usage credits are powerful tools for developers ([Location 2527](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2527)) - developers are not prospects. They are certainly influencers, and in some cases, they may have formal or informal sign-off on platform adoption. However, metaphorically speaking, you don’t take developers out for a round of golf, and try to close the deal on the 18th hole. Instead, you give them knowledge, you give them tools, you give them trials, and you let them work with your products at their own pace, on their own projects, at their own time. Developers don’t want slick marketing collateral; they want code that works. ([Location 2607](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2607)) - They don’t care about analyst reports; they care what their peers are thinking and saying. ([Location 2613](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2613)) - What developers want is constantly changing. And thus, engagement must always grow and evolve to meet developers’ needs. Understand that developers don’t like to be sold to, and need to be engaged, not pitched. Anything that’s purely a marketing effort will fail. Get executive buy-in and support for developer engagement, from the highest level. Define a small core team (handful or less) that defines direction, incorporates input, and makes fast decisions, and most of all, isn’t afraid to make changes in mid-stream. Engage online and in person. The key is back-and-forth engagement and continuous education – not presenting one-way marketing messages. Think big, and execute in small increments showing some value in each increment. A lot of small activities can be more effective for reaching diverse audiences, as well as allowing for rapid changes and iterative learning. And always remember to be authentic, open, and honest in your developer engagement. ([Location 2689](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2689)) - While developers do seek guidance from their vendors, they often prefer to get information from their peers; meaning from your community, particularly from external developer experts within it. ([Location 2714](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2714)) - encourage a network that provides expert advice from external sources. ([Location 2716](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2716)) - Your network should be a good mix of internal and external developer experts, ranging from specialists to generalists, who act as educators and role models. ([Location 2736](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2736)) - Developer Evangelists who are most likely to sit directly within your developer relations team. They are often (if not always) developers themselves, and they possess first-hand experience with the broad range of solutions that outside developers use. Given their direct experience with diverse solutions, these evangelists can speak knowledgeably to developers about a variety of technical topics. ([Location 2749](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2749)) - Product Experts. They are more specialized, yet still gifted at relating to developers. Internally, they are your product managers and product engineers. Their contributions come from their deep know-how in their product areas; offering up information and insights to developers who focus on their products. ([Location 2753](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2753)) - A program for evangelists, product managers, and other highly skilled and motivated developers – like a broader developer community – is a method for providing expert access. But whereas the community is open to all types of members (developers primarily, but certainly not limited to that audience), the developer program is, not surprisingly, geared to the developer audience. ([Location 2787](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2787)) - To break things down even further, our developer program concentrates heavily on three areas: awareness, engagement, and adoption. Awareness, as the name implies, makes developers aware of products. Engagement educates developers more deeply about these offerings. Adoption includes tools and content that developers require to build and implement solutions. ([Location 2790](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2790)) - consider how your experts should cover the complete range, from product specialists to evangelists with a broader base of knowledge. ([Location 2828](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2828)) - Calling it a community for developers is a fairly broad statement. Does that mean developers can wander in and post about whatever they want, where they want? That invites chaos. ([Location 2829](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2829)) - Think of the community in terms of the areas of a developer’s expertise. ([Location 2836](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2836)) - The topics are part of what the community is (a destination for information about x, y, z, etc.), but the definition also needs to cover what the community does, or more appropriately, what members do in it. ([Location 2850](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2850)) - define the developer community as a place where members can get and share information about the topics you’ve identified as most relevant to your audience, and that can be supported by your developer experts. ([Location 2857](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2857)) - It’s tempting to turn the community into a marketing tool to churn out company-generated messages. To some degree, this will be unavoidable. ([Location 2860](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2860)) - developers will see it as a go-to destination for information and guidance, and so that experts will feel inclined to participate actively. ([Location 2878](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2878)) - Make sure that your program gives the experts a sense of identity and purpose. ([Location 2888](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2888)) - To handle these events successfully, your experts will require effective public speaking and teaching skills. The shy ones might limit themselves to the online community, but wherever possible, you’ll want experts who can operate both online and in person. ([Location 2905](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2905)) - Member of the Month feature shines a spotlight on up and coming community participants, to show our appreciation and encourage them to get more involved. ([Location 2913](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2913)) - Your developer program requires a solid base of experts and a bullpen of up-and-comers. You must find them, coach them, keep them. Your developer program and community, and all of your attempts to provide expert access, cannot succeed without them. So look for the experts within your company and outside of it, and never stop searching. ([Location 2939](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2939)) - In developer marketing, we invest a lot of time in attracting developers to our platforms and, in developer relations, we educate those developers about what they can do, and then help them build products. ([Location 2950](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2950)) - While developer marketing and developer relations are usually not part of a profit and loss calculation, the success of our communities often ties to revenue somewhere else in the company. ([Location 2952](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2952)) - Designer Day events, including engaging with design schools for the first time. ([Location 2966](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2966)) - Winners received a variety of benefits including: A physical award to show off to friends, family, and colleagues Recognition in a public ceremony at SDC Mention in a press release timed during SDC Banner promotions and other premium merchandising in the Galaxy Store “Best of” award badges and imagery for use in their own marketing channels and events Features in communications to Samsung Developer Program members including an interview-style blog post and social campaigns. ([Location 2985](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=2985)) - Outside of these awards, the team also focused their time on the top sellers that were generating the most revenue or were otherwise off to a strong start. We wanted to see how we could help our top indies get to the next level. ([Location 3007](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3007)) - Sometimes developers value recognition as much as, or even more than, revenue. Being recognized as a top developer on your platform may help them land a future job. It can also be fun to show off your achievements. We are in the early stages of rolling out digital credentials to our developer and designer communities. ([Location 3046](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3046)) - coordinated with design schools across the United States to come on campus and provide a workshop for students in graphic design curriculums. ([Location 3053](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3053)) - They could choose to publish their content for free to build their online portfolio and reputation or choose to make it available for sale and start earning revenue. When you’re in college, any income can mean the difference between instant ramen noodles or peanut butter and jelly and a night out with your friends. We also found these students to be some of our most eager and creative workshop attendees. There was nothing they couldn’t achieve. ([Location 3055](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3055)) - time to ROI”) ([Location 3084](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3084)) - How do they define ROI? Is it revenue? Recognition? Learning new skills? Minimizing technical rework? Don’t just listen to your top partners. Call your top indie developers; find out what is working for them and what isn’t. Personal connection leads to higher satisfaction for both your external developers and your employees. Use the feedback you get to change what your program offers and how other teams within your company operate. ([Location 3129](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3129)) - “Having an open platform makes not a successful platform business, nor thousands of tinkering developers a healthy ecosystem.” ([Location 3358](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3358)) - well-maintained technical documentation is a must for developers to start engaging with your platform at an event. Getting started should be simple, and onboarding should be measured in minutes, not hours or days. It is frustrating for developers to waste half of their time at an event struggling to get their bearings on the table stakes, such as getting an environment setup and working with API authentication. If your docs are less than perfect or your platform is a bit more complex, provide quick-start guides, or starter packs (sample apps that are easy to grok and then build upon) that help developers accelerate. ([Location 3499](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3499)) - holding an event at or near the office lowered the quality and character ([Location 3520](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3520)) - It’s best to hold your event off site, or in an office that is not the home base for the majority of the team that is staffing the event. ([Location 3524](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3524)) - Ideally, the event is held in a place that is convenient for your ecosystem developers to attend, taking into consideration their travel and lodging costs. ([Location 3549](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3549)) - a location that entices people to come is also helpful. ([Location 3550](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3550)) - try not to be drawn into holding your event at your office as a cost-saving measure. ([Location 3551](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3551)) - we’ve historically used Net Promoter Score (NPS) as well as a few other metrics to establish the quality of the event. ([Location 3596](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3596)) - we shifted to a “top 5 metric” where attendees rate the event on a scale of 1 to 5 – one being “poor” and five being “awesome.” This provides us with a percentage based result which we find better reflects the quality of the event compared to NPS, and addresses the susceptibility of those enormous score swings. ([Location 3599](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3599)) - share a recap with your company to highlight what was accomplished, what was learned, and provide recognition to your teammates for their support of the event. ([Location 3613](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3613)) - events play a key role in engaging with one’s target audience because they present opportunities for attendees to: Connect with like-minded people from the host company or wider community Build relationships and network with one another Deliver meaningful, constructive product feedback. ([Location 3666](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3666)) - “Welcome to developer marketing. You cannot market to developers”. ([Location 3708](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3708)) - Creating physical space for authentic conversations - whether it be a meet up lounge at a large event, or a booth at a trade show, the right space design can create the “hallway track.” Different configurations invite audiences of varying levels of awareness and engagement: demo stands and lightning talk spaces draw people into the space hands on labs spaces encourage learning and Q&A highboy tables welcome 1:few discussions reconfigurable stools accommodate larger groups. ([Location 3712](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3712)) - Having experts available - in addition to thoughtful space design, trust and authenticity can be accomplished by including technical experts in the planning and staffing of an event. While titles and roles may vary, success can be achieved by involving individuals who are willing and able to not only advocate on behalf of an organization, but also on behalf of the developer. In addition, commit to listening to, documenting and passing along constructive product feedback. This also satisfies the desire for access to experts. ([Location 3723](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3723)) - Developers don't just want a slide presentation. They want to see code, touch code and break code. ([Location 3762](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3762)) - Attention to who is speaking, and action taken to seek out and encourage participation from a range of individuals, rather than waiting to see who submits a proposal, and shrugging off a lack of diversity if few are received from typically under-represented groups. ([Location 3774](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3774)) - Thoughtfulness around images in decks and other marketing materials. People want to see themselves, and don’t want to see stereotypes, such as groups comprising just “brogrammers”, exacerbated. ([Location 3779](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3779)) - well-publicized code of conduct and an escalation path for attendees who are not treated properly at the event, such as Google’s Event Community Guidelines and Anti-Harassment Policy sdata.me/sukUxE or the Salesforce Event Code of Conduct sdata.me/SmINbq. ([Location 3781](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3781)) - Developing a strong acquisition strategy to reach into under-represented communities, including through partnerships with other diversity-focused tech organizations, meet ups and training programs. ([Location 3786](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3786)) - Creating content that empowers speakers and attendees to share how they've successfully created diverse and inclusive environments. Focus on sharing solutions vs rant sessions about the state of diversity in the tech industry. ([Location 3788](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3788)) - Thoughtfulness around language used to promote activities, with attention paid to intersectionality. For example, do not list out all the possible URM groups you can think of in your marketing materials—website, social media pages, etc. You are bound to miss folks. Instead, let your audience know that your event/meetup is open and welcoming to everyone and discrimination will not be tolerated. ([Location 3791](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3791)) - Making people feel welcome through shirts in multiple sizes and cuts, pronoun stickers, and accessible, all-gender restrooms. ([Location 3795](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3795)) - Building out all spaces to make them accessible to all physical abilities, as well as including mother’s rooms and prayer rooms. ([Location 3796](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3796)) - Ensuring social activities have a range of well-labeled food and drink options as well as activities for all interests and abilities. ([Location 3798](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3798)) - Sponsorships can range from $1K for smaller events up to hundreds of thousands of dollars. In addition, most sponsorships will have an accompanying execution cost for things such as booth design and construction, swag, printing, and rentals. Depending on the number of staff needed, and the number of complimentary passes included in the sponsorship, you may also need to account for additional pass purchases. Budget in advance accordingly, and choose events selectively if your budget is limited. ([Location 3813](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3813)) - ask questions such as size and composition of the audience, whether your company has previously sponsored the event (and if so, if it was impactful), what post-event data will be provided as part of the sponsorship, whether the event aligns with key product announcements or stories, if it is minimally staffed, and if it has a code of conduct and commitment to diversity and inclusion. ([Location 3818](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3818)) - an event is only as effective as its connection to a larger marketing plan and the post-event nurture strategy. Ensure that you’re able to confidently answer questions such as: Are objectives clearly outlined, and can they be measured? Do the objectives ladder up to larger objectives around the product, technology or community? Do the tools and resources exist to follow up with leads, whether through client teams, email or both? Is there a post-event plan to “keep the lights on”, such as a recap email, blog post series, event content amplification campaign (e.g. twice weekly tweets highlighting session recordings), or re-engagement via digital advertising? For the teams involved, does their post-event workload allow for the bandwidth to execute post-event activities? ([Location 3871](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3871)) - developer programs can provide substantial content and structure to the event’s programming. ([Location 3886](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3886)) - Do you have certification programs? Consider add-on trainings on day zero or after the event wraps for people to get certified. ([Location 3887](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3887)) - Swag (‘Stuff We All Get’) ([Location 3944](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=3944)) - We see Innovators as individuals who build developer experiences on top of other developer experiences. ([Location 4143](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4143)) - Each Innovator provides us with access to developers in a new segment. Furthermore, these Innovators tend to have strong direct market knowledge and can provide interesting feedback to help you improve your own products. ([Location 4147](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4147)) - An important characteristic of an Innovator is that they are small business that is not yet fully established. This is important because the primary motivation of Innovators to work with us is to raise awareness of their product offerings so they can grow larger. Innovators frequently have stockpiles of talent, domain knowledge and motivation. What they lack is exposure. ([Location 4164](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4164)) - The goal of a well-run Innovator program is to shine the spotlight directly on each Innovator to give them more opportunities to tell their story. The faster these Innovators move, the more they grow and the more they benefit your company. ([Location 4167](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4167)) - If you have identified your angle – what it is that you can do for developers better than anyone else – it doesn’t matter how big or small, broad or narrow, make sure that you can solve that particular problem completely, and do it better than anything else in the market. ([Location 4205](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4205)) - There is a clear distinction to make when talking about developer relations and APIs. You need to consider whether your API is the product, or if your API feeds and supports a product. ([Location 4589](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4589)) - work on the developer experience (DX). ([Location 4613](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4613)) - The goal of DX is to maximize the conversion of people wanting to work with your APIs to those who will integrate them. In a world where developers are alone in front of their computers consuming your APIs, your DX needs to be at its best to make them feel autonomous and guided along the way to consumption. ([Location 4615](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4615)) - The perceived value of your API is measured across eight pillars of the developer experience: discovery, design, onboarding, documentation, tooling, management, transparency and communication, and a “no-surprise” policy. ([Location 4622](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4622)) - The way developers discover your APIs and the value it provides is key in starting your relationship with developers. ([Location 4625](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4625)) - Documentation should be divided into two parts. The first is a “tell-don’t-teach” approach, where you provide full explanations of how things work with a clear overview of the API and how it works, what it enables, authentication mechanisms, API references, etc. This is a little bit like the dictionary part of the API. ([Location 4661](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4661)) - The tooling provided by your developer portal is an important part of the developer experience. Tooling can include an API explorer, authentication playground, API debugging console, API sandbox, interactive documentation, an API description file like a downloadable OpenAPI specification, user personas, etc. Your developer relations team will be in charge of this experience and including all of these tools into the DX. Tooling is a pillar of DX that makes the difference when there is a lot of competition in the API market. ([Location 4671](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4671)) - Another pillar of the DX is the developer dashboard and API management for developers. You need to provide capabilities to developers and they will consume them, but developers need to know their level of consumption, the performance, and the error rates to effectively monitor their consumption. This is why a key part of DX planning must focus on how to give developers the maximum amount of information for monitoring their API usage. Common metrics include the number of API calls per endpoint, average response times, time to first byte, time to last byte, and the percentage of errors. You can decide to provide all the necessary metrics that your developer community wants to best manage their app with the right granularity. Also, don’t forget that a good DX involves nice user interfaces and dashboards to easily follow their app and API integration dynamics. Developers love design too! ([Location 4676](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4676)) - The transparency pillar is about delivering the maximum truth to developers with clear and direct communication. First, let’s remember that transparency needs to be aligned with your internal culture before it can be applied outside the organization. In the context of APIs and developer relations, transparency is about communicating the roadmap, the health of the platform, the strategy of the company, and its intention towards its APIs. ([Location 4683](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4683)) - Developers make things work. In that sense, they need to know things in advance so that their work is predictable. If you break that predictability, you break your trust with developers. ([Location 4693](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4693)) - Evaluating the quality and potential of your developer community is a key element of your developer relations strategy. ([Location 4711](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4711)) - calls “the nuts and bolts” of developer relations. It is a mix between developer relations practices and metrics to invest and track effectively. It is split into two parts; the API usage tracking and the developer tracking. ([Location 4717](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4717)) - “If you can’t measure it, you can’t improve it,” Admiral Lord Nelson used to say. On the other side, as the Goodhart law states, “when a measure becomes a target, it ceases to be a good measure.” How do you find the right balance between metrics and the goals of your developer relations strategy? You just have to match your KPIs with your APIs. ([Location 4721](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4721)) - Number of visits to the developer portal's homepage and documentation: ([Location 4733](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4733)) - Number of blog article views and reads: ([Location 4736](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4736)) - Number of developers registered to your newsletter: ([Location 4738](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4738)) - Number of speaking engagements / number of people reached by the talk: ([Location 4741](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4741)) - Open source stars and contributions for tools: ([Location 4747](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4747)) - Direct revenues generated by the API: ([Location 4794](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4794)) - Indirect revenue generated by the API: ([Location 4797](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4797)) - Conversation activity: ([Location 4806](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4806)) - Mentions from others: ([Location 4810](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4810)) - API presence and use in cool hacks and at hackathons: ([Location 4814](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4814)) - To build support for your developer relations work amongst your organization's managers, you will need to match the APIs metrics with business KPIs. ([Location 4848](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=4848)) - Think about migration first rather than last - ([Location 5113](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=5113)) - Transparency trumps everything ([Location 5117](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=5117)) - Tools such as response code lookups, compatibility checkers, migration wizards, etc. ([Location 5123](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=5123)) - There are 3 key steps involved in the creative process with an agency: Write your creative brief Choose your agency partner Receive creative content. ([Location 5162](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=5162)) - The following is a simple set of 10 questions you’ll want to answer in your creative brief. Ideally you should write no more than 1 paragraph for each of these to ensure brevity: What is your project title? What is the purpose of your project? (Explain why are you doing this and your business rationale) How is this good for your brand? Who is your target user or audience and what is your one key insight about them? What is the product/program benefit to your user? – (Remember to be inspiring here!) What do you want your target user or audience to do differently? What are the creative deliverables?  What is your target launch date and where will it launch? How large is your budget? (This is optional as to whether to include in the brief. I would suggest talking through instead) Who are the project owners? (our name, the name of co-leads who will interface with the agency and how to contact them). ([Location 5173](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=5173)) - how do they test and triage bugs? Are they familiar with handing off code? Have they checked-in projects on Github before? These things will prove that they’re living breathing developers with their finger on the pulse of your project. ([Location 5233](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=5233)) - talk in developer speak. Their voice and tone needs to match that of the developer audience for your product. ([Location 5237](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=5237)) - we encourage our agency partner to post the code to their own GitHub repositories, talk about the development on their blog and use their work to attract business beyond our engagement. This shows 2 things. 1) That we care deeply about the final deliverable and 2) That we’re invested in the success and credibility of our partner, as much as they are in our own success. ([Location 5275](https://readwise.io/to_kindle?action=open&asin=B07XM8GDD9&location=5275)) ## Related - [[3. Resources/Readwise/Books/Developer Relations|Developer Relations]] - [[3. Resources/Readwise/Books/Developer, Advocate!|Developer, Advocate!]] - [[3. Resources/Readwise/Books/The Business Value of Developer Relations|The Business Value of Developer Relations]] - [[3. Resources/Readwise/Books/The Developer Advocacy Handbook|The Developer Advocacy Handbook]] - [[3. Resources/Readwise/Books/Docs for Developers|Docs for Developers]]