Gaspar · Santa Catarina · Brasil
Eu construo sistemas que escalam e times que entregam.
Comecei em suporte técnico, virei desenvolvedor, virei líder e hoje respondo pela tecnologia do produto na Gethub como CTO, sem largar o Rails.
Quem está do outro lado dos dois serviços.
Backend com mais de uma década de estrada. Comecei atendendo usuário por telefone, e-mail e chat, e foi ali que entendi uma coisa que carrego até hoje: o gargalo raramente é o código. É gente, contexto e processo.
Virei desenvolvedor mantendo um ERP em Delphi e ajudando a construir, desde o começo, um SaaS novo em Rails. Depois assumi times, e hoje respondo pela tecnologia do produto na Gethub como CTO, com arquitetura numa mão e 1:1 na outra.
Acredito em DDD pra organizar o domínio, TDD pra dormir tranquilo, e agilidade como cultura, não como cerimônia. Código bom resolve problemas. Time bom resolve qualquer problema.
Números honestos, contados a partir de quando a coisa começou de verdade. Nenhum arredondado para cima.
Não são duas carreiras paralelas. É um serviço só, com dois processos que dividem a mesma memória e caem juntos quando um deles falha.
Cuido do sistema que não pode cair e do time que não pode adoecer.
A carreira versionada como git log, e como no git log a versão mais recente vem primeiro. A versão sobe quando o tipo de problema muda, não quando o cargo muda. Dados reais, HiGestor e Gethub.
Só dá pra ligar os pontos olhando pra trás. Duas árvores que subiram na mesma campanha, cada habilidade abrindo a porta da próxima. Clique numa pra ver quando entrou e o que ela destravou.
Virei líder pelo caminho mais útil que existe: fui o dev que atendia o cliente. Quem já explicou um bug por telefone para um usuário irritado escreve log diferente, nomeia erro diferente e prioriza diferente. Trago isso para dentro do time.
Contexto antes de tarefa. Um time que entende o porquê corrige a rota sozinho quando o cenário muda, e o cenário sempre muda.
Na prática significa três coisas. 1:1 com pauta, semanal, sobre carreira e não sobre status de card. Decisão escrita, porque discussão que só aconteceu no Slack não existe daqui a seis meses. E cadência escolhida: Scrum quando a demanda cabe em ciclo fechado, Kanban quando o fluxo é contínuo e interrompido por suporte. Método é ferramenta, não identidade.
Não delego responsabilidade sem delegar autoridade junto. Quem responde pelo módulo decide o desenho dele, e meu papel é garantir que a pessoa tenha contexto de negócio suficiente para decidir bem. Reviso, questiono e assino embaixo quando dá errado.
Não sou eu falando de mim. É uma recomendação de quem já me liderou.
"Leonardo é um profissional extremamente competente. Tem ótimas habilidades técnicas e também é um ser humano diferenciado. Sabe lidar com pessoas, atuar em equipe e dialogar com os clientes. Sua capacidade de buscar soluções permite que ele contribua na resolução de problemas de uma maneira diferenciada. Muito ético, honesto e dedicado. Foi um prazer imenso trabalhar com ele."
Formação e certificações reais. O que dá lastro ao que está escrito acima.
Aberto a conversa sobre liderança técnica, gestão de times ágeis e back-end em Ruby on Rails. Respondo com leitura honesta, inclusive quando eu não for a pessoa certa para a vaga. Manda o contexto: o problema, o time e o que já tentaram.
Projeto sob medida é pela Innova Plus, minha empresa de desenvolvimento.