The Developer's Advocate
An internal evangelist occupies an unusual position: they must be trusted by both sides of a divide. To application developers, they are a guide and ally — someone who helps them get value from the platform without wading through dense documentation. To the platform team, they are a voice of the customer — someone who brings back unfiltered feedback about what's confusing, broken, or missing.
This dual role is what makes DevRel genuinely difficult. An evangelist who only advocates for the platform becomes a marketing mouthpiece that developers stop trusting. An evangelist who only advocates for developers becomes a complaint aggregator with no ability to drive change. The effective internal DevRel practitioner holds both perspectives simultaneously and uses the tension between them to improve the platform.
Core Tactics
The "Paved Road" Demo
Don't just list features in a wiki page. Run live coding sessions where you go from a blank directory to a deployed, production-ready service using only the platform's tools. The goal is to make the "happy path" feel effortless and to surface any friction points in real time. A good demo answers the question developers actually have: "What does this save me from doing myself?"
# Example: A 5-minute demo script structure
# 1. Start from scratch
mkdir my-new-service && cd my-new-service
# 2. Use the platform's scaffolding tool
platform-cli init --template python-api --name my-new-service
# 3. Deploy with a single command
platform-cli deploy --env staging
# 4. Show the result: URL, metrics dashboard, and auto-configured alerts
platform-cli status my-new-service
The power of this demo is not the commands themselves — it's the contrast with what the developer would have had to do manually (write a Dockerfile, configure CI, set up monitoring, request DNS entries, etc.).
Release Notes with Personality
Move away from dry, robotic changelogs. Every update should include "The Why" — the human problem that motivated the change. Compare these two approaches:
Robotic: v2.4.1 — Updated CI runner image from ubuntu-20.04 to ubuntu-22.04.
DevRel: v2.4.1 — We heard you. Build times were averaging 10 minutes, which meant waiting through lunch for a green check. We've upgraded the CI runner and parallelized the test stage. Average build time is now 2 minutes. If you're still seeing slow builds, drop into #platform-support and we'll investigate your specific pipeline.
The second version does three things: it acknowledges the developer's pain, it quantifies the improvement, and it opens a feedback channel. Developers who feel heard are more likely to report problems rather than silently work around them.
Internal Case Studies
Abstract documentation tells developers what a feature does. A case study tells them what it did for a team they know. "How the Payments Team reduced their cloud costs by 30% using our new autoscaler" is more persuasive than any feature matrix because it answers the implicit question: "Is this worth my time to learn?"
A good internal case study follows a simple structure: the team's original problem, the specific platform feature they used, the concrete outcome (time saved, cost reduced, incidents prevented), and a quote from an engineer on that team. The quote is critical — peer testimony carries more weight than platform team self-promotion.
Interviewers for Platform Engineering roles often ask: "How do you drive adoption of internal tooling without mandating it?" The answer they're looking for is not "we write good documentation." It's a multi-channel strategy: live demos that show the before/after contrast, peer case studies that provide social proof, and feedback loops (office hours, NPS) that make developers feel like co-owners of the platform rather than passive consumers. Frame your answer around the difference between compliance-driven and community-driven adoption.