Manual do CTO de Startup

Manual do CTO de Startup

Habilidades essenciais e boas práticas para equipes de engenharia de alta performance

Introdução

• Aprender sempre: o autor tinha, desde criança, uma paixão por computadores e programação de software, e por meio disso percebeu a importância do aprendizado contínuo. Para ter sucesso como líder técnico, é importante aprender e evoluir constantemente.
• O dilema do líder técnico em startups: a maioria das startups tem um cofundador técnico, e essas pessoas escrevem a base de código inicial e contratam os primeiros engenheiros. No entanto, à medida que a equipe cresce, o líder técnico precisa migrar para um papel de gestão, e nesse processo pode faltar experiência em liderança.

Sobre o autor

• O autor acumulou experiência em várias startups e vem atuando como líder técnico. Por meio de experiências em diferentes startups, passou a compreender as diversas habilidades e os desafios necessários para a liderança técnica.

Como usar este livro

• Este livro é uma referência para líderes que gerenciam equipes de engenharia de software e aborda diversos temas em capítulos independentes. Cada capítulo apresenta o tema, oferece uma visão geral e traz boas práticas.

Processos de negócios

• Explica processos de negócios para oferecer um ponto de partida para a resolução de problemas. É necessário ajustar e escalar os processos de acordo com o tamanho da equipe e da empresa.

Pessoas e cultura

Princípios básicos de gestão

• A regra de ouro da gestão: o desempenho da equipe é o critério pelo qual o desempenho do gestor é medido. É preciso dar suporte para que os membros da equipe possam entregar o seu melhor.
• Árvore de competências profissionais: para a liderança técnica, é preciso investir não apenas em habilidades técnicas, mas também em habilidades de gestão.

Melhoria contínua

• Kaizen: tanto a equipe quanto cada indivíduo devem buscar melhoria contínua. Erros devem ser encarados como oportunidades de melhoria.

Coaching

• O gestor deve atuar como um coach que ajuda os membros da equipe a darem o seu melhor.

Encontrando um mentor de gestão

• É importante encontrar um mentor de gestão para a transição para a liderança. Com o mentor certo, é possível aprimorar as habilidades de liderança.

Reuniões 1:1

• Reuniões 1:1 são uma oportunidade de construir relacionamento com os membros da equipe, entender seus pontos fortes e fracos e ajudá-los a dar o seu melhor.

Reuniões skip-level

• É possível coletar diferentes perspectivas reunindo-se regularmente com os subordinados diretos dos gestores, e com isso melhorar o negócio.

Coaching para gestores

• O desempenho dos gerentes intermediários é importante para o desempenho da organização. É preciso desenvolver gestores por meio de capacitação e suporte contínuos.

Reuniões 1:1 com engenheiros

• Reuniões 1:1 com engenheiros são uma oportunidade de ouvir os problemas que eles enfrentam e ajudá-los a encontrar soluções. É preciso deixar claro o objetivo da reunião e conduzir uma conversa produtiva.

[GN⁺]

Comentários no Hacker News

• Quando vejo um documento desses, costumo ir primeiro para a parte que conheço a fundo para verificar o que foi dito. Aqui dizem que normalmente leva de 6 a 12 meses para preparar e executar auditorias PCI DSS ou SOC 2, então você não deveria tentar obter a certificação na última hora, mas para startups eu quase daria o conselho oposto
  Em especial, a comprovação SOC 2 é fácil de obter, e gastar dinheiro de forma proativa antes mesmo de um pedido de compra estar em jogo é desperdício. Claro, coisas como configurar single sign-on ou proteger branches do Git, que depois servem de base para a comprovação, é bom fazer cedo, mas isso já está mais para práticas básicas recomendadas que você deveria adotar de qualquer forma, mesmo sem planejar obter SOC 2. Se um cliente grande não exigir, não vejo necessidade de fazer SOC 2. Seria bom que alguém revisasse as outras partes deste documento também

  • É uma boa abordagem. Procurei a parte sobre banco de dados e, no geral, estava boa. Só não me parece que em 2025 uma startup precise focar em SQL vs NoSQL. Bancos SQL populares já suportam bem JSON, então dá para usar PostgreSQL ou MySQL, com os quais os engenheiros estão mais familiarizados, e usar CloudSQL ou RDS para cuidar de backup e replicação
    Com uma réplica de leitura para BI e uma ferramenta de visualização decente, isso aguenta bem por bastante tempo, até antes de gastar valores de 5 ou 6 dígitos em algo como Snowflake
  • Pela minha experiência, empresas dispostas a fechar com startups em estágio inicial e que querem um relatório SOC 2 normalmente não têm problema em seguir em frente colocando no contrato obter SOC 2 Type 1 em até 6 meses, desde que a pessoa técnica consiga convencer a equipe de TI do outro lado, em uma conversa, de que a capacidade técnica é boa
  • Discordo respeitosamente quando os processos de contabilidade e cadeia de suprimentos ficam dentro de um ERP corporativo. Reverter depois processos que não são auditáveis custa tempo e dinheiro demais, e o negócio ainda precisa continuar operando nesse meio-tempo, então, nesse caso específico, acho mais barato e melhor torná-los auditáveis desde o primeiro dia
  • A aplicabilidade desse conselho pode variar bastante conforme o setor. Se você vende um produto B2B que lida com informações de identificação pessoal, na prática precisa de SOC 2 para não virar motivo de riso em uma reunião de pitch
    Dependendo da situação de caixa, o custo de usar um serviço automatizado de checklist de conformidade SOC 2 como o Secureframe pode ficar na casa de alguns milhares de dólares, e isso não só força a adoção de boas práticas, como também organiza tudo do jeito específico exigido pelo SOC 2, facilitando a auditoria. Comparado ao tempo de desenvolvimento e gestão de projeto necessário para colocar no caminho do SOC 2 uma organização já profundamente marcada por processos fora de conformidade, não é um investimento grande
  • Não entendo muito de compliance, mas isso soa bem estranho. Pelo que li por alto sobre SOC 2, parece que é necessário fazer uma enorme coleta de evidências durante vários meses antes da auditoria, então não sei como você saberia depois do fato o que precisaria ter preparado se não tivesse investido tempo antes
    Essa ideia de que é fácil conseguir a comprovação SOC 2 também é o completo oposto do que ouvi de outras pessoas sobre esse tema. Sempre ouvi que é muito difícil e demorado, então queria entender o que estou deixando passar. Se realmente for algo fácil, adoraria estar errado

• Vejo com frequência a ideia de que, ao virar VP ou CTO, você para de programar. Eu entendo que habilidade de gestão não é a mesma coisa que habilidade de programação, mas é difícil entender por que as pessoas largam o teclado e desperdiçam seu primeiro superpoder
  Dá para continuar sendo um CTO técnico do começo ao fim. Trate a equipe e a empresa como um serviço que precisa de contribuição ativa, manutenção e suporte on-call, e ao mesmo tempo continue construindo, colocando a mão na massa sozinho e junto com o time

  • No nível de VP/CTO, não há tempo para contribuir e manter código. Se há tempo, esse título provavelmente é mais simbólico do que real. Por exemplo, o “CTO” de uma startup com time de 3 pessoas
    O problema de verdade é assumir cedo demais na carreira um cargo em que não há tempo para programar. Tipo aceitar um papel de arquiteto em que você só desenha caixas no quadro e vai de reunião em reunião, ou uma função que na prática é gerencial, mas vem com o rótulo de “tech lead”. Você se acostuma a não escrever código e, anos depois, quando precisa buscar outro emprego, vai para entrevistas de programação encarando o fato de ter passado uma parte considerável da carreira sem programar. Para muita gente, o ritmo não volta rápido
  • Na minha experiência, o problema era simplesmente que o dia só tem tantas horas. Durante 7 anos, eu tive cerca de 20 a 25 pessoas sob minha responsabilidade direta ou indireta, e realmente faltava tempo para fazer algo útil no código
    Era muito melhor usar meu tempo resolvendo problemas que as outras pessoas não conseguiam resolver. Às vezes eu pegava uma mudança bem simples para passar pelo nosso processo com as próprias mãos e ver onde dava para melhorar. Continuei programando à noite e nos fins de semana, mas não é a mesma sensação, e com o tempo você inevitavelmente enferruja um pouco. Ainda assim, durante um período sabático, foi realmente muito prazeroso passar o dia inteiro programando com a mão na massa
  • Quando você deixa de ser um contribuidor individual puro, outras prioridades aparecem. Por isso, qualquer trabalho de contribuidor individual pode ser interrompido a qualquer momento. Aí você não pode assumir algo próximo do caminho crítico e, se assumir, vai acabar bloqueando outra pessoa ou tendo de repassar a tarefa
    Dá para fazer reviews ou participar de reuniões de design, mas, se pegar trabalho central, no fim surgem problemas
  • Não acho que exista uma única resposta certa, mas chega um ponto em que a contribuição de código de um VP/CTO tem muito menos alavancagem do que contratar o próximo engenheiro-chave, montar um roadmap técnico para ficar à frente da concorrência ou alinhar a organização de engenharia com o resto da empresa
    O código que um VP/CTO pode escrever também pode ser escrito por outra pessoa do time, e talvez até melhor. Já os outros trabalhos que mencionei provavelmente são aqueles em que o VP/CTO é a melhor pessoa da empresa para atuar. Deixar de lado, em grande parte, o trabalho técnico prático para focar no que é mais importante para o time e a empresa é uma decisão bem razoável
  • Meu último cargo de CTO era com um time de 40 pessoas, e eu já estava completamente sobrecarregado desde o primeiro dia. E isso mesmo sendo alguém bom em gestão de tempo. Eu queria passar 50% do meu tempo programando, se fosse possível, mas não havia tempo para isso, nem existia uma estrutura de suporte que eu pudesse delegar; eu mesmo tive de construí-la na marra. E isso, por si só, já era mais um motivo para não ter tempo
    A ideia de continuar programando é boa, mas normalmente não é por isso que pagam você. Eu me considero um desenvolvedor muito forte, mas dá para contratar alguém assim por menos do que o salário de um CTO. Fazer um CTO mais caro executar esse trabalho é ineficiente. Para constar, alguns anos depois voltei a ser contribuidor individual, e pretendo seguir assim pelo resto da carreira

• Eu diria que chat síncrono não existe
  Se precisa ser síncrono, não deveria ser feito numa janela de chat. Pelo menos não, a menos que tenha havido um acordo do tipo “vamos focar em um chat em tempo real por alguns minutos”. Se for remoto, ligue; se for presencial, converse cara a cara. Não se deve jogar uma mensagem no chat esperando resposta imediata

• Fiquei curioso para saber se houve algum caso em que o modelo de “dois times” não gerou ressentimento. Também não sei se houve situações em que as pessoas não quisessem naturalmente migrar para o time do futuro
  No papel parece uma boa ideia, mas é difícil acreditar que funcione bem na prática. O caso mais próximo que já vi foi um time de biblioteca que criava serviços como design system e componentes para que outros times usassem

  • Em uma empresa anterior, havia uma versão de produto on-premise para a qual a empresa vendia suporte estendido de prazo extremamente longo, embora a versão estivesse próxima do fim do suporte. Um time pequeno, talvez de umas 3 pessoas, era responsável apenas por garantir que essa versão continuasse suportada, que o pipeline funcionasse e que correções grandes pudessem ser distribuídas quando necessário
    Desde que mantivessem essa responsabilidade em ordem, podiam usar o tempo restante livremente em qualquer coisa que considerassem valiosa para a empresa. Era um acordo muito bom. As outras pessoas eram gratas porque aquele time pequeno assumia o trabalho sujo, e o time de manutenção gostava porque no tempo livre podia consertar coisas incômodas de longa data ou fazer pesquisa. Esqueci os detalhes, mas lembro que saíram melhorias bem legais e resultados interessantes de pesquisa. Também ajudou o fato de que as pessoas desse time eram muito competentes e autônomas, mas isso também custava mais caro
  • No livro, a solução para esse problema parece ser a rotação regular. Um post no blog da Microsoft recomenda trocar parte dos membros entre os dois times toda semana e definir o time de clientes como um time temporário
    Já passei por alguns lugares onde times totalmente separados funcionavam bem. Em jogos, dá para pensar em time de engine e time de jogo. Em um dos meus cargos antigos, mesmo dentro do time de jogo, eu assumia funcionalidades que levavam de 6 a 12 semanas, lançava, e depois cuidava de manutenção, atualizações e dívida técnica. O foco principal era o que tinha acabado de ser lançado, mas também havia tempo para voltar a trabalhos anteriores, e outros times seguiam o mesmo ciclo e entravam em onboarding de novas funcionalidades 6 a 8 semanas depois, repetindo esse padrão
  • Já experimentei um sistema estilo dois times no passado. O Red Team cuidava do desenvolvimento de funcionalidades, e o Blue Team da estabilidade e da correção de bugs
    Não tratávamos isso como times fixos, mas como um fluxo de trabalho em que as pessoas alternavam a cada sprint, ou seja, a cada duas semanas. Funcionou bem por cerca de 3 meses, mas depois deixou de fazer sentido e, nessa época, a organização cresceu e reestruturamos os times em torno de capacidades de negócio ou domínios
  • De forma parecida, já usei um esquema de rodízio em que engenheiros passavam uma semana lidando com suporte e relatórios de bugs. Isso evitava bastante as armadilhas de um modelo de “dois times” totalmente separado. Escrevi um pouco mais em https://news.ycombinator.com/item?id=43337703#43339972
  • Se o “time de clientes” tiver recursos suficientes e for recompensado de forma adequada, acho que não haveria tanta vontade de migrar para o “time do futuro”. Mas, mesmo sem separar, normalmente a manutenção passa fome enquanto novas funcionalidades levam toda a atenção e todos os recursos. Dividir em dois times parece até ter grande potencial de piorar isso

• Materiais assim não servem para serem usados como bíblia, e sim porque dão uma visão ampla das responsabilidades e preocupações
  A menos que você tenha tido um grande mentor ou trabalhado sob alguém realmente excepcional, quando chega a esse cargo ninguém senta ao seu lado para te dar uma lista do que precisa observar. Em cada seção, isso ajuda porque leva você a perguntar: “qual é a nossa resposta?”, “concordamos com isso?”, “nosso processo é melhor?”, “o que deixei passar?”

• Impressionante ver essa separação em dois times tão explicitamente. É uma forma fantástica de fazer você continuar lançando coisas até o custo de colocar algo minimamente aceitável em produção ficar alto demais
  Quando você rompe o ciclo de feedback de volta para as pessoas que construíram o software originalmente, essas pessoas ficam um pouco mais felizes por um tempo e outras ficam um pouco mais infelizes. Aí o time de funcionalidades passa a não querer mais ser interrompido nunca, e o time de clientes deixa de receber recursos para consertar qualquer coisa de verdade
  Pior ainda: o time de funcionalidades não aprende nada além de como empurrar coisas para fora. O motivo de tudo ficar mais lento e mais caro com o tempo é que você removeu a única função de adaptação adequada para desenvolver bom software: o processo de reintegrar feedback negativo à fonte do desenvolvimento. Se fosse um verdadeiro manual de liderança para CTOs, deveria dizer claramente: “é sua responsabilidade ajudar os desenvolvedores a melhorarem mesmo enquanto entregam em produção, e eles nem sempre vão gostar disso”

  • Dizer que isso “permite que o time de funcionalidades se concentre 100% no futuro sem ser interrompido por tarefas de suporte ao cliente” está mais para dizer que o time de funcionalidades pode continuar sem a menor noção do desastre que soltou até o navio bater de cheio no iceberg
    Isso também cria conflitos de merge entre um time de funcionalidades impulsionado por vendas e um time de manutenção impulsionado por atendimento ao cliente. Se o “time de clientes” é descrito como uma etapa da qual depois se sai, então é óbvio qual dos dois vai ganhar a disputa por prioridade. E a frase “mais um caminho para engenheiros individuais, especialmente juniores, aprenderem e crescerem” no fim soa como “os sêniors não querem limpar a bagunça, então jogam isso para os juniores”
  • Em assunto relacionado, nas empresas em que trabalhei, os lugares que tinham time de plataforma em geral estavam contaminados por overengineering. Aqui, time de plataforma no sentido de um terceiro time de apoio que cuida de ferramentas, práticas e código compartilhado
    Esse tipo de time tende a atrair pessoas que desprezam o trabalho de entregar funcionalidades e corrigir bugs e querem abstrair demais os problemas. Em vez de corrigir bugs, vão criando abstrações cada vez mais complexas com a promessa de impedir que bugs existam desde o começo, e o resultado é previsível
  • Isso é trabalho de PM. Você precisa de uma pessoa ou de algumas pessoas trabalhando com clientes e definindo, a partir do feedback, a visão de como todas as funcionalidades devem se encaixar
    Clientes, especialmente os não técnicos, normalmente não têm uma visão de produto coerente e muitas vezes só querem a correção imediata do problema atual, independentemente de qualquer outro plano. Às vezes o feedback entra em conflito porque os próprios clientes não se comunicam entre si. Se você joga esse peso para os desenvolvedores, além da capacidade técnica de conhecer e manter bem a base de código eles ainda precisam administrar toda a comunicação, e todos os desenvolvedores precisariam compartilhar a mesma visão coerente para tomar decisões cuidadosas. Num cenário atual em que desenvolvedores também gerenciam infraestrutura, isso na prática vira uma pessoa fazendo dois ou três trabalhos
  • Para compensar isso, trocávamos os times a cada sprint ou a cada poucos sprints. Assim as pessoas ganhavam experiências mais variadas e, se criassem uma funcionalidade cheia de bugs, acabavam tendo que corrigi-la depois, então o feedback continuava existindo
    As pessoas pareciam gostar muito mais desse modelo. Não ficavam esgotadas de sempre corrigir bugs, e também evitávamos essa ruptura do feedback que você descreveu tão bem
  • Desenvolvedores devem operar e fazer a manutenção do software que criam. É um princípio tão simples quanto isso

• Neste ponto, já fiz tantas entrevistas que perdi a conta, então acho um pouco difícil concordar. Uma dificuldade é que, na etapa de inscrição, há ou pode haver candidatos demais, e nessa fase normalmente é a equipe de recrutamento que interage com os candidatos
  Incluir perguntas como no exemplo é ok, mas, para filtrar candidatos não qualificados, são necessárias perguntas que não sejam de sim/não nem de escala. Eu prefiro perguntas bem simples com resposta clara. Há surpreendentemente muitas pessoas que dizem estar “muito confortáveis” com JavaScript e ainda assim não sabem o que é ===. Então faço uma pergunta como “qual é o operador de igualdade estrita em JavaScript”. Qualquer programador JavaScript deveria saber, mas só essa pergunta já elimina 50% do grupo de candidatos e economiza um tempo enorme da organização

• Fala-se muito em adequação cultural, mas boa parte disso parece trazer à tona camadas ocultas de discriminação que fazem mal à empresa. Abertura cultural é um fator de sucesso, e discriminação, na minha visão, empurra na direção oposta
  Quando vejo a frase “os melhores líderes acompanham a taxa de sucesso, não têm medo de admitir erros de contratação, contratam devagar e demitem rápido”, dá vontade de postar a imagem que o JWZ (Jamie Zawinski) mostra quando detecta o cabeçalho referrer apontando para este site. Basta procurar no Google o que Jamie Zawinski disse sobre a Y Combinator. Ele também é a pessoa que recebeu crédito pela decisão da Netscape de liberar o Netscape Navigator como open source e por grande parte do trabalho que levou ao motor de renderização daquele navegador. É por isso que existe o Firefox

  • Ver “adequação cultural” como discriminação oculta é uma interpretação cínica e, nos casos que vi, isso foi usado com mais frequência para proteger o candidato de pegar um trabalho que ele não gostaria
    Em um dos meus primeiros empregos, tentaram proibir completamente qualquer coisa que pudesse ser chamada de adequação cultural nos critérios de contratação. Como resultado, algumas pessoas odiaram a empresa assim que entraram e saíram em poucas semanas ou meses. Um candidato enfatizava planejamento e previsibilidade e reclamava que as empresas anteriores se moviam rápido demais. Nós éramos uma startup e, como era de se esperar, ele odiou a empresa. Mas não podíamos expressar essa preocupação no processo de decisão de contratação. Considerava-se que isso era “adequação cultural” e que poderia levar à discriminação. Depois que coisas parecidas aconteceram mais algumas vezes, essa política desapareceu em silêncio, e passamos a poder avaliar novamente a compatibilidade com a cultura de engenharia
  • Todo processo de contratação discrimina. O importante é quais características ele favorece e desfavorece, e o que ele exclui
    “Adequação cultural” é, em geral, uma troca: abre mão de parte da diversidade de pensamento em troca de eficiência de comunicação e alta confiança. Como as pessoas já sabem como devem agir e o que esperar umas das outras, não é preciso criar muitas diretrizes, mas isso também as torna mais vulneráveis ao pensamento de grupo e a vieses cognitivos relacionados. É algo como: “há todas as cores do arco-íris neste navio, mas até o nosso Klingon acha que os Klingons são maus”
  • Aceitei a tangente e fui pesquisar, mas os resultados da primeira página eram todos comentários do Hacker News mencionando Jamie Zawinski, então parei por aí. Seria bom se você explicasse do que se trata

• Não tenho certeza se o conselho de “criar uma biblioteca de vídeos explicativos” é bom. Pode fazer sentido para coisas específicas, como UI ou animação
  Mas, no geral, ler texto é mais eficiente do que assistir a vídeo. Quando se está com pressa, também é muito mais fácil ir para as partes importantes em um texto do que em um vídeo

  • Algumas pessoas gostam de vídeo, outras preferem texto. Ambos são investimentos que exigem esforço e trazem resultado. Agora, graças à IA generativa, ficou mais fácil produzir os dois