Porque Developer Relations?

Nos últimos meses eu tenho visto um aumento crescente no interesse da indústria de tecnologia sobre relacionamento com desenvolvedores (Developer Relations), também conhecido por DevRel para os íntimos.

O número de oportunidades profissionais na área não para de crescer mundialmente, e empresas que nunca tiveram algo estratégico para desenvolvedores estão tentando entender o que é isso, enquanto outras estão expandindo muito suas equipes e ações de engajamento.

Os desafios da pandemia tornaram ainda mais difícil conseguir atrair desenvolvedores para conhecer seus produtos e serviços. Os mecanismos de marketing tradicional e corporativo que ainda traziam resultados (questionáveis) nesta área, passaram a não funcionar mais tão bem, e a competição enorme pela atenção das pessoas nesse novo mundo online obriga as empresas a pensar fora da caixa e finalmente entender de verdade o mundo dos desenvolvedores de software. Brindes legais nos estandes em eventos, meetups descolados com pizza e cerveja simplesmente não existem mais. Atração e retenção de talentos então, ficou ainda mais complicado. Com o home office virando o novo normal, aquele seu escritório descolado já não diz muito.

Mas porque engajar desenvolvedores virou algo tão importante e estratégico? Não tenho todas as respostas para isso, mas gostaria de dividir alguns insights com vocês, e estou disposto a conversar sobre eles nos comentários.

Nos últimos anos, o poder de influência dos desenvolvedores em decisões de tecnologia que tem impacto financeiro enorme só aumentou. Quando falamos de tecnologias e arquiteturas emergentes então, ele é gigante. Não sei se alguém já contou isso em público, mas eu vou contar o segredo: Nós desenvolvedores temos a habilidade para recomendar ou rejeitar tecnicamente qualquer tecnologia, produto ou serviço, e sim… muitas vezes fazemos isso para nos manter em nossa zona de conforto ou manter nosso nicho de especialização como "o futuro". Triste, mas verdade! (desculpa aí se vou colocar alguém em maus lençóis por contar esse segredo :) )

A grande missão do relacionamento com desenvolvedores é atuar como curador da jornada de aprendizado e experimentação dos desenvolvedores, trabalhando para que ela seja a mais suave, efetiva e objetiva possível. Nosso desafio é tornar a tecnologia, produto ou serviço que estamos trabalhando parte da zona de conforto dos desenvolvedores, idealmente trazendo-os para a co-criação de tal forma que se tornem parte daquilo que estão usando (aqui dá para começar a entender como Open Source é fundamental para o sucesso). Saímos do ponto "temos um produto", para o "temos uma comunidade". O resto é história, e o Java é um excelente exemplo disso.

Isso requer habilidades, conhecimentos e experiência em três áreas: Tecnologia, Comunidades e Marketing/Comunicação. Não existe receita de bolo, nem solução mágica, mas existem boas práticas e muitas lições aprendidas com os erros que cometemos e que observamos outros cometerem nas últimas décadas. Cada tecnologia, comunidade e cultura local demanda uma adequação dos planos, repaginação das mensagens e estratégias, muitas vezes completamente diferentes para atingir os objetivos. Essas diferenças são gritantes quando falamos de países ou regiões do globo diferentes, mas elas são fundamentais também dentro de um país imenso e multicultural como o Brasil.

No tempo em que a oferta de hardware e software era majoritariamente controlada por poucas empresas no mercado, isso tudo era muito fácil. Durante décadas usamos apenas dois tipos de plataforma (baixa e alta), e na baixa praticamente uma única arquitetura computacional e de processamento com um único sistema operacional.

Hoje vivemos uma profusão de tudo. Diversas arquiteturas computacionais, diversas formas de processamento, incluindo o processamento híbrido (processador + aceleradores), diversos tipos de dispositivos, muitos sistemas operacionais, milhares de bibliotecas e frameworks e por aí vai.

Como exemplo prático disso, a opção de um desenvolvedor ou de uma equipe (influenciada por desenvolvedores) por utilizar um determinado framework ou biblioteca, define imediatamente quais serão os sistemas operacionais utilizáveis, quais serão os processadores ou aceleradores aplicáveis e quais serão as possibilidades de comercialização do produto final, sem contar toda a definição da infra estrutura de operação e oferta de serviços. Define ainda quais serviços poderão ser integrados com facilidade e quais interfaces de comunicação poderão ser utilizadas. É sobre esse alicerce de tecnologia que produtos e serviços serão construídos.

Mas se alguém "de cima" tomar todas essas decisões e vier no famoso top down… vou contar outro segredo: a chance do projeto dar errado é enorme. Sem desenvolvedores comprometidos e satisfeitos com o que estão criando, nada brilhante vai ser desenvolvido. Ai vira um turnover imenso, conhecimentos e aprendizados se diluindo com o tempo e voilá… temos aquele legado que não funciona direito, traz mais problemas do que solução e ninguém está disposto a colocar a mão para resolver o vespeiro.

Olhando para a indústria de hardware, se antes para garantir que seu hardware pudesse ser utilizado em grandes empresas bastava um esforço de vendas focado em tomadores de decisão, hoje quando o hardware está em um imenso datacenter e acessado através de uma maravilhosa abstração chamada de "nuvem", o papel dos desenvolvedores de software passou a ser imenso. Acredite se quiser, a decisão sobre se o seu hardware será utilizado ou não em um projeto que pode escalar e ficar imenso, está a um clique ou uma linha de configuração que um desenvolvedor está escrevendo lá no começo, quando o protótipo do projeto está sendo utilizado, e dependendo do grau de otimização necessário, ele não vai voltar lá e refatorar tudo "de boa vontade" (caímos no turn over e no caos legado já mencionados).

Estudar, aprender e se familiarizar com novas tecnologias não é algo simples, demanda muito tempo (e investimento), e aprendemos nos últimos anos que é uma atividade que se torna muito menos complicada quando feita em grupo, em comunidade. Saber como colaborar nessa jornada, principalmente respeitando as regras quase nunca escritas que regem comunidades é fundamental.

Me motivei a compartilhar aqui essas provocações, porque com o aumento da oferta por esses profissionais, já começam a aparecer os "consultores especializados", as empresas de "as a service" e os "entendidos da coisa toda", que há um ano ou dois atrás eram tudo isso da novidade da moda. 

Me questionei muito antes de publicar esse artigo, mas tem hora que a paciência fica curta. Eu trabalho com developer relations há 17 anos, antes mesmo disso ter esse nome (ou de ter um nome qualquer, na verdade), e tenho muitos amigos que fazem um trabalho sério há quase 20 anos também. Deixo aqui o meu recado: Cuidado com os gurus de plantão. 

Depois de 17 anos fazendo isso, não me considero especialista pois a cada dia aprendo algo novo. É uma arte em desenvolvimento, e não um conjunto de regras e sim: depende de pessoas, de empatia e de respeito, muito mais do que de tecnologia.