The Tech Content Creator Series is a monthly interview series where I chat with industry leaders in various technical communication roles (technical writers, documentation engineers, developer advocates, and what have you) about their careers. It's like chatting with a mentor, over a cup of coffee.

In this episode, I sat down with Dillion Megida, an internal developer advocate at Adyen. Currently residing in the Netherlands but originally from Nigeria, Dillion started his career as a freelance content writer before becoming a full-time front-end developer. He later transitioned to developer advocacy, while seeking a role that would allow him to combine coding and content creation. His first position was as an external developer advocate at Stream, where his audience consisted of customers using the company's product. Now at Adyen, he works as an internal developer advocate, focusing on the company's developers as his target audience.

Earlier this year, while speaking at the Copenhagen Developers Festival, I met some Internal Developer Advocates from Lego. This was my first real exposure to such a role. So when I got the chance to speak with Dillion, I was excited to finally be getting answers about this position for myself and others.

Psst! I'm writing a book on developer advocacy for individual contributors. It's a distillation of everything I and others—combined with 15 years of experience as a developer advocate ICs—have learned about being an indispensable rock star developer advocate. Sign up for my newsletter to read the first two chapters for free when it drops! :)

In this episode, you’ll find answers to questions like:

• What is internal developer advocacy?
• How is internal developer advocacy different from external developer advocacy?
• How do you demonstrate value in internal developer advocacy?
• How can one become an internal developer advocate or transition to internal developer advocacy?

Enjoy!

What is Internal Developer Advocacy?

Dillion hadn’t planned on transitioning to internal developer advocacy. He enjoyed external developer advocacy at Stream, particularly creating content and supporting customers, though he found the marketing aspects less appealing.

Unfortunately, he was laid off due to the economic crisis. While searching for new developer advocacy jobs, he discovered internal advocacy while job hunting. Intrigued by this unfamiliar variation, he decided to give it a try, driven more by circumstance than choice.

Since becoming an internal developer advocate, here’s what he’s learned about the role:

While traditional developer relations is an inside-out form of advocacy, internal developer advocacy is an outside-in approach focused on developer experience. An internal developer advocate is a developer who serves as a resource for other developers. They are the one who understands how all the pieces fit together, is enthusiastic about advocating for other developers, and are willing to help them grasp core concepts.

Internal Developer Advocacy vs. External Developer Advocacy?

“Technical depth requirements depend on the company and role, whether internal or external. In my current role, I'm not expected to produce all the content for our tools - that's the responsibility of those who build them. However, I need a good understanding of how these tools work to keep information up-to-date and well-structured.

In my previous external role, I needed deep technical knowledge of our React SDK. Currently, I focus more on structure, visibility, and availability of content rather than creating technical content from scratch. The level of technical depth required varies based on company expectations, regardless of whether the role is internal or external.”

~Dillion Megida

While both internal and external developer advocacy involve the same three elements—community, code, and content—there are several key differences:

1. Audience

For external advocacy, your audience is customers who use your product to build their startups or projects. In internal advocacy, you're working with two types of developers within the company: platform engineers who build internal tools, and product engineers who use those tools to build customer-facing products.

As an internal developer advocate, Dilion’s audience are the product engineers, and he bridges the gap between them and the platform engineers to ensure their internal tools are as user-friendly as possible.

Internal developer advocacy might also mean that you have to cater to different flavours of developers with diverse technology stack within your team. For example, Dillion expected to work between just two groups of engineers, but he has found myself working with multiple teams across the company - CI/CD, security, and various other departments. This broader exposure has been interesting, but also more complex than he anticipated.

2. Content

Content creation efforts differs between internal and external developer advocacy. External advocacy focuses on articles, case studies, and demos, while internal advocacy requires adapting to your specific internal developers’ needs. This might involve organizing training sessions, improving platform tool documentation, or addressing immediate challenges. You'll also need creative solutions to break down knowledge-sharing silos and make institutional knowledge—information typically known only to long-term employees—more accessible.

3. Metrics & OKRs

Measuring success in developer advocacy is generally challenging. In external developer advocacy, metrics like community growth rate, content engagement, feedback implementation rates, event attendance and engagement, DevRel-enabled marketing qualified leads (i.e., how many people enter the sales funnel from DevRel content or activities) are the order of the day. In internal developer advocacy, it's a bit different.

Internal developer advocacy metrics and OKRs are focused on improving internal developer happiness and satisfaction. For example, Dillion recently worked on a workflow that allowed engineers to document code through comments and markdown files in their repositories, generating documentation that's publicly available. Success was measured by seeing more engineers documenting previously undocumented pages because the process became more convenient.

While measuring developer happiness is vague, focus is given to specific improvements that contribute to satisfaction. Dillion's team tracks metrics like:

• Reduction in outdated documentation
• Number of teams using new tools or workflows
• Increased documentation coverage
• Engineer feedback and adoption rates

Sometimes they can't get exact numbers, but they can observe trends and improvements in developer productivity and satisfaction.

4. Documentation

The key difference in documentation between internal and external developer advocacy lies in context.

Internal documentation can assume readers already understand company-specific terms and concepts. For example, you wouldn't need to explain technical fundamentals like containerization—something that would be necessary in external documentation.

While internal documentation can adopt a more casual tone, it still demands clear organization and structure. Even with this informal approach, keeping information accessible and well-organized remains essential.

Peculiarities and Challenges associated with Internal Developer Advocacy

I asked Dillion things he has found challenging or interesting about the peculiar role of internal developer advocacy, and this is what he said:

Proving Value and Impact in Internal Developer Advocacy is Tricky

It can be challenging to demonstrate value in internal developer advocacy compared to external roles. In external advocacy, developers must use formal channels like GitHub, forums, and social media to get help, making an advocate's impact clear and measurable. With internal advocacy, however, product developers often skip the internal developer advocate entirely, going straight to platform teams when they need help, through casual conversations over coffee or lunch.

While this informal dynamic doesn't reduce the internal developer advocate's importance, it does make their impact less visible. To address this challenge, you must gradually build trust and prove your role's value. This means creating structured processes that ensure you're part of key feedback loops and decisions.

Dillion emphasizes that the goal isn't to control developer interactions, but rather to showcase the unique contributions you as an internal developer advocate can bring to the table—like organizing feedback, facilitating solutions, and improving processes in ways that wouldn't otherwise happen.

You just might have to gain deep understanding of different technical domains

Since the role of an internal developer advocate is to connect platform teams to product teams, varieties abound. You may find yourself working on projects with multiple teams around the company—from CI/CD, to security, to business enablement teams, and even DevOps—just like Dillion. The good thing is that you'll gain a lot of valuable domain knowledge and deep understanding of various technical domains.

For instance, working on a project to improve engineer efficiency, Dillion had to learn about GitLab pipelines so thoroughly that he considered creating a YouTube series about it. Similarly, while working on another project, he had the opportunity to become very proficient with regular expressions—something many developers still struggle with.

So you want to become an Internal Developer Advocate?

If you’re thinking of transitioning to internal developer advocacy, here’s Dillion’s advice:

Consider the company and job description. During interviews, pay close attention to what's expected of you. Ask specific questions about:

• Daily responsibilities
• How success is measured
• Career progression opportunities
• The company's definition of advocacy

You should know that career paths in developer advocacy aren't always clear-cut, like they are in engineering roles. Some people spend years in advocacy before reaching senior levels, while others transition to director of developer relations or return to engineering.

Consider what your career might look like in 5–7 years. With external advocacy, there's likely to be continued demand as companies need that external communication channel. Internal advocacy might remain more specific to larger, established companies that can support specialized roles. Smaller companies might not need dedicated internal advocates, as team members can communicate directly.

If you want to reach out to Dillion directly, you can find links to all the places he hangs out online on his website.

Psst! I'm writing a book on developer advocacy for individual contributors. It's a distillation of everything I and others—with a combined 15 years of experience as developer advocate ICs—have learned about being an indispensable rock star developer advocate. Sign up for my newsletter to read the first two chapters for free when it drops! :)