O entrevistado desta edição é um dos profissionais que eu mais admiro. Quando entrei em contato com o Thiago para convidá-lo para o projeto fiquei um pouco nervoso mas ele foi muito solícito e entregou não uma entrevista, quase um MBA!
Pegue um café e comece a fazer anotações, pois você tem em mãos um material incrível tanto para líderes quanto para pessoas Staff+.
No momento, estou em um período sabático, depois de 20 anos na área de desenvolvimento de software e os últimos 11 nos EUA em posições de liderança de engenharia (American Express, Apple e, recentemente no Nubank).
Na minha última posição, como Diretor de Engenharia no Nubank, escalei o Time de Mobile Platform de ~30 para 100+ pessoas, consolidei a adoção da arquitetura de Server-Driven UI como padrão, redesenhei processos e conduzi reestruturações profundas que aumentaram a performance do app, a governança técnica e colaboração entre BUs melhorando a experiência de mais de 100M de usuários.
Ao longo dos últimos 20 anos, passei por ThoughtWorks, American Express, Apple e Nubank - sempre no desafio de escalar times de engenharia e ajudar pessoas a crescerem para níveis Staff+ e EM+.
Paralelo a isso, sou criador de conteúdo (podcast Engineering Advice You Didn’t Ask For, LinkedIn e Substack), palestrante (QCon, InfoQ Dev Summit) e organizador de comunidade (Engineering Leadership NYC).
Hoje escrevo, dou palestras, facilito painéis e faço aconselhamento em estruturação de organizações de engenharia, equipes de plataformas e carreira Staff+/EM+.
Três desafios específicos que aparecem sempre na minha experiência:
1. O desafio da ambiguidade: Staff+ opera em território de problemas mal-definidos. O nosso papel como liderança não é decodificar o problema para o Staff+, é ajudá-los a desenvolver a musculatura de julgamento técnico e político necessária para navegar sozinhos. É desconfortável porque você não pode só “dar a resposta”, isso cria uma relação de dependência e o líder acaba virando o gargalo e o Staff+ fica com baixa autonomia.
2. O desafio da paciência: Staff+ trabalham em escalas de tempo mais longas. Enquanto existe muita pressão organizacional nos OKRs e projetos de curto-prazo, eles estão construindo sistemas que vão dar retorno em 12-18 meses. Você precisa protegê-los da ansiedade organizacional por resultados imediatos, sem necessariamente blindá-los. Staff+ também precisam desenvolver o discernimento para saber quando seletivamente comprometer no longo-prazo para ajudar o time e a organização a curto-prazo.
3. O desafio do ego: Uma das transições mais desconfortáveis para pessoas Staff+ é aceitar que você não deve mais ser o cérebro técnico da sala o tempo todo e que isso é bom. Muitos engenheiros chegam ao nível de Staff porque eram os experts, as referências, os “heróis” resolvedores de tudo. Mas, ironicamente, permanecer nesse modo é exatamente o que bloqueia o crescimento a partir desse ponto.
O verdadeiro desafio é fazer as pazes com o fato de que, em uma organização saudável, outras pessoas vão saber mais do que você em áreas críticas. E o seu papel não é competir com elas, é inspirar e orquestrar esses talentos e criar o espaço e o sistema para que floresçam. É sobre resiliência e sustentabilidade organizacional e não sobre destaque individual.
Quanto às características, depois de ajudar dezenas de engenheiros a chegarem no nível Staff+ (e ver outros estagnarem), identifiquei três expectativas universais (que eram verdade para Staff+ em todas as empresas por onde passei):
1. Raio de impacto (Blast Radius): Seu impacto precisa ser amplo e/ou profundo. Você resolve problemas que afetam múltiplos times/profundidade organizacional (impacto horizontal), ou que têm profundidade técnica brutal (impacto vertical), ou que são uma mistura dos dois.
Se você ainda está resolvendo problemas de um time só, você não é Staff+ ou vai ter sérios problemas em justificar o seu impacto nesse nível no próximo ciclo de avaliação de performance.
2. Planejamento e execução em múltiplas escalas de tempo (Multi-Scale Planning): Você precisa operar em múltiplas escalas de tempo simultaneamente: o que importa hoje, nesta sprint, neste quarter, e ao longo do(s) ano(s).
Engenheiros que operam só na lógica da próxima sprint não chegam ao nível Staff+.
3. Escopo de atuação e nível de autonomia (Ownership Progression): Seu papel precisa evoluir de Executor para Explorador e, por fim, Orquestrador:
Executor (Solver): Recebe um problema e resolve.
Explorador (Finder): Identifica problemas e oportunidades antes que virem crises.
Orquestrador (Driver): Define e direciona quais problemas valem resolver, alinhando estratégia técnica e de negócio.
Staff+ operam majoritariamente como Exploradores e Orquestradores. Se você ainda depende do seu manager para te dizer o que fazer, você ainda não está pronto para esse nível.
Quanto às habilidades práticas, vejos as seguintes como críticas para pessoas em cargos staff+:
1. Clareza, organização e poder de síntese: Staff+ precisa traduzir complexidade em clareza. Você pega um problema gigante com 15 variáveis, 8 stakeholders, e 3 meses de contexto - e consegue destilar isso em uma página que faz o caminho parecer inevitável. Isso se manifesta em RFCs bem escritas, ADRs que as pessoas conseguem entender 6 meses depois, e tech talks que deixam a audiência pensando “óbvio, por que não fizemos isso antes?”
Se você precisa de 40 slides e 3 reuniões para explicar sua proposta, você ainda não tem essa habilidade.
2. Julgamento técnico, de negócio e organizacional: Essa é a habilidade mais difícil de desenvolver e a mais importante para Staff+. É saber:
Quando fazer review mais alto-nível e quando fazer um review profundo
Quando buscar consenso e quando tomar decisão de forma unilateral
Quando priorizar velocidade e quando priorizar qualidade
Quando simplificar e quando dizer “não”
Quando shippar “um pouco cedo” e quando esperar por uma solução mais robusta
Isso não se aprende lendo blogs. Isso vem de muitos anos errando e acertando.
3. Navegação de conflito: Staff+ trabalha em problemas que cruzam múltiplos times, o que significa múltiplas opiniões, prioridades conflitantes, e egos envolvidos. Você precisa saber alinhar stakeholders sem escalar o drama. Isso significa entender os incentivos de cada lado, encontrar win-wins quando possível, e saber quando escalar a decisão para cima.
Se toda discordância técnica vira guerra política, você não está pronto ainda.
4. Multiplicação de impacto: Staff+ que tenta fazer tudo sozinho cria gargalo organizacional. Você precisa multiplicar impacto através de outros:
Mentoria de engineers mais júniors (ensinar a pescar)
Sponsorship — não só mentoria, mas colocar eles nas reuniões deles, abrir portas, fazer conexões
Delegação orquestrada — delegar com contexto, alçada e checkpoints claros
Heroísmo individual não escala. Construir sistemas e pessoas que entregam sem você escala.
5. Profundidade seletiva: Staff+ precisa saber quando entrar fundo e quando ficar mais na superfície. Entrar fundo quando o sinal real se perde no ruído, quando ninguém mais tem contexto suficiente, quando a decisão é crítica, quando o risco é alto. Sair rápido assim que o contexto está estabelecido e o time pode seguir sozinho para você não virar gargalo.
O erro comum é ficar superficial demais (e perder credibilidade técnica) ou profundo demais em tudo (e virar o gargalo).
A boa notícia é que todas essas habilidades são treináveis. Mas requerem tempo, feedback honesto, e muita prática deliberada.
Inclusive, alguns meses atrás escrevi sobre isso no Linkedin: Why have you been stuck at the Senior level for so long? (or, Top Drivers of Staff-Plus Promotions vs. Top Reasons Cases Stall):
Muito! E falo isso com base na minha própria experiência dos últimos anos. Dar palestras, facilitar painéis e participar de podcasts técnicos te obrigam a formalizar pensamento, testar frameworks com pares e praticar comunicação executiva — habilidades críticas para Staff+ que muitas vezes ficam subdesenvolvidas quando você passa anos focado só em código na bolha da sua empresa.
Como facilitador e organizador de quase uma dúzia de meetups do Engineering Leadership NYC nos últimos 2 anos, eu mesmo refinei meus frameworks de delegação, influência e feedback debatendo com Staff+ e outros líderes (CTOs, Diretores, Gestores) de contextos completamente diferentes (startups seed stage, Big Techs, grandes corporações tradicionais).
Pra mim, o valor de participar eventos é triplo:
1. Organização do pensamento e destilação de conhecimento: Quando você precisa explicar um problema, uma ideia ou um conjunto de boas práticas complexas para 100 pessoas em 20 minutos, você precisa destilar anos de experiência tácita em um framework prático que outros conseguem entender e usar.
Cada painel que organizei me obrigou a estruturar melhor meu próprio pensamento. Escrever uma talk é uma “forcing function” para transformar conhecimento tácito (aquilo que você sabe fazer mas não sabe explicar) em conhecimento explícito (frameworks que outros podem aplicar).
A consequência prática: você cria os seus próprios frameworks e se torna melhor em comunicação executiva. E Staff+ que não consegue articular decisões técnicas em narrativas claras tem teto de impacto.
2. Exposição a contextos diferentes: Staff+ vive no perigo da “armadilha da bolha” — você fica tão expert no jeito que sua empresa resolve problemas que perde perspectiva do que funciona (ou não funciona) em outros lugares e contextos.
Eventos te expõem a, por exemplo, como uma big-tech como a Apple aborda a criação de uma equipe de plataforma vs. como startups fazem vs como scale-up brasileira faz. Isso expande drasticamente seu repertório de soluções. Quando você volta pro seu contexto, consegue adaptar padrões, pensar fora da caixa e reutilizar soluções que funcionaram em escala completamente diferente da sua.
A consequência prática: você para de reinventar a roda. Metade dos “problemas impossíveis” que seu time enfrenta já foram resolvidos por alguém em outro contexto. É verdade que você também consegue essa exposição lendo livros e assistindo palestras no youtube, mas eventos te conectam com essas pessoas. Às vezes uma troca de 5 ou 10 minutos com alguém após a palestra, destrava algo que levaria meses para você descobrir sozinho.
3. Networking de longo prazo: Várias oportunidades interessantes que apareceram na minha carreira vieram através de pessoas que conheci em eventos.
Staff+ precisa pensar 10-20 anos à frente, não apenas no próximo ciclo de performance ou no seu próximo emprego. Sua rede de relacionamentos (principalmente fora da sua empresa atual) é sua rede de segurança quando as crises de mercado acontecem, empresas fazem layoffs, ou você quer pivotar de carreira.
A consequência prática: quando você precisa de ajuda — seja técnica (como vocês resolveram sharding?) ou de carreira (vale a pena aceitar essa oferta?) ou de cultura (como é mesmo trabalhar pra essa empresa? Como é o work-life balance? como os executivos tratam os funcionários?) — você tem um grupo de pessoas que confiam em você e vão te responder informalmente até mesmo coisas confidenciais que você nunca teria acesso porque confiam em você, já falaram com você, já se beneficiaram de algum insight seu…
Sim, e a diferença é substancial. O desenvolvimento de carreira de Staff+ exige uma abordagem completamente diferente de ICs mais júniors.
Com Sênior e abaixo, eu atuo mais como gestor clássico: defino escopo de atuação esperado, delego tarefas alinhadas com crescimento, dou feedback frequente sobre execução, e ajudo a ajustar o plano conforme necessário. É uma relação mais direta e mais constante.
Com Staff+, eu atuo menos como “gestor clássico” e mais como um conselheiro estratégico e um consultor organizacional. A mudança fundamental é: eles não precisam de mim pra dizer o que fazer, eles precisam de mim para ajudá-los a navegar como maximizar impacto na escala organizacional.
Na prática, isso se traduz em duas diferenças principais:
1. Staff Projects: Este é provavelmente o conceito mais importante que refinei nos últimos anos: todo Staff+ deve ter um Staff Project bem definido por ciclo.
Um Staff Project não é “mais uma task” ou “mais uma expectativa de entrega”, é uma iniciativa estratégica que:
Tem impacto organizacional (afeta múltiplos times ou tem profundidade técnica brutal)
Demonstra as três expectativas de Staff+: Blast Radius, Multi-Scale Planning, e Ownership Progression (de Solver pra Finder pra Driver)
É mensurável em termos de negócio, não apenas em termos técnicos
O meu papel como líder é ajudar a escolher o Staff Project certo (alinhado com estratégia da empresa + área de força deles), conectá-los com stakeholders certos, e ajudar a remover bloqueios organizacionais que eles não conseguem remover sozinhos.
2. Criação da mentalidade de “First Team”: Com Staff+, eu invisto pesado em criar senso e mentalidade de “your peers as your first team” entre eles. A ideia de que o grupo de pares: outros líderes técnicos + managers é o primeiro time deles, não o seu grupo de squads, seu escopo principal ou OKRs.
Staff+ que só pensa no benefício do seu próprio “reino” (seus próprios squads) tem teto de impacto. Isso cria dificuldade de pensar macro na organização, navegar ambiguidade e fazer trade-offs — skills críticas para o nível. Os melhores Staff+ pensam em como suas decisões afetam toda a organização — e isso só se desenvolve quando eles têm relacionamento forte com outros líderes técnicos.
A consequência prática disso como líder é que você cria uma cultura de liderança técnica distribuída, não centralizada em você. Quando você tira férias ou sai, a organização continua funcionando porque você não precisa fazer “baby sitting” entre os staffs e porque você não é o gargalo.
Inclusive, escrevi sobre isso em detalhes no artigo da InfoQ: “How to Scale Your Impact at the Staff-Plus Level“ — lá eu quebro exatamente o conceito de Staff Projects, o flywheel de crescimento contínuo, e os padrões de comportamento que levam a promoções bem-sucedidas vs os que bloqueiam.
Sim. Baseado na minha experiência dos últimos 5 anos liderando dezenas de Staff+ (e vendo muitos líderes errarem nisso), aqui vão três práticas que me ajudaram muito a escalar:
1. Peça One-Pager antes iniciativas grandes: Antes de um Staff+ começar qualquer projeto de 3+ meses, peça um documento de uma página (o famoso “one-pager”) com:
Problema em linguagem de negócio: “Qual KPI do negócio isso move? Quanto?”
Contexto e aposta técnica: Por que agora? Por que essa solução?
Trade-offs explícitos: O que você está otimizando? O que está sacrificando?
Definição de sucesso e não-objetivos: O que conta como vitória? O que está fora do escopo?
Isso força a clareza de pensamento antes de investir meses de trabalho. Metade dos projetos que falham morrem porque o problema nunca foi bem definido.
2. Alinhe autoridade com responsabilidade: É verdade que a matriz RACI ajuda muito aqui, mas um erro muito comum que eu cometi por muito tempo e vejo vários líderes errando nisso é: delegar ownership (R - responsability) sem dar poder de tomada de decisão (A - accountability). Se você diz “você é owner de X”, mas continua tomando decisões finais, revisando tudo, ou exigindo aprovação para cada mudança, no fundo, você não delegou nada. Você criou um teatro de empoderamento.
Na prática: quando delegar, seja explícito sobre:
Quais decisões eles podem tomar sozinhos?
Quais precisam de alinhamento?
Quais decisões só você pode tomar como líder?
Quem eles precisam informar ou consultar antes de seguir em frente?
Staff+ sem autoridade real vira gargalo disfarçado de líder, um líder sem poder de decisão ou autoridade nenhuma. Com o tempo, eles param de tomar iniciativa porque aprenderam que “ownership” ali não significa nada. Não se sentem realmente donos: responsible + accountable.
3. Use o framework L-N-O para calibrar a alocação de tempo: Roubei isso do Shreyas Doshi e uso muito nos 1:1s com os Staff+. É uma maneira simples de priorizar tarefas com maior impacto ou leverage (poder de alavanca):
L: Leverage: Atividades com retorno exponencial (mentorship, platform work, RFCs, design docs)
N: Neutral: Retorno linear (code review, incident response, bug fixes)
O: Overhead: Retorno negativo (reuniões desnecessários, context switching, retrabalho)
No 1:1, revise onde o Staff+ tá gastando tempo. Se mais de 30% está em Neutral/Overhead, você tem problema. Staff+ deveria viver em Leverage (mais de 50% do tempo), senão você tem Senior Engineer caro, não Staff+.
Com isso, você rapidamente identifica se Staff+ está virando “firefighter heroico” (Neutral/Overhead alto) ou se está realmente multiplicando impacto (Leverage alto).
O princípio maior: liderar Staff+ não é sobre controle. É sobre criar condições para que eles multipliquem impacto através de decisões técnicas sólidas, alinhamento estratégico, e delegação sistemática. E o principal: fazer isso com uma motivação alta.
Sim, várias! Os Staff+ que mais se destacam sabem usar o manager como multiplicador de impacto.
Seguem três sugestões que eu via com frequência em Staff+ de alta performance em relação a sintonia deles com seus líderes:
1. Dê visibilidade constantemente, evite ao máximo surpresas: Nada destrói confiança mais rápido que seu manager descobrir algo crítico através de outra pessoa.
Errado: Trabalhar 3 meses num RFC e dropar no Slack da org sem aviso nenhum.
Certo: “Identifiquei problema X. Vou investir 2 semanas explorando. Te atualizo antes de socializar mais amplamente a solução que vou propor.”
Você mantém autonomia, dá visibilidade e recebe em troca contexto político que não tem (”Timing ruim, VP cancelou iniciativa similar” ou “Perfeito, alinhado com prioridade Q3”) e micro-feedbacks, algumas dicas ou “toques”que não teria caso não tivesse dado visibilidade do seu plano e intenção.
Tem um texto excelente que ilustra esse ponto muito bem que um dos Principal Engineers que eu trabalhava no Nubank jogava nos canais pelo menos uma vez por mês para lembrar a galera: Don’t ask forgiveness, radiate intent.
2. Traga opções ranqueadas, não perguntas abertas:
Errado: “O que você acha que devemos fazer sobre latência do serviço X?”
Certo: “Identifiquei 3 possíveis abordagens:
Quick fix (2 semanas, 30% melhoria, alto tech-debt)
Refactor moderado (2 meses, 70% melhoria, sustentável)
Rearquitetura completa (6 meses, 95% melhoria, impacto platform-wide)
Recomendo #2 porquê [contexto]. Porém, precisaríamos de metade da equipe dedicada a isso por 2 meses sem feature work, o que muito provavelmente atrasaria o projeto Z em 3 semanas. Faz sentido?”
Você demonstra maturidade técnica e de negócio e deixa claro os trade-offs — exatamente o que se espera de Staff+.
3. Use seu gestor como “parceiro de treino”, não como aprovador/revisor:
Os melhores Staff+ não vêm pedir aprovação — vêm testar raciocínio, fazer brainstorming de ideias. “Estou pensando em propor solução X. Aqui estão meus assumptions. Você vê algum blind spot? Stakeholder que eu deveria consultar antes?”
Isso transforma 1:1 de status report em uma discussão estratégica. Seu manager investe mais em te ajudar porque você usa o tempo dele para pensar e pegar feedback, não para reportar.
Se seu gestor não entende o valor do que você faz, em 99% das vezes, o problema é sua comunicação, não a inteligência dele. Staff+ precisa traduzir impacto técnico em linguagem de negócio. Se você não consegue, você tem um gap crítico.
Sim, e o curioso é que foi o mesmo conselho, repetido de uma forma ou de outra por diferentes líderes e pares que tive por mais de 11 anos.
> “Seja mais assertivo. Fale o que você realmente pensa. Discorde abertamente quando necessário.”
O problema é que eu achava que já estava fazendo isso. Quando eu discordava de uma decisão, não criava conflito. Eu era racional, educado, ponderado. Nunca batia de frente. E por anos, interpretei isso como profissionalismo: como autocontrole. Mas, o que ninguém me dizia diretamente (e talvez nem eu soubesse explicar) é que, muitas vezes, isso era passivo-agressividade camuflada de maturidade.
Você engole uma ideia maluca que vai afetar você e seu time. Fica quieto na reunião. Mas depois… aparece. Na reação no Slack. No desânimo. Na ironia. Na fofoca. Na falta de comprometimento com algo que você nunca comprou — mas também nunca disse que não comprava.
Foi só em 2023 que eu consegui, de fato, entender e mudar esse padrão. O livro The Assertiveness Workbook me ajudou a nomear o que eu estava vivendo:
> “Assertiveness isn’t about building a good disguise. It’s about developing the courage to take the disguise off.”
(”A assertividade não se trata de criar um bom disfarce. Trata-se de desenvolver a coragem para abandonar o disfarce.”)
> “The passive style is primarily avoidant — the flight response. The aggressive style is the fight response. Passive-aggressive is both. Assertiveness is neither. It’s calm, clear, and creative.”
(> “O estilo passivo é principalmente evitativo — a resposta de fuga. O estilo agressivo é a resposta de luta. O estilo passivo-agressivo é ambos. A assertividade não é nenhum dos dois. É calmo, claro e criativo.”)
> — *The Assertiveness Workbook*
Assertividade não é bater de frente. Não é causar barraco. É ter coragem de ser claro. É dizer: “Eu não concordo com isso, e aqui está o porquê.” Mesmo que cause desconforto. Mesmo que vá contra o consenso aparente.
E depois, sim, se for decidido seguir outro caminho ou um caminho intermediário — aí entra o famoso “Disagree and Commit”: você então aceita como se fosse a sua própria ideia, porque tudo que podia ser dito, foi. Tudo foi considerado, foi. Nada ficou não dito.
Tem um texto muito legal sobre isso do David Anderson que enviei para vários dos meus Staffs+ (que tinham problemas similares) e que ilustra bem o problema da passividade-agressiva e como ela quase que impossibilita o disagree and commit real de acontecer (causando uma estagnação na carreira de muitos que não conseguem evoluir nessa questão)
> “There is not a leadership principle named disagree and then reluctantly move forward. When you commit, you need to take that decision as your own.”
(> “Não existe um princípio de liderança chamado discordar e depois seguir em frente com relutância. Quando você se compromete, precisa tomar essa decisão como sua.”)
> “In an interview: “I told them that we shouldn’t build the feature that way, but they wouldn’t listen. So I built the feature that way, even though I repeatedly said this was stupid. Sure enough, I was right, it didn’t work right, and it was a huge disaster. Hah!”
In this type of example, it is a triple failure on your part. You failed to influence your team to do the right thing. What you built failed. And you failed to own your decision. A huge pile of fail.”
(> Em uma entrevista: “Eu disse a eles que não deveríamos desenvolver a funcionalidade daquela forma, mas eles não me ouviram. Então eu desenvolvi a funcionalidade conforme eles queriam, mesmo tendo repetidamente afirmado que isso era imbécil. E, como esperado, eu estava certo, não funcionou direito e foi um grande desastre. Hah!”
Nesse tipo de exemplo, trata-se de um triplo fracasso da sua parte. Você falhou em influenciar sua equipe a fazer a coisa certa. O que você construiu falhou. E você falhou em assumir a responsabilidade pela sua decisão. Um grande fracasso.”)
> “Triple failure: failed to influence, failed to succeed, failed to own.”
> — David Anderson on Disagree and Commit — Getting Things Done With Backbone.
Na prática, isso se traduz em frases como:
💬 **Disagree:** “I have concerns about this path. Here’s what I see as risks…”
💬 **Commit:** “Now that we’ve considered what you mentioned/suggested and decided, here’s how I’ll help make it successful.”
💬 **Ask for context (with ownership):** “I’ll own this decision. Can you help me understand X better so I can explain it clearly to my team?”
Esse aprendizado mudou minha liderança. Mas escolhi falar sobre isso aqui porque ele também toca um padrão muito comum entre engenheiros e engenheiras mais introspectivos. A gente engole sapo em silêncio achando que “não vale a pena”. Só que engolir, dia após dia, tem um custo invisível: desgaste emocional, sensação de isolamento, e a falsa impressão de que você está sozinho — quando, muitas vezes, tinha um monte de gente na sala pensando o mesmo.
Assertividade é o caminho do meio entre o silêncio e o embate. E, como diz o livro, “não é sobre controlar os outros — é sobre controlar a si mesmo.”
Leio muito, principalmente livros e artigos (long-form). Tipo, muito mesmo, ~200 livros/ano desde 2014 (já são 1.700+ livros acumulados). Mas, não leio para “completar” livros, abandono a grande maioria nos primeiros 3 capítulos. Leio para construir o que chamo de arquitetura intelectual.
Aqui estão as fontes que mais impactaram meu pensamento sobre liderança e Staff+:
Sobre Gestão:
Mark Horstman - The Effective Manager & The Effective Hiring Manager
Amy Jen Su - The Leader You Want to Be
Claire Hughes Johnson - Scaling People
Sobre Staff+ Engineering:
Will Larson - Staff Engineer, An Elegant Puzzle & The Engineering Executive’s Primer
Tanya Reilly - The Staff Engineer’s Path
Daniel Heller - Building a Career in Software
Sobre Planejamento e Gestão de Projetos:
Daniel Vacanti - When Will It Be Done?
Gojko Adzic - Impact Mapping,
Scott Berkun - Art of Project Management
Sobre Filosofia & Long-term Thinking:
Umberto Eco - How to Write a Thesis
Antonin Sertillanges - The Intellectual Life
Arnold Bennett - How to Live on 24 Hours a Day
The Pragmatic Engineer (Gergely Orosz)
Irrational Exuberance (Will Larson)
Scarlet Ink (Dave Anderson)
Acompanho muitos canais e podcasts também, mas são muitos que ficaria difícil listar aqui. No Youtube, mantenho duas playlists, uma das palestras legendárias (minhas favoritas que estão disponíveis no youtube) e outro com todas as minhas palestras, entrevistas e participações:
Também mantenho várias listas de favoritos que acumulei ao longo dos anos:
Livros técnicos:
Palestras:
Artigos:
Podcasts:
Eu também escuto muito podcasts, e ano passado publiquei a lista dos meus favoritos do ano:
LinkedIn: É onde sou mais ativo - linkedin.com/in/thiagoghisi
Posto sobre liderança, Staff+, desenvolvimento de carreira, times de plataforma, organização de equipes de engenharia, e às vezes threads sobre leitura e aprendizado.
Substack: thiagoghisi.substack.com.
Textos mais longos e inclusive vários guest posts.
InfoQ: Artigos sobre Staff+ e escalar organizações de engenharia. Busque por “Thiago Ghisi” que acha os artigos publicados.
Comunidade: Engineering Leadership NYC. Facilito e co-organizo eventos e painéis mensais sobre liderança em engenharia de software em NYC.
Contato: Me manda DM no LinkedIn — pode demorar, mas respondo.
Nenhuma publicação
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.