Quando um Dev Sênior Não é Suficiente
Algumas semanas atrás um fundador me procurou: time pequeno, seis engenheiros, uma feature de IA em produção, crescendo rápido. Coisa que a gente vê bastante hoje em dia. Eles tinham um dev sênior excelente. Excelente de verdade. Do tipo que responde pergunta complexa e não foge de desafio.
O problema é que não havia desafio ali para ele. As decisões que estavam se acumulando não eram decisões de código.
Deviam migrar de um provedor de modelo para outro? Construir a própria camada de retrieval ou usar uma gerenciada? Hospedar o banco vetorial ou ficar no SaaS? Como tratar residência de dados para clientes europeus? Qual a abordagem certa de avaliação? Quando "bom o suficiente" significava lançar, e quando significava continuar iterando? O dev sênior tinha opinião sobre todas elas, mas eram opiniões de engenharia, não de estratégia. Ele conseguia te explicar três formas de fazer cada coisa. Não conseguia dizer qual delas era a certa para o negócio, porque isso não era função dele, e não era justo exigir que fosse.
Várias vezes na minha carreira, eu fui esse dev. Se você não sabe para onde quer ir, qualquer estrada serve.
É aí que um CTO fracionado começa a atuar em um projeto de IA. Quando surge a necessidade de tomar decisões orientadas pelo negócio.
O que um CTO fracionado realmente faz
O título soa como uma versão diluída de um CTO full-time. Mas é um papel diferente, com outro formato.
Um CTO full-time é dono da tecnologia. Ele contrata, demite, define o roadmap, senta nas reuniões de liderança e responde pelos resultados ao longo de anos. Um CTO fracionado não faz nada disso, e nem deveria. O papel está mais perto de um conselheiro sênior com autoridade de implementação sobre decisões específicas.
Para um projeto de IA, o trabalho se agrupa em cinco frentes.
Decisões que exigem profundidade técnica e contexto de negócio ao mesmo tempo. Construir ou comprar? Otimizar para velocidade ou para precisão neste caso de uso? Quanto gastar em infraestrutura agora e quanto adiar? Não são decisões do dev sênior, e também não são do fundador, porque o fundador não tem o contexto técnico para avaliar os trade-offs.
Decisões de arquitetura com consequências de cauda longa. O que você decidir hoje sobre banco vetorial, gestão de prompts, infraestrutura de avaliação e observabilidade vai determinar o que é possível (e o que é caro) daqui a dezoito meses. Times pequenos tomam essas decisões numa reunião de planejamento de sprint e pagam por elas durante anos. O CTO fracionado é quem olha a arquitetura proposta e faz as perguntas que ninguém no time tem senioridade para fazer.
Tradução entre o time e o resto do negócio. O fundador pergunta "dá para adicionar essa feature?". O dev sênior responde "dá, mas leva três semanas". O CTO fracionado é quem diz "dá, três semanas de construção, mas exige mudar a camada de retrieval, o que afeta todas as outras features, e a ordem certa é fazer estas duas outras coisas antes". Esse tipo de tradução é o que a maioria dos times não tem, e o que a maioria dos projetos travados precisa.
Decisões de contratação para papéis específicos de IA. Como é um bom engenheiro de ML, comparado a um bom engenheiro de infraestrutura que por acaso conhece APIs de LLM? Quando você precisa de alguém dedicado a avaliação? Quando o time atual já basta e só falta dar cobertura para ele? São decisões que times pequenos costumam errar porque contratam o que acham que precisam com base nas vagas que viram por aí.
Uma segunda opinião que não está na folha de pagamento. O dev sênior do time tem incentivos de carreira. Dizer "não sei como fazer isso" ou "acho que erramos a decisão de seis meses atrás" é mais difícil quando você está tentando manter o emprego. O CTO fracionado não tem esse incentivo. Confrontar o time e a gestão faz parte da descrição da vaga.
O que um CTO fracionado não é
Não é programador. Se o contrato vira entrega de features, o CTO fracionado está sendo mal usado, e o time está pagando taxa de consultoria sênior por trabalho que um engenheiro pleno deveria fazer.
Não é gerente de projeto. CTO fracionado que vira PM está sinalizando que o time tem uma lacuna enorme de liderança para resolver. Se o time precisa de um PM, contrate um PM. Custa menos e faz melhor.
Não é vendedor. Alguns CTOs fracionados são a cara técnica de uma agência de consultoria, ali para empurrar mais serviço. Se o seu vive recomendando fornecedores externos, principalmente os que ele tem relação, isso é um conflito de interesse que vale examinar.
Não é solução permanente. Os bons se tornam desnecessários em doze a dezoito meses, seja ajudando você a contratar um CTO full-time, seja deixando o time num ponto em que ainda não precisa de um. Quem é CTO fracionado da mesma empresa pequena há três anos já não é fracionado.
Quando você precisa de um CTO fracionado
A maioria das empresas em estágio inicial não precisa. Precisa de engenheiros sêniores e de um fundador que consiga decidir. Colocar um CTO fracionado por cima disso é um custo que não se paga.
Você começa a precisar quando estas coisas ficam verdadeiras ao mesmo tempo:
- A parte de IA do seu produto é crítica o bastante para que errar custe clientes, dinheiro ou, pior, os dois.
- Seus engenheiros sêniores são excelentes, mas não são as pessoas certas para tomar decisões estratégicas de tecnologia, seja porque não têm a experiência, seja porque não foi para isso que você os contratou.
- Você ainda não está pronto para um CTO full-time, seja por custo, seja porque a empresa não está no estágio em que esse papel faz sentido, seja porque você não encontrou a pessoa certa.
- Existem decisões travando o time agora, e o custo de errar é maior que o custo de buscar ajuda de fora.
Se duas das quatro são verdadeiras, provavelmente dá para se virar com calls de consultoria pontuais. Se três ou quatro são, um arranjo de CTO fracionado é quase obrigatório.
Se nenhuma é, você não precisa disso. Use o dinheiro em coisas que deixem seus devs mais felizes.
Como o trabalho funciona na prática
A maioria dos meus contratos de CTO fracionado roda dois dias por semana, às vezes três em períodos mais pesados. O trabalho se divide em três blocos.
Tempo de estratégia. Revisões de arquitetura, decisões de construir ou comprar, avaliação de opções e recomendações escritas que o time possa consultar depois. É a parte mais visível e a que os fundadores costumam esperar.
Tempo com o time. Um a um com engenheiros sêniores. Revisão de pull requests nas partes estrategicamente importantes do sistema. Programação em par nos problemas difíceis, quando isso ensina algo ao time. Freiar o instinto do time de superdimensionar ou subdimensionar coisas específicas. Um time que recebe seis meses de questionamento semanal de alguém de fora com opinião é um time melhor no fim desses seis meses, independentemente do que foi entregue.
Tempo de liderança. Participar de reuniões de conselho quando decisões de IA estão na mesa. Escrever as seções técnicas dos updates para investidores para o fundador não ter que fazer. Ajudar a redigir descrições de vaga, rubricas de entrevista e faixas de oferta para contratações técnicas. Ser a pessoa que o fundador liga quando recebe uma proposta de integração com um fornecedor e precisa de alguém para ler o contrato com olhos de engenharia. Essa parte é menos visível e costuma ser onde mais valor aparece.
A divisão varia. Alguns contratos são 80% estratégia e 20% time. Outros são o inverso. O formato deve seguir o que a empresa precisa de fato, em vez de um template fixo.
Quanto custa um CTO fracionado?
Vou dizer uma coisa que a maioria dos consultores não diz: trabalho de CTO fracionado é mais caro por hora que trabalho de construção, e o valor nem sempre é óbvio no primeiro mês. Você está pagando por julgamento, pela ausência dos erros que não cometeu e pela existência de uma relação que permite chamar alguém quando precisa. Nada disso aparece bonito numa lista de entregáveis.
Isso quer dizer que o arranjo só funciona quando a empresa está num estágio em que o custo de decisões ruins justifica o custo de acertá-las. Antes do product-market fit, é melhor usar esse dinheiro para contratar mais um engenheiro. Depois da tração, quando uma decisão errada de arquitetura pode custar seis meses de refatoração, a conta inverte.
Um teste útil: se seu engenheiro sênior tomasse amanhã uma decisão que se mostrasse errada, o custo do erro seria maior ou menor que três meses de honorários de CTO fracionado? Se for menor, você ainda não precisa disso.
Como isso se encaixa no resto do seu investimento em IA
Um CTO fracionado não substitui o trabalho descrito no post sobre contratar um consultor de IA para uma construção específica, nem o do post sobre por que os seus prompts não são o problema. Aqueles são contratos com escopo e entregáveis.
As empresas que vi fazer isso bem usam os três em momentos diferentes. Chamam um consultor para construir a primeira versão. Chamam um arquiteto quando a primeira versão para de funcionar. Chamam um CTO fracionado quando o time fica grande o bastante para precisar de liderança e pequeno o bastante para uma contratação full-time não fazer sentido. Três necessidades diferentes, três contratos diferentes.
Se as decisões estratégicas estão se acumulando mais rápido do que seu time consegue tomá-las bem e você ainda não justifica um CTO full-time, isso é um arranjo de CTO fracionado. Dois dias por semana, escopo escrito, saída definida. O objetivo é te deixar numa posição em que você não precise mais de mim. Comece por aqui.