Antes de trabalhar com DevRel, eu pagava as contas sendo uma cientista de dados. Hoje eu posso dizer que troquei a ciência de dados para trabalhar em developer relations com sucesso já que atingi a marca de 1 um ano trabalhando como Developer Advocate! 🎉



Eu no primeiro dia de trabalho oficial em Março de 2021

Por isso achei que seria interessante escrever sobre os aprendizados deste ano e compartilhar isso com você que está lendo. Um pequeno aviso: esse texto é um pouco longo, então sente-se confortavelmente. 😉

O que eu costumava fazer antes de ser contratada como uma Developer Advocate

Um pouquinho de história antes de mergulhar nos aprendizados já que, talvez você não me conheça ou saiba com o que eu trabalhava antes.

Há algum tempo, eu costumava trabalhar como cientista de dados. No primeiro emprego que tive, eu cheguei a apresentar mais de 13 palestras sobre o projeto em que eu trabalhava, chamado de Serenata. Incluindo uma palestra em Taiwan, tudo isso em menos de um ano. O Serenata, é um projeto de tecnologia cívica e de código aberto que dependia de nós, pessoas desenvolvedoras e cientistas de dados, para espalhar a palavra sobre esse projeto para que ele pudesse prosperar.



Eu apresentando sobre Rosie, AI do Serenata, num Meetup lá em 2017

Além de apresentar palestras em vários eventos e conhecer muitas pessoas, também criamos muito conteúdo técnico para tornar o projeto mais acessível para quem não tem o conhecimento para ler e entender código. Você pode conferir a página do projeto aqui.

Mais ou menos na mesma época, eu também criei com amigos o Pizza de Dados, o primeiro e mais querido podcast sobre ciência de dados do Brasil. Compartilhar conhecimento em vários formatos virou uma paixão. Eu amo dar palestras, ministrar tutoriais, falar com pessoas e ajudá-las.

Acontece que isso tudo é grande parte de ser uma developer advocate. Eu só não sabia disso naquela época. Veja bem, isso foi por volta de 2017, nós estamos agora em 2022, e developer relations ainda é algo muito novo no Brasil, então imagina como não era lá em 2017.

O que é Developer Relations ou Developer Advocacy?

Acho que a primeira pergunta que me fazem quando digo que sou uma developer advocate é “developer o quê?”. As pessoas geralmente não entendem logo de cara. Developer advocacy é algo tão novo que nem tem um nome oficial em Português, mas se vê sendo chamado de Evangelismo às vezes.

Por isso, não me surpreende quando as pessoas não entendem o que eu faço apenas dizendo o nome do meu cargo, mas com certa frequência rola um entendimento quando eu explico o que eu faço. Sempre rola um “ah, sim, combina com você”, especialmente se a pessoa conhece a minha participação nas comunidades de tecnologia.

Se você não sabe o que é DevRel, aqui está a breve descrição: Faço amizade com pessoas que desenvolvem para ajudá-las a entender tópicos complexos e trabalhar com mais eficiência. Agora, existem muitas maneiras de você alcançar esse objetivo, eu faço isso dando palestras, escrevendo artigos em blogs, vídeos, podcasts, etc.

Você pode estar se perguntando por que eu digo que “faço amizade”, certo? Bem, eu gosto de descrever dessa maneira porque as pessoas tendem a pedir ajuda a seus amigos e amigas, e esse é o meu objetivo maior, ser alguém que qualquer pessoa pode pedir ajuda, especialmente quando se fala de criar e manter software.

Palestras, tutoriais escritos, workshops, podcasts, vídeos e assim por diante, são apenas uma parte do processo de ser uma developer advocate. A parte que as pessoas costumam ver. Há também a outra parte, a parte em que você tem que fazer relatórios sobre eventos e iniciativas em que trabalhou. Você precisa testar novos recursos e fornecer feedback internamente. Você documenta os processos e ajuda a estruturar as formas de ajudar o negócio a ter sucesso. E tudo isso enquanto você passa parte ou a maior parte do seu tempo viajando para encontrar com as pessoas desenvolvedoras onde elas estiverem.

As relações com uma pessoa desenvolvedora são um tópico complicado se você pensar sobre isso. Você precisa ter muitas habilidades: habilidades técnicas, de comunicação e interpessoais, também senso de negócios, ser orientada a dados e ainda ser uma participante ativo de qualquer comunidade de tecnologia e colocar as pessoas em primeiro lugar. Isso me lembra esse tweet:

Tradução livre: Developer advocacy é simples. Você só precisa de habilidades de engenharia, marketing, desenvolvimento de negócios, gerenciamento de produto, criação de conteúdo e ser uma pessoa habilidosa em comunicação, tanto na forma escrita, quanto na fala. Depois disso, o trabalho meio que rola sozinho.

Se você estiver considerando quais habilidades melhorar para se tornar DevRel, pense nas habilidades que mencionei neste artigo e tente desenvolvê-las no seu dia-a-dia. Acontece que a maioria dessas habilidades são úteis independentemente do seu papel e, quanto mais cedo você começar, mais fácil será a sua jornada para se tornar uma DevRel. 😉

Como eu decidi que DevRel era o que eu queria?

Além de palestrar em diversos eventos e conhecer várias pessoas enquanto eu trabalhava no Serenata, eu também criei muito conteúdo técnico sempre buscando fazer o projeto ser mais acessível para as pessoas que não tinham um conhecimento técnico para entender o código.

Depois de sair do Serenata, eu fiz questão de participar ativamente na comunidade Python, não importando onde eu estivesse trabalhando. Sempre que pude, dei palestras no meu tempo livre, mantive o meu blog e continuei gravando o Pizza de Dados.



Eu, Lele Portella e Ceci Vieira numa live stream

Em resumo, chegou um dia em que eu decidi que queria mudar o meu trabalho para que ele incluísse mais atividades de compartilhamento de conhecimento ao invés de só fazer isso no meu tempo livre. Com um pouco de sorte, na mesma época, a Auth0 estava tentando contratar uma pessoa developer advocate. Foi nesse momento que decidi agarrar a minha chance.

Antes de começar o processo seletivo, eu fiz o que eu sempre faço: pesquisa. Pesquisei mais a fundo o que queria dizer “ser DevRel” e aí numas sessões de pesquisa achei um ebook escrito por Sam Julien, naquela época, Head de DevRel na Auth0. O ebook chamava “Getting Started in Developer Relations”, e eu devorei o livro em menos de dois dias. Foi nessa hora que caiu a ficha: Eu já fiz isso antes… E eu amei fazer isso!

Como é o dia de uma Dev Advocate?

No lugar de falar sobre o meu dia, eu vou falar da minha semana por que eu acho que isso vai ilustrar melhor o que uma pessoa pode fazer na posição de DevRel.

Dia da semana Atividades
Segunda • Fazer a triagem dos pedidos de colaboração
• Conferir as perguntas de pessoas embaixadoras
• Praticar uma palestra que vou apresentar no dia seguinte e garantir que ajustes não são necessários
Terça • Participar da reunião 1:1 com meu gerente direto
• Participar da reunião 1:1 com um colega de outro time sobre uma iniciativa nova
• Apresentar uma palestra num evento
• Preparar o rascunho de uma palestra para uma chamada que acaba no fim da semana
Quarta • Participar da reunião semanal do time
• Documentar um processo novo
• Escrever o rascunho de um novo vídeo que eu vou gravar
• Revisar o trabalho da especialista de localização
Quinta • Fazer análise de dados da newsletter enviada semana passada
• Rascunhar um blog post que vai acompanhar o vídeo
• Rascunhar uma amostra de código que vai ser usada no vídeo e no blog post
Sexta • Participar da reunião semanal de alinhamento e novidades da empresa
• Participar do happy hour semanal com os colegas de time
• Revisar um blog post de um colega

Você pode fazer tudo que eu listei na semana acima e ainda ter uma agenda completamente diferente para semana seguinte, especialmente se você estiver viajando para participar de um evento presencial. Você ainda pode arrumar tempo para ajudar a comunidade em algo ou trabalhar em algum projeto pessoal.

Uma coisa eu garanto, isso tudo pode até parecer repetitivo - tudo que você faz é sempre sobre compartilhar conhecimento ou ajudar alguém -, mas nunca tem um momento sem graça.

Onde o time de DevRel se encontra em uma organização?

Pelo que andei vendo, existem três locais para encontrar o time de developer relations dentro de uma empresa:

  • Engenharia: como parte do time de engenharia de software
  • Marketing: como parte da organização de marketing
  • Produto: como parte de desenvolvimento de produto

Onde você encontra o time geralmente dita como o time é visto por outras pessoas na empresa: Se é um cargo técnico e se é compensado como tal. No caso da Auth0, o time de DevRel está sobre a organização de Developer Marketing debaixo do guarda-chuva de Marketing e é visto como um cargo técnico.

O que eu aprendi como cientista de dados e ainda uso diariamente?

Acima de tudo, trabalhar com ciência de dados me ajudou a desenvolver a habilidade de comunicar conceitos complexos com facilidade para qualquer audiência, habilidade que levo comigo em tudo que eu faço, mas além disso, existem outras habilidades que eu aprendi enquanto cientista de dados que uso diariamente. É importante ressaltar que algumas dessas habilidades se não todas elas podem ser desenvolvidas independentemente do seu trabalho. 😉

📆 Priorização

A pergunta que eu e meus colegas mais fazemos nas sessões de planejamentos sempre é: “O que vai trazer maior impacto pro que estamos tentando fazer?”. A cientista de dados que mora em mim sempre diz: Bem, depende do que estamos tentando otimizar, e por consequência me faz pensar em qual área queremos crescer. Qual a fundação que queremos construir para que possamos colher os frutos desse trabalho no futuro?

Pra ser sincera, essas perguntas se aplicam a qualquer trabalho de desenvolvimento de software também. A ciência de dados me ajudou a encontrar respostas baseadas em dados e observações do passado. Também me ajudou a definir um caminho saudável de crescimento com base nas informações disponíveis.

🗣 Habilidades de comunicação

A maior parte do que eu faço é: entender os pontos problemáticos e fornecer orientação para aliviar ou se livrar deles. Para fazer isso bem é necessário se comunicar e adaptar o estilo de comunicação baseado no público com quem se está falando.

Em um ano, você pode falar em mais de 10 eventos, todos eles com audiências contendo níveis variados de conhecimento, habilidades, stack favorita e muito mais. Você pode trabalhar em uma palestra para um evento mês que vem enquanto termina o material de um tutorial para um hackathon da semana que vem. Esses dois eventos requerem um formato diferente de comunicação e estruturação de conteúdo.

Eu tenho que escrever relatórios sobre os eventos e iniciativas que eu fiz ou contribui de tempos em tempos. Também preciso conversar com outros times na empresa para fornecer feedback em projetos e features. Comunicação está no centro de DevRel.

⏱ Time-boxing e criação de código de exemplo

Isso eu aprendi faz um tempão quando eu usava ciência de dados para aquele projeto Serenata e, acredite se quiser, eu ainda uso diariamente, especialmente para saber quando pedir ajuda. Por exemplo, eu tinha que implementar uma aplicação de exemplo para demonstrar uma feature de extensibilidade nova: Auth0 Actions.

Eu tinha um plano.

Eu queria fazer uma aplicação baseada em um dos tutoriais que temos no Blog da Auth0. Eu separei um tempo para trabalhar nisso: “Eu tenho 2 dias para para fazer isso funcionar e, se não funcionar, eu replanejarei”. Dois dias se passaram e adivinha? Não consegui fazer a amostra de código funcionar como eu queria. Eu percebi que tava complicando uma coisa que deveria ser simples: a parte de código que não tinha nada a ver com a feature.

A parte boa disso tudo, é que eu não tava sozinha nisso tudo. Chamei um colega de trabalho para conversar. A gente bolou um plano juntos para fazer a minha ideia dar certo usando uma aplicação beeeem mais simples e já pronta. O resultado dá pra ver aqui:

Time-boxing é uma técnica fundamental para me dar tempo de testar as coisas que eu to fazendo e saber quando pedir ajuda. Principalmente, me ajuda a ter tempo para redirecionar o meu plano caso seja necessário. Assim eu consigo ser efetiva em criar coisas novas em um tempo aceitável.

📈 Análise de dados básica

Uma pergunta constante em DevRel, não importando a empresa que você trabalha, é: “Como medimos sucesso?” E, às vezes, é bem difícil responder isso. É aí que um entendimento básico sobre dados se torna relevante.

Por exemplo, eu lidero e mantenho a newsletter para pessoas desenvolvedoras Zero Index. Ela sai mensalmente e contém uma coleção de conteúdo curado para pessoas desenvolvedoras — aliás se você quiser, dá pra assinar e conferir edições passadas aqui. Dá pra dizer que uma definição de sucesso para esse projeto seria enviar a newsletter para mais pessoas, mas eu vejo muito mais possibilidades além disso.

A gente quer enviar para mais devs, claro, mas queremos enviar informação que seja relevante, mas como você pode entender isso se você não sabe medir a relevância de uma informação? Provavelmente você vai trabalhar com pessoas que podem te ajudar a entender os dados, né?

Como eu ainda tenho o coração de cientista de dados, eu coloquei os músculos que desenvolvi durante anos e apliquei isso para tentar entender como as pessoas interagem com conteúdo que a gente compartilha. Fiz uns gráficos, e dei uma olhada na estrutura e como ela mudou ao longo do tempo. Tudo isso resultou em ideias de testes A/B que pudemos fazer com o intuito de melhorar a experiência de quem lê a newsletter.

Você pode deixar a ciência de dados, mas a ciência de dados nunca te deixa.

Então é verdade que de tempos em tempos eu ainda uso dados para entender o mundo à minha volta mesmo que isso não seja parte da descrição do meu trabalho. 😉

Coisas novas que tive que aprender

Veja bem, muitas coisas novas apareceram junto com a nova carreira especialmente no domínio de identidade, autenticação e autorização, que eram algo completamente novo para mim, além disso também surgiram coisas sobre criação de conteúdo para uma empresa e não para mim ou meus amigos.

Reaproveitar conteúdo

Uma coisa engraçada, quando estamos escrevendo código queremos usar o conceito DRY (don’t repeat yourself) de não ficar repetindo código, mas quando se fala de conteúdo, nós fazemos o oposto. Reaproveitar conteúdo é algo bom. Um artigo no blog pode virar um fio no twitter, uma palestra, um episódio de podcast, ou até mesmo um vídeo no YouTube.

Você precisa fazer o seu conteúdo “escalar” e distribuir esse conteúdo em plataformas variadas é uma forma de fazer isso, principalmente por que pessoas diferentes aprendem de jeitos diferentes. Por exemplo, algumas pessoas, como eu, preferem conteúdo escrito, outras preferem vídeo ou podcasts e assim por diante. Para você ser efetiva no seu trabalho você provavelmente vai fazer mais um formato ou se juntar com algum colega para que você faça um formato e essa outra pessoa cuide de outro formato.

Identidade, autorização e autenticação

Como eu trabalhei com ciência de dados na maior parte da minha vida profissional, os desafios ligados ao mundo da identidade não era algo que eu tinha contato, pelo menos não até eu entrar na Auth0. Identidade é difícil. É complexo e tem várias sutilezas que às vezes passam despercebidas até para pessoas desenvolvedoras mais experientes.

Vale salientar que identidade aqui não é o seu RG ou CNH mas sim quem você é no mundo da tecnologia, seus cadastros de usuário, seus acessos a sistemas e muito mais.

Vamos ser honestas, por causa de quão difícil identidade pode ser, autenticação e autorização são sempre uma preocupação secundária para muitas pessoas desenvolvedoras. Não é comum ter uma abordagem que lida com identidade primeiro - tenha em mente que isso deve mudar nos próximos anos.

A parte boa disso tudo, é que eu abraço os desafios trazidos por problemas e conceitos complexos. Eu gosto de entender essas coisas e destrinchá-las para tornar tudo isso mais fácil de absorver. Eu vejo isso como algo que eu fazia quando eu começava um cargo novo em ciência de dados: Eu estudava os dados e o negócio para entender os problemas que a empresa estava tentando resolver e começava a construir coisas a partir desse conhecimento.

Então eu não comecei a fazer de fato DevRel, mas também eu estava aprendendo coisas novas e complexas. Eu me divirto aprendendo conceitos como MFA e SSO dessa vez não só como usuária, mas também como desenvolvedora. Eu ainda estou longe de ser uma expert nesse novo domínio, mas eu estou adorando cada pedacinho dessa jornada de conhecimento.

Desenferrujando os conhecimentos sobre API e desenvolvimento web

Além da parte sobre identidade, tinha mais uma coisinha que eu precisei relembrar conceitos e sobre como fazer: APIs e aplicações web. Eu não só trabalhei com ciência de dados, mas também trabalhei uma parte do tempo como desenvolvedora web, então em algum ponto da minha carreira eu sabia sobre APIs e como construí-las.

A verdade é que, embora os modelos que eu costumava fazer deploy na AWS Sagemaker tivessem endpoints, já fazia um bom tempo que eu não desenvolvia APIs de verdade. Então eu tive que relembrar conceitos sobre RESTful, OpenAPI e outros verbos HTTP além de PUT, POST e GET.

Entregar conteúdo e não código

Se eu tivesse que dizer quanto tempo eu passo codando, acho que só chega a 10% do meu mês. Apesar de que eu ainda escrevo código de vez em quando — até JS eu escrevi outro dia — a quantidade hoje em dia é bem menor se comparado com a época que eu fazia análise de dados e criava modelos de machine learning.

Tenha em mente que isso não quer dizer que todas pessoas em DevRel são assim… Até mesmo no meu time temos developer advocates que escrevem muito mais código. A quantidade de código escrito vai depender das iniciativas que cada developer advocate cuida. Afinal de contas, nós ainda somos pessoas desenvolvedoras e mantemos sites como jwt.io ou webauthn.me, isso quer dizer que parte dos meus colegas passa mais tempo escrevendo código do que eu especialmente para manter essas iniciativas.

O meu foco não escrever código, mas sim ajudar pessoas e ensiná-las como implementar coisas nas suas aplicações. Eventualmente eu acabo escrevendo código para isso, afinal de contas eu estou ajudando a aumentar a adoção de um produto para devs, mas mais do que codar, a minha obrigação é entender como construir aplicações para ajudar outras pessoas a fazerem o mesmo.



Eu apresentando minha palestra sobre Auth0 no Developer Day 2021, clica aqui pra ver o video por completo

Agora, ao invés de resolver bugs, eu devo entregar um blog post que ensina como implementar fluxos de login/logout numa aplicação de página única em Python por exemplo. Isso não me impede de fazer contribuições para os SDKs da Auth0, isso só quer dizer que eu foco em outras coisas além do código.

No caso da Auth0 em particular, os códigos estão quase prontos. Nós temos uma biblioteca imensa amostras de codigo e quick-starts. Eu posso me apoiar em materiais feitos por pessoas que entendem muito desse novo domínio, e criar coisas novas com o foco em compartilhar conhecimento e, se eu conseguir fazer tudo isso ser divertido, ainda “ganho pontos extras”.

Empresas menores podem ter responsabilidades relacionadas a atividades para comunidades, como por exemplo gerenciar fóruns e comentários em redes sociais além de ter algum envolvimento com a parte de experiência da pessoa desenvolvedora (developer experience), vale salientar que isso não acontece na Auth0, nós temos times específicos focados em cada um desses meios, mas trabalhamos em conjunto para ajudar as pessoas que usam a gente.

Vale apontar que a forma que a Auth0 lida com DevRel eh bem madura e que isso nem sempre é o caso de outras empresas. Para esses casos menos maduros, eu consigo ver que pessoas de DevRel passariam mais tempo escrevendo código do que eu por exemplo.

A progressão de carreira

A parte boa de fazer DevRel num time bem estabelecido, entre outras coisas, é que a sua vida fica um pouco mais fácil quando você começa a pensar na sua progressão de carreira.

Na Auth0 temos a pessoa contribuidora individual (IC) esse caminho pode levar ao Staff Developer Advocate e Lead Developer Advocate, e também tem o que eu gosto de chamar de caminho da liderança, onde você consegue seguir para posições como Diretora de Developer Relations. É importante salientar que essas divisões não impedem as pessoas de virar gerente uma vez que elas são staff e vice-versa, mas esses caminhos estão lá para garantir que cada pessoa tem uma forma de se desenvolver e avançar na carreira.

Outras empresas podem ter progressões de carreira diferente da que descrevi. Essas posições também podem ser alteradas ou adaptadas com o crescimento do time. Quem sabe? Pode ser que um dia eu vire diretora de Developer Relations América Latina… As possibilidades são muitas.

Recapitulando

Esse ano foi muito divertido. Eu me sinto ainda mais criativa quando olho pro meu trabalho. Eu consigo ajudar pessoas. Deu pra perceber que eu amo o que eu faço? Criar conteúdo para ajudar outras pessoas é a minha missão de vida e é maravilhoso conseguir fazer isso no meu trabalho.

Mal posso esperar pra ver o que vai rolar daqui pra frente.