How Internal Developer Advocacy Leads to Improved DevEx

Developer relations (DevRel) is, as most tech organizations and developers know, a wide-ranging discipline that demands a multidisciplinary approach to achieve its aims – communication and feedback. But what about internal developer advocacy? In this article, we will explore how internal developer advocacy shapes developer experience, makes developers be successful and helps deliver on organizations' goals.

Inside-Out: What is Developer Relations?

Bridging the gap between technology and user adoption, DevRel is hands-on in driving numerous two-way street activities aiming to advance engineering skills and product engineering. DevRel carries the voice of an organization and its products to developers (and by extension, to engineering teams) and collects and shares the voice of the developer community back to the organization to catalyze product improvements. These activities vary but usually include:

• Awareness building
• Creating content
• Education
• Tech demos
• Community building
• Advocating and sharing knowledge
• Empathizing with developers
• Acquiring feedback

Outside-In: How DevRel is Turning Inward with Internal Developer Advocacy

Internal developer relations is a growing movement and the role of developer advocate is becoming popular, mostly mirroring externally facing DevRel, only with the goal of enabling internal teams.

The goals, however, can differ. In many organizations, the idea of turning developer relations outside-in is to ensure greater developer productivity, shared best practices, and better developer experiences. Communication and educational activity achieves this. Another goal is to build awareness around and encourage the use of internal tools, in a bid not just to ensure that the org is "drinking its own champagne" but to actively gain insight to make the tools better.

Why Internal Developer Advocacy?

The oft-discussed "shift left", which puts more responsibility into developers' hands throughout the software life cycle, theoretically offers opportunities for developers to take full control not just for writing code but also for shipping and running of the software they create. But how far would this trend penetrate into organizations without some robust internal developer advocacy going on, whether formal or informal?

In the cloud-native space, at least, the complexity of full life cycle ownership makes a complete shift left difficult and possibly undesirable. But many orgs aim to move toward a model that gives developers more responsibility. The success of this approach will depend largely on organizational goals and maturity and how much support organizations provide for their developers.

Informal Developer Advocacy: Paving the Path with Developer Platforms and Support

Not every organization will have been built from the ground up with the goal that developers will run their own show completely. But the few that do will balance developer freedom and responsibility with at least informal internal developer advocacy. Lunar Bank, for example, expects its developers to manage the full software life cycle and invests in empowering them to do so effectively. Lead Platform Architect, Kasper Nissen, explained that this is only possible if it is manageable by paving a clear path with opinionated workflows and by giving developers effective onboarding and self-service education. While this is not a formal internal developer advocacy program, per se, Lunar does focus on centralizing developer experience through a developer control plane, or internal developer platform, which has accelerated developer ramp-up and productivity.

Zipcar DevOps Platform Engineer, Bo Daley, agreed, "Supporting developer efficiency and success with an opinionated developer platform paves a seamless path to production”. The platform team strives to help developers become more effective at their jobs, building a developer experience that lets devs understand how their work interacts with other components in the system without slowing them down. We want to provide tools and a platform to help them get their work done.

Ambassador Labs's SVP of Engineering, Bjorn Freeman-Benson, argued that developer ownership of the software development life cycle isn't a new concept, and he has introduced it in all of his previous organizations. By extension, he stated that the organizations that ask developers to take on full operational responsibilities owe developers self-service tools and onramps to ensure that the foundation for shipping and running services is solid. Internal advocacy, in this scenario, is more about relieving developers of things like configuration, for example, with an internal developer platform that handles underlying infrastructure, automating the things developers don't really need to know.

In this way, an aspect of internal developer advocacy is developing teams internally to support the developer experience from the point of view of shipping software at maximum speed while still maintaining safety. Platform and SRE teams, while not directly internal DevRel, are resources for improving the internal developer experience, which extends to improving the ability to ship more software faster.

As CartaX's Mario Loria argued, "The role of the SRE is changing, as the need for driving increased awareness of internal platforms and feedback cycles grows." Mario continued, reflecting on how SRE functions should support developer experience, "It should not be up to me as an SRE to define how your application gets deployed or at what point it needs to be rolled back, or at what point it needs to be changed, or when its health check should be modified. Developers should be capable of — and empowered — to make these determinations."

Formal Developer Advocacy: Community, Knowledge Sharing, Communication, and Elevating Developer Voices

While technology and tooling are important components of the cloud native developer experience, some of the greatest understanding and growth comes from the community, developers connecting with each other and sharing knowledge, fostering and focusing on communication, and elevating developer voices — formally and informally.

Tap into the Wisdom and Talent of the Community

Katie Gamanji, former ecosystem advocate at the CNCF and current senior engineer at Apple, shared, "Anyone who's trying to understand what cloud native is… you can get your answers in the community, both the cloud-native community and the wider open source community. Once you are in this space, I think it's very important to get to know your folks, the maintainers of the projects you're using, or even become one of the contributors. The community is there; try to reach out. Technology is great, but the community around cloud native, it's what really makes it great."

More broadly, if answers, guidance, consensus come from the community, peers and practitioners, it makes sense that community is a touchpoint for internal developer advocacy, even if it is an inside-out form of outreach, i.e., not staying within one's own organization. Instead, it's internal dev advocacy within the community. Community wisdom is then taken into and often adopted within developers' organizations.

Community is also important for filling the ever-present talent gap in tech organizations. Alan Barr, internal developer and security platform product owner at Veterans United Home Loans, affirmed that competition for talent is fierce, but that the community helps to bridge the gap, "We are trying to compete for talent, and we don't have the luxury of pursuing top-tier Silicon Valley talent. But what we can look for is talent fresh from university or our local community and enable them to work in an opinionated environment that we have created to not just help them develop their skills but also to feed into the goals of the company. Where we're trying to add value is in developing skills and training. We have a really great community. We have great values that make many of these [people] want to stick around. But whether they do or not, we have molded more effective and efficient developers who take good, solid principles with them about how to be better software engineers."

Break Down Silos with Communities of Practice and Knowledge Sharing

An extension of community, and slightly more formal, is the adoption of communities of practice, which Apostolis Apostolidis (Toli) of cinch cited as a critical means of "continuously improving the craft of software engineering in informal groups". Toli's views highlighted the need for internal developer relations functions as a way to combat knowledge loss.

He continued, "Knowledge loss is a downside to the way many development teams are organized. One of the biggest problems we have, in Team Topologies speak, is that we have a lot of stream-aligned teams, but minimal platform teams. This leads to over indexing on streams, and each team focuses on their individual domains, and the different disciplines are not talking to each other. You lose critical knowledge-sharing. The way teams are set up, people do not build cross-functional relationships with each other, but we want people to learn together and from each other. In questioning, "How do we continuously improve our craft?”, we need to consider how teams work together (and ensure that they do) and look to informal communities of practice."

Communicate Culture Change: Share the Why and How and Invite Participation

Education, documentation and training are, of course, essential parts of onboarding and supporting developers and advancing their skills. While these are critical parts of the internal developer advocacy equation and overall communication, the bigger picture for internal developer communication is understanding its value and grasping the underlying shake-up and disruption of culture change.

Alan Barr explained that while education and training efforts are vital, "they don't explain why we're making a platform or the reasons why we built it or the why behind other initiatives." Alan went on to highlight the importance of storytelling and making the "why" matter in getting developers onboard. Communicating clearly and transparently is key. "Not understanding why frustrates developers. Why are we doing a certain thing? We want to tell a story that explains, 'Here's why you're part of the journey. Here's how you're going to contribute to the journey. And in the case of the developer platform, here's how it's going to improve your experience'.

"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. Whether or not we ultimately act on feedback and ideas, a big lesson learned was that all the stakeholders wanted to feel heard."

Two-way communication, according to Crystal Hirschorn, Director of Engineering - Infrastructure, SRE and Developer Experience at Snyk, is critical to supporting the developer experience. An organization can build a platform and tools for developers, but first, the org has to listen to developers to understand their needs before building these tools, and then once these tools are developed, communication back to developers is just as important. You need to get the people you're designing for on your side. "It is powerful to get the developers who use and advocate for the platform to rally adoption and enthusiasm."

Crystal championed the idea of internal developer experience teams to focus on inward-facing efforts, listening to developers and the R&D org to get fast internal feedback loops, "We want to remove barriers to entry to make the developer's life as easy as possible, reducing developer toil and pain, possibly even finding interesting cases where our platform does more than just reduce pain and instead brings joy. We aim for delivering a developer platform that is a pleasure to use and that makes a developer's work easier." Introducing internal developer advocacy can make that journey shorter.

Internal Developer Advocacy: "Champion the Developer who is a Resource for Other Developers"

Longtime Google staff developer advocate Kelsey Hightower recently explained in a DockerCon talk that you, "...don't want a 10x developer... what you want is someone who can come in and make 10 other developers more productive". Whether formally or informally, organizations can benefit from introducing internal developer advocacy to elevate developer voices and needs and create something akin to the "10x developer" Kelsey described.

Bo Daley from Zipcar shared a similar approach, "Any time you find one of these developers internally who seems like they are on the verge of 'getting it', or putting all the pieces together, invest in that developer because they will help other developers, get them across the line in understanding the core concepts. Champion the developer who is a resource for other developers."

Crystal from Snyk provided a real-world example of a developer who put himself into an unofficial internal developer advocate situation, explaining that the developer who wants something more than the platform offers should be free by default to explore because "they can be a great resource for other developers". In the Snyk case, the developer happened to have an infrastructure background, followed the Snyk playbook and developed for himself what he needed.

The critical difference, though, is that his advocacy didn't stop there. That developer advocated for the team in monthly R&D discussions, explaining his self-service approach to getting what he needed without infrastructure-team interaction. Many developers will take advantage of the opportunity to be that internal resource, helping themselves and others, when given the freedom to do so.

Toli from cinch shares a similar approach. Coming from a coaching background, he spent a lot of time coaching developers one-on-one. But recognizing eventually that this coaching could not scale with escalating growth, it made sense to codify and share knowledge (and automate workflows) to bridge knowledge gaps while at the same time building teams in which each team had a dedicated jack-of-all-trades, or what is effectively an internal developer advocate or enabler in each team.

"We deliberately designed the organization to give each team a dedicated person to function as software engineers who had an extra focus on infrastructure, CI/CD and observability and monitoring, and a little bit of SRE. Someone for each team who thought about the software life cycle and relieved the rest of the team from that heavy lifting", Toli explained. "This helped solidify the new processes while slowly evolving the culture. We found that this approach helped teams build software,  faster and better. It introduced the idea of many enablers, or coaches, which worked great."

Conclusion: Double Down on Internal Developer Relations

No matter the size of the organization, internal developer relations enables engineering and product teams to become more productive and deliver value to customers rapidly and safely.

A balance of drawing on internal developer platforms and tools as a technical baseline will help to reduce developer cognitive load. There also needs to be a clear focus on fostering awareness of internal tooling, increasing collaboration, and community building to let you safely place your business-focused bets using an increasingly efficient and effective developer experience.