Mauricio Linhares

Technical Lead e Senior Engineer II na equipe de Edge/Platform Services, Digital Ocean

Conheci o Mauricio graças ao seu papel no podcast Hipsters.tech e desde então me tornei grande fã. Sem mais delongas, fique com a entrevista com o grande Mauricio Linhares.

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

Hoje eu estou como Technical Lead e Senior Engineer II na equipe de Edge/Platform Services. A maior parte do trabalho é trabalhar em ou criar novas plataformas que as equipes internas possam usar pra escrever aplicações de forma mais eficiente. Somos responsáveis por vários tipos de plataformas diferentes, o API gateway, servidores de Redis e Kafka internos, aplicações de autenticação, notificações via email ou websockets e coisas relacionadas. 

No geral são necessidades que são compartilhadas por várias equipes de produto dentro da empresa e não faria sentido ficarem de responsabilidade de uma equipe de produto específica porque é uma coisa que praticamente todas as outras equipes dependem diretamente. Estamos sempre procurando encontrar problemas e espaços onde existe uma necessidade para várias equipes e criando uma plataforma que as equipes possam usar em vez de ter que manter diretamente.

Então o trabalho vai de escrever softwares novos, fazer implantação e operar software de caixinha (como Kafka e Redis), trabalhar com outras equipes nas necessidades que eles tem hoje ou vão ter no futuro e garantir que todos esses sistemas funcionem corretamente no ambiente distribuído que temos hoje.

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?

O impacto principal é o de poder ajudar a definir as plataformas e soluções que outras equipes da empresa vão trabalhar. Como muito do trabalho é rodar ou escrever sistemas que vão ser compartilhados com equipes diversas, precisamos coletar informações e tomar decisões considerando como isso vai impactar e influenciar o caminho que as outras equipes vão seguir na hora de escrever as aplicações.

Muitas vezes as equipes decidem ou não por usar uma tecnologia colocando mais peso em coisas que nós já fornecemos internamente porque isso significa menos trabalho pra eles e isso implica que o nosso fornecimento têm que também ajudar quem está usando esses sistemas a usá-los corretamente. Na maior parte desses casos nós direcionamos as equipes no caminho das melhores práticas no uso dessas plataformas, adicionamos alertas e métricas automáticas pros casos de problema mais comuns e incluímos ferramentas e visualizações pra que quem está usando essas plataformas consiga entender o que está acontecendo com o uso de forma self-service em vez de ser uma coisa que exija contato direto com a equipe.

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?

Acho que atualmente tá meio que 60/40 pra liderar e codar por causa de compromissos internos de mentoria e o trabalho que tenho feito em outra equipe pra ajudar nos processos e no onboarding de outras pessoas, mas no geral eu ainda trabalho bem mais escrevendo código do que liderando. 

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

A semana começa com reuniões pra definir as prioridades da semana, discutir coisas externas a equipe que vão afetar o nosso trabalho. Especificamente pra mim também preciso preparar pras duas mentorias que estou fazendo esse semestre. O resto da semana é distribuído em trabalhar nas coisas acordadas no início da semana, participar das reuniões com grupos de trabalho e lidar com walk-ins que possam acontecer e sejam prioritários pra semana. 

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?

O sucesso no geral é definido pelos objetivos que são definidos nos trimestres, então o foco é atingir esses objetivos específicos, que no geral são de alto nível, como entregar uma funcionalidade específica ou uma nova plataforma. Definitivamente mudou tanto com a posição como também com o amadurecimento da empresa, hoje o foco é muito mais em pensar em objetivos de negócio e o impacto que essas coisas vão causar na empresa em si do que simplesmente entregar artefatos de código.

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?

No geral aqui "quem faz, define". Então quando a equipe abre um RFC pra discutir alguma coisa nova que precisa ser implementada ela vai pedir feedback das outras equipes mas se espera que a equipe em si já tenha uma idéia da arquitetura que a solução vai seguir. Então não existe um "grupo" de arquitetura que define essas coisas mas sim um ambiente de discussão do que as equipes estão pensando em fazer na forma de arquitetura. 

Então dentro da equipe e em trabalhos que afetam a equipe diretamente eu participo das definições, mas não é comum participar disso em equipes não relacionadas, até porque seria difícil tomar decisões ou definir arquiteturas pra problemas com os quais eu não me envolvo no dia a dia. E as decisões no geral são tomadas em consenso dentro da equipe, dificilmente uma pessoa sozinha toma todas as decisões sem ter discutido isso antes com o resto das pessoas afetadas pela mudança.

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?

Empatia. Entender que as coisas existem porque em algum momento alguém chegou a conclusão de que aquela era a melhor solução no momento. Entender que existem contextos diferentes e que uma decisão que parece ruim hoje pode ter sido a melhor no passado ajuda a brigar menos e procurar mais encontrar soluções em vez de somente reclamar de problemas existentes.

Escrever. Quanto mais você sobe e precisa ter mais impacto, mais você precisa ser capaz de transformar as idéias na sua cabeça em textos simples, claros e diretos sobre o que você quer fazer. Escrever um RFC com uma proposta pra resolver um problema complexo que consiga explicar o problema pra diversidade de pessoas que precisam ler e entender o material é uma qualidade imprescindível pra qualquer desenvolvedor que quer continuar crescendo e tendo mais impacto na carreira.

Delegar. É impossivel liderar todos os esforços e fazer todos os trabalhos sozinho. É importante que a pessoa entenda que deve haver espaço pra repassar o trabalho e entregar soluções pra outras pessoas, seja pra fazer com que as coisas continuem acontecendo como também pra fornecer oportunidades pra que outros possam crescer também dentro do ambiente de trabalho. Desenvolvedores que desejam crescer precisam também gerar demanda pra que quem está nos seus arredores cresçam também e fazem isso delegando trabalho importante e de alto impacto pra essas pessoas. 

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

Internamente estamos sempre trabalhando dentro da equipe pra fazer com que todo mundo possa fazer todos os trabalhos e se desenvolver de forma completa, então se espera que todos façam mentoria interna na equipe o tempo todo. Também temos um programa semestral de mentoria, onde atualmente faço mentoria de duas pessoas. 

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?

Promoções aqui no geral acontecem quando você está executando "no próximo nível" então no geral são sobre o conjunto de atividades que você teve durante o ano. Dificilmente um projeto só seria um objetivo grande o suficiente, a não ser que realmente seja uma coisa de longo prazo e que impacta uma parte considerável do negócio, mesmo nesse caso o projeto provavelmente seria dividido e avaliado em milestones menores. 

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 acho que isso é uma decisão pessoal e de carreira de cada pessoa. A minha decisão foi de que ainda tenho muito a aprender na carreira técnica e queria investir mais nisso antes de ir pro caminho da gestão. Imagino que eventualmente vou virar gestor até mesmo pela progressão natural de liderança que você precisa pra causar mais impacto no trabalho mas vejo isso mais como um caminho natural do que como uma decisão que precisa ser tomada num momento ou em outro. Eu ainda me vejo trabalhando com desenvolvimento por mais alguns anos até que seja o momento ideal de migrar pra gerenciar pessoas. 

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

Focar na importância do trabalho pra solucionar problemas reais que o negócio está enfrentando. Cada decisão e objetivo de alto nível deve estar relacionado a algum impacto real que vai ser sentido na área e você deve ser capaz de explicar esse impacto e como ele vai melhorar o dia a dia do trabalho. Criar esse relacionamento do trabalho que está sendo feito com resultados reais conecta o trabalho e cria um senso muito melhor de controle e de direcionamento do que você está fazendo.

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

No geral eu acompanho HackerNews e sigo pessoas conhecidas da comunidade no twitter e tiro minhas recomendações de lá. Sendo velho, ainda prefiro ler livros mas assisto palestras e acompanho eventos de tecnologia no Youtube também.

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

https://twitter.com/mauriciojr 

https://www.linkedin.com/in/mauriciolinhares/ 

https://hipsters.tech/