# Developer, Advocate! ## Book Overview Developer, Advocate! is an oral history of the developer advocacy profession, assembled by Geertjan Wielenga through interviews with practitioners across the tech industry. The book captures the voices of people who've built careers at the intersection of engineering, community, and communication -- people who get paid, as one interviewee puts it, to have fun and share that fun with others. The book grapples with the identity crisis at the heart of developer relations: where does your allegiance lie between the company that employs you and the community you serve? Wielenga threads this tension throughout each conversation, letting advocates speak candidly about the ethical dilemmas, the title debates (evangelist vs. advocate), and the constant negotiation with marketing departments who want to broadcast messages developers don't want to hear. What emerges is a portrait of a role that's equal parts technical credibility, storytelling ability, and community instinct. The practitioners interviewed share a common DNA: they're tinkerers who expand new worlds, document them, and enthuse about them. The book serves as both a career guide for aspiring advocates and a mirror for those already in the field. ## Key Themes and Highlights ### The Evangelist vs. Advocate Debate The shift from "evangelist" to "advocate" is more than cosmetic. Multiple interviewees explain why the religious connotations of "evangelist" create real problems -- one Microsoft field evangelist was detained at a border crossing in a Muslim country because his job title raised flags. The consensus is clear: "I prefer 'advocacy' over 'evangelism' because it implies a more measured, thoughtful, and nuanced discussion." The term matters because it signals intent -- advocates listen and represent, while evangelists preach. As one practitioner notes, "Tech evangelist seems to have fallen from favor as a title in the last few years." ### Honesty and Credibility as Currency The book's most consistent theme is that developer advocates must be honest to be effective. "Not being able to speak honestly about a product would mean that I was failing as an advocate." This means being willing to ask your employer hard questions: "Are you okay with me saying good things about the competition? Are you okay with me talking about rough spots in our API or our product?" Credibility with developers is earned through technical depth -- "If you want to be an advocate towards developers, the first thing you have to do is be a developer." Without that credibility, the role collapses into marketing, which developers instinctively reject. ### The Tension Between Engineering and Marketing Developer advocacy exists where "engineering meets marketing," but that positioning creates constant friction. "Developer relations is just an extension of marketing, but it's different when you market to developers because they don't like being marketed to." Advocates describe spending significant energy pushing back against marketing teams who want to fill social channels with irrelevant content. "Much of your job will be saying no to marketing people." The role demands a different communication style -- one that builds trust rather than broadcasts messages. ## Analytical Reading - **Central Argument:** Developer advocacy is a distinct profession that requires authentic technical credibility, honest communication, and a careful balance between company interests and community needs. - **Key Evidence:** First-person accounts from dozens of practitioners across companies like Microsoft, Google, and various startups, sharing real-world anecdotes about role challenges and successes. - **Methodology/Approach:** Interview-based oral history, letting practitioners define the role through their own experiences rather than imposing a framework. - **Strengths:** The diversity of voices gives a panoramic view of the profession. The candid discussions of ethical dilemmas and title politics ground the book in practical reality rather than aspiration. - **Limitations:** The interview format can feel repetitive -- the evangelist vs. advocate debate surfaces in nearly every conversation. The book lacks a strong editorial synthesis that ties the individual stories into a cohesive framework. It's also heavily weighted toward Western tech company perspectives. ## Personal Reflection This book validates something many in DevRel sense but struggle to articulate: the role only works when built on genuine technical respect. The practitioners who thrive aren't the best speakers or the most polished writers -- they're the ones developers recognize as peers who've "put the miles in." That credibility can't be manufactured through marketing budgets or social media strategies. The emphasis on saying no to marketing resonates with the broader challenge of building trust-based relationships in technical communities. The book connects well to ideas in The Business Value of Developer Relations and People Powered about community-first approaches to developer engagement. The insistence on honesty -- even about your own product's weaknesses -- mirrors the principles of radical candor applied to a community context. The burnout thread running through several interviews is worth attention. The advice to be conscious of how much you can do as one person, to ask for help, and to recharge applies far beyond DevRel. It's a reminder that community-facing roles extract a particular kind of energy that needs active management. ## Action Items - [ ] Audit current developer-facing communications for marketing language that should be replaced with authentic technical content - [ ] Build open-source contributions into professional development plan as a credibility investment - [ ] Establish clear boundaries between DevRel and marketing responsibilities, with documented guidelines for content approval