Mary Thengvall - The Business Value of Developer Relations: How and Why Technical Communities Are Key To Your Success

Any other supplementary material referenced by the author in this book is available to readers at https://www.marythengvall.com/devrelbook .

I am deeply passionate about communities. I have been ever since my earlier involvement in open source and when I started experimenting with building my first few communities back when I lived in the UK.

This early interest really culminated when I strapped on my goggles and nose-dived into a new project called Ubuntu, tasked with building a global movement around an open source operating system. Eight years later I came up for air, and we had built a community comprised of hundreds of developers around the world, millions of users, local Ubuntu groups littered across the globe, and people actively shaping Ubuntu every day by producing documentation, translations, marketing initiatives, testing, and more.

This early experience in my career showed me the true potential for harnessing groups of engineering talent and availability, particularly when wrapped around a clearly articulated mission.

I didnt fully appreciate this, though, until I worked at XPRIZE, an organization that coordinates and leads major incentive competitions. My first XPRIZE, the Global Learning XPRIZE, challenged teams to build an Android app that taught kids how to read, write, and perform arithmetic within 18 months without the aid of a teacher. It was designed to bring education to the more than 250 million kids who dont currently get it around the world. The prize purse was a whopping $15 million, underwritten in part by everyones favorite science-reality entrepreneur, Elon Musk.

Working at XPRIZE was at times bizarre. It was an environment where over lunch we would talk about how we could solve water sanitization issues, produce vehicles to improve goods and services in rural third-world areas, use 3D printing to print houses for low-cost widespread housing initiatives, and more. This is what I loved about XPRIZE: genuine moonshot thinking underlined by the question How do we incentivize people enough to make this reality?

Unsurprisingly, the Global Learning XPRIZE attracted a wide range of people, from educators to startup founders, artists, translators, and more.

Many developers joined, but due to the competitive nature of the prize, their ideas and talent were... well, rather private. Competitors formed into their own teams and attacked the challenge with steel smiles and open minds, but this innovation occurred largely in a private setting, with the exception of some shared foundational projects.

As such, one element that was so compelling and familiar to me about the open source developer experience was curiously missing: problem-solving and collaboration around tractable solutions, out in the open.

This was entirely to be expected and no fault of XPRIZE. The organization was not an open source project, and the whole point of the incentive prize model is that people actually compete with each other. However, as Eleanor Roosevelt once mused, Absence makes the heart grow stronger, and I started to miss the culture of collaborative engineering communities, with the broader open source community being one such prime example.

This realization was not merely a cultural one. It got me thinking about the psychology and driving forces behind developers. What really makes great engineers tick? Throughout my career at that point, there were clear differences in engineering culturessuch as the difference between a GitHub generation startup and an enterprise Windows shopbut there were a remarkable amount of consistency and common themes too.

This is something that would illustrate itself in droves over the following years. As a consultant, I build community strategy and execution for a wide range of industries, including technology, financial services, consumer products, entertainment, security, professional services, and others. A significant chunk of my work is focused on building developer communities and ecosystems where developers either build on top of a platform or contribute to a core platform itself.

Across these widely varying clients, it has been fascinating to see these consistent themes emerge among these different types of developers, even when the scope, focus, culture, and norms of these different organizations vary so significantly. Of these commonalities, though, I see one of the most significant as being a desire for mastery .

With any disciplinecarpentry, mechanical engineering, chemical engineering, biomedicine, robotics, and othersthere is a journey from learning to optimization and then mastery .

A fundamental principle in converting learning to mastery is not just that we can furnish ourselves with the education to deliver good work, butimportantlythat we can construct hypotheses for how to execute this work well, and then something or or someone validates or rejects our hypothesis. In other words, we need to be able to experiment and see whether our experiments work out.