Developer Relations: A Five-Level Maturity Model ![rw-book-cover](https://readwise-assets.s3.amazonaws.com/static/images/article3.5c705a01b476.png) ## Metadata - Author: [[About Michael Mahemoff]] - Full Title: Developer Relations: A Five-Level Maturity Model - Category: #articles - Document Note: --- tags: - #developerrelations - #devrel - #maturitymodel - #developeradvocacy author: About Michael Mahemoff source: [Developer Relations: A Five-Level Maturity Model] reference: [https://softwareas.com/developer-relations-a-five-level-maturity-model/?__readwiseLocation=#:~:text=LEVEL%200:%20No%20developer%20relations,for%20developers%20using%20the%20platform] date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} --- # Title: Developer Relations: A Five-Level Maturity Model ## Table of Contents: - [๐Ÿ“ Summary](#summary) - [๐Ÿ“– Main Content](#main-content) - [๐Ÿ—’๏ธ Notes](#notes) - [๐Ÿ“– References](#references) - [๐Ÿ—ฃ๏ธ Paraphrase](#paraphrase) - [๐Ÿ“ฐ Newsletter](#newsletter) - [โœ… Action Items](#action-items) - [๐Ÿงช Hypotheses](#hypotheses) - [๐Ÿ“Š Methodology](#methodology) - [โ“ Questions](#questions) - [๐Ÿ”ฎ Future Research](#future-research) - [๐Ÿ’ก Implications](#implications) - [๐Ÿง  Learning Styles Assessment](#learning-styles-assessment) - [๐Ÿ“Š Accessibility Assessment](#accessibility-assessment) - [๐ŸŒ DEIB Assessment](#deib-assessment) - [๐Ÿ” Logical validity](#logical-validity) - [๐Ÿ” DARVO Analysis](#darvo-analysis) - [๐Ÿ” SEO Evaluation](#seo-evaluation) - [๐ŸŽฏ Conclusion](#conclusion) ## ๐Ÿ“– References: 1. Mahemoff, Michael. *Developer Relations: A Five-Level Maturity Model*. Software as. [Link](https://softwareas.com/developer-relations-a-five-level-maturity-model/?__readwiseLocation=#:~:text=LEVEL%200:%20No%20developer%20relations,for%20developers%20using%20the%20platform) ## ๐Ÿ“ Summary: The article presents a maturity model for developer relations consisting of five levels, from no developer relations efforts to a quantified approach that actively measures the impact of Developer Relations (DevRel). It emphasizes that ascending through these levels has associated costs and risks, suggesting companies evaluate their current status and future goals in Developer Relations. ## ๐Ÿ“– Main Content: The maturity model described by Michael Mahemoff serves as a guide to understanding the varying levels of commitment and sophistication in developer relations. 1. **Level 0: No developer relations** - organizations do not make any effort to engage with developers or promote their platform. 2. **Level 1: Informal** - Some developer relations occur through other departments, but no official program exists. 3. **Level 2: High-touch** - This level involves very selective engagement with top-tier partners but does not seek to broadly communicate with all developers. 4. **Level 3: Evangelism** - At this stage, the organization actively promotes the platform to a wider audience through various channels. 5. **Level 4: Advocacy** - Here, the organization has a two-way relationship, providing feedback from developers back to the product teams and vice versa. 6. **Level 5: Quantified** - In the most mature stage, the organization measures success and returns on technologies through developer relations efforts. The author cautions against assuming all companies should aim for the highest level, as the costs and risks can outweigh the benefits depending on the company's context. ## ๐Ÿ—’๏ธ Notes - **Maturity Levels**: - **Level 0**: No internal efforts for developer relations. - **Level 1**: Informal development relations handled by PR or business roles. - **Level 2**: High-touch relationships with select partners for specific goals. - **Level 3**: Active promotion and recruitment of developers at scale. - **Level 4**: Two-way relationship fostering collaboration to enhance developer needs. - **Level 5**: Metrics-driven approach focusing on ROI for developer relations. - **Caveats**: - Each companyโ€™s context may dictate a different optimal level of operation. - The model is not a ladder of success but facilitates understanding where a company currently aligns. - The complexity of organizations doesnโ€™t always fit neatly into one level. ## ๐Ÿ—ฃ๏ธ Paraphrase: While many organizations might be eager to reach the top of a maturity model, it's essential to consider the associated costs, risks, and potential distractions such ascendance incurs. Not every company has the same incentives to elevate their developer relations; thus, determining oneโ€™s current position in the model and understanding oneโ€™s strategic objectives are crucial steps for success. A maturity model serves as a valuable framework that assists organizations in grasping their current state without being pigeonholed to a singular number, allowing for nuanced understanding across different segments of an organization. ## ๐Ÿ“ฐ Newsletter: Hey Tech Enthusiasts! ๐Ÿš€ This week, we delve into the fascinating realm of Developer Relations! Have you ever wondered about the different levels a company may achieve in fostering relationships with developers? Michael Mahemoff breaks it down into five insightful stagesโ€”from having no developer relations to a sophisticated system that measures its effectiveness. ๐ŸŒŸ In our community highlights, we explore exciting updates in web development and showcase some of the newest plugins that can help elevate your projects! Let's get coding and sharing our experiences! Stay tuned for more updates, and as always, happy coding! For further insights, check out the full article [here](https://softwareas.com/developer-relations-a-five-level-maturity-model/?__readwiseLocation=#:~:text=LEVEL%200:%20No%20developer%20relations,for%20developers%20using%20the%20platform). ## โœ… Action Items: - Align personal advocacy work with the maturity levels discussed. - Identify where GoDaddy currently stands regarding each level of the DevRel maturity model. - Encourage the development of outreach techniques that suitably advocate for both the platform and the developer community. - Incorporate insights from this model into future educational programs on open source contributions and community engagement. - Work toward measurable objectives and inclusivity goals as a potential OSPO director. ## ๐Ÿงช Hypotheses: 1. Organizations that engage actively at Level 4 benefit from faster feedback loops translating into improved product offerings. 2. Companies that neglect to develop a developer relations strategy may see decreased developer satisfaction and engagement over time. ### ๐Ÿ“Š Methodology: - Case studies of organizations at different levels of the model. - Surveys sent to developers and advocates for feedback on their interactions with platforms. - Analysis of developer activity pre-and post-implementation of structured developer relations. ### โ“ Questions: - What metrics can define success for developer relations at each maturity stage? - How do different organizations recognize their current maturity level? ### ๐Ÿ”ฎ Future Research: - Examining the retention of developers engaged at various maturity levels. - Investigating the ROI associated with improved developer relations frameworks. ### ๐Ÿ’ก Implications: - Effective developer relations can lead to improved developer engagement and satisfaction, impacting overall product success and community growth. ### ๐Ÿง  Learning Styles Assessment: - Engaging various learning styles (auditory, visual, kinesthetic) can improve developer relations and the delivery of educational content. ### ๐Ÿ“Š Accessibility Assessment: - Evaluate whether online resources and developer tools are accessible to all developers, ensuring inclusive outreach. ### ๐ŸŒ DEIB Assessment: - Assess where the developer relations program excels and could improve in diversifying participation and ensuring equal access to opportunities. ### ๐Ÿ” Logical validity: - The argument flow in the article is grounded and well-reasoned, clearly framing the concept of levels without presupposing that higher is always better. ### ๐Ÿ” DARVO Analysis: - Potential DARVO signs can emerge when organizations react defensively to feedback; for instance, claiming that external criticisms do not reflect their dedication to developers. ### ๐Ÿ” SEO Evaluation: - Evaluate the presence of key terms such as "developer relations," "maturity model," and links to related resources within the content for better search visibility. ## ๐ŸŽฏ Conclusion: The five-level maturity model for developer relations presents - URL: https://softwareas.com/developer-relations-a-five-level-maturity-model/?__readwiseLocation=#:~:text=LEVEL%200:%20No%20developer%20relations,for%20developers%20using%20the%20platform Having worked on both sides of developer relations, here are some thoughts about different levels of maturity for developer relations. **LEVEL 0: No developer relations** No internal effort is made to promote the platform, support developers, or capture their feedback. **LEVEL 1: Informal** No official developer relations staff or programme, but some developer relations handled by other functions. PR may be promoting the platform, business development may be partnering with and supporting developers. **LEVEL 2: High-touch** High-touch, often stealthy, relations with prized partners (i.e. large, established, companies or those with sufficient resources to build showcases for new features). This is a โ€œdonโ€™t call us, weโ€™ll call youโ€ outreach which may entail the platform providing funding or direct technical capability to build out the integration, and often working with as-yet unannounced technology so it can be launched with a set of poster-child applications. **LEVEL 3: Evangelism** Promoting, explaining, and supporting the platform at scale via conferences, partnerships, and online media. Proactive efforts to recruit large amounts of developers to use the platform. **LEVEL 4: Advocacy** A 2-way relationship in which the platformโ€™s own staff sees themselves as not just advocating for the platform, but as [advocating for developers using the platform](http://almaer.com/blog/developer-advocate-versus-technical-evangelist-when-names-change-the-tone). With this mindset, developer relations plays an active role in feeding back real-world bugs and feature requests, and building supporting tools to improve the developer experience. **LEVEL 5: Quantified** Metrics-driven approach in which the return-on-investment for developer relations is understood and outreach efforts are able to quantified, both with high-touch partners and at scale. --- Now some caveats about this. First, how *not* to use this model. Any maturity model immediately makes you think companies should be ascending to the top level, but that is not the case and not the intention here. Ascending comes at a cost that may not be justified; clearly, a pure platform company (e.g. Twilio, Stripe) has a lot more incentive to get to the top than a product company with an experimental โ€œlabsโ€ API, for example. There is financial cost, additional risks, and distraction to the rest of the organisation; all that needs to be weighed up. The purpose of this model, then, is to provide useful labels to facilitate these kinds of decisions. Not to imply one is intrinsically better than another. So the way to actually use this model is simply to be true to yourself. Where are you now and where do you want to be? If youโ€™re happy at level zero, scale any devrel back. If you want to shoot for level 5, start ramping up. Companies often differ widely between official and actual practices. A company may have no official developer relations programme, but instead have a technical marketing team or a super-engaged developer team who perform the same function. Likewise, no amount of fancy business cards will compensate for a developer relations programme that doesnโ€™t develop and rarely relates. Hopefully, this model helps people to understand where theyโ€™re at. Final caveat: Turns out you canโ€™t pigeonhole a complex organisation into a simple number rating. The lines will blur when applying these definitions to $YOUR\_FAVORITE\_EXAMPLE. You may apply these definitions to a whole company, a single division, or a single product. (Updated same day: moved maturity levels to top of article) ![Michael Mahemoff's Picture](https://softwareas.com/assets/images/authorimage.jpg) Michael is a full-stack product maker. Curious about programming, tech, startups, and future trends. #### Read Next, Developer Relations: A Five-Level Maturity Model, About Michael Mahemoff, 01jvfnm1e6zevz3aq20qndr4zb.