# The Developer Journey: From Awareness to Advocacy ## Sources - [[3. Resources/Readwise/Books/The Business Value of Developer Relations|The Business Value of Developer Relations]] by [[Mary Thengvall]] [Open in Kindle](https://www.amazon.com/dp/B07FKFQ1NK) - [[3. Resources/Readwise/Books/Developer Marketing Does Not Exist|Developer Marketing Does Not Exist]] by [[Adam DuVander]] [Open in Kindle](https://www.amazon.com/dp/B091NK954H) ## The Synthesis in 3 Sentences Developer Relations exists at both the top and bottom of the funnel — responsible for brand awareness and for making sure existing developers are taken care of — but its primary goal is never lead generation. The moment a developer community senses that your team simply wants them to sign on the dotted line, you lose all credibility. The path from awareness to advocacy runs through education, genuine relationship-building, and a developer experience that reduces time-to-Hello-World while treating open source and paid communities with equal respect. ## Key Themes ### Theme 1: DevRel is Not Marketing — It's Education and Relationship Thengvall is explicit: "the primary goal of Developer Relations is not lead generation" and "the Developer Relations team should never carry a quota related to a particular number of leads" ([Location 743-748](https://readwise.io/to_kindle?action=open&asin=B07FKFQ1NK&location=743)). DuVander frames this as the title thesis: "Developer marketing does not exist because you can't bring your typical tactics to this skeptical audience... share knowledge, not features" ([Location 1754](https://readwise.io/to_kindle?action=open&asin=B091NK954H&location=1754)). Both authors converge on education as the replacement for traditional marketing. DuVander's practical formulation: "reframing toward education will help you find the mindset to attract a technical audience" ([Location 118](https://readwise.io/to_kindle?action=open&asin=B091NK954H&location=118)). ### Theme 2: The Developer Experience Funnel Thengvall maps the developer journey through "Pirate Metrics" — Awareness, Acquisition, Activation, Retention, Revenue, Referral, Product ([Location 1546](https://readwise.io/to_kindle?action=open&asin=B07FKFQ1NK&location=1546)). DuVander focuses on the critical "Time to Hello World" — how fast a developer can see value from your product ([Location 341](https://readwise.io/to_kindle?action=open&asin=B091NK954H&location=341)). Both agree that the transition from awareness to activation is where most developer products fail: if documentation is hard to find, the getting started guide is bloated, or self-serve sign-up is gated behind a sales call, developers leave. ### Theme 3: DevRel as Cross-Functional Connector Thengvall uses a vivid metaphor: "DevRel is the people building the train tracks. Marketing builds the train station. Engineering builds the train. Sales drives the train home" ([Location 755](https://readwise.io/to_kindle?action=open&asin=B07FKFQ1NK&location=755)). DevRel's unique skill is communicating across Marketing, Product, Engineering, Sales, and the community simultaneously ([Location 1309](https://readwise.io/to_kindle?action=open&asin=B07FKFQ1NK&location=1309)). DuVander lists the collaborators: API Product Managers, Customer Support, Technical Account Managers, Sales Engineers, Solutions Engineers, Customer Success ([Location 1690](https://readwise.io/to_kindle?action=open&asin=B091NK954H&location=1690)). DevRel teams have "T-shaped skills" — broad collaboration (horizontal) but often lack depth in any one vertical ([Location 3801](https://readwise.io/to_kindle?action=open&asin=B07FKFQ1NK&location=3801)). ### Theme 4: Community Must Be Authentic, Not Manufactured Thengvall warns against starting proprietary-product meetups: "A meetup hosted by a company about its proprietary product is easily called out by developers as a sales tactic" ([Location 3317](https://readwise.io/to_kindle?action=open&asin=B07FKFQ1NK&location=3317)). The better approach: "Figure out where your customers already hang out and meet them at their level" ([Location 2389](https://readwise.io/to_kindle?action=open&asin=B07FKFQ1NK&location=2389)). DuVander reinforces this: "Enter into Long-Term Partnerships, Not Quick Growth Tactics" ([Location 1415](https://readwise.io/to_kindle?action=open&asin=B091NK954H&location=1415)). ### Theme 5: Burnout is the Industry's Shadow Thengvall dedicates significant space to DevRel burnout: "true burnout is a state of chronic stress and frustration at work that leads to physical and emotional exhaustion" ([Location 3505](https://readwise.io/to_kindle?action=open&asin=B07FKFQ1NK&location=3505)). The root cause is structural: "What burns people out is not doing hard work, but rather feeling like their work doesn't matter" ([Location 3526](https://readwise.io/to_kindle?action=open&asin=B07FKFQ1NK&location=3526)). When DevRel teams can't prove their value or are treated as a cost center, burnout accelerates. Thengvall recommends no more than 50% travel and a "four-hour decompress" weekly ([Location 3247, 3708](https://readwise.io/to_kindle?action=open&asin=B07FKFQ1NK&location=3247)). ## Tensions and Questions - **Measurement paradox:** Both authors acknowledge that DevRel metrics are hard to quantify. Thengvall says "ROI Is a Difficult Metric for DevRel" and advocates combining quantitative data with "gut" intuition from people who know the community. But this makes DevRel perpetually vulnerable to budget cuts when companies tighten spending. - **Advocate vs. Ambassador vs. Evangelist:** Thengvall explicitly rejects "evangelist" due to religious connotations ([Location 1910](https://readwise.io/to_kindle?action=open&asin=B07FKFQ1NK&location=1910)) but the industry still can't agree on titles. The role ambiguity (is this marketing? engineering? community?) is both DevRel's strength and its organizational weakness. - **Personal brand vs. company brand:** Thengvall notes that when you hire a DevRel professional, "you automatically acquire their following" ([Location 1154](https://readwise.io/to_kindle?action=open&asin=B07FKFQ1NK&location=1154)). But what happens when they leave? This tension is unresolved in both books. --- ## My Thinking (I WRITE THIS) ### What surprised me: ### What I now believe: ### What this challenges: ### What remains unclear: --- ## Links ### Related Notes - [[3. Resources/Readwise/Books/Developer Relations|Developer Relations]] — extends this journey model with operating and measurement patterns for DevRel teams. - [[3. Resources/Readwise/Books/Developer, Advocate!|Developer, Advocate!]] — supplies the practitioner view of advocacy across the developer journey. - [[3. Resources/Readwise/Books/The Developer Advocacy Handbook|The Developer Advocacy Handbook]] — expands the cross-functional responsibilities summarized here. - [[3. Resources/Readwise/Books/The Business of Belonging|The Business of Belonging]] — David Spinks on community strategy - [[3. Resources/Readwise/Books/Working in Public|Working in Public]] — Eghbal on open source community dynamics - [[3. Resources/MOCs/Open Source Governance MOC]] — governance patterns apply to DevRel community management - [[3. Resources/MOCs/Commons & Community Governance MOC]] — "the commons that deny exit become coercive" maps to the authenticity requirement ### Permanent Note Seeds - [x] Developers hate being marketed to — education is the only marketing that works with technical audiences → [[3. Resources/Permanent Notes/Education Is the Only Marketing That Works With Developers]] — crystallizes; turns the source's anti-marketing stance into a durable education principle. - [x] DevRel sits at both the top and bottom of the funnel but should never carry a sales quota → [[3. Resources/Permanent Notes/DevRel Should Never Carry a Sales Quota]] — crystallizes; separates DevRel's cross-funnel influence from direct sales ownership. - [x] The train track metaphor: DevRel builds the infrastructure that connects all other departments to the developer community → [[3. Resources/Permanent Notes/DevRel as Railroad Infrastructure]] — crystallizes; frames DevRel as shared connective infrastructure across departments. - [x] Time-to-Hello-World is the single most important metric for developer experience → [[3. Resources/Permanent Notes/Time-to-Hello-World Is the Critical Developer Experience Metric]] — crystallizes; turns the journey's earliest success threshold into an operating metric. - [x] DevRel burnout is structural, not personal — it stems from work that feels invisible to the organization → [[3. Resources/Permanent Notes/DevRel Burnout Is Structural Not Personal]] — crystallizes; locates burnout in organizational invisibility rather than individual weakness. ### MOC Updates - [ ] [[3. Resources/MOCs/Open Source Governance MOC]] — add link under "Community Management" section - [ ] Create new **DevRel MOC** to house this and future DevRel literature notes - [[3. Resources/MOCs/DevRel MOC]] — applies-in: the MOC lists this note under The Developer Journey.