O fundador técnico de uma startup com 30 engenheiros continua escrevendo código em tempo integral. As decisões de arquitetura acumulam na fila dele, os sêniors deixam de propor mudança porque a revisão leva dias, e a organização não evolui porque ninguém com mandato para conduzir a arquitetura está conduzindo.
Sinais de que o gargalo é você
- Seus pull requests ficam parados enquanto o resto do time espera resposta
- Sêniors já dizem "o Marc revisa depois" e seguem com o trabalho incompleto
- Decisão técnica de peso vira reunião porque só você tem o contexto inteiro
- Nenhum engenheiro do time explica a arquitetura toda para um recém-chegado
Os quatro sinais apontam para a mesma causa: o papel do CTO mudou e o cargo que você exerce é o de antes. Melvin Conway descreveu em "How Do Committees Invent?" (Datamation, 1967) que o desenho do sistema reproduz a comunicação de quem o constrói. Com uma pessoa no centro de toda decisão, todo desenho passa por ela e envelhece no ritmo dela.
O trabalho que fica com o CTO
Três frentes ficam sem dono enquanto você está no editor: a direção técnica dos próximos 18 meses, com os trade-offs que entram e os que ficam de fora; a formação de gente técnica capaz de assumir decisões que hoje passam por você; e o encaixe entre estratégia de engenharia e metas de produto.
Andrew Grove mede o trabalho de um gestor pelo que a organização sustenta sem ele, em High Output Management (Vintage, 1985). Código que fica com você é a menor das alavancas na sua mão. Marty Cagan descreve em Empowered (Wiley, 2020) times de produto que decidem perto do trabalho quando a liderança fixa direção e limites. Sem esse movimento, o time espera você no código e na direção ao mesmo tempo.
Transição de 90 dias
Dias 1 a 30. Transfira um domínio por vez, começando pelo que depende menos de você. Some do seu caminho as dependências críticas: quem aprova deploy, quem roda o plantão, quem revisa o módulo de pagamento.
Dias 31 a 60. Reduza code review ao que muda contrato entre módulos. Reserve dois dias da semana para contribuição técnica e corte a frequência a cada duas semanas.
Dias 61 a 90. Pare quando a organização responder sem você no código. Se uma decisão voltar para você duas vezes na mesma semana, o domínio daquela decisão continua com você.
Do que você tem medo
Perder relevância, ver alguém errar onde você não erraria, ficar longe da ferramenta. Todo fundador técnico atravessa esses três. O custo de continuar aparece em semanas de decisão parada e num time que não treinou ninguém para assumir o seu lugar.
O que volta depois
Entre três e seis meses, decisões que paravam em você passam a andar sem reunião, dois engenheiros conduzem review de arquitetura sozinhos e você recupera dias inteiros para pensar na direção. Duas semanas de férias depois, os pull requests seguem aprovados e o plantão tem dono.
