The Business Value of Developer Relations

What it’s about

Mary Thengvall’s book (known as the avocado book for its cover) explains what developer relations is, why companies invest in technical communities, and how DevRel teams can show their value to a business that wants numbers. It covers community building, where DevRel should sit in an organisation, and which metrics actually reflect long-term relationships.

What I learned

It’s relationships, not marketing. Developers can smell a sales pitch. DevRel works when it genuinely helps people succeed with the technology and listens to what they need.

The value is real but long-term. Community trust takes time to build, so DevRel teams need to agree up front how they’ll be measured, before someone asks for a quarterly lead count.

Community is a feedback loop. A healthy community tells you what’s broken in your product long before your metrics do.

What I applied

The clearest example is from early in my career. At Elanco I built a CMS migration tool that worked well enough to open-source, and wanting to share it led to interviews with the Kontent team, a guest article on their blog and an invitation to a live Twitch interview (which brand guidelines meant I had to decline). This book was recommended to me right then, and it explained what was happening: a vendor investing in its community through real customers’ stories (A Resumable CMS Migration Tool).

The biggest shift was realising that internal platforms need developer relations too. Adoption is earned through guilds, demos and docs, not through mandates.

• At Accedo I started weekly in-office developer sessions, ran a testing workshop and mentored newer developers. That was community building inside one project (Smart TV Apps on Low-End Devices).
• At Sky I chaired a cross-team UI guild: a regular, predictable forum with shared demos, tech wins and health checks. Practices such as Playwright spread through the community rather than by decree (Chairing a Cross-Team UI Guild).
• For the graph library, I ran a showcase where Storybook acted as living documentation and a demo app consumed the built package, which is DevRel for an internal library (Building a Graph Component Library).
• When I moved on, the knowledge-transfer sessions were paired with written docs, because docs are what people return to (Knowledge Transfer Before Moving On).

What I’d take further next time: agree how a guild or platform community will be measured at the start, as the book suggests, instead of relying on goodwill.

Later, at Accedo, I did a version of the job myself. In the second half of my time there I was acting as a developer advocate: running community developer engagements, knowledge sessions and hackathons to build a developer community spirit (Accedo). The book’s lesson held: you earn a community, you don’t market at it.

Where it connects

Chairing a Cross-Team UI Guild · Knowledge Transfer Before Moving On · Pair Programming · Users Not Customers