How do I get into DevRel?

Developer Relations sits between a company and the developers who use its product. Developers trust other developers, not ads, so a company that wants developers to adopt its API, SDK, database or platform needs people who can teach, build and listen in public. That is the job.

The simplest working definition comes from Mary Thengvall: DevRel is the umbrella term for the strategies and tactics that build relationships with developers. The relationship runs both ways. You bring the product to developers through content, talks, docs and community. You also bring developers back to the company, turning their friction, feature requests and bug reports into signal that product and engineering can act on. The second half is the one beginners forget, and it is what separates DevRel from promotion.

This phase gives you two foundations:

1. A clear model of the function. Where it came from, the roles inside it, why companies pay for it, and how the org chart changes what "good" looks like. Without this you will say yes to everything and get measured on the wrong things.
2. A technical baseline. You don't need to be a staff engineer, but you do need to build a working demo, read someone else's code, open a pull request and talk about deployment without bluffing. Developers notice immediately when someone doesn't really get it, and credibility is the currency of this whole career.

If you come from engineering, the first module will be new and the second will be review. If you come from marketing, writing or community work, it's the other way round. Either way, finish both before moving on. Every later phase assumes them.

Phase 1 gave you the why and the technical baseline. Phase 2 is the what: the four disciplines that make up day-to-day DevRel work.

• Content Creation teaches at scale: tutorials, docs, samples, video.
• Community Building creates a place where developers help each other and help shape the product.
• Public Speaking & Events builds trust fast, one room at a time.
• Developer Experience removes the friction that makes developers quit.

They reinforce each other. A talk becomes a blog post, which becomes a docs page, which answers a community question, which reveals a DX problem, which becomes a product fix, which becomes your next talk. That loop is DevRel. The better you understand it, the more each piece of work compounds.

You don't need to master all four at once. Most practitioners go deep in one or two early in their career. Engineers often lead with content and DX, and community builders with community and events. Aim for working competence in all four before moving to senior roles. Each module ends with a Compass Challenge that produces a real, public portfolio piece. Do them: a portfolio of four challenge outputs is a strong DevRel application on its own.

Two things decide whether a DevRel career grows: whether people know your work and whether you can prove it matters. This phase covers both.

Personal brand isn't vanity. In DevRel your reputation is part of the job. Developers listen to people they recognise and trust, event organisers invite speakers they've seen, and hiring managers shortlist candidates whose work they've already read. As Adora Nwodo says in her Strategy Room session, visibility doesn't mean hundreds of thousands of followers. It means being known for something specific by the right people.

Analytics is the other half. DevRel teams without numbers get cut; DevRel teams with only vanity numbers get misunderstood. You'll learn to separate signal from noise, report in the language of business outcomes and use data to decide what to stop doing.

Treat these as one system: the same habits of consistency, clarity and reflection power both.

Open source is where developers learn, collaborate and build their reputations. Most modern software depends on it, and many developer communities form around it. For DevRel, open source is both a skill (contributing, maintaining) and a strategy (using openness to build trust, adoption and community).

Nadia Eghbal's Working in Public describes an important shift: many popular projects now have large numbers of users but very few maintainers. The bottleneck isn't contributions; it's maintainer attention. Good DevRel in open source makes maintainers' lives easier. It triages, documents, onboards contributors well and never floods projects with low-effort PRs.

This phase covers the full picture, from your first pull request to company open source strategy, governance and licensing.

Senior DevRel is less about doing more talks and more about designing systems that create outcomes. At this level you're expected to set strategy, justify investment, work across the company and grow other people.

Two ideas run through this phase:

1. DevRel is a business function. Your programs exist to serve company goals, adoption, retention and product quality, in ways only DevRel can. You'll learn to set goals leadership understands and to show progress against them.
2. Leverage over effort. You can't personally talk to every developer. Senior practitioners multiply impact through programs (champions, education), systems (feedback loops, content engines) and people (hiring, mentoring).

Watch Rohit Ghumare's Strategy Room session on systems thinking and Linda Ikechukwu's session on turning developer education into business outcomes. Together they frame this whole phase.