Pixel Breeders Insights
Português
Voltar para todas as publicações
Editorial

O CTO que você não consegue contratar — e por que isso ainda não é seu problema

O CTO que você não consegue contratar — e por que isso ainda não é seu problema

A maioria dos fundadores não-técnicos tenta contratar um CTO no momento errado. Até a Series A, a escolha certa quase sempre é um sócio de entrega. Veja como saber em que ponto você está.

Um fundador com quem trabalhamos ano passado contou, num café em São Paulo, que tinha gastado quatro meses procurando um CTO. Conversou com vinte e três pessoas. Nenhuma topou. Duas disseram sim e sumiram antes de assinar. Ele terminou o café e fez uma pergunta que, naquele ponto da rodada, era uma emergência: “Quem fundadores não-técnicos contratam quando não conseguem o CTO?”

A pergunta está errada. A pergunta certa é: você devia estar contratando um CTO?

A maior parte dos fundadores em estágio inicial que conhecemos está convencida de que sim. Leram o playbook. O playbook diz: contrate o co-founder técnico, dê 20–30% da empresa, suba o produto, levante a rodada. O playbook tem quarenta anos de idade em tempo de startup. Foi escrito quando não havia outro jeito de construir software. Hoje há.

Até a Series A — e às vezes bem além dela — a escolha certa para um fundador não-técnico quase nunca é contratar um CTO. A escolha certa é trabalhar com um sócio de entrega que se comporta como um. A diferença é sutil, o custo é dramático, e a maior parte dos fundadores só percebe depois que já entregou o equity.

O que um CTO faz, na prática (e por que você não precisa da maior parte disso)

Antes de discutir se contratar, vale ser específico sobre o que está sendo contratado. Um CTO real, em uma empresa com capital de risco, faz cinco trabalhos. Define a arquitetura do produto. Contrata e gere o time de engenharia. É dono do roadmap técnico e das decisões em relação ao roadmap de negócio. Representa engenharia para o board, para investidores, para clientes enterprise. E — geralmente em quinto lugar, apesar do que os fundadores presumem — às vezes escreve código.

Para uma empresa em pré-seed ou seed, os trabalhos três, quatro e cinco são quase totalmente fictícios. Não há time de engenharia para gerir. O board ainda não importa. Cliente enterprise não existe. O que você de fato precisa, nos primeiros dezoito meses, é o primeiro trabalho — alguém que arquitete o sistema — e um time pequeno que execute essa arquitetura sem fazer do fundador um gargalo.

Um sócio de entrega faz a parte do arquiteto e fornece o time. Uma contratação de CTO faz a parte do arquiteto e você fornece o time. Em um modelo, o problema de recursos é resolvido no dia um. No outro, vira o primeiro projeto do CTO — e em geral consome seis meses e a maior parte do runway que você captou na rodada.

A conta que os fundadores não fazem

Aqui está a comparação que ninguém faz com o fundador, porque as pessoas na sala costumam ter interesse em um dos lados.

Contratar um CTO no seed: você dá entre 15 e 25% do equity e paga um salário entre R$ 30k–60k/mês no Brasil ou US$ 200–280k/ano nos EUA. Ele entra, e nos dois primeiros meses recruta. Faz duas primeiras contratações. Três meses depois, você tem três engenheiros, nenhum produto ainda, e o maior custo fixo do P&L é o time de engenharia. Você passa os próximos doze meses gerindo o gerente que gere o time. O CEO que disse “não quero ser tech manager” vai, de fato, ser tech manager.

Trabalhar com um sócio de entrega: você paga um valor de projeto — para uma primeira versão típica, entre R$ 200k–600k ou US$ 80k–200k diluídos em quatro a nove meses. O time é alocado no dia um. A conversa de arquitetura acontece com uma pessoa sênior antes da primeira linha de código. Você consegue lançar, vender ao primeiro cliente, iterar — sem queimar runway com pessoas que você ainda não consegue gerir produtivamente.

Em dezoito meses, quando a empresa está maior e o custo de desenvolvimento via parceiro por funcionalidade começa a superar o custo de uma equipe interna, é a hora de contratar. Aí você sabe exatamente que tipo de CTO precisa, porque o código diz. Você contrata alguém que se encaixa na arquitetura que você já tem, em vez de adivinhar a arquitetura que vai precisar antes que qualquer código exista.

“Mas eu quero um sócio”

É aqui que os fundadores empurram de volta. Não querem terceirizar o produto. Querem um sócio. Querem alguém que perde sono pelo mesmo problema. Querem um nome no deck.

Ouvimos. É uma preferência real, e não está errada. Mas vale ser honesto sobre o custo e o que você ganha.

Um co-founder técnico que entra no seed raramente é a pessoa que constrói a empresa que você terá na Series A. As habilidades necessárias no mês dois — codar, lançar rápido, montar o banco — não são as habilidades necessárias no mês vinte — contratar engenheiros, definir cultura de engenharia, particionar o sistema, lidar com auditoria de segurança. O número de CTOs que faz as duas coisas bem, em sequência, num time abaixo de cinquenta pessoas, é pequeno. O número que acha que faz é grande.

Se você quer um sócio, busque um para o lado do negócio onde você de fato tem um gap permanente. Um sócio comercial se você é um especialista de domínio. Um sócio de produto se você é comercial. Um segundo sócio comercial se você é construtor. O trabalho técnico — até você ter volume suficiente para manter um time ocupado em tempo integral, em algo que você entende bem o suficiente para direcionar — pode ser conduzido por um parceiro sem perder nada importante. A exceção é quando o trabalho técnico é o moat defensivo do produto (um produto pesado em pesquisa de IA, infraestrutura profunda, hardware-software combinado), e mesmo aí a maior parte dos fundadores superestima quanto do código inicial é o moat.

Como saber em que lado você está

Duas perguntas. Responda honestamente, por escrito, antes de marcar a próxima reunião com candidato a CTO.

Primeira: eu conseguiria, agora, escrever um briefing de uma página sobre o que queremos construir nos próximos seis meses — o que faz, quem usa, como é o sucesso, com o que precisa integrar? Se sim, você não precisa de um CTO; precisa de um sócio de entrega que pegue esse briefing e execute. Se não, o gap é a montante de engenharia — é clareza de produto. Um CTO não vai resolver isso para você mais rápido do que mais um mês de conversa com cliente.

Segunda: se um engenheiro sênior entrasse amanhã, o que eu colocaria nele no primeiro mês? Se a resposta honesta é “descobrir o que construir” — esse é um gap de produto, não de engenharia. Se a resposta é “construir A e B, aqui estão as specs” — você não precisa de uma contratação, precisa de execução. Se a resposta é “gerir os quatro engenheiros que acabamos de captar dinheiro pra contratar” — você se convenceu do problema errado.

A única resposta honesta que justifica uma contratação de CTO no seed é: temos uma decisão técnica complexa que se compõe ao longo de anos, a defensibilidade do produto está nessa decisão, e eu não posso, em sã consciência, terceirizá-la. É uma situação real. Também é rara. A maioria dos fundadores não está nela; acha que está porque o playbook disse que deveriam estar.

O que “sócio de entrega” significa de verdade

Usamos a expressão com cuidado, porque ela já foi tão usada por agências que quase não significa nada. Um sócio de entrega — o tipo que descrevemos — está mais perto de um CTO fracionário do que de uma fábrica de software. A relação tem quatro propriedades.

O engenheiro sênior que escopa o seu projeto é o mesmo que revisa o código seis meses depois. Não há handoff entre comercial e delivery, porque quem prometeu a arquitetura é quem a constrói. Você vê como as decisões são tomadas — toda discussão de arquitetura é uma conversa real, não um entregável. Os trade-offs são visíveis. O time escreve código que você vai conseguir contratar outra pessoa para manter quando o time interno chegar — porque a transição é um objetivo declarado do contrato, não uma reflexão tardia.

Essa última propriedade é a que a maior parte dos fundadores não enxerga ao avaliar parceiros. O parceiro errado constrói um sistema que só ele consegue manter, porque isso prende o fundador. O parceiro certo constrói algo que um futuro CTO consegue assumir limpo — é assim que você sabe que o parceiro tem skin no seu jogo de longo prazo, não só na fatura deste trimestre.

Quando, de fato, contratar

Há sinais. O mais claro é volume — quando há trabalho de engenharia, semana após semana, suficiente para que pagar via parceiro fique mais caro que rodar um time interno, e esse volume está estável há pelo menos seis meses. Costuma acontecer entre Series A e Series B em SaaS B2B, e mais cedo em produtos de consumo capital-light.

O segundo sinal é velocidade de decisão técnica — quando a frequência de decisões técnicas é alta o suficiente para que a comunicação com o parceiro vire imposto. Nesse ponto, um líder interno é mais rápido, mesmo que individualmente não seja melhor.

O terceiro sinal é gravidade de talento — quando os engenheiros que você quer recrutar só vêm se houver um CTO com credibilidade técnica para liderá-los. Esse sinal aparece mais tarde do que os fundadores imaginam; engenheiros sêniores aceitam entrar numa empresa em alta com um sócio de entrega forte se o fundador for honesto sobre o modelo e houver um caminho para a primeira contratação de VP/CTO.

Quando contratar, contrate alguém que se encaixa no código que o parceiro construiu, não na ideia abstrata de “um CTO”. O trabalho do parceiro é tornar essa contratação mais fácil, não mais difícil. É esse o teste.

A coisa silenciosa que ninguém diz

Vimos dezenas de fundadores em estágio seed passar por essa decisão. Os que contrataram cedo demais quase todos disseram, doze meses depois, que queriam não ter feito. Os que escolheram primeiro um parceiro quase nunca disseram o oposto. A assimetria não é sutil.

Há um motivo. A pressão para contratar um CTO no seed é, na maioria das vezes, social. Vem de investidores que gostam de um time completo no deck. Vem de pares que tomaram a mesma decisão antes de parcerias de software customizado serem críveis. Vem da própria ansiedade do fundador de ser a única pessoa do cap table que não escreve código. Nada disso é argumento sobre o que é bom para a empresa. São argumentos sobre o que é confortável para o fundador.

A resposta desconfortável é que, nos primeiros dezoito meses, a maior parte dos fundadores não-técnicos não precisa de um CTO. Precisam de uma pessoa sênior que já fez esse tipo de coisa antes, um time pequeno que executa, e disciplina para manter o próprio papel apontado para clientes, distribuição e o negócio — não para o organograma de engenharia que ainda não existe.

Quando esse dia chegar, contrate. Até lá, construa.

Deixe um comentário