**Author:** [[3. Resources/Authors/Mary Thengvall|Mary Thengvall]] # Book Overview ![[The Business Value of Developer Relations Visual.excalidraw]] ## About the Author Mary Thengvall has been building developer communities for over a decade, with stints at O'Reilly Media, Chef, and SparkPost before becoming VP of Developer Relations at Camunda. She's the founder of DevRel Collective (a community of DevRel professionals), the creator of the DevRel Weekly newsletter, and co-host of the Community Pulse podcast. Her background is unusual for the field -- she started in community management rather than engineering, which gives her a perspective that's more focused on relationship-building and organizational strategy than on code. Jono Bacon (author of *The Art of Community*) wrote the foreword and frames Thengvall as someone who's spent years answering the question most DevRel people dread: "What's the ROI?" ## Central Thesis Developer Relations professionals are the connective tissue between a company and its technical community. They aren't marketers, aren't support engineers, and aren't salespeople -- though they touch all three functions. Their job is to build genuine relationships with developers, listen to community needs, translate those needs back into the organization, and create the conditions for mutual value. Thengvall's core argument is that putting the community's interests first isn't altruism -- it's the most effective business strategy. But DevRel teams that can't prove their value in terms the business understands will get cut. The book is an attempt to provide both the philosophical foundation and the practical measurement toolkit to prevent that. ## Why This Book Matters Developer Relations is a field with a persistent legitimacy problem. Practitioners know the work matters, but most can't articulate *how* it matters in terms that finance, sales, or executive leadership care about. The result is that DevRel teams are often the first to get cut in downturns -- not because they don't create value, but because nobody can point to where the value lives. Thengvall's book is the first serious attempt to bridge that gap. It's split into two parts: one aimed at decision-makers who need to understand *why* they should invest in DevRel, and one aimed at practitioners who need to know *how* to do the work and prove its worth. For anyone building, managing, or justifying a DevRel function, this is the closest thing the field has to a foundational text. --- # Chapter Summaries ## Part I: What Is the Value of a Technical Community? ### Chapter 1: An Introduction to Community Thengvall starts by defining what community actually means -- and more importantly, what it doesn't mean. She borrows Jono Bacon's definition: a group of people who share common principles and develop shared practices that help individuals thrive. The key distinction is between a community (which exists for mutual benefit) and an audience (which exists for the company's benefit). She walks through the evolution of developer communities from open source mailing lists to modern DevRel programs, and introduces the idea that developer relations professionals operate as a bridge between the company and the community. The chapter establishes that community isn't a marketing channel -- it's a relationship, and treating it like a funnel is a fast way to lose trust. ### Chapter 2: Selling Community to Your Company This is the chapter most DevRel practitioners will dog-ear. Thengvall tackles the problem of getting organizational buy-in for community investment. She introduces the "DevRel as avocados" analogy -- explaining that, like avocados, DevRel provides enormous value but can spoil quickly if neglected. The chapter covers identifying internal champions, building the business case, and establishing quick wins that demonstrate value before asking for bigger investment. She's honest about the difficulty: most executives don't intuitively understand DevRel, and the burden of proof falls on the DevRel team, not on the skeptics. The chapter introduces the concept of "time-to-value" -- how quickly a developer can go from discovering your product to having a working implementation -- as a metric executives can understand. ### Chapter 3: Keeping a Pulse on the Community Thengvall argues that the most important DevRel skill is listening. This chapter covers the practical mechanics: monitoring community channels, tracking sentiment, running surveys, conducting user interviews, and building feedback loops that get community insights back to product and engineering teams. She introduces the "warm handoffs" concept -- the idea that DevRel's unique value is connecting the right community member to the right internal person at the right time. A warm handoff isn't a sales lead. It's a qualified connection where both sides benefit. Trip reports (structured summaries of event attendance and community interactions) get detailed treatment as a tool for turning qualitative observations into actionable intelligence. ### Chapter 4: Measuring Your Success The measurement chapter is the book's heaviest lift. Thengvall introduces two frameworks: Libby Boxes (a visual way to map metrics to specific DevRel activities and their organizational impact) and AAARRRP (a developer-specific adaptation of the pirate metrics framework -- Awareness, Acquisition, Activation, Retention, Revenue, Referral, Product). She's direct about the challenge: DevRel impact is often indirect, and trying to measure it the same way you'd measure a sales pipeline produces misleading numbers. The solution isn't to avoid measurement. It's to identify metrics that accurately capture what DevRel actually does -- which is build relationships, create content, provide feedback, and reduce friction -- and connect those metrics to business outcomes. The chapter covers both quantitative metrics (content reach, event attendance, time-to-hello-world) and qualitative measures (community sentiment, quality of feedback, strength of relationships). ### Chapter 5: Building a Developer Relations Team Thengvall covers team structure, hiring, and organizational placement. She introduces the "mall map" analogy -- you need to know where you are before you can plan where to go -- and applies it to DevRel team planning. The chapter covers the three main DevRel roles (Developer Advocate, Technical Community Builder, Developer Evangelist) and the important distinctions between them. She addresses the organizational placement question (should DevRel sit under Marketing, Engineering, Product, or its own function?) with nuance: there's no universally right answer, and the best placement depends on the company's maturity, size, and what it needs DevRel to accomplish. The chapter also covers hiring for values alignment over pure technical skill, and why DevRel teams that don't have executive sponsorship eventually fail regardless of the quality of their work. ## Part II: Building and Maintaining Community ### Chapter 6: Finding Your Community This chapter addresses the practical question of where your community actually lives and how to meet them where they are rather than forcing them to come to you. Thengvall covers identifying community channels (GitHub, Stack Overflow, forums, Slack/Discord, Twitter, meetups), understanding the difference between owned and external communities, and the strategic decision of when to build your own platform versus participating in existing ones. She argues against the instinct to create a branded community from scratch -- most companies should start by showing up in the communities that already exist around their technology or problem space. ### Chapter 7: Building a Healthy Community Community health requires intentional cultivation. Thengvall covers establishing community guidelines, creating inclusive spaces, building contributor pathways (from observer to participant to contributor to leader), and the critical importance of a Code of Conduct that's actually enforced. She draws on examples from the Kubernetes and Docker communities to show what healthy community architecture looks like. The chapter emphasizes that community health isn't measured by size alone -- a small, engaged community is worth far more than a large, passive one. ### Chapter 8: In-Person Events: The How, Why, and Where Events are DevRel's most visible and most expensive activity, and Thengvall treats them with appropriate scrutiny. She covers the spectrum from large conferences to small meetups to company-hosted developer days, and introduces the "event scoreboard" concept for evaluating which events are worth attending. The chapter addresses practical concerns -- talk proposals, booth presence, hallway track strategy, post-event follow-up -- and connects each activity to measurable outcomes. She's honest that events are hard to measure and easy to justify with vanity metrics, and pushes for more disciplined evaluation of whether conference presence actually produces the outcomes the team claims. ### Chapter 9: Dealing with Common Community Issues The operational reality chapter. Thengvall addresses burnout (the defining occupational hazard of DevRel), dealing with toxic community members, managing the tension between community advocacy and company priorities, and handling crises. The burnout section is particularly substantive -- she covers the structural causes (constant travel, emotional labor, context-switching between internal and external audiences) and the organizational responsibility to prevent it rather than treating it as an individual failure. The chapter also addresses the tension that arises when the community wants something the company won't deliver, and how DevRel professionals navigate that gap without losing credibility on either side. ### Chapter 10: Building Your Personal Brand Thengvall closes with the relationship between personal brand and company brand in DevRel. She argues that DevRel professionals *should* build their own personal brands, and that this isn't disloyal to the company -- it's a feature, not a bug. A DevRel person with a strong personal reputation brings that credibility to the company. The chapter covers content creation, speaking, writing, social media presence, and the practical concern of what happens to your community relationships when you change jobs. She's direct that companies who try to prevent their DevRel team from building personal brands are sabotaging themselves. --- # Key Themes and Highlights ## DevRel Is a Relationship Function, Not a Marketing Channel This is the book's foundational distinction. Developer Relations works because it's built on genuine relationships and trust. The moment DevRel becomes a glorified marketing operation -- pushing products rather than solving problems, generating leads rather than building relationships -- it loses its effectiveness. Thengvall returns to this point repeatedly: the community can tell the difference between someone who's there to help and someone who's there to sell. DevRel teams that prioritize company metrics over community needs eventually lose the community. ## The Measurement Problem Is Real But Solvable DevRel's biggest organizational vulnerability is the difficulty of measuring its impact. Thengvall doesn't dodge this -- she acknowledges that DevRel impact is often indirect, lagging, and hard to attribute. But she argues that the response shouldn't be to avoid measurement or to co-opt sales metrics that don't fit. Instead, she pushes for purpose-built metrics: warm handoffs, time-to-value, community sentiment, content engagement, and the AAARRRP framework. The Libby Boxes framework is her tool for making the connection between DevRel activities and business outcomes visible. ## Warm Handoffs as the Core Value Metric Of all the metrics Thengvall discusses, warm handoffs get the most emphasis. A warm handoff is when a DevRel professional connects a community member to the right person inside the company -- not as a cold lead, but as a qualified introduction where both sides have context and incentive to engage. This captures what DevRel actually does that no other function can replicate: it builds the relationship capital that makes these connections productive rather than transactional. ## Burnout Is a Structural Problem The burnout discussion stands out because Thengvall treats it as an organizational failure, not a personal one. DevRel professionals travel constantly, switch between deeply technical and deeply interpersonal work, serve two masters (company and community), and often lack clear career paths. When they burn out -- and they burn out at alarming rates -- the cause is structural, and the fix has to be structural too. This means reasonable travel expectations, clear role definitions, executive support, and career ladders that don't dead-end. ## Community First Is a Business Strategy The book's central paradox: putting the community's needs first -- even when that means saying uncomfortable things to your company, or recommending a competitor's product when it's a better fit -- is actually the most effective business strategy. It's counterintuitive for organizations accustomed to treating everything as a pipeline, but Thengvall makes the case that the trust you build through genuine community-first behavior pays off in retention, referral, and product quality in ways that traditional marketing can't replicate. --- # Analytical Reading ## Main Arguments 1. Developer Relations is a distinct discipline, not a subset of marketing, sales, or engineering. 2. DevRel's unique value is building genuine relationships between a company and its technical community. 3. Putting community needs first isn't altruism -- it's the most effective long-term business strategy. 4. The measurement problem is DevRel's biggest organizational vulnerability, and it can be addressed with purpose-built frameworks (Libby Boxes, AAARRRP). 5. Warm handoffs -- qualified connections between community members and internal teams -- are DevRel's most valuable and most unique output. 6. DevRel teams need executive sponsorship, clear organizational placement, and defined career paths to survive. 7. Burnout in DevRel is a structural problem caused by role design, not a personal failure. 8. Community health requires intentional investment in inclusion, governance, and contributor pathways. 9. Personal brand and company brand are complementary in DevRel, not competitive. ## Methodology This is a practitioner's handbook, not academic research. Thengvall builds her arguments from personal experience (a decade in community roles), case studies from named companies (SparkPost, PagerDuty, CoreOS, Algolia, Twilio, Google, Docker, Kubernetes), and interviews with other DevRel professionals. The AAARRRP framework adapts Dave McClure's pirate metrics for developer audiences. The Libby Boxes framework appears to be original. There's no systematic data collection, no controlled studies, and no statistical analysis. The book's authority comes from lived experience and broad pattern recognition across the DevRel field, not from empirical proof. ## Strengths The book fills a genuine gap. Before this, there was no single resource that covered both the strategic justification for DevRel and the practical execution. Thengvall's willingness to tackle measurement head-on -- rather than waving it away as "too hard" or "you just have to trust us" -- gives the book credibility with the skeptical audience that DevRel teams need to convince. The warm handoffs concept is genuinely useful and captures something that other frameworks miss. The burnout discussion is honest and specific. The two-part structure (decision-makers first, practitioners second) is smart design. ## Limitations The book is strongest on the *why* and weakest on the *how*. The measurement frameworks (Libby Boxes, AAARRRP) are introduced but not deeply developed -- a reader looking for step-by-step implementation will want more detail than they'll find here. The case studies tend toward the positive (successful DevRel programs) without much attention to why DevRel programs fail in detail. The book assumes a SaaS or developer-tools context that doesn't translate cleanly to all industries. Some of the tactical advice (specific tools, platforms, community channels) has dated as the landscape has shifted. The writing is occasionally repetitive -- the core argument about community-first strategy gets restated more times than necessary. And the book doesn't engage much with critics who argue that DevRel is fundamentally a marketing function with better branding. --- # Personal Reflection ## Key Takeaways The warm handoffs concept is the book's most portable idea. It gives DevRel a metric that captures their unique contribution rather than borrowing metrics from sales or marketing that never quite fit. The other big takeaway is the structural framing of burnout -- not as "you need to set better boundaries" but as "the organization needs to design roles that don't systematically destroy people." The social operating mechanisms concept from *Execution* maps interestingly onto Thengvall's argument about DevRel team placement and organizational buy-in. In both cases, where the function sits in the org chart matters less than what happens in the regular meetings and reviews. A DevRel team under marketing can operate with genuine community orientation if the social operating mechanisms support it. A DevRel team with its own reporting line can still get co-opted if the regular operating rhythms push toward lead generation over relationship building. ## Questions Raised - How do the measurement frameworks scale for very early-stage companies that don't have enough data to populate them? - The warm handoffs metric captures DevRel's unique value, but how do you prevent it from being gamed -- turned into a quantity metric rather than a quality one? - What does DevRel look like in companies whose users aren't developers? Does any of this translate to non-technical communities? - How does the community-first philosophy survive a genuine financial crisis where the company needs short-term revenue from the community? - The book treats DevRel as inherently good for both company and community. When do those interests genuinely conflict, and how do you handle the irreconcilable cases? ## Connections to Other Works - [[Execution]] by Larry Bossidy and Ram Charan -- Bossidy's social operating mechanisms framework maps onto Thengvall's arguments about where DevRel sits in the organization. Culture travels through meetings, not org charts. - [[Good to Great]] by Jim Collins -- Collins' emphasis on getting the right people on the bus parallels Thengvall's chapter on building DevRel teams and the importance of values alignment in hiring. - [[The Lean Startup]] by Eric Ries -- Ries' build-measure-learn loop connects to Thengvall's feedback loops between community and product, and the emphasis on measuring what matters rather than what's easy. - [[High Output Management]] by Andy Grove -- Grove's concept of managerial leverage connects to the idea that DevRel's value multiplies through the relationships and connections it creates. - [[Turn the Ship Around!]] by L. David Marquet -- Marquet's model of distributed leadership maps onto Thengvall's argument that DevRel professionals need autonomy and trust to build authentic community relationships. --- # Reading Notes - Thengvall's definition of community (shared principles + shared practices that help individuals thrive) is more useful than most because it excludes audiences. An audience is people you talk at. A community is people who help each other. - The "DevRel as avocados" analogy is charming but tells a serious story: DevRel provides enormous value when ripe, but spoils fast when neglected. You can't stockpile it. - The mall map analogy for team planning (know where you are before planning where to go) is simple but gets misapplied constantly. Teams skip the assessment and jump to ambition. - Time-to-value (how fast a developer goes from discovery to working implementation) is the metric executives understand fastest because it maps to their own experience of friction. - The Libby Boxes framework needs more development than it gets here. The concept is right -- map activities to metrics to outcomes -- but the implementation details are thin. - AAARRRP (Awareness, Acquisition, Activation, Retention, Revenue, Referral, Product) adapts pirate metrics well for developer audiences, but the "Product" addition is the most interesting part. DevRel should feed product decisions, not just marketing ones. - The honest treatment of DevRel organizational placement -- there's no universally right answer -- is refreshing after reading too many prescriptive takes. - The burnout section should be required reading for anyone managing DevRel professionals. The structural causes (constant travel, emotional labor, role ambiguity, serving two masters) are predictable and preventable. - The Code of Conduct discussion is practical: a CoC only matters if it's enforced, and enforcement requires clarity, consistency, and willingness to act even against high-value community members. - The personal brand argument is correct and underappreciated: DevRel people who build strong personal brands bring credibility that benefits the company. Companies that fight this are shooting themselves in the foot. - The book's biggest weakness is repetition. The community-first argument gets made well the first time, adequately the second, and redundantly the third through fifth. ## Readwise Highlights - [[3. Resources/Readwise/Books/The Business Value of Developer Relations|The Business Value of Developer Relations - Kindle Highlights]]