Skip to main content

​
Overview

DevRel (Developer Relations) is what a company does to build relationships with developers. Understanding what that work rests on means understanding the culture shared among software engineers — the values of learning, sharing, and improvement — and the communication that makes those values visible from outside. This page covers the culture of software engineers. It first defines DevRel, then works through engineering culture, the three layers of the engineering community, and what technical communication achieves.

​
What DevRel is

​
The general definition

DevRel (Developer Relations) is the relationship a company builds with developers, and the function responsible for building it. What distinguishes it from general marketing or public relations is the counterpart: developers, whether as users of a product, as participants in a community, or as potential colleagues.

​
Two orientations

Many companies hold both orientations at once, and the balance shifts as the business changes. Naming which one a given activity serves prevents it from being judged by the wrong measure.

​
Examples of taking part

​
Principles

Put the participant's purpose first

Design each activity around what participants came for. Content whose main purpose is promotion loses the audience it was meant to reach.

Stay neutral on technology

Avoid ranking languages, tools, or roles against each other. Comparisons should describe the conditions under which each fits.

Plan for continuity

Relationships are built by repeated contact. Size the activity so it can be sustained rather than run once at full effort.

Measure indirectly

Accept that attribution is partial. Track participation, repeat attendance, and reach over time instead of assigning each activity a direct return.
These principles constrain each other in practice. Continuity limits how large any single activity can be, and neutrality limits how directly an activity can serve the company’s short-term interest. Deciding those trade-offs deliberately, rather than per activity, is what makes the function’s output consistent over time.

​
What engineering culture is

​
Values

Engineering culture is a set of values held in common by engineers, independent of any single employer or technical field. It is not a company’s internal rules, benefits, or ways of working; those are organizational culture, and they differ from company to company. Engineering culture is what recurs across communities, collaborative projects, and public writing regardless of who employs the people involved. Three values account for most of what is observed.

​
Why these values hold

These are not preferences that happen to be common. Three properties of engineering work make them practical necessities. Technical knowledge keeps changing. Tools and frameworks turn over on a scale of a few years, and new areas such as cloud and AI keep being added to what has to be learned. Learning is a condition of continuing to work in the field, not an optional virtue. Knowledge does not decrease when copied. Explaining a solution does not remove it from the person explaining. Because the cost of sharing is low and both sides gain, sharing spreads more readily here than in fields where know-how is scarce by nature. What is built is never finished. Software that stays in use keeps absorbing changes in requirements, environment, and load, so “it works” describes a state rather than a completion. Improvement is the activity that maintains that state. Open source is the clearest instance of the three appearing together: the code is published, anyone can read and learn from it, and improvements can be contributed back to the same codebase.

​
The structure of the engineering community

​
Three layers

The engineering community is made up of three layers with different actors and different motives. Treating them as one is a common source of failure when a company begins to participate.

​
How the layers relate

Individuals move across all three layers. The same person writes a personal article, helps organize a meetup, and speaks at an event hosted by their employer. Because it is the same person who crosses the layers, how they are treated in one layer affects trust in the others. Communities run on volunteer effort and depend on neutrality. Organizers generally do not profit, participants attend by choice, and the place holds together only while people believe it is not being run as a sales channel. That belief is the community’s principal asset. Companies participate as businesses, and that motive is legitimate and does not need to be concealed. What matters is the order of exchange. A company that first offers something the community wants — a venue, funding, speakers, published knowledge — retains its access. A company that asks for attention first tends to lose that access, and the loss is difficult to reverse.
Access to a community is not a channel a company owns. It is granted by the people who organize and attend the place, and it is withdrawn when the place stops serving them. Plan participation on the assumption that it can be withdrawn.

​
Kinds of places

Communities gather in several formats. They differ in scale, in how much preparation they need, and in what they are suited to.

​
What technical communication achieves

​
Definition and forms

Communication matters both for a company’s own product and for its technical branding. Technical communication is the act of putting engineering knowledge outside the person or team that holds it, in a form other people can use. It covers several forms, and they are not interchangeable.

​
Three effects

The learning cycle

Explaining forces the explainer to close gaps that were tolerable while the knowledge stayed private, and readers avoid re-solving a solved problem.

Technical branding

Published work makes an organization’s technical standard observable from outside, which is what other parties assess before working with it.

Effects on recruiting

Communication conveys what a job description cannot: the actual problems a team works on and the quality of its decisions.
The learning cycle returns to the communicator first. Writing an explanation exposes the parts of an understanding that were never examined, because a reader will not accept a step the writer cannot state. Feedback then corrects what the writer got wrong, which is a form of review that is otherwise hard to obtain. Technical branding follows from accumulation rather than from any single piece. An organization that publishes its decisions consistently becomes predictable to outsiders, and predictability is what makes technical partnerships and adoption decisions possible. Recruiting effects are real but indirect. Content made to serve its audience attracts people who value the same things; content made to attract applicants reads as advertising and loses the audience it needs. Treating recruiting as a downstream effect rather than a direct goal is what keeps the material worth their time.
The effects of communication appear slowly and are hard to attribute to any single article or event. Evaluate the activity over a period long enough to contain many of them, rather than judging each one on short-term numbers.