Startup CTO's Handbook - Manual para CTOs de Startups
(github.com/ZachGoldberg)- Fornece o conteúdo mais recente do livro Startup CTO's Handbook, e o texto principal pode ser lido em Markdown
- O livro pode ser comprado na Amazon e na Audible
- O link da versão mais recente em Markdown renderizada em PDF está marcado como Coming Soon, e o manuscrito original atualmente existe como uma versão desatualizada no Google doc
- Recomenda-se contribuir com issues e pull requests para refletir adições, mudanças, sugestões e críticas em edições futuras
- A licença permite copiar, modificar e redistribuir, desde que não haja revenda, o nome do autor e os créditos de autoria sejam mantidos, e versões posteriores sejam publicadas sob uma licença semelhante ou idêntica
1 comentários
Opiniões no Hacker News
Há pontos com os quais eu claramente concordo. Por exemplo, sou a favor de gravar todas as reuniões. Mas também há muitas partes com as quais pessoalmente não concordo, como gestão de desempenho[0]
Não é necessariamente uma crítica; quero dizer que a abordagem e o estilo de liderança podem variar conforme a área do problema. Espero que este guia não seja tratado como algo sacrossanto. Se o conteúdo aqui não bater com a sua experiência, recomendo confiar mais na sua própria experiência
[0] https://twitter.com/bcantrill/status/1216491216356823040
Como CTO, não vejo como fazer esse pedido sem coerção
Dito isso, na prática, muitas vezes há lacunas técnicas reais, e acho que, quando o gestor atua como coach, pode acelerar o crescimento e o desempenho de alguém
Aquele lado está falando de gestão de desempenho prospectiva, sobre como melhorar o desempenho daqui para frente. Mas, na maioria das empresas, a avaliação de desempenho é mais uma avaliação retrospectiva, que ranqueia o desempenho passado no processo de distribuição de remuneração e promoções
Processos prospectivos são ótimos, mas, no fim, ainda é necessária alguma avaliação do desempenho passado
Tive a oportunidade de trabalhar com o autor em duas empresas, e é difícil expressar em palavras a diferença que essas coisas fazem quando são implementadas de fato
O impacto não fica restrito ao produto ou à engenharia; ele se espalha pela organização inteira. Qualquer sistema ou recomendação acabará precisando ser adaptado à sua própria organização, mas recomendo aproveitar o máximo possível a forma como Zach ensina
Eu gosto de gravar reuniões. Não para usar como prova quando a equipe começa a procurar culpados, mas porque é realmente bom poder rever reuniões e discussões
Se estou em uma discussão importante ou reunião de alinhamento que exige bastante da minha capacidade, é difícil me concentrar no tema e, ao mesmo tempo, tomar notas e lembrar de tudo. Saber que há uma gravação me permite usar a reunião para focar, fazer boas perguntas e validar premissas
No dia seguinte, posso ouvir a chamada de novo, pausar, ouvir em 2x ou 3x, fazer anotações pessoais, escrever a ata ou um resumo interno, encontrar inconsistências de raciocínio ou rodar uma ferramenta de anotações com IA no meu próprio horário
Também ajuda quando alguém está doente, precisa buscar a sogra no aeroporto, tem outra reunião ao mesmo tempo ou entra na empresa uma semana depois de uma reunião importante de alinhamento. Se a reunião não for importante, é só ignorar; basta ter regras razoáveis de exclusão automática
Eu realmente não acho que as pessoas passem tempo fuçando escondidas em lugares onde não deveriam entrar, então não vejo isso como um grande problema
Reuniões de equipe também tendem a inclinar a conversa para quem se sente mais confiante falando. Isso prejudica especialmente pessoas recém-chegadas ou pessoas cuja língua principal é outra
Não sou contra reuniões em si. Há pessoas que preferem muito mais se comunicar por voz do que por texto, e uma boa equipe deve ser capaz de acomodar as formas de trabalho preferidas de cada integrante
Mas, se uma reunião de equipe é importante e exige bastante capacidade dos participantes, então ela não deveria ser uma reunião. Reuniões só deveriam acontecer quando todos os participantes julgam que uma reunião é o melhor meio para aquela conversa específica
Reuniões são como ficar sentado diante de uma mangueira: você acaba perdendo os detalhes
Migramos para o Google Workspace porque é fácil gravar e pesquisar reuniões. Por exemplo, a gravação fica incorporada ao evento do calendário
Se uma reunião não é importante o bastante para ser gravada, provavelmente também não valia a pena acontecer
Pessoalmente, coloco mais horas por dia do que outras pessoas, mas isso não acontece de forma síncrona. Reuniões importantes podem se sobrepor, e só ler a ata faz perder muitas nuances. Além disso, as pessoas nem leem direito as atas
Mesmo assim, ter a reunião gravada é muito útil porque permite revisar a ata rapidamente e com precisão. Por isso, estou defendendo gravações de reuniões com bastante força
Quanto mais rápido entendermos a causa real, mais rápido poderemos corrigir o problema. Para entender esse conceito e como aplicá-lo à empresa, recomendo muito Extreme Ownership, dos ex-Navy SEALs Jocko Willink e Leif Babin
A participação assíncrona em reuniões é excelente pelos motivos mencionados acima. Ela torna pesquisáveis as informações presentes na reunião. Hoje, reuniões podem receber legendas por processamento de linguagem natural, e esse conteúdo passa a ser encontrável por LLMs
Atualmente estamos treinando um chatbot interno com conteúdo do Confluence e pretendemos expandi-lo para incluir o conteúdo de reuniões gravadas
Fazendo um pouco de divulgação, estou criando uma ferramenta que transforma entradas de várias fontes em insights e tarefas: https://designpro.ai. Já a usei para extrair insights de transcrições de chamadas e sei que funciona de verdade
Tornei-me CTO recentemente, e uma das maiores dificuldades é a comunicação com o CEO. Talvez o livro trate disso, mas li apenas o índice
Nos últimos 8 meses, o CEO não quer reuniões de alinhamento, não quer planejar nada, não quer liderar uma visão e quer se concentrar apenas em killer features
Também não quer criar mockups ou protótipos para testar com usuários e diz que, se for para fazer, precisa ficar bonito. Não quer fazer nada que leve mais de uma semana e também rejeitou reuniões eficazes
O que quero dizer é que justamente as coisas que não estão no livro são as que sinto falta. Para referência, somos apenas 3 cofundadores
O CTO era o “cara de tecnologia” do CEO e, por ser o mais brilhante ou importante entre esses caras de tecnologia, acabou recebendo o título de CTO
É triste dizer isso, mas você precisa considerar a possibilidade de que o CEO esteja vendo você como apenas mais um funcionário com um título bacana. Com essa mentalidade, do ponto de vista do CEO, incluir você nas decisões dele pareceria desperdício
Ainda lembro exatamente da resposta do Marc: “Se há dúvida, não há dúvida”
Sei que é uma decisão grande demais para ser convencida por um comentário qualquer na internet, mas, ainda assim, já se passaram 8 meses. Você provavelmente já tentou tudo que valia a pena tentar para consertar isso
O que ainda falta tentar? Logicamente, o que você espera que aconteça daqui para frente? Você precisa pensar em quanto mais da sua vida pretende investir nessa situação, quando poderia se mudar facilmente para algo produtivo
Falando sério, o que você encontrou agora é justamente o ponto que torna esse trabalho difícil
Primeiro, seria bom marcar 1:1s com outros executivos. Se houver executivos com quem você trabalhe além do CEO, você poderá obter mais contexto sobre a situação em que entrou. Ao entender as necessidades deles, você também enxerga as necessidades da organização mais ampla
Você foi contratado para eliminar os problemas do CEO, mesmo que ele não peça. A capacidade de se integrar à equipe executiva é uma das melhores formas de demonstrar competência, e o que isso exige é consistência, diligência, mente aberta e disposição para fazer perguntas genuinamente úteis
Segundo, se o CEO e a equipe executiva se reúnem regularmente, peça para participar; se não, vale a pena planejar isso você mesmo. Idealmente, depois de alinhar primeiro com os executivos que não sejam o CEO. Mesmo que o CEO não possa comparecer a todas ou à maioria das reuniões, ele provavelmente agradecerá a iniciativa, e isso também ajudará a construir confiança
Como você já disse que ele não quer esse tipo de reunião, talvez seja preciso começar indiretamente, por meio de outro executivo que tenha influência sobre o CEO
Terceiro, se você é CTO, há uma grande chance de que o CEO queira algum tipo de 1:1 regular, nem que seja para garantir que você não vai embora. Basta encontrar uma cadência que caiba na agenda do CEO: semanal, quinzenal, mensal etc.
O objetivo dessa reunião é alinhar com o CEO e receber feedback sobre áreas em que você está indo bem e áreas em que pode melhorar. Se não conseguir marcar isso, eu consideraria que esse não é um ambiente em que você possa ter sucesso e recomendaria sair
Se for difícil marcar essa reunião, é melhor insistir primeiro nas duas abordagens anteriores para construir a relação e depois tentar. Se você não consegue reservar nenhum horário regular, com qualquer frequência, com o CEO e outros executivos, então você não é de fato o CTO e deveria considerar sair
Escrevi sobre essa diferença aqui: https://www.mooreds.com/wordpress/archives/2555
Mas a falta de planejamento e a falta de condução de visão são preocupantes. Ambas são centrais para o papel de um CEO em estágio inicial. Você sabe por que ele está tão focado apenas no curto prazo? Está tentando empurrar um MVP para captar investimento ou vender, ou simplesmente não há visão? Eu investigaria isso para entender o motivo. Ou, como outros disseram, sair também é uma opção
Você já chegou à etapa em que, ao organizar os passos de curto prazo realmente necessários, o CEO diz “beleza, é isso que vamos fazer”?
Ou está naquela fase maravilhosa em que, se você tenta avançar com a certificação SOC2, o CEO diz “ainda não”, mas no pitch de vendas fala “estamos caminhando para a certificação SOC2”?
Não se preocupe. O esquizofrênico não é você
A Wikipedia descreve DevOps como um conjunto de práticas que combina desenvolvimento de software e operações de TI, então traduzir isso como “todo o trabalho para garantir que o software de negócio rode em lugares que não sejam a máquina do desenvolvedor” parece uma interpretação meio estranhamente diferente da definição original
Especialmente a parte sobre especialista em DevOps
Vou reescrever para comunicar isso melhor
Não conheço nenhuma das empresas ou pessoas mencionadas aqui. Fico curioso se outras pessoas conhecem
Antes de gastar tempo lendo, digo que tenho uma desconfiança instintiva de pessoas chamadas de “chief technology officer”. Vale a pena ler?
O público-alvo parece ser pessoas que herdaram o título de CTO por serem cofundadores técnicos de uma startup, com pouca ou nenhuma experiência profissional
Fui CTO em três empresas nos últimos 10 anos, e talvez eu esteja ficando velho e menos paciente, mas, como outros disseram, parece mais um livro para recém-formados que acabaram de virar CTO como cofundadores. Estou dando mentoria técnica para pessoas assim
Pela minha experiência, quanto mais tempo você passa nesse papel, mais passa a procurar informações mais concretas, como em livros tipo Accelerate
Tecnologia chata é realmente importante. Startups do setor privado já são entidades instáveis por natureza; por que aumentar ainda mais o risco com tecnologia não comprovada?
Por exemplo, houve um período entre 2013 e 2016 em que o MongoDB, de um jeito difícil de explicar, virou praticamente o banco de dados padrão. Parecia que cerca de um terço das startups tinha migrado de MySQL ou Postgres para MongoDB. Foi um caos total e um desastre idiota
Nesses casos, é difícil imaginar um motivo para escolher Mongo. Além de acelerar um pouco os primeiros dias de desenvolvimento por não precisar criar e atualizar um schema, não há muito mais
O problema é que, no momento em que os dados ficam complexos e surge a necessidade de algo como BI, você acaba pagando essa vantagem inicial com juros enormes
De qualquer forma, mesmo que os dados não sejam relacionais, o JSON do Postgres funciona melhor que o Mongo
Algumas tecnologias novas desaparecem, outras permanecem
No começo da minha carreira, SQL era a nova tecnologia brilhante. Defendi fortemente que a empresa abandonasse bancos de dados em rede e fosse para SQL, e o resultado foi muito bom
O mesmo valeu para programação orientada a objetos em comparação ao C tradicional
Algumas tecnologias nunca chegam ao nível prometido e acabam virando uma amarra para as organizações que as adotaram
Houve também uma época em que ainda era cedo demais para adotar tecnologias de LLM de forma responsável. Mas em breve chegará o momento em que o conselho perguntará por que elas não foram adotadas. Talvez para casos de uso externos; certamente para casos de uso internos
Uma das tarefas difíceis de um CTO é julgar o momento de adoção de novas tecnologias. É preciso avaliar quando uma tecnologia chata é a melhor para a empresa, quando é aceitável trazer uma tecnologia ainda inicial e quando uma nova tecnologia se torna um acelerador tão grande que passa a ser obrigatória
Achei interessante a divisão do CTO em três tipos: orientado a tecnologia, orientado a pessoas e orientado ao externo
Uma startup em estágio bem inicial está me oferecendo um papel de CTO. Ainda não há produto, apenas algumas demos básicas, e eles estão se preparando para captar investimento pre-seed
Fico pensando no que seria mais necessário nesse papel. Um CTO técnico ou um CTO de pessoas? No começo, como é preciso desenvolver o produto, parece ser principalmente um papel técnico. Mas me pergunto quando ocorre a transição para um CTO mais centrado em pessoas. Gostaria de ouvir insights ou experiências sobre isso
Seja principalmente esse papel, sustente os outros mais ou menos como der e, quando esse trabalho ficar grande ou importante demais, contrate alguém para assumir pelo menos uma das outras duas áreas
A segunda pergunta, mais difícil de responder, é o que eles — ou seja, os outros CXOs — querem que você seja. Isso pode bloquear a primeira resposta. Em alguns casos, é um CTO sem o C: apenas a pessoa técnica que recebe ordens do que fazer, roda demos para impressionar e não ouve o “porquê” do negócio
Tenho alguns links salvos sobre “o que exatamente é um CTO”
http://www.startuplessonslearned.com/2008/09/what-does-start...
https://www.allthingsdistributed.com/2007/07/the_different_c...
Também recomendo The Manager’s Path, da Camille Fournier
Foi dito que “pagar dívida de forma proativa é um investimento necessário na saúde geral da engenharia”, mas algumas dívidas técnicas acabam sendo mais baratas, no conjunto, se você der calote em vez de pagá-las
Desde que o gerente de produto não tente cobrar a dívida
Mas um projeto com certo nível de escala e complexidade só chega à falência técnica quando você não segue os conselhos do livro. Se ignorar a dívida técnica para lançar funcionalidades, os releases ficam cada vez mais difíceis e os bugs cada vez mais frequentes
Parabéns pelo lançamento do livro
Com base na minha experiência como CTO de uma startup pequena e VPoE de uma empresa de capital aberto, estou escrevendo Opinionated Launch(https://opinionatedlaunch.com) para compartilhar ideias práticas
Ao começar a escrever, percebi que os temas se dividiam em dois caminhos: gestão/equipe/pessoas e tecnologia. Acabei me concentrando no lado técnico, pelo qual tenho mais paixão, e fico feliz que alguém esteja cobrindo o restante