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.