> ## Documentation Index > Fetch the complete documentation index at: https://lib.findy.co.jp/llms.txt > Use this file to discover all available pages before exploring further. # The role of Developer Relations > Defines DevRel as a company's function for reaching developers, then covers engineering culture, the engineering community's three layers, and technical communication. ## 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 | Orientation | Who uses the product | What the function works toward | | ----------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | Product-oriented | Developers are the users, as with APIs, SDKs, developer tools, infrastructure, and components | Adoption and continued use: documentation, samples, support, and feeding user feedback back into the product | | Branding-oriented | Users are not necessarily developers | Recognition and trust for the engineering organization: publishing, hosting events, supporting employees who speak | 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 | Way of taking part | What it requires | | ------------------------------ | -------------------------------------------------------------------- | | Hosting your own events | Continuous planning capacity and a reason for participants to attend | | Sponsoring community events | Funding or a venue, offered without conditions on the content | | Running engineering media | A steady supply of writers and an editorial process | | Supporting employees who speak | Time, review, and a policy on what may be disclosed | | Contributing to open source | Sustained engineering time, not a one-time donation | ### Principles Design each activity around what participants came for. Content whose main purpose is promotion loses the audience it was meant to reach. Avoid ranking languages, tools, or roles against each other. Comparisons should describe the conditions under which each fits. Relationships are built by repeated contact. Size the activity so it can be sustained rather than run once at full effort. 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. | Value | What it means | How it appears in practice | | ----------- | ------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | Learning | Treating current knowledge as provisional and keeping it up to date | Reading source code and design documents, trying unfamiliar tools, studying the reasoning behind a design | | Sharing | Moving knowledge outside the person who holds it | Documentation, peer review, articles, talks, open source | | Improvement | Treating a working system as still improvable | Reworking a structure that has drifted, retrospectives, automating repeated work | ### 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. | Layer | Actor | Primary motive | Typical form of communication | | ---------- | --------------------------------------- | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | Individual | An engineer as a person | Organizing their own understanding and building a public record of it | Articles, talks, open source contributions, answers to questions | | Community | Volunteer organizers and participants | Sustaining a place where people with a shared interest can learn | Study groups, meetups, tech conferences, open source projects | | Company | A business and the engineers it employs | Product adoption, technical branding, recruiting | Company-hosted events, engineering media, sponsoring, support for employees who speak | ### 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. | Format | Scale and cadence | What it is suited to | | ------------------- | -------------------------- | -------------------------------------------------------------------------------------- | | Study group | Small, recurring | Working through a single topic with the same participants over time | | Meetup | Small to medium, recurring | Meeting people with a shared interest; conversation matters as much as the sessions | | Tech conference | Large, usually annual | Covering a whole technical area at once and reaching people outside the regular circle | | Online event | Any scale, low travel cost | Reaching participants regardless of location, and leaving a recording behind | | Open source project | Continuous, no venue | Collaborating on an artifact rather than on an occasion | ## 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. | Form | What it suits | | ------------------------ | ------------------------------------------------------------------------------------------------ | | Engineering articles | Explaining a decision and the reasoning behind it at length, in a form that stays readable later | | Talks at events | Reaching an audience at a fixed time and answering questions directly | | Study groups and meetups | Building relationships with a small number of people in depth | | Open source | Publishing the result itself, where the artifact carries the explanation | | Public documentation | Serving readers who arrive with a specific question already formed | ### Three effects Explaining forces the explainer to close gaps that were tolerable while the knowledge stayed private, and readers avoid re-solving a solved problem. Published work makes an organization's technical standard observable from outside, which is what other parties assess before working with it. 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.