DevRel Guia essencial de Developer Relations
Pachi Parra, Letícia Leonardo
Introdução
Você já ouviu falar em Developer Relations, ou DevRel? Se ainda não conhece, tudo bem! Quando começamos na área de tecnologia, também não fazíamos ideia do que esse nome significava. Hoje podemos dizer com certeza: é uma das áreas mais legais e interessantes que conhecemos.
Developer Relations é sobre criar conexões.
É o trabalho de unir empresas e comunidades técnicas, ajudando ambas a crescerem juntas. De um lado, pessoas tecnologistas e, do outro, empresas que querem e precisam se comunicar melhor com elas.
Apesar do “Developer” no nome, DevRel não é exclusivo para quem escreve código. Tudo o que você vai aprender aqui também vale para profissionais de QA, dados, DevOps, segurança ou qualquer pessoa da tecnologia que precise interagir com comunidades técnicas, já que todas essas áreas juntas compõem o ecossistema de desenvolvimento. Então pedimos que você tenha isso em mente sempre que ler o termo "pessoas desenvolvedoras".
Neste livro, queremos mostrar como essa área funciona na prática, de um jeito acessível e didático. Vamos explorar as principais atividades de DevRel, entender como ele pode ser estratégico para a sua empresa e, principalmente, como você pode começar ou evoluir sua carreira nessa área apaixonante.
Escrevemos para você que:
- é pessoa desenvolvedora e quer explorar uma nova carreira sem sair da tecnologia;
- já trabalha com conteúdo técnico ou lidera equipes e quer entender como DevRel pode ajudar;
- atua com marketing e tem comunidades técnicas como público;
- trabalha na gestão de uma empresa e deseja implementar essa área;
- e, claro, para todo mundo que quer se conectar melhor com comunidades técnicas.
O único pré-requisito? Ter curiosidade sobre como unir tecnologia e pessoas de forma leve, verdadeira e eficiente.
Este livro é baseado nas nossas experiências e nos conhecimentos que adquirimos ao longo dos anos atuando com DevRel. Em alguns momentos, vamos trazer dados, pesquisas e fatos. Em outros, compartilharemos nossa opinião e aprendizados pessoais. Ao final de cada capítulo, você também encontrará a contribuição de outras pessoas que atuam na área, trazendo diferentes olhares, vivências e contextos que enriquecem ainda mais essa conversa.
Prefácio
Escrevo este prefácio com um sentimento misto de alegria e responsabilidade. Alegria por ter sido convidado pela Pachi para participar de um livro que pode ajudar muita gente no mundo, mas principalmente no Brasil, a organizar ideias e práticas.
Destaco, inicialmente, como cientista que, para além do conhecimento experimentado, há o conhecimento empírico (aquele criado em cima de observações e da experiência das pessoas envolvidas). Para além disso, há o conhecimento que pode ser construído, assimilado e compartilhado em comunidades por meio da oralidade, da escrita, das sensações e da cultura.
A primeira responsabilidade se apresenta porque Developer Relations (DevRel) ainda é uma área que, com frequência, costuma ser entendida de forma simplificada, e isso gera frustração tanto para quem trabalha com DevRel quanto para quem espera resultados dela.
Acredito que, a partir daqui e deste livro, poderemos nos comunicar como comunidade brasileira usando a expressão “Relações com pessoas desenvolvedoras”. Confesso que, com todo o avanço tecnológico, prefiro chamá-las de pessoas engenheiras. Isso, inclusive, eleva a complexidade ao redor de DevRel.
DevRel costuma ser confundido com uma lista de atividades. Eventos, posts, encontros, programas, materiais. Tudo isso pode fazer parte, mas não explica o que está em jogo. Quando as estratégias de DevRel envolvem somente uma agenda, o trabalho perde direção e a organização passa a medir movimento como se fosse transformação. Também não se entende o retorno do investimento nessa área. A pergunta que me move aqui é mais básica: o que DevRel sustenta quando funciona e o que se perde quando ela é tratada como algo periférico?
Uma das melhores formas de começar essa conversa é separando o que é DevRel do que é Developer Experience. DevX diz respeito à vivência interna de quem constrói software. É o fluxo no dia a dia, os pontos de atrito, a autonomia, a previsibilidade, o suporte entre pessoas, a clareza de decisões técnicas, a documentação, os caminhos de onboarding.
DevRel, por sua vez, atua em outra camada. Ela lida com relações sociotécnicas e com a forma como o valor circula entre pessoas, times, produto, engenharia e comunidades. Isso inclui relações internas e externas. Inclui também o que conecta pessoas a artefatos como código, documentação, APIs, ferramentas, exemplos e processos.
Quando a organização trata DevRel e DevX como a mesma coisa, costuma não fazer bem nenhum dos dois. Pensem comigo: se o ambiente interno é frágil, DevRel não consegue sustentar confiança, nem dentro nem fora. Existe uma boa experiência interna, mas não há DevRel. As melhorias ficam isoladas e não se transformam em aprendizado coletivo, contribuição contínua ou evolução compartilhada do ecossistema. Uma coisa prepara o terreno; a outra cria caminhos para que esse terreno se conecte a uma rede maior.
Eu gosto de insistir na palavra “relação” porque ela ajuda a evitar um desvio comum. Não estamos falando apenas de relacionamento informal ou de proximidade carismática com comunidades. O constructo “relação” tem um sentido mais estrutural, que envolve ligações e coordenação.
E, no mundo do software — inclusive nos sistemas já construídos por IA — essas ligações não são apenas entre pessoas. Elas também acontecem entre pessoas e artefatos e entre os próprios artefatos. Os artefatos são elementos vínculativos entre modelos do mundo real e modelos computacionais. Vínculo exige relação! Uma documentação que não se sustenta, um exemplo que não compila, uma API que muda sem aviso, um roadmap que some, um canal de suporte sem resposta, tudo isso é parte da experiência e parte das relações.
Nesse ponto, aparece uma imagem que muita gente usa para definir DevRel: a ponte entre a organização e as comunidades. Eu concordo com a metáfora, mas com um cuidado. Ser ponte não é apenas traduzir linguagem técnica para linguagem de negócio, nem transformar roadmap em conteúdo.
Ser ponte é alinhar ritmos, expectativas e incentivos. É perceber sinais internos, fricções, capacidades, prioridades reais. E perceber sinais externos, demandas, padrões de adoção, dúvidas recorrentes, oportunidades. A ponte é o trabalho de coordenação que transforma esses sinais em decisões mais coerentes, comunicação mais honesta e caminhos melhores de contribuição.
Quando esse trabalho é bem feito, ‘developer advocacy’ não é defender pessoas desenvolvedoras de um lado contra o outro. É representar necessidades técnicas de forma compreensível e acionável para produto e negócio, sem perder o que é essencial.
Evangelismo não é falar da empresa para fora como propaganda. É criar condições para que pessoas consigam aprender, construir e contribuir com menos atrito, com mais clareza e com mais sentido.
Também por isso medir DevRel é um desafio recorrente. O que é fácil de contar nem sempre é o que importa mais. É tentador reduzir o trabalho a volume de atividades, mas o que sustenta DevRel aparece em sinais de continuidade, profundidade e reciprocidade. Aparece em contribuições que acontecem com mais frequência e com mais qualidade. Aparece em feedback que volta para dentro e muda decisões. Aparece em comunidades internas que se fortalecem, em suporte que deixa de ser improviso, em onboarding que vira trajetória, em confiança construída ao longo do tempo.
Este livro existe para ajudar a nomear essas coisas e oferecer caminhos práticos. Para quem está começando e precisa de estrutura. Para quem já faz DevRel e quer organizar estratégia. Para quem está em produto e engenharia e precisa entender como DevRel pode se integrar sem virar um apêndice. E para quem já percebeu que comunidade não é um canal e que ecossistema não é um slogan.
Vejam, eu, como cientista, poderia cobrar todas as referências e citações que sustentem argumentos fortes. Mas sei que o texto foi construído por pessoas de referência da comunidade brasileira. Convido você a ler esse conjunto como motivador para reflexões mais profundas, para que possamos estabelecer uma comunidade de discussão em torno de conflitos produtivos pela área de DevRel.
Ninguém me convence de que não podemos ter o DevRel com cara, som e cheiro de Brasil!
Espero que as próximas páginas te ajude a enxergar DevRel com mais precisão e a praticá-la com mais intenção.
Avante, comunidade brasileira de DevRel.
Awdren de Lima Fontão
Pesquisador brasileiro na área de DevRel. Doutor em Informática na área de Engenharia de Software. Um manauara com parte da Amazônia e do Pantanal.
Sumário
- 1. O que é DevRel?
- 1.1 O que DevRel é e não é
- 1.2 DevRel como ponte: interesses da comunidade e da empresa
- 1.3 DevRel: profissão, programa e atividades
- 1.4 Os pilares de DevRel: código, conteúdo e comunidade
- 1.5 Conclusão do capítulo
- 2. Os pilares de Developer Relations
- 2.1 Pilar 1: Código — A base da credibilidade técnica
- 2.2 Pilar 2: Conteúdo — O poder de ensinar e inspirar
- 2.3 Pilar 3: Comunidade — Criando conexões e pertencimento
- 2.4 O equilíbrio dos pilares
- 2.5 Conclusão do capítulo
- 3. Por que sua empresa precisa de Developer Relations?
- 3.1 A desconexão entre empresas e comunidades técnicas
- 3.2 O papel estratégico do DevRel
- 3.3 Mas DevRel é para toda empresa?
- 3.4 Sinais de que é hora de implementar DevRel
- 3.5 Conclusão do capítulo
- 4. Modelos de atuação: DevRel interno e externo
- 4.1 DevRel externo: quando a comunidade é o foco
- 4.2 DevRel interno: quando a prioridade é cuidar da casa
- 4.3 Como entender qual modelo de DevRel faz mais sentido para começar
- 4.4 Conclusão do capítulo
- 5. A missão e o trabalho de uma pessoa no DevRel
- 5.1 O papel de quem constrói pontes
- 5.2 As habilidades que sustentam esse trabalho
- 5.3 Desafios e recompensas
- 5.4 Conclusão do capítulo
- 6. Comunidade e relacionamentos autênticos
- 6.1 O que comunidade é (e o que não é)
- 6.2 O ciclo de valor de uma comunidade
- 6.3 O papel estratégico da comunidade para a empresa
- 6.4 Conclusão do capítulo
- 7. Como começar a sua carreira em DevRel?
- 7.1 Os diferentes backgrounds e sua importância na área
- 7.2 Os perfis de DevRel
- 7.3 Como identificar seu perfil em DevRel e criar seu portfólio
- 7.4 O que todos têm em comum? Conteúdo e presença na comunidade
- 7.5 Ferramentas e boas práticas para criar conteúdo técnico (mesmo que você não seja especialista no assunto)
- 7.6 Como vencer o medo de se expor e compartilhar?
- 7.7 O papel da marca pessoal na sua trajetória
- 7.8 Conclusão do capítulo
- 8. O que eu gostaria de saber antes de entrar em DevRel (e como você pode se preparar)
- 8.1 Lições aprendidas na prática
- 8.2 Erros comuns e como evitá-los
- 8.3 Cuidados com burnout, autogestão e sobrecarga emocional
- 8.4 Conclusão do capítulo
- 9. Estratégias para começar a implementar Developer Relations na sua empresa
- 9.1 Quando é a hora certa para contratar
- 9.2 Comece pequeno: frameworks para um MVP de DevRel
- 9.3 A primeira contratação de DevRel
- 9.4 Conclusão do capítulo
- 10. Métricas em Developer Relations: do engajamento ao valor de negócio
- 10.1 O desafio da subjetividade
- 10.2 O primeiro passo: qual é o objetivo?
- 10.3 Do engajamento genérico a resultados estratégicos
- 10.4 Conclusão do capítulo
- 11. Anexo A — Estudos de caso fictícios em Developer Relations
- 11.1 Case 1: DevRel Externo – Uma startup B2D construindo seu programa de DevRel do zero
- 11.2 Case 2: Fintech Aurora – Fortalecendo cultura técnica e colaboração interna com DevRel
- 12. Depoimentos de profissionais de Developer Relations
- 13. Recursos e materiais de estudo para DevRel
Dados do produto
- Número de páginas:
- 191
- ISBN:
- 9788555194269
- Data publicação:
- 05/2026