Rafael Dohms

Principal Engineer na SurveyMonkey

Interrompi minhas férias por um motivo mais do que especial: publicar a entrevista com um dos profissionais que eu mais admiro e respeito, o grande Rafael Dohms! Sou fã do trabalho que ele fez nas comunidades de PHP no Brasil e tive a oportunidade de trabalhar com ele em um projeto alguns anos atrás.

Conte um pouco sobre sua posição atual. Qual é o seu título e que tipo de trabalho você faz geralmente?

Minha posição atual é de Principal Engineer na SurveyMonkey. Frequentemente referenciada internamente como Principal Architect pois meu foco é em arquitetura. Descrever minha posição é um pequeno desafio, mas gosto de me ver como um facilitador, oscilando entre tarefas mais "contribuir individual" e tarefas mais "gerencia", mas com o foco em ajudar times e indivíduos a obter sucesso.

Que tipo de impacto você sente que mais gera na sua posição atual? E como isso é diferente em relação a sua posição anterior?

Subindo de senior, staff ate principal a grande mudança que vejo é do impacto se afastar do "código de produção", e focar mais em ajudar times a ter este impacto direto no código. Comunicação e direção são hoje os focos da minha função, ajudando os times a usar essas ferramentas para entregar mais e melhor. Criar um ambiente de colaboração entre times, entre pessoas de um mesmo nicho, e até dentro de times e ajudar estes a trazer soluções de mais qualidade, com pairing, sessões de desenho de sistemas e com iniciativas como Guildas e Capítulos.

Qual é o percentual de trabalho entre código e liderança que você desempenha hoje? 50/50? Passa mais tempo trabalhando com tecnologia/codando ou mais tempo liderando pessoas?

Acredito que meu tempo de código fica em torno de 30-40%, mas em sua grande parte é focado em "código não critico" ou em criar código que vai ser commitado por outra pessoa (pairing, design, etc..). Grande parto do meu trabalho de código é feito em sessões de pairing com times.

Como é um dia normal na sua rotina? Ou como é uma semana normal para você?  Quais são suas rotinas principais?

A semana se divide em reuniões recorrentes, reuniões não planejadas ou espontâneas e trabalho individual. As reuniões recorrentes são dedicadas aos grupos de trabalho, seja de chapters e guildas ou de grupos focados em algum tópico como arquitetura.

As reuniões espontâneas giram em torno de necessidades dos times ou de projetos ou reuniões 1:1 com diversas camadas de engenheiros.

O tempo de trabalho individual oscila entre tempo de código, documentação arquitetural, desenhos arquiteturais, ou somente tempo dedicado a estudar um aspecto do projeto ou empresa que necessita de alguma intervenção.

Como você mede seu sucesso? Quando somos pessoas desenvolvedoras de software é comum medirmos nosso sucesso pelo número de commits, pull requests, entregas realizadas. Isso mudou de alguma forma em sua posição atual?

Esta é uma pergunta difícil mesmo. Meu gerente costuma dizer que um bom arquiteto é aquele que ninguém vê seu resultado direto, mas vê o resultado de todos ao seu redor. Isso é uma maravilha para a síndrome do impostor.

Porém este quadro faz muito sentido, é difícil medir meu impacto direto, qual seria? Quantas caixas tem meu diagrama? quantas reuniões eu fiz? Realmente a medida é em parte feita pelo efeito geral da qualidade da produção do time como um todo.

Eu procuro me medir por atividade, quanto eu sinto que estou ajudando indivíduos e times e me envolvendo em projetos. Às vezes aparece algum sucesso grande e fácil de medir, mas em geral dependo muito do feedback e de quanto me procuram e me incluem. Julgo que se meu trabalho não fosse bom, evitariam me convidar para participar de colaborações.

Você participa das decisões de tecnologia ou arquitetura? Como gerencia essa influência em relação aos demais times? Você toma boa parte das decisões ou guia os times para que eles cheguem às conclusões?

Sim, sou peça chave nas decisões e nos processos que levam a decisões. Eu acredito que o bom arquiteto é o que reconhece que não sabe de tudo. Eu procuro guiar times a tomarem decisões melhores, trazendo o máximo de contexto e informações para ajudar. O diferencial que posso usar nestes casos é o de ter uma visão mais ampla do todo. Mas no final do dia eu quero que os times sejam donos de suas decisões, pois eles sabem mais do contexto onde estão, e eu só posso ajudar decisões, não falar para eles o que fazer.

Que soft-skills você percebe que fazem a diferença na sua posição? E como eles diferem da posição anterior, como dev senior?

Acredito que a ferramenta mais importante na minha posição tem sido a comunicação. Habilidade de aproximar as pessoas certas e facilitar a conversa entre elas. Engenheiros que têm oportunidades de conversar sobre assuntos variados de seu interesse são, na minha opinião, peça chave de um time de sucesso.

Entre um sênior e os níveis acima a grande diferença é como resolver problemas, se é mão na massa ou ajudando outros a botar essa mão na massa. Nesse escopo de comunicação a habilidade de explicar, de transmitir ideias, de usar meios visuais, de puxar a visão do todo para o contexto foram peças que me ajudaram a avançar e ajudar outros.

Você dedica tempo para mentorar as demais pessoas dos times?

Sim, embora eu gostaria de dedicar mais tempo e de forma mais estruturada, porém este ano tem trago desafios diferentes. Por hora eu faço mentoria de forma mais informal, quando a oportunidade se faz presente, e de diversas formas, conversas, projetos, etc…

Para chegar a esta posição, você entregou algum projeto especial, ou você sente que foi uma progressão pelo conjunto das suas contribuições?

Um pouco dos dois. No período antes da aquisição da Usabilla pela SurveyMonkey junto com outros engenheiros nós iniciamos um grande projeto arquitetônico que revolucionou como era construído nossos serviços.

Com o lançamento deste produto e mudanças internas eu me vi numa situação de passar muito tempo colaborando com engenheiros e líderes de produto, tornando muito difícil entregar minhas próprias tarefas. Neste momento tive uma conversa com meu líder para analisar esta situação e chegamos a conclusão de que este papel de arquiteto teria mais impacto e acabei assumindo esse papel.

Após a aquisição houve uma continuação deste meu papel atuando entre os times, entre os departamentos e compartilhando informações com todo o departamento, e isso levou a uma expansão desse papel, e mais liberdade para atuar em diversas áreas da empresa e com diversos times.

Que dicas você pode dar para quem está decidindo se continua o caminho de desenvolvimento ou se deve ir para a área de gerenciamento de pessoas? O que levou você a escolher pelo primeiro caminho?

Eu honestamente acho que a linha entre os dois é tênue. Comunicação e lidar com pessoas faz parte de ambos caminhos, apenas o intuito e foco mude.

Eu adoro trabalhar com pessoas, mas tenho menos alegria em gerenciar as coisas mundanas, e planejamento. Embora o planejamento ainda faça parte de ser um principal, não é um grande foco. Focar mais em ajudar os times a atingir as metas definidas pelo time ao invés de definir e monitorar estas metas me satisfaz mais.

Algumas dicas básicas: o real desafio são as pessoas, sendo gerente ou não; seu impacto nem sempre vai ser direto e fácil de medir; Ser arquiteto não é saber as respostas, é saber ajudar outros a ver as respostas.

Você lembra de algum conselho ou dica que recebeu quando entrou nesta posição e que foi importante para você?

Duas ideias ficaram comigo ao longo do tempo: 

Aprenda a receber e dar feedback e incorpore ele no seu dia a dia. Saber ouvir críticas e elogios e saber quando usá-los para motivar ou crescer seus colegas é uma ferramenta chave para melhorar seu impacto e a convivência. Além de procurar encarar desafios com positividade, ciclos negativos e pessoas negativas não ajudam ninguém.

Todo código é escrito para resolver o problema do dia que foi escrito, e portanto quando você for olhar para ele com olhos do "problema de hoje" vai torcer o nariz e chamar de legado. Entender o problema do passado e o de hoje e entender como mover esse código para frente sem "recomeçar do zero" são as ferramentas que vão ajudar a entregar valor de verdade.

Quais fontes você usa para se especializar? Blogs, livros, canais do Youtube.

Desde cedo em minha carreira eu aprendi a dar valor a comunidades, conferências e uma boa rede de contatos. Às vezes pego um livro para ir mais a fundo em um assunto, mas invariavelmente chego nesses livros ou assuntos em conversas com colegas de profissão, seja em um meetup, um bar ou uma conferência.

Onde as pessoas podem te encontrar? Site, Linkedin, Twitter, etc. 

Basicamente é só procurar por rdohms em qualquer canto que acha, mas ficam esses contatos:

• Linkedin: https://www.linkedin.com/in/rafaeldohms/

• Twitter (ou X, ou já morreu): @rdohms

• Mastodon: https://phpc.social/@rdohms

• http://doh.ms