O papel do CTO em scale-ups

Toda vez que recebo um CTO de scale-up pra mentoria, três temas voltam. Sempre os mesmos três. Não na ordem dos cursos. Na ordem do desespero.

Esse post é o que eu queria ter lido há 15 anos.

Os 3 dilemas

Em scale-up (50-500 pessoas em engenharia), o CTO vive em tensão permanente entre três pares de opostos. Cada par puxa pra direções diferentes, e a maioria dos artigos sobre o tema fingem que isso é resolvível com framework.

Não é. Os dilemas não se resolvem. Você gerencia eles com critério, sabendo que vai estar errado às vezes.

Dilema 1: Estratégia × Execução

A literatura clássica diz: “CTO bom delega execução pra focar em estratégia”. Isso é parcialmente verdade, e completamente perigoso.

A verdade prática:

• Se você só faz estratégia, o time perde respeito técnico. Você vira “powerpoint guy” e a engenharia para de te incluir nas decisões reais.
• Se você só faz execução, você não escala. O time fica gargalado em você, e estratégia de tecnologia da empresa para de existir.

O ponto de equilíbrio muda toda semana. Início do trimestre, mais estratégia. Crise de produção, mais execução. Final de ciclo de planning, mais estratégia. Membro do time pedindo demissão, execução pura (eu vou).

A regra que sigo: 70% estratégia, 30% execução, mas a distribuição varia. O que não pode é zerar nenhum dos dois por mais de duas semanas.

Dilema 2: Hands-on × Delegação

Esse é o mais doloroso. Você foi promovido a CTO porque é tecnicamente excelente. O dia que você para de codar é o dia que você começa a virar o que sempre criticou.

A literatura diz “delegue tudo”. A realidade:

• Se você delega tudo, sua intuição técnica atrofia. Você começa a depender 100% do que o time te conta, e perde a habilidade de fazer perguntas perigosas (aquelas que pegam o problema escondido).
• Se você não delega nada, você bloqueia carreiras. Os engineering managers e tech leads precisam de espaço pra liderar. Você ocupando o palco mata gente.

Como resolvo: mantenho 1 projeto técnico real por trimestre. Não código de produção (não tenho tempo de revisar requirements direito). Mas algo de profundidade — um spike, uma arquitetura, uma POC.

Isso mantém minha intuição viva, sinaliza pro time que código importa, e me dá um lugar concreto pra “estar com” os engenheiros sem invadir o trabalho deles.

Dilema 3: Hire × Fire

O dilema que custa mais dinheiro pessoal. Não da empresa, seu.

Hire (contratar bem) é a habilidade que mais se fala. Fire (deixar ir) é a habilidade que mais decide o resultado.

A verdade que ninguém escreve:

• Demitir tarde custa mais que contratar errado. O custo de manter um senior técnico que parou de evoluir é o time inteiro perdendo confiança nas tuas decisões de contratação.
• Demitir rápido sem ter feito o trabalho de feedback (ver post anterior) é covardia. Você decidiu antes de tentar.

A pergunta que uso: “Se essa pessoa não estivesse no time hoje, eu contrataria?” Se a resposta é “talvez não”, o feedback difícil tá atrasado. Se a resposta é “definitivamente não”, o desligamento tá atrasado.

Demorei a aprender isso. Sou um cara que valoriza muito relação. Vai contra meu instinto deixar ir. Mas instinto não é decisão de liderança, é hábito pessoal.

O que ninguém te conta sobre o cargo

CTO de scale-up tem três trabalhos paralelos que ninguém menciona no JD:

1. Tradutor entre engenharia e negócio. Você é o ponto onde as duas linguagens encontram. Se você falha em traduzir, ou a engenharia constrói coisa que não vende, ou o negócio promete coisa que não escala.

2. Espelho técnico do CEO. O CEO precisa de alguém que diga “essa decisão de produto vai destruir o sistema”. Não pra brigar, pra avisar. Você é o único que pode.

3. Defensor de moral em downturn. Quando vier corte, e vai vir, o CTO é quem segura a engenharia. Não é o eng manager. É você. Eles olham pra você pra saber se o navio tá afundando.

Nenhuma dessas três coisas aparece no contrato. Todas as três decidem se você dá conta do cargo.

A trajetória típica que dá errado

O padrão de fracasso que mais vejo:

1. Engenheiro brilhante vira tech lead com 6 anos de carreira.
2. Vira eng manager aos 8 anos. Mantém código suficiente pra não atrofiar.
3. Vira head of engineering aos 11 anos. Para de codar. Começa a confiar 100% nos relatórios.
4. Vira CTO aos 13 anos. Tá tecnicamente desatualizado mas não percebe.
5. Aos 15 anos, time perde confiança técnica. Demissão silenciosa começa.

O ponto de erro é o passo 3. Parar de codar antes de ter construído a habilidade de fazer perguntas técnicas profundas sem código.

Se você tá nesse caminho, faz um spike por trimestre. Não importa se ninguém vê o código. Importa que sua cabeça não atrofie.

Os 3 sinais de que tá indo bem

Sinais práticos que uso pra medir se um CTO tá indo bem em scale-up:

1. A engenharia recebe estratégia da empresa, não só decreto. Decisões de negócio chegam com contexto técnico já considerado.
2. Eng managers/tech leads tomam decisões maiores sem te incluir. Eles dizem “decidi X porque Y”, e Y é defensável. Você só endossa.
3. CEO consulta você em decisões não-técnicas. Cultura, contratação, M&A. Isso significa que você virou peer de verdade, não só especialista.

Se nenhum dos 3 está acontecendo após 18 meses no cargo, tem trabalho a fazer.

Fechamento

CTO em scale-up não é cargo, é compromisso de fazer escolhas impossíveis sem framework e dormir bem mesmo assim.

Os melhores que conheço têm uma coisa em comum: aceitaram que vão estar errados às vezes, e construíram uma rede de mentores e pares pra calibrar. Solo, o cargo destrói. Em rede, ele evolui você.

Se você tá nesse cargo agora e dormindo mal, talvez seja hora de conversar com alguém que já passou por isso. Mentor, conselheiro, peer. Qualquer um que não dependa do seu desempenho pra existir.