Developer relations

Developer relations (DevRel) is an activity that connects a technical product with the developers who use it. It combines education, community exchanges, technical assistance and communicating needs to internal teams. Its purpose is to make the product easier to understand and use, while ensuring that difficulties encountered in practice are heard.

The work can take the form of code examples, tutorials, demonstrations or workshops. Exchanges with developers also feed into bug reports, feature requests and improvements to resources. DevRel passes these on to the people who can address them. This contribution does not give DevRel the final say over the product roadmap.

The technical depth depends on the role. A remit focused on code requires usable examples and explanations of how they work. An activity focused more on the community can draw on engineers to answer specialist questions. Technical assistance can therefore be part of the role, with escalation contacts to define when a request goes beyond the person's expertise.

The reporting arrangement must be made clear within the organisation. Links with marketing are documented, but they do not constitute a universal model. To define the role, specify the audiences concerned, the resources expected and the teams that will receive feedback.

Developer relations, community engagement and developer experience: who does what?

• Developer relations brings together several activities to make the product easier to use and represent users' needs within the company.
• Community engagement here means exchanges with developers. Define whether the role also covers content and technical assistance.
• For developer experience, specify the difficulties DevRel should identify and the decisions that remain with product and engineering teams.

A product aimed at developers must be understandable and possible to try and use. Hiring for DevRel can meet the need to connect technical explanations with users' actual difficulties. The quality of the role depends as much on the ability to communicate as on the ability to collect feedback the company can act on.

The first decision concerns which activities take priority. If you mainly expect code examples and demonstrations, the candidate must have the relevant technical skills. If the need mainly concerns community exchanges, define how they will obtain help from engineers. Confidence in public speaking alone does not demonstrate the ability to build a usable technical resource.

The second issue concerns how feedback is handled. Consider who receives a reported bug, who examines a feature request and who decides to change the documentation. Without a designated contact, the role can accumulate observations without internal teams knowing what to do with them. Conversely, promising developers a change that DevRel cannot authorise weakens the relationship.

Fictional example: a company is preparing workshops around an API. Exchanges reveal a recurring integration difficulty. DevRel can produce a clearer example and pass the problem on to the product team. The product lead retains the decision over a change to the API.

Finally, distinguish what is done from what you want to improve. The number of pieces of content or participants describes activity. To assess its usefulness, relate the resources produced to the questions they answer and the lessons passed on. Avoid combining communication, support and sales expectations in one role without specifying their priority and the support available.

• Create code examples and resources to help developers use the product.
• Explain technical concepts, adapting demonstrations to the audience’s level of understanding.
• Run workshops and community exchanges around uses of the product.
• Collect the difficulties, needs and suggestions expressed by developers.
• Pass bug reports and feature requests on to product or engineering teams.
• Improve tutorials and other resources based on the feedback collected.
• Direct questions beyond their expertise to the appropriate technical contacts.

The skills to look for depend on the work you will assign to the person. For a role focused on demonstrations and code examples, examine development experience that enables them to produce a usable resource. A software or open-source contribution can show how the candidate understands a problem, builds a solution and explains it to others.

The documented pathways are not limited to a single qualification. GitLab mentions experience creating software or contributing to open source. This example indicates ways to acquire skills, without establishing a mandatory qualification for the profession as a whole.

For education, look for work that combines an explanation with a practical use: a tutorial, demonstration or annotated example. Its value lies in the understanding it gives the intended audience, with sufficient technical command to answer questions related to the content.

Community experience can also prepare someone to listen and pass on requests. The Mozilla account describes a pathway without initial technical training, supported by engineers. This variation does not remove the need for development skills in a role focused on code. Finally, distinguish responsibilities already carried out independently from those undertaken with support. The expected level of autonomy must match the supervision available.

To assess this profile, adapt the following steps to the activities and level of autonomy you want to assign to them.

1. Define assessment criteria linked to the role

Use distinct criteria: coding practice, clarity of explanations, listening to developers and passing on feedback. For each, specify the expected work and available help. Add management only if the role includes a team.

Distinguish essential skills from those that can be acquired with support. For a community remit, examine the ability to involve engineers. For a technical remit, give more weight to the examples developed.

2. Examine previous work

Ask for a tutorial, demonstration or code example the candidate can present. Ask them to clarify their personal contribution, the intended audience and the difficulties encountered.

Invite them to explain a technical choice, then rephrase the explanation for a less experienced developer. Observe the precision of the answers and the consistency between the content and the example.

Understandable work and a clearly explained contribution are positive signs. An appealing presentation whose code the candidate cannot explain calls for further investigation.

3. Set a limited practical exercise

Fictional example: you provide a demonstration API and an integration difficulty. Ask the candidate to prepare a short example, then explain how they would help the developer concerned.

Provide the necessary information and state the time allowed. Assess the reasoning, clarity of the deliverable and identification of limits. Then ask what information would be passed on to the product team if the difficulty reveals a possible bug.

A candidate who distinguishes what they can resolve from what they need others to examine provides a useful signal. A promise to change the product without a contact authorised to decide is a warning sign.

4. Assess communication and coordination

Ask them to describe a difficult question received from a developer. Examine how the candidate understood it, what they answered and whom they approached.

Ask how they would convey conflicting feedback to the product team. Look for faithful rephrasing and information that enables the request to be examined. Probe answers that reduce developers to an audience to persuade.

If the role includes management, ask them to explain an experience of recruitment, training or supporting others. Distinguish participation in an activity from responsibility for a team.

5. Allocate assessments and take references

Assign the code review to someone capable of assessing how it works. Involve a product contact to assess how difficulties are communicated and the person responsible for the role to assess priorities.

If the company lacks this expertise, bring in an independent technical expert to review the deliverable. Define the scope of their review so that each assessment addresses an identified criterion.

With the candidate's consent, request references on the responsibilities they actually held and the autonomy observed. Compare these with the supervision you need to provide. Finish with the points established and those that still need verification.