Dicas para acertar as relações com o desenvolvedor na sua empresa

Muitas empresas percebem que precisam de desenvolvedores para construir com elas, mas não sabem como. Aqui estão algumas coisas que você deve (e não deve) de um dos melhores profissionais de DevRel do setor.

Na tecnologia, algumas coisas são intuitivamente importantes, mas com impacto notoriamente difícil de medir. Veja o DevRel, ou relações com desenvolvedores, por exemplo. Tornou-se um truísmo que os desenvolvedores são os novos criadores, que podem ser imensamente importantes para o sucesso de uma plataforma ou serviço. E, no entanto, como Shawn Wang, da Temporal, escreveu, o DevRel geralmente é “muito chiado, bife questionável”.

Dada a aparente incapacidade de medir consistentemente o impacto que o DevRel tem na fortuna de uma empresa, por que as empresas continuam a investir? Porque eles definitivamente estão investindo, e não apenas nos EUA e na Europa, e não apenas em fornecedores de tecnologia, como detalhei. Dado há quanto tempo Wang está envolvido no DevRel e para quem (AWS, pouco antes de ingressar na Temporal), suas sugestões sobre como medir o impacto do DevRel são particularmente instrutivas.

Todas as crianças legais estão fazendo isto

Claro, o pessoal de DevRel que você segue no Twitter provavelmente trabalha para AWS, Google e Microsoft, mas essas empresas de nuvem dificilmente são as únicas empresas que empregam profissionais de DevRel. Fiz uma pesquisa rápida e encontrei DevRel na Ford Motor Company (automotiva), CapitalOne (serviços financeiros), Ubisoft (jogos) e muito mais. Isso porque, embora cada organização tenha necessidades diferentes de desenvolvedores terceirizados, cada vez mais as empresas veem valor em permitir que os desenvolvedores desenvolvam seus ativos de software (ou hardware).

Ou, como Martin Woodward, diretor sênior de relações com desenvolvedores do GitHub, enfatizou: “A razão pela qual o DevRel está em alta no setor agora é porque mais e mais pessoas estão entrando no software e entendem a importância da comunidade e da criação de efeitos de rede em torno de seu software para que ele cresça e cresça organicamente.” Se todas as empresas são cada vez mais dependentes de software, praticamente todas as empresas podem se beneficiar de ter mais desenvolvedores usando e/ou contribuindo para esse software de alguma forma.

Ainda assim, uma vez que você reconhece que precisa do DevRel, por qualquer motivo, como você mede o sucesso?

VEJO: Kit de contratação: desenvolvedor Android (TechRepublic )

É comum ver métricas de vaidade como estrelas do GitHub (para um projeto de código aberto que você possa ter) ou crachás digitalizados em eventos presenciais (lembra deles)? Estes são inúteis, argumentou Wang. Em vez disso, “Pare de procurar: sua métrica North Star é ‘desenvolvedores ativos mensais’”. Ou seja, o número de desenvolvedores assinando seu boletim informativo, contribuindo com seu projeto, seguindo seu perfil no Twitter relacionado ao desenvolvimento etc. Ao agregar todas as diversas maneiras pelas quais os desenvolvedores se envolvem com sua empresa, você obtém uma visão holística da saúde da comunidade . Se esse número estiver subindo, ótimo. Se baixo, não tão grande.

Um problema em medir o DevRel é que é fácil sucumbir à lei dos grandes números. Não, não lei dos grandes números; em vez disso, quero dizer a ideia de que todo mundo quer grandes números porque grande é bom, certo? Pode ser. Mas no DevRel, muitas das melhores coisas vêm de alcançar menos pessoas, mas mais valiosas. Ou, como disse Wang, muitas métricas do DevRel falham “porque valorizam a quantidade sobre a qualidade, a amplitude sobre a profundidade, o gratuito e superficial sobre o pago e indicando interesse sério”.

Pense nisso desta maneira. Se estou executando um projeto de código aberto, é tentador pensar que uma comunidade vibrante se parece com dezenas de milhares de colaboradores do projeto. No entanto, para a grande maioria dos projetos, menos de 10 pessoas fazem 90% do trabalho, como descobriu um estudo recente. Quase todos os projetos, então, se beneficiariam mais ao encontrar uma dessas 10 pessoas que podem se envolver profundamente em um projeto, em vez de tentar reunir um exército de espectadores. Para o profissional DevRel que ajudou a trazer aquele colaborador, seu trabalho está feito para o ano.

VEJO: O negócio líderes Como Desenvolvedor: O subir do nenhum código e código baixo software (gratuito PDF) (TechRepublic)

O que nos traz de volta à questão do que o DevRel deveria estar fazendo. Isso depende do seu produto/projeto, como observado, mas uma coisa que Wang menospreza, que tenho visto rotineiramente em várias empresas, é usar o DevRel para informar o desenvolvimento de produtos. Parece uma ótima ideia. Isso raramente funciona: “A realidade é que muitas vezes a proporção desse tráfego de duas vias é de 99% de saída e 1% de entrada”, escreveu ele, “porque as organizações de produto/engenharia não reservaram nenhuma largura de banda para ‘shadow PM- ing’ da devrel e todas as métricas da devrel são focadas em outbound.”

Então, que boas razões para ter DevRel? Gosto de pensar no DevRel como uma maneira autêntica de envolver (ou comercializar) desenvolvedores. Isso pode ser feito, disse Wang, concentrando o DevRel na comunidade, conteúdo e/ou produto. Uma empresa pode querer construir uma ampla comunidade em torno de um projeto complementar de código aberto, por exemplo, algo que facilite a venda do produto principal, ou talvez a comunidade tenha simplesmente a intenção de fazer com que os possíveis compradores se sintam seguros em números. Ou talvez o DevRel criasse conteúdo técnico profundo que permitisse que desenvolvedores de terceiros construíssem com ou sobre o produto da empresa. Falando em produto, o DevRel também pode ser a equipe que dá vida a um produto através da construção de demos e, através deste e de outros meios, ajudando a equipe de produto da empresa a saber quando um novo produto não está pronto para disponibilidade geral.

Mas espere! Tem mais. Tanto mais, aliás, que deixo para vocês lerem o excelente post de Wang. Apenas lembre-se: o DevRel “certo” é ajustado às necessidades específicas de sua organização. Você não é o Google. Você não precisa da organização DevRel do Google. Como escrevi: “Então, antes de contratar um lead DevRel no molde de [Google’s] Kelsey Hightower (de fato, um nível muito alto), primeiro entenda a comunidade que você espera ter. Pode ser que o candidato ideal se sente no cubículo ao lado.”

.