# Book Overview ![[Developer Relations Visual.excalidraw]] ## About the Author Caroline Lewko and James Parton are DevRel practitioners and consultants who have spent years working with companies to build and scale developer programs. Lewko is the founder of DevRelBook.com, a resource hub for DevRel professionals, and has extensive experience in program strategy and execution. Parton brings a background in developer marketing, community management, and go-to-market strategy for developer-focused products. Together, they've created what aims to be the definitive operational guide for DevRel -- not a philosophical treatise, but a practical handbook that covers everything from defining what DevRel is to measuring its impact and scaling the team. Their perspective is informed by direct experience and by extensive interviews and research with practitioners across the industry. ## Central Thesis Developer Relations is the professional practice of engaging developers as the primary users of a product, encompassing developer marketing, developer advocacy, developer experience, developer education, developer success, and community management. Lewko and Parton argue that DevRel requires its own distinct strategy because developers are a fundamentally different audience: they're logical, critical thinkers who value efficiency, distrust marketing fluff, and rely heavily on peer recommendations. The book's central framework is the developer journey -- Awareness, Activation, Engagement, and Retention -- and it argues that every DevRel activity should map to one of these stages. The journey isn't a marketing funnel imposed on developers; it's a model for understanding what developers need at each stage and designing programs that serve those needs. The book insists that DevRel must align with company goals, demonstrate measurable value, and be understood as a long-term investment (3-5 years minimum) rather than a quick-win initiative. ## Why This Book Matters This is the most comprehensive, structured guide to building a DevRel program from scratch. While other books cover specific aspects of DevRel (community building, events, advocacy), Lewko and Parton cover the entire landscape in a single, organized framework. The program maturity model (Stages 0-4) gives organizations a way to assess where they are and what they need to prioritize next. For anyone standing up a new developer program or inheriting an existing one, this book provides the strategic framework and tactical guidance to operate systematically rather than ad hoc. Readwise highlights: [[3. Resources/Readwise/Books/Developer Relations]] # Chapter Summaries ## Part I: Develop a Common Understanding ### What Is Developer Relations? DevRel is defined as both a professional practice and a program. It encompasses developer marketing, evangelism, advocacy, support, developer experience (DX), developer education, developer success, community relations, and program management. The book uses a tree metaphor: the trunk and roots are community -- without a healthy community, nothing else thrives. DX is the developer equivalent of UX. Developer marketing creates awareness. Developer education drives adoption. Developer success supports ongoing engagement. The three key differentiators of DevRel are: (1) your primary target audience is developers, (2) your strategy is designed to change developer behavior, and (3) your internal definition of success is predicated on developers. ### Where Does Developer Relations Fit? DevRel sits at the intersection of product, engineering, marketing, and sales. The book uses Mary Thengvall's quote from Ewan Davis: "To the community, I represent the company. To the company, I represent the community." DevRel professionals must understand multiple functional areas -- product management, engineering, marketing, sales -- because the role touches all of them. The chapter helps practitioners from different backgrounds (product, engineering, marketing) understand how their existing skills translate to DevRel. ### The Value of the Developer Economy This section establishes why companies should invest in DevRel by framing the scale and economic impact of the global developer community. It contextualizes DevRel as a business investment, not a nice-to-have, and lays the groundwork for the business justification chapters that follow. ## Part II: Key Differentiators ### The Audience: Developers Developers are logical, systematic thinkers who value efficiency and have low tolerance for people who pretend to understand their world but don't. The book advises: be factual in messaging, minimize fluff, and have developers review communications before publication. Developers want to see what's possible with your product -- use cases, showcase projects, and code samples are more compelling than marketing copy. They want to be the first to know but aren't necessarily the first to try; early adopters need incentives. Self-service options (free sign-up, no credit card required, free credits) encourage experimentation. ### Developers As Decision Makers Purchasing decisions involve multiple roles: initiator, technical decision maker, business decision maker, influencers, and approver. DevRel must create materials for each role: technical docs and quickstart guides for implementers, case studies and ROI analyses for business decision makers, and testimonials for influencers. ### Developer First and Developer Plus Developer First companies create products designed for developer use and treat developers as the primary decision makers (bottom-up approach). Developer Plus companies sell primarily to businesses or consumers but also offer developer products as a complement. The distinction matters for program strategy: Dev First companies make DevRel core to the business; Dev Plus companies must constantly justify DevRel's value to stakeholders who view it as peripheral. ### Business Models and Developer Products The B2D (Business to Developer) model differs from B2B and B2C because you're not selling finished products -- you're offering components and tools with the promise that something can be created. Marketing focuses on inspiring developers to see what's possible, backed by technical docs and code samples that provide the instructions. The book uses the value proposition canvas framework: define your customer's jobs to be done, the pains they face, and the gains they seek, then map your products to those needs. ## Part III: Alignment on Goals ### Company Goals and Alignment DevRel programs must link their activities to company priorities. In Dev Plus companies, DevRel is likely not viewed as core to the business, so practitioners must constantly educate stakeholders and connect their work to corporate goals. The book warns that programs face constant scrutiny and potential disruption, even when things are going well. Being armed with data is your best defense. ### Program Goals Most companies expect instant results but DevRel is a 3-5 year play. The four high-level objectives are Awareness, Activation, Engagement, and Retention. Program goals should account for variables including corporate goals, number of products supported, team size and skills, organizational placement, business model, budget, geography, program maturity, and competitive landscape. At least one goal should show how the program contributes value to the business. ## Part IV: Go-to-Market ### Developer Segmentation Four segmentation filters: technical (product-focused), user (developer-focused), organization (customer/use-case-focused), and market (industry/geography-focused). Each segment should be evaluated for relevance, size, value, and targetability. ### Developer Personas Personas make everyone's job easier -- the more specific you can be, the better your documentation, messaging, and product decisions become. The book provides a detailed persona template including name, photo, job title, company type, technical skills, current work/use cases, pain points, decision influence, information sources, awareness of your product, and pricing thresholds. ### Messaging Developer messaging must be factual, down-to-earth, and non-corporate. Separate developer-centric messaging from stakeholder-centric messaging. Map messaging to the developer journey stage for relevance. Include tone and voice, heroes and stories, feature keywords, benefit keywords, differentiation, and key statements. ### The Developer Journey The journey encompasses Discover, Evaluate, Learn, Build, and Scale. Each stage has specific touchpoints, content needs, and friction points. The book emphasizes friction logging (walking through the journey yourself), community feedback, and analytics-based evaluation. ### Developer Experience (DX) DX is the experience developers have when interacting with your product and documentation. DevRel advocates for developers by acting as an information valve, working with product teams on personas, encouraging journey measurement, ensuring community requirements influence roadmaps, and keeping up with market trends. Documentation must be current -- nothing undermines confidence faster than outdated or inaccurate docs. Technical writers who work with engineering and product teams are essential. ### Evaluate and Learn Stages Key touchpoints include product pages, documentation landing pages, FAQs, use cases, case studies, forums, webinars, quickstart guides, and getting-started experiences. The Learn stage adds formal training programs, office hours, additional learning resources (ebooks, video tutorials, podcasts), and sandbox environments. Reference guides and changelogs become important as developers go deeper. ### Build and Scale Stages As developers mature, storytelling becomes more important -- how your technologies fit the big picture, new ways of working, and best practices. SLAs, product roadmaps, case studies, ambassador programs, partner programs, and certification programs all play roles in retaining and scaling developer engagement. Sharing your product roadmap builds trust by showing developers you plan to be around. ### Developer Marketing Marketing tactics create awareness, generate leads and revenue, and nurture relationships. The developer hub splits between marketing-owned front-end and product-owned back-end (console/dashboard). Content formats range from case studies and whitepapers to blog posts and podcasts. Email nurture campaigns follow specific triggers: event registration, product signup, or dormancy. Active participation in external developer communities is an effective strategy. ### Events The book provides detailed guidance on event strategy: define why you're attending (learn, speak, educate, presence, sponsor), evaluate credibility, audience fit, resourcing, and budget. Tactical advice covers pre-event promotion, team selection, event planning, demo preparation, booth design, lead capture, feedback gathering, follow-up, content repackaging, and internal debriefs. Online event tips include testing equipment, clear agendas, audience engagement techniques, shorter durations, and recording for replay. Hackathon guidance emphasizes managing expectations and not claiming IP. ### Community A community can expand team capacity, bring authentic experience free of corporate bias, and provide peer advocacy that developers trust. Community members fall into passive contributors (lurkers who still absorb value), active contributors (regular participants across channels), and in-between floaters. Building community requires a culture of openness, community guidelines, a Code of Conduct, gamification (with caveats), and random acts of kindness. Open source communities have unique dynamics: implicit trust in visible code and clear win-win contribution value. ## Part V: Managing and Growing Your Program ### Metrics Metrics must include: the end goal, the target number, the time frame, and the reporting source. Program-level metrics align to Awareness, Activation, Engagement, and Retention. Community metrics include quantitative data (Stack Overflow questions, GitHub stars, forum activity) and qualitative data (surveys, NPS, product sentiment). The book insists on asking "So what?" after every metric and "What do I adjust?" It warns against three dangerous signals: perpetuating the myth that DevRel is hard to measure, believing targets stifle creativity, and constantly inventing new metrics. ### Team DevRel encompasses advocacy, support/success, events, developer education (DevEd), digital marketing/web, and community management. The book notes that DevRel careers can have a glass ceiling: the jack-of-all-trades nature makes it hard to go deep enough for lateral moves, small team sizes limit management experience, and limited external awareness of DevRel roles constrains opportunities. Recruiting advice includes scouting developer communities for potential talent. ### Program Phasing The maturity model defines five stages: - **Stage 0 (Ground Zero)**: No program, no staff, no budget, no strategy. - **Stage 1 (Improvised)**: 1-3 enthusiasts, no formal program, ad hoc outreach, <1000 community, $0 budget. - **Stage 2 (Establishment)**: 1-5 dedicated staff, basic plan, testing channels, <5000 community, <$50k budget. - **Stage 3 (Growth)**: <10 staff, formal strategy, formalized outreach, <10,000 community with contributors, <$1M budget. - **Stage 4 (Scale)**: >10 staff, sophisticated outreach, comprehensive DX, >50,000 community with active contributors, >$1M budget. Each stage describes expectations across product count, program maturity, staffing, strategy, budget, internal alignment, outreach sophistication, education/DX quality, metrics maturity, and community size. # Key Themes and Highlights ## Defining DevRel > 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. DevRel isn't one activity -- it's an umbrella covering a wide range of functions, unified by the target audience: developers. ## The Dual Representation Problem > "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" This quote (attributed to Ewan Davis, cited via Mary Thengvall) captures the fundamental tension of the DevRel role. You're always advocating in two directions simultaneously. ## Developers as a Unique Audience > 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. There is freedom for your communications to be much more technical and specific than traditional mainstream marketing. Less fluff, more substance. Understanding this audience's character is prerequisite to everything else. If you can't speak their language authentically, they'll tune you out. ## The B2D Model > The business model for Developer Relations is called "Business to Developer" or B2D. > It's not about selling a finished product; rather, component pieces or tools are offered with the promise that something could be created. B2D is fundamentally different from B2B or B2C. You're selling potential, not a finished product. Marketing must inspire while documentation must enable. ## DevRel Is a Long Game > 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. This is the single most important expectation to set with leadership. DevRel programs that get cut at 12 months never had a chance. ## Documentation as Trust > 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. Documentation quality is a trust signal. Stale docs communicate that you don't care about the developer experience. ## Roadmap Transparency > 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. Developers invest heavily in your platform. Showing them where you're going gives them confidence to invest further. ## Metrics Discipline > Ask, "So what?" after every metric > 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. 3. DevRel practitioners who believe they need to constantly invent new metrics. The book pushes back hard against the "DevRel is unmeasurable" narrative. If you can't measure it, you can't defend it. ## Program Maturity Over Time > 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. DevRel isn't a single hire -- it's a cross-functional program that grows through collaboration and specialization over time. ## The Career Challenge > One of the challenges with DevRel has been career paths have a reputation of having a glass ceiling as seniority increases. The jack-of-all-trades nature of DevRel creates real career development challenges. The book honestly acknowledges this without pretending it's solved. # Analytical Reading ## Main Arguments 1. DevRel is a comprehensive discipline encompassing marketing, advocacy, education, experience design, success, and community management -- all unified by a developer audience. 2. Developers require fundamentally different engagement approaches than traditional B2B or B2C customers: factual messaging, peer credibility, code-first experiences, and self-service options. 3. Every DevRel activity should map to the developer journey stages: Awareness, Activation, Engagement, and Retention. 4. DevRel programs must align with company goals and demonstrate measurable business value to survive organizational scrutiny. 5. DevRel is a 3-5 year investment that builds compounding returns through community trust and peer advocacy. 6. Documentation quality, DX friction reduction, and roadmap transparency are trust signals that directly affect developer adoption and retention. 7. Program maturity follows a predictable progression from ground zero to scale, with specific staffing, budget, and capability requirements at each stage. ## Methodology The book is structured as a comprehensive operational handbook, drawing on practitioner experience, industry frameworks (value proposition canvas, developer journey mapping), and community-sourced best practices. It's prescriptive rather than research-based -- more "here's how to do it" than "here's what the data says." The maturity model provides a diagnostic and planning framework. The heavy use of annotated highlights (the reader's own notes are extensive) suggests deep, practical engagement with the material. ## Strengths The comprehensiveness is the book's defining strength. It's rare to find a single volume that covers the full lifecycle of a DevRel program -- from definition and organizational placement through segmentation, messaging, every journey stage, events, community, metrics, team building, and program phasing. The maturity model gives organizations a concrete assessment tool. The consistent mapping of activities to the four objectives (Awareness, Activation, Engagement, Retention) provides strategic clarity. The honest treatment of career challenges and organizational politics adds credibility. ## Limitations The comprehensiveness comes at the cost of depth in some areas. Practitioners deeply experienced in, say, community management or events strategy will find those chapters more introductory than advanced. The book assumes a certain organizational size and structure that won't match every company. Some of the tactical advice (event checklists, online event tips) may date quickly as platforms and practices evolve. The prescriptive tone occasionally edges toward rigidity -- real programs often need more improvisation than the framework suggests. # Personal Reflection ## Key Takeaways The maturity model (Stages 0-4) is the most immediately actionable framework in the book. It lets you assess where your program is, what's realistic to achieve next, and what resources you need to get there. The four-objectives framework (Awareness, Activation, Engagement, Retention) provides the strategic backbone for every conversation about what DevRel should be doing and why. The distinction between Developer First and Developer Plus companies is critical for setting expectations. In Dev Plus organizations, the constant work of educating stakeholders and connecting DevRel to core business goals isn't a distraction from the "real work" -- it is the work. Without internal buy-in, external programs can't survive. The emphasis on DevEd as potentially the primary DevRel function (over advocacy) is an important evolution in how the field thinks about itself. The pandemic accelerated this shift, but the underlying logic is sound: education is the most scalable and defensible form of developer engagement. ## Questions Raised - How should the maturity model adapt for Dev Plus companies where DevRel will never be core to the business, even at maturity? - What's the right balance between the four objectives at different maturity stages? Should Stage 1 programs focus almost entirely on Awareness, or try to cover all four? - How do you handle the tension between DevRel's long-term nature and quarterly business review cycles? - As AI-assisted development changes how developers learn and build, how should DevRel programs adapt their education and DX strategies? ## Connections to Other Works This book pairs directly with [[3. Resources/Readwise/Books/Developer Marketing and Relations]], which takes a more multi-perspective, case-study approach to similar topics. Mary Thengvall's *The Business Value of Developer Relations* goes deeper on the business justification and internal advocacy dimensions. Jono Bacon's *People Powered* extends the community management dimension. The developer education themes connect to [[3. Resources/Readwise/Books/Design for How People Learn]] by Julie Dirksen. The metrics and goal-setting frameworks connect to OKR methodology. The maturity model echoes capability maturity models from other disciplines (CMMI, etc.). The book's companion site at DevRelBook.com provides additional frameworks and templates.