Internal Developer Advocacy: What Should You Do Next?
Developer advocacy, or developer relations (DevRel) as it is often known, is a well-known and in-demand discipline. It requires practitioners to wear a lot of different hats, doing everything from public speaking, teaching, advising and listening, while continuing to stay abreast of the latest trends in the tech and software development world.
No one in the tech sector denies the influence and importance of developer relations. It’s critical to bridging the gap between technology and user adoption, advancing the practice of software engineering and carrying the voice of the developer community back into organizations to drive products and innovation forward.
Traditional developer relations are, first and foremost, an inside-out form of advocacy. Internal developer advocacy is gaining traction, offering an outside-in approach to developer relations with a focus on developer experience.
While there are undeniable overlaps in external and internal developer advocacy, the internal developer advocate works to shape the developer experience internally, helping them to be successful in an organization and supporting them as they work toward delivering on an organization’s goals.
Why Make DevRel Face Inward?
Internal developer relations, with the primary goal of enabling internal development teams, is more than just a momentary trend. As someone who has been in developer relations for a long time, I’ve heard chatter about internal developer roles ramping up and have met a growing number of people working in these roles, which include dev enablement and developer experience teams.
The burgeoning popularity of internal developer advocacy highlights both the need for providing formal support for the developer experience and acknowledging the increasing complexity of the space in which developers work, particularly with cloud native technologies.
A brief analysis of the nascent internal developer advocacy discipline led me to a few conclusions about informal and formal developer advocacy, the conditions that created the need for internal DevRel functions and how to make internal developer advocacy successful.
Organizational maturity and culture influence how internal developer advocacy figures into a development team, if at all.
Informal Internal Developer Advocacy: Technology, Tools and Paved Paths
Some organizations were built from the start with the idea of empowering developers with full software life cycle responsibility. Lunar Bank, based in Denmark, is one such organization. Ahead of the curve, Lunar has invested heavily in developer experience, most notably through creating “paved paths,” or opinionated developer platforms and workflows, for developer onboarding and self-service.
Lunar’s emphasis on creating conditions, training, tools and support for developer freedom and responsibility is an example of informal developer advocacy. Internal developer platforms have centralized the developer experience, accelerating developer onboarding and increasing productivity.
Developer platforms guide the same type of informal developer advocacy at Zipcar, where the platform team works to provide a seamless path to production, giving them the tools they need and understanding of dependencies without slowing them down. The platform team becomes developer advocates by proxy.
If an organization asks its developers to take on operational responsibility, the platform team should deliver self-service tools and onramps.
If an organization asks its developers to take on any level of operational responsibility, the platform team should deliver self-service tools and onramps to relieve developers of things they don’t really need to know to do their jobs. An example of these “areas of relief” is configuration.
A developer does not need to know everything about this, and an internal developer platform should handle the underlying infrastructure. Platforms and platform engineering, then, supports developer experience and “advocates” for developers by enabling consistent, safe, fast software deliveries.
Formal Internal Developer Advocacy: Community and Communication
Formal developer advocacy, while frequently converging around individuals or teams whose role is designed specifically to cater to internal development teams, also focuses on community. It connects developers with each other to share knowledge and experience and fuel collaboration.
The Value of Community
The cloud native community is active and vibrant, but also complex. It’s an ideal playground for building communities to make sense of and move cloud native technology forward. The community and its participants provide value by generating consensus around best practices, tools and processes, creating learning and sharing opportunities, and helping to build networks of experts and practitioners.
Community is an outreach-based, often externally facing initiative. But it is also a critical forum for internal developer advocacy in that community guidance, best practices and wisdom are introduced into and adopted by developers’ organizations, making community practices and standards internal.
The community is also the source of the more formal “communities of practice,” which are groups that aim to continuously improve the craft of software engineering in informal groups. These communities contribute expertise and combat knowledge loss within the community itself, but also extend knowledge-sharing beyond the community, with developer advocates taking learnings back to their internal teams, helping to foster cross-functional relationships and breaking down silos.
The Power of Two-Way Communication
Education and training, while critical to onboarding and creating a good ongoing developer experience, are gateways to facilitating the “how” of development work. Creating a good developer culture depends on communication, which relies on good storytelling and explaining the “why” behind different initiatives.
Alan Barr, of Veterans United Home Loans, said it best: “Communication is a really high-leverage activity. Half the battle is building the product and then the other half is communicating the value and getting people to use it and feel heard when they do.”
Two-way communication also requires listening. An organization can build a platform and tools for developers, but first, the organization has to listen to developers to understand their needs before building these tools. Then, once the tools are developed, communicating with the developers is just as important.
Internal developer advocates or internal developer experience teams can fast-track the inward-facing communication efforts, helping to get fast internal feedback loops while speeding up the path to making developers’ lives easier.
This also reduces developer toil and cognitive load, making the overall developer experience — and tools supporting it, such as a developer control plane — a pleasure rather than a challenge. Internal developer advocacy cuts the time to an improved developer experience.
The Case for Internal Developer Advocacy
Organizations can gain value from adding internal developer advocacy to their development teams both informally and formally. It’s all about elevating developer voices. As cloud luminary Kelsey Hightower explained in a recent DockerCon talk, you “don’t want a 10x developer… what you want is someone who can come in and make 10 other developers more productive.”
At the heart of elevating the developer voice is the idea of “championing the developer who is a resource for other developers.” Internally, identify a developer who understands how all the pieces fit together, is enthusiastic about advocating for other developers and is willing to help them grasp core concepts. Investing in an internal developer advocate pays dividends.
“Champion the developer who is a resource for other developers.”
Depending on the organization, there are very different ways to go about investing in this internal developer advocate. Crystal Hirschorn, director of engineering at Snyk, described an example in which a developer became an unofficial internal developer advocate.
Because the developer had an infrastructure background, he followed the Snyk playbook and developed something he needed, but that did not exist. He exemplified the push for developer freedom and took his work a step further. He advocated for the team in monthly R&D discussions, explaining his self-service approach to getting what he needed without infrastructure-team interaction.
Another organization, cinch, had to find a way to scale up its “developer coaching” approach as the company expanded. Its approach was to codify and share knowledge (and automate workflows) while building teams where each included an internal developer advocate who was not only a developer but also focused on the bigger picture, including infrastructure, CI/CD, observability and monitoring. This approach helped teams build software faster and better, and introduced the idea of having many coaches or internal developer advocates.
Conclusion: The ROI of Internal Developer Advocacy
Internal developer advocacy takes developer relations, a well-known, outward-facing discipline, and turns it inward to help shape the developer experience, support developer success and contribute to achieving organizational goals.
The value of internal developer advocacy becomes clear as developers adopt and use developer platforms, and rely on greater collaboration, communication and community, all in the service of shipping software faster and safely. Internal developer advocacy is one tool that gives organizations the ability to safely place business-focused bets using an increasingly efficient and effective developer experience.
