You don’t often see a technical book amongst the list of DevRel content creation.

While technical books aren’t as important as they used to be, they do still have a place in this multi-channel world of technical content.

Last year I co-authored a book for an open source CMS called TYPO3 and I want to share the story for any other developer advocates out there who may be inspired to do something similar.

The need for a book

TYPO3 has a mature, thriving community around it yet they still want to grow. They want to increase awareness internationally, grow adoption and grow their user base. They want to increase code contribution - they’re an open source community so of course they want more contributors. They also want to continue building their community.

The TYPO3 community decided that a book was going to contribute to this strategy.

Book Cover

You may be thinking, “We’ve got a website. We’ve got official docs. If we’ve got new folks wanting to find out about our product, we just send them to the website. If we’ve got devs wanting to use our API, we send them to our quick start guide”.

A book answers that need much better. Rather than having a collection of blog posts or pages in the docs, the power of a book is that you can meet the needs of different types of readers in one go, by carefully curating and presenting your content with a clear goal in mind.

Speaking to different readers

We structured the TYPO3 Guidebook to have two clear parts: four chapters with conceptual material followed by 10 practical guides. This allowed us to reach the broadest possible audience, and tailor the content to meet the needs of readers with different goals.

Book has two parts

Books serve beginners well because they are foundational and linear. A newbie developer can just start at the beginning and read. They’ll get the overview, and they can work through the tutorials sequentially. Our publisher, Apress, hosts a GitHub repo per book, so we’ve got all the code from our guides to serve the hashtag lazy developer.

Books also help experienced developers who are approaching a new technology for the first time. They’ll be able to understand the basic principles right away like the system architecture, development approach, and coding standards and guidelines. These readers probably won’t work through the practical component of the book like a newbie might, but you can bet they will eyeball those to get a feel for how it hangs together.

Books help decision makers and anyone evaluating a technology. Perhaps they’re going to be maintaining the thing so they want to find out how to support and upgrade it, and learn more about performance and security. They don’t have to navigate docs, or wade through marketing content on a website to get to that detail.

Where does DevRel fit in?

Sam Julien, creator of the Developer Microskills newsletter, talks about how the range of developer advocate responsibilities falls into two broad categories: speaking and listening.

We did the listening part first.

My co-authors and I are members of the TYPO3 community and we just fully immersed ourselves. We attended loads of events and conducted a lot of interviews (face to face and written). We spent time speaking with highly technical, highly passionate developers about the CMS, what they liked about it, how they used it, and the very specific areas that they worked on. This covered the DevRel area of community and all throughout the writing and review phase of the book, we covered off the feedback aspect. (Using Google Docs let us share the draft content broadly for maximum input.)

The speaking part came next.

The speaking comes with the creation of the book itself. We took the expertise and knowledge from the community and stitched it into a cohesive whole so that the book can do the speaking, covering key DevRel points of awareness and education.

The value of a book for a community

Books on technology age quickly. Of course online content like docs and blog posts are going to have the most up-to-date information about a technology. But books ain’t dead. And print books still outsell ebooks.

Don’t underestimate the affordance of a book. Instead of reams of online articles or procedurals, you can encapsulate it in a tangible, portable asset that goes where you go, and tells the story of your community or product.

Add a book to your content strategy

My message with this story is for other communities and organizations to consider writing a book too.

By creating a book, you’re tapping into the expert knowledge of your devs and channeling that into a usable, tangible asset.

You’re creating a curated resource to help other devs learn, and on the flipside, you’re telling the story of your product and sharing the value of what your devs have built.