- Muitos CTOs migram para uma atuação mais focada em gestão, mas alguns ainda mantêm a prática de desenvolver produtos escrevendo código diretamente
- Geram alta alavancagem dentro da organização por meio de três tipos de trabalho de desenvolvimento: projetos experimentais, pedidos urgentes de clientes e correções de bugs
- Ao continuar programando, conseguem sentir na prática a utilidade real e os limites das ferramentas de IA, garantindo mais realismo nas decisões técnicas
- Em vez de priorizar gestão, colocam seus pontos fortes e sua motivação em resolver problemas e construir produtos, desenhando uma estrutura organizacional que torne isso possível
- Não existe um modelo rígido para o papel de CTO; o essencial é encontrar um estilo de liderança adequado aos próprios pontos fortes e ao contexto da empresa
Por que continuo escrevendo código como CTO
- Muitos CTOs param de programar com o tempo, mas alguns ainda mantêm uma atuação em que desenvolvem e colocam funcionalidades em produção diretamente
- Nos últimos 12 meses, lançaram várias funcionalidades importantes sem ter nenhuma pessoa reportando diretamente a eles
- Não é apenas um hobby: atuam como desenvolvedores de funcionalidades centrais que realmente entram no produto
- Isso é definido como “uma das atividades de maior alavancagem para um líder técnico”
Três tipos de projetos que de fato constroem
1. Projetos experimentais de longo prazo (Long-horizon experimental projects)
- Dentro da organização, há pouquíssimas pessoas capazes de realmente construir um produto novo
- Isso porque a maioria das organizações está focada em manter e expandir o produto existente
- Só fundadores, alguns executivos e contribuintes individuais (ICs) de alto desempenho costumam ter espaço para tentar algo novo
- Por causa da estrutura organizacional, dos incentivos do roadmap e do orçamento de risco limitado, a maioria dos engenheiros não consegue tocar projetos incertos por vários meses
- O CTO está em uma posição única para acelerar projetos experimentais incertos, com base em um entendimento profundo da dor do cliente e da arquitetura
- Houve fracassos, mas também grandes sucessos
- Caso de um produto de chat com IA: a equipe via valor na ideia, mas vinha adiando o projeto por falta de tempo e folga; então um protótipo foi desenvolvido durante o feriado de Ação de Graças
- Depois, em colaboração com a equipe, o projeto foi transformado em um produto comercial com milhões de dólares em ARR
2. Atendimento a pedidos críticos de clientes (Critical customer asks)
- Há situações em que uma funcionalidade necessária com urgência para um cliente importante vira bloqueio para um grande contrato ou uma renovação
- Em vez de deslocar um engenheiro que já está no sprint atual, o CTO assume diretamente com base em decisão rápida e entendimento do sistema como um todo
- Exemplo real: um cliente de US$ 1 milhão por ano pediu uma funcionalidade de redução de dados para fins de compliance
- Na avaliação inicial da equipe, parecia que o cliente teria de construir uma integração via API por conta própria ou que seriam necessárias várias reuniões entre produto, jurídico e engenharia
- O CTO construiu e colocou no ar uma versão funcional em um único dia, preservando a relação com o cliente
3. Correções de bugs (Bugfixes)
- Muita gente se surpreende, mas corrigir bugs é uma das formas preferidas de manter um mapa mental da base de código
- Ao rastrear por que a paginação quebra na página 3 dos resultados de busca, ou por que uma conexão WebSocket cai exatamente após 60 segundos, a pessoa percorre o sistema inteiro
- Isso traz uma compreensão intuitiva da dívida técnica que é difícil obter apenas com code review ou discussões de arquitetura
- Essa vivência ajuda a manter a intuição necessária para decidir direção e prioridade de investimentos técnicos
Por que continuar programando
1. Para entender o que realmente funciona
- Usando ferramentas de IA todos os dias, como Claude Code, Codex e Cursor, fica possível distinguir realidade de hype ao tomar decisões sobre ferramentas e contratação
- Exemplo recente: tentaram fazer uma funcionalidade que mexia com integrações complexas via vibe-coding, mas não avançou; escrevendo manualmente, o progresso foi muito mais rápido
- Não era muito código, mas exigia lógica precisa, uma área em que LLMs são mais fracos
- Em contrapartida, outra funcionalidade grande foi desenvolvida quase inteira com Claude Code
- Entender onde a IA é excelente (CRUD, testes, boilerplate) e onde falha (precisão, nuances de sistema) é melhor do que decidir com base no hype do Twitter
- Estando dentro do código, dá para sentir quando pressionar e quando aliviar
- Dá para perceber quando a arquitetura está complexa demais ou quando a dívida técnica realmente virou problema
- Um gestor que depende apenas de relatórios pode deixar passar muita coisa
2. Para focar no que faz bem e no que gosta de fazer
- Construção organizacional e gestão de pessoas não são algo de que o autor goste especialmente
- Gestão de engenharia exige dinâmica interpessoal, avaliação de desempenho e desenho organizacional
- É uma função importante, mas não é onde estão seus maiores pontos fortes
- Por isso, ele contrata excelentes engineering managers e líderes
- Eles fazem isso melhor e gostam mais disso
- Assim, o CTO pode se concentrar em desenvolvimento de produto, resolução de problemas técnicos e programação
- Startups são como uma “maratona em ritmo de sprint”, então o papel é desenhado em torno do tipo de trabalho que mantém o interesse e permite correr rápido por muito tempo
- Esse é um modelo sustentável por anos e muito importante para a empresa
3. Porque as ferramentas de IA ampliaram a alavancagem
- Alguns anos atrás, era difícil encontrar tempo para programar enquanto se cuidava do trabalho estratégico
- Com o crescimento da empresa, o dia ficava tomado por reuniões e por tarefas fora da área de maior domínio
- Foi um dos períodos profissionalmente mais difíceis
- As ferramentas modernas de IA mudaram essa equação de forma fundamental (especialmente nos últimos meses)
- A produtividade aumentou de 2 a 3 vezes em relação ao passado
- Essas ferramentas não substituem julgamento nem conhecimento técnico; ao contrário, tornam essas habilidades ainda mais valiosas
- Se você instruir uma ferramenta de IA com algo como “construa uma exportação de dados que siga o formato de exportação CSV existente, mas inclua três campos adicionais da tabela de perfil do usuário”, ela consegue gerar a maior parte do código corretamente
- Isso funciona porque há contexto profundo sobre o que precisa ser feito e onde encontrar cada coisa
- Um engenheiro sem familiaridade com essa parte da base de código gastaria bastante tempo só para entender os detalhes
- O trabalho muda de “escrever cada linha de código” para “fornecer contexto, tomar decisões e avaliar soluções”
- Felizmente, há muito contexto acumulado
Encontrar o seu próprio jeito
- Ao pensar em como definir o papel de CTO, o autor cita o post de Greg Brockman sobre como a Stripe definiu o papel de CTO
- Depois de conversar com vários CTOs, ficou claro que há enorme variação na forma que esse papel pode assumir
- Alguns CTOs são visionários de tecnologia, outros são construtores de organização, outros são centrados em infraestrutura
- O ponto em comum é que grandes CTOs entendem onde podem gerar mais valor levando em conta suas capacidades específicas, seus interesses e o contexto da empresa
- No caso do autor, isso significa escrever bastante código
- Ele gosta mais de construir software do que de desenhar a organização
- É especialmente eficaz por causa do conhecimento profundo dos clientes e da base de código
- E contrata engineering managers fortes
- Mas este é um caminho pessoal, não uma prescrição
- O papel de CTO é muito flexível
- Construção de organização, desenvolvimento de estratégia de produto e outras frentes: a liderança técnica pode variar conforme os pontos fortes, a fonte de energia e as necessidades da empresa
- Para engenheiros que se preocupam com a ideia de que liderar significa abandonar o trabalho técnico: existem muitos caminhos possíveis
- O essencial é identificar a área em que você é singularmente excelente
5 comentários
Sou CTO em exercício e discordo bastante deste texto.
Concordo 100% que não se deve parar de programar, mas isso pode ser resolvido contribuindo para open source que não tenha relação com o produto da empresa. Acho que isso só faz sentido do ponto de vista de que, como founder técnico de uma startup em estágio inicial, é preciso atuar como generalista.
Bom para você... mas e a empresa?
Tem que fazer um trabalho condizente com o salário que recebe...
Acho estranho que um CTO toque diretamente um projeto experimental. Se derem tempo suficiente para o pessoal da linha de frente, eles dariam conta muito bem. O que mais me causa estranheza é a ideia de que apenas o CTO deva conduzir um projeto experimental de longo prazo. Se ele tem autonomia para alocar recursos, bastaria conseguir recursos específicos para o projeto experimental e dar tempo suficiente para a equipe executar o trabalho.
Caminho pessoal... preciso gerenciar bem para que a parte de gestão da organização não aumente demais, né..
Opinião no Hacker News
Se eu estivesse pensando em me candidatar a uma empresa e visse um post de blog em que o CTO se gaba de fazer commits de código todo fim de semana, eu me prepararia para fugir
O papel da liderança é criar uma cultura organizacional saudável, e se gabar de trabalhar no fim de semana é o oposto disso
Além disso, dizer publicamente que resolveu um problema de cliente em um dia sem passar por revisão jurídica nem de engenharia é um sinal de alerta perigoso
Em startups em estágio inicial, a cultura é totalmente diferente, e esse tipo de texto acaba funcionando mais como um filtro para selecionar as pessoas certas
O código que escrevo costuma ser mais para melhorar a DevEx interna ou resolver dívida técnica
Nunca pulo revisão legal, e lido mais com coisas em nível de PoC do que com código de produção
Para um CTO fundador, é importante estar perto do código, mas o essencial é não perder o equilíbrio
O papel de CTO varia de empresa para empresa
Como no caso de Greg Brockman na Stripe, alguns CTOs são visionários técnicos, outros são arquitetos organizacionais, e outros são centrados em infraestrutura
No meu caso, eu gosto de programar e estou profundamente envolvido com os clientes e com a base de código, então essa é a forma em que gero mais valor
O cargo de “CTO” tem uma definição vaga
Alguns CTOs vieram da fundação e programam com liberdade, enquanto outros trabalham mais voltados ao cliente e acabam até perdendo acesso ao código
Por outro lado, também existem CTOs arbitrários
No fim, só faz sentido perguntar “por que você programa?” quando está claro de que tipo de CTO estamos falando
Nesse caso, o nome CTO é apenas uma divisão de papéis
O CTO foca em estratégia e direção, enquanto o VP se concentra na gestão cotidiana de engenharia
Não importa se isso é feito construindo a organização ou programando diretamente
Quando alguém da gestão escreve código diretamente, a revisão de código pode ficar distorcida e a equipe pode acabar confusa
No fim, é possível que essa pessoa não seja um CTO de verdade, mas alguém que no fundo ainda se vê como desenvolvedor
Não sou totalmente contra CTO programar, mas neste caso parece haver falha no exercício do papel de CTO
A liderança técnica real está sendo feita por engenheiros fundadores, mas com uma remuneração muito menor, e essa estrutura é o problema
Um CTO sem estrutura de reporte e que só programa me parece mais próximo do papel de desenvolvedor sênior do que de estratégia
Eu também já recebi uma proposta assim, mas no fim não passava de um título formal
Acho que o papel vai mudar quando a organização crescer
Em startups pequenas, meu trabalho é tocar os sprints junto com a equipe, resolver a causa quando o cronograma escorrega e cuidar de quem está em burnout
Mas, pelo texto, se a equipe não tem nem folga para tentar projetos de AI mais quentes, então isso já é um problema organizacional
Em vez de o CTO sair programando, ele deveria resolver esse tipo de gargalo sistêmico
Em cada empresa, o papel de “sênior” ou “head” pode ser completamente diferente
Os problemas que surgem quando um CTO se envolve demais em programação são claros
Distorção em revisão de PR, descuido com a função principal, confusão de papéis e interferência na autonomia da equipe
A ideia de que “CTO não deve programar e só fazer estratégia” é um pensamento mecânico
A essência de uma empresa de tecnologia é entregar valor, e às vezes a coisa mais valiosa que um CTO pode fazer é implementar diretamente uma grande funcionalidade em um dia
Pode ser um dia muito mais produtivo do que uma reunião de KPI
Às vezes, pessoas de nível C precisam recuperar diretamente a sensibilidade do trabalho de campo
Em alguns casos, a pessoa pode ter virado CTO apenas por ser cofundadora
Se entrar em outra empresa com essa mesma abordagem, talvez nem alcance o nível de um staff engineer
Por fim, o fato de a página de preços do site da empresa não mostrar preços reais pode gerar confusão, então isso precisa ser corrigido