I have been working in startups since 2004. I spent 10 years at Apontador/MapLink and was part of Creditas (fintech last valued at $4.8bi) from its early days. Initially, as an Advisor, I hired the first software engineers for Creditas. As the business developed, I joined the project full-time as VP. I scaled the technology team to 150 people and later led international expansion and new product initiatives. After completing the full structuring of Creditas' tech department, I left in 2022 and, after a sabbatical, started working as an independent consultant in 2023. I write short texts about Leadership and Management
Vejo muitos líderes vivendo o dilema de serem muito bonzinhos ou muito duros. Como quase tudo na vida, é importante encontrar um equilíbrio e evitar os extremos. Você não precisa ser aquele líder que todos odeiam, nem precisa ser amado por todos o tempo todo. Busque sempre ser Agradável e Exigente. Um abraço, Leo
En enero de 2024, escribí este post en LinkedIn anunciando mi decisión de seguir oficialmente como consultor independiente de tecnología. Ahora, un año después, quiero compartir con ustedes cómo fue mi 2024: De los 8 servicios iniciales que imaginé ofrecer, 3 destacaron: Mentoría para CTOs Diagnóstico de equipos de Producto y Tecnología CTO-as-a-Service (Transición de CTOs) Además, surgió una cuarta demanda: head hunting. Tuve la oportunidad de ayudar a empresas a encontrar a las personas...
Em janeiro de 2024, escrevi este post no LinkedIn anunciando minha decisão de seguir oficialmente como consultor independente de tecnologia. Agora, um ano depois, quero compartilhar com vocês como foi o meu 2024: Dos 8 serviços iniciais que imaginei oferecer, 3 se destacaram: Mentoria de CTOs Diagnóstico de Times de Produto e Tecnologia CTO-as-a-Service (Transição de CTOs) Além disso, uma quarta demanda emergiu: head hunting. Tive a oportunidade de ajudar empresas a encontrar as pessoas...
Muchos líderes de ingeniería no saben responder a esta pregunta o creen que un sprint del equipo no tiene costo alguno. Esto reduce el nivel de exigencia y evita cuestionamientos sobre el verdadero valor que el equipo está entregando. Veamos un cálculo simple y aproximado: si tu equipo tiene 1 Product Manager, 1 Engineering Manager y 4 desarrolladores dedicados, con un salario mensual promedio de USD$1,800 (lo cual implica un costo real para la empresa de USD$3,100 incluyendo impuestos,...
Muitos líderes de engenharia não sabem responder a essa pergunta ou consideram que um sprint do time é de graça. Isso faz com que não tenham o nível de exigência necessário e não se questionem o tempo todo sobre qual o valor que o time está realmente entregando. Vamos a uma conta simples e aproximada: se sua equipe tem 1 Product Manager, 1 Engineering Manager e 4 desenvolvedores dedicados, todos contratados no regime CLT, com um salário médio de R$10.000 (o que implica um custo real de...
Es común ver situaciones en las que los miembros del equipo se sienten insatisfechos con algo y terminan dirigiendo toda su frustración hacia el liderazgo. Pero creo que construir una empresa exitosa es una responsabilidad compartida, que no recae solo en los líderes o el equipo directivo, sino en todos los colaboradores, quienes pueden contribuir con pequeñas mejoras en el día a día. Cuando alguien está insatisfecho, esa persona es muchas veces la más indicada para resolver el problema, ya...
É comum ver situações em que membros da equipe se sentem insatisfeitos com algo e acabam direcionando toda a sua frustração para a liderança. Mas acredito que construir uma empresa de sucesso é uma responsabilidade compartilhada, que não cabe só aos líderes ou ao C-Level, mas a todos os colaboradores, que podem contribuir com pequenas melhorias no dia a dia. Quando alguém está insatisfeito, essa pessoa é muitas vezes a mais indicada para resolver o problema, já que se importa mais com ele do...
Una queja común entre los nuevos líderes de equipo que antes eran devs es la sensación de que “no hicieron nada” al final del día. Cuando les pregunto qué hicieron, la respuesta suele ser algo así: “Hice 1-on-1s con dos miembros del equipo: ayudé a uno con problemas de gestión de tiempo y medité un conflicto de otro con un área asociada. Participé en reuniones para definir OKRs y ayudar al PM a detallar historias. Analicé métricas e identifiqué un cuello de botella que nos estaba retrasando....
Uma queixa comum entre novos líderes de equipe que eram devs é a sensação de que "não fizeram nada" ao fim do dia. Quando pergunto o que fizeram, normalmente a resposta é algo assim: "Fiz 1-on-1s com dois liderados — ajudei um com questões de gerenciamento de tempo e mediei um conflito de outro com uma área parceira. Participei de reuniões para definir OKRs e ajudar o PM a detalhar stories. Analisei métricas e identifiquei um gargalo que nos atrasava. Só consegui programar no fim da tarde." E...
Si eres dev y no estás de acuerdo con que un ítem de trabajo de tu backlog vaya a generar el resultado esperado: sí, debes hablar con la persona de producto sobre esto. ¿Será que tiene una lógica que no quedó clara para el equipo, o estás analizando el problema de una manera diferente que podría hacerle cambiar de opinión? si aún así no estás de acuerdo, ofrece alternativas sobre cómo validar esta hipótesis de una manera más rápida y económica que construir la funcionalidad completa. Si eres...
Se você é dev e não concorda que um item de trabalho do seu backlog vai gerar o resultado de trabalho esperado: sim, você deve conversar com a pessoa de produto sobre isso. Será que ela tem um racional que não ficou claro pro time ou será que você está analisando o problema de um outro jeito, que pode fazê-la mudar de ideia? se ainda assim você não concordar, ofereça alternativas sobre como validar essa hipótese de um jeito mais rápido e barato do que construir a funcionalidade inteira. Se...