Founding engineer: o que um fundador não-técnico precisa saber antes de fazer essa contratação

Uma fundadora com quem eu vinha conversando há meses ligou numa terça à tarde. Tinha acabado de assinar uma proposta com o engenheiro que vinha tentando contratar desde o fechamento do seed. Equity: 4%. Salário: $185K. Cargo: Founding Engineer. Ela queria que eu desse uma olhada na carta-proposta antes de mandar.

Li duas vezes. Liguei de volta.

“Você sabe que acabou de contratar o seu CTO, né?”, falei.

“Não, não. É um founding engineer. Ele vai construir o produto. O CTO eu contrato depois.”

“Tá. Mas a pessoa que você acabou de dar 4% vai ser dona de cada linha de código da sua empresa pelos próximos dezoito meses. Vai escolher a stack. Vai escolher o banco. Vai decidir o que merece refatoração e o que vai ficar improvisado. Se você trouxer um CTO acima dele em nove meses, o que você acha que acontece?”

Silêncio. Depois: “Caraca.”

Ela não enviou a proposta. Passamos duas horas reescrevendo o cargo, o equity e a conversa que ela estava prestes a ter. O engenheiro acabou entrando. O título permaneceu. A estrutura embaixo do título foi corrigida antes de virar problema.

É por essa ligação que este artigo existe.

O que é um founding engineer?

Um founding engineer é o primeiro engenheiro que uma startup contrata como funcionário com equity, em vez de freelancer ou hire fracionado, para ser dono do build técnico do produto antes de existir um CTO ou um time de engenharia.

É a resposta de manual. Cobre mais ou menos metade do que você está de fato comprando.

A outra metade é a parte que os blogs de recrutamento omitem. Um founding engineer é a única pessoa na sua folha de pagamento que vai conhecer o codebase inteiro. Vai ficar sozinho no build pelos primeiros 12 a 24 meses. Vai absorver toda ambiguidade de produto que você jogar nele, traduzir em sistema, e conviver com as consequências quando você mudar de ideia. Vai definir os defaults técnicos que os próximos dez engenheiros vão herdar. E porque entrou quando a empresa ainda era arriscada, vai segurar uma fatia do cap table que, se a empresa der certo, deixa ele rico de uma forma que nenhum engenheiro futuro vai ser.

É essa a contratação. Não é um dev. Não é um freelancer. Nem é um IC sênior de uma empresa grande. É uma contratação no nível de founder, com uma fatia menor de equity e um escopo mais estreito, mas com o mesmo peso estrutural.

Quem não entende isso erra a proposta, erra o título, erra o equity e erra a relação. Antes de escrever a vaga, fica claro com você mesmo sobre o que está fazendo.

Founding engineer vs CTO: qual dos dois você está contratando, de fato?

É aqui que a maioria dos fundadores não-técnicos tropeça, e é o erro mais fácil de corrigir se você pega cedo.

CTO é executivo. Define direção técnica, gerencia engenheiros, vai a reunião de conselho, conduz a conversa de arquitetura com o resto da liderança e é dono da reputação técnica da empresa no mercado. O trade-off é liderança em troca de velocidade de IC. A maioria dos CTOs em estágio inicial gasta menos da metade da semana escrevendo código.

Founding engineer é IC. Constrói. Pega uma ideia de produto pela metade e entrega algo que cliente pagante consegue usar. É o pulso técnico da empresa, mas não gerencia time porque time ainda não existe.

A pergunta do CTO e a pergunta do founding engineer não são a mesma contratação. O jeito de distinguir as duas é se perguntar, com honestidade: eu preciso de alguém na sala de conselho agora, ou preciso de alguém entregando código?

Se a resposta é “na sala de conselho”, você procura um CTO. O mercado dessa contratação é raso, lento e caro. A maioria dos fundadores não-técnicos em estágio inicial não consegue, de fato, contratar um CTO de verdade nesse momento, e tentar quase sempre produz um candidato sobrequalificado para o trabalho de IC e subqualificado para o cargo executivo.

Se a resposta é “entregando código”, você quer um founding engineer. O mercado é mais profundo, o salário é menor e quem aceita é alguém cuja comp vai ser puxada por equity porque o atrativo é a propriedade sobre o canvas técnico.

Um padrão comum que dá errado: contratar um founding engineer com comp de founding engineer, dar um escopo de CTO (“você vai definir a direção técnica, conduzir a engenharia, ser dono da arquitetura para sempre”), e trazer um CTO de verdade acima dele um ano depois. O founding engineer vira um senior IC quieto que se sente rebaixado, ou sai com o equity e o contexto que tem. Vimos isso acontecer três vezes nos últimos dezoito meses. Em duas delas, o founding engineer saiu.

Casa o título com a comp, a comp com o escopo e o escopo com onde a empresa está, de fato, no build.

Founding engineer vs co-founder: a linha que importa

Tem uma terceira linha que vive borrada, e ela importa mais do que o título sugere.

Co-founder é dono da empresa. Assina documento. Carrega responsabilidade legal e financeira. Compartilha o perfil de risco do fundador: pouco ou nenhum salário no começo, vesting de quatro anos contando desde o dia um da empresa, com direitos e proteções que aparecem no cap table desde o momento da constituição.

Founding engineer é funcionário. Entra depois que a empresa existe. O grant de equity é estruturado como concessão do option pool, com vesting começando da data de entrada, e strike price definido por avaliação 409A que já reflete algum valor da empresa. Recebe salário de verdade desde o primeiro dia. Pode pedir demissão sem que isso seja um evento no nível de founder.

Fundadores às vezes tentam empurrar uma coisa pela outra. “Ele é praticamente co-founder, só entrou tarde.” Três meses depois, o engenheiro continua com um grant padrão de funcionário e o fundador se pergunta por que ele não tem o nível de engajamento esperado.

Se você quer uma relação de co-founder, estrutura como relação de co-founder. Isso significa equity em nível de founder (mais perto de 10-25% do que de 1-5%), vesting de founder, voz de founder na empresa. Significa abrir mão de uma fatia relevante do cap table.

Se você não pode fazer isso, o que você quer mesmo é um founding engineer. Seja honesto. Paga bem, dá propriedade sobre o canvas técnico, e não promete o que não pode entregar.

A versão honesta dessa conversa, feita logo no início, é a diferença entre uma contratação que dura cinco anos e uma contratação que vira disputa no cap table.

Quanto de equity um founding engineer deve receber?

A faixa de mercado, enquanto este texto está sendo escrito, gira em torno de 0,5% a 2% para um founding engineer contratado no ano seguinte ao seed, com vesting de quatro anos e cliff de um ano. Dentro dessa faixa, o número se move conforme alguns vetores específicos.

Vetores que empurram o equity para cima:

• O candidato já fez isso antes. Foi founding engineer numa startup que entregou produto, mesmo que a empresa não tenha exitado. Pattern matching pesa.
• O candidato está aceitando uma queda relevante de comp em relação ao último cargo.
• O candidato está entrando antes do fechamento do seed, quando o risco é materialmente maior.
• O candidato tem uma especialização técnica específica de que o produto precisa, e que você não consegue em outro lugar.

Vetores que empurram o equity para baixo:

• A empresa já tem produto em mercado, receita real e validação. O desconto pelo risco some.
• O salário está em ou perto do mercado, então o equity não está compensando uma queda de comp.
• O candidato está entrando pós-Série A, com 409A que já se moveu.

Duas coisas para evitar.

Primeiro, não dá equity para vencer o candidato. A gente já viu fundador não-técnico subir o equity em 50% na ligação de fechamento para arrancar o sim. O candidato disse sim; o fundador pagou pela decisão na rodada seguinte, quando o cap table parecia desbalanceado e o diligence de investidor apontou o problema. Se o candidato é a pessoa errada com 1%, vai continuar sendo errada com 1,5%. Acha outro vetor (data de entrada, salário, escopo, título) ou acha outro candidato.

Segundo, não dá equity sem vesting. Single-trigger acceleration num grant de founding engineer é tiro no pé. Vesting menor do que quatro anos, também. O cliff importa mais do que o percentual. Cliff de dois anos num grant de 1% dá ao fundador um ano de opcionalidade. Grant sem cliff dá ao engenheiro alavancagem no dia 90.

Em caso de dúvida, olha o State of Equity anual da Carta e compara com empresas no seu estágio e na sua geografia. Os números mudam todo ano, e o benchmark público é mais preciso do que o que você vai ouvir na sua própria rede.

Os três armadilhas em que o fundador não-técnico cai ao contratar um founding engineer

A gente assistiu a essas armadilhas em tempo real, com clientes que continuamos atendendo e com fundadores que decidiram fazer por conta.

Armadilha um: contratar alguém bom em tecnologia e ruim em ambiguidade.

Um engenheiro sênior de uma empresa de 400 pessoas, muitas vezes, é um founding engineer pior do que um engenheiro pleno de uma empresa de 12. O skill de que o founding engineer precisa não é profundidade em uma stack específica. É tolerância a requisitos vagos, julgamento para tomar uma decisão 70%-certa rapidamente e entregar, e temperamento para fazer o próprio raciocínio de produto enquanto o fundador ainda está descobrindo o que construir. Engenheiros que cresceram em ambientes bem especificados costumam travar diante de uma ideia pela metade e do pedido de torná-la real. O fundador interpreta a trava como “precisa de mais direção” e começa a escrever ticket, o que é o oposto do motivo pelo qual contratou o engenheiro.

Tela para tolerância a ambiguidade do mesmo jeito que você testa skill técnico. Pergunta: me conta um projeto em que o requisito não estava claro e você teve que descobrir o que construir. Se a resposta é uma narrativa polida e sem atrito, ele está te contando como gostaria de lembrar do trabalho. Se a resposta é “a gente errou o spec duas vezes, aí sentei com o cliente por duas horas e a gente descobriu o que importava”, esse é o founding engineer.

Armadilha dois: contratar alguém que você não consegue gerenciar.

Founding engineer entra atrás de autonomia. Quer entregar sem ser orientado. Mas autonomia não é o mesmo que ausência de relação. Um fundador não-técnico ainda precisa conseguir perguntar “essa é a melhor escolha?” e receber uma resposta de verdade, numa linguagem em que ele consiga agir. Se o engenheiro não consegue explicar trade-offs técnicos em consequências de negócio, o fundador vai acenar, aprovar, e assistir decisões serem tomadas sem conseguir avaliá-las. Isso é o começo do problema de caixa-preta sobre o qual esta marca escreve há anos.

A tela aqui é uma conversa, não um teste de código. Passa uma hora discutindo uma decisão real que o candidato precisou tomar no último trabalho. Ele explicou o trade-off em termos que você acompanhou? Ele empurrou de volta quando você propôs algo que não fazia sentido? Te deixou se sentindo respeitado, ou pequeno? Se a conversa foi boa, provavelmente a relação de trabalho vai ser boa.

Armadilha três: contratar alguém que não consegue virar gestor, e descobrir isso no nono mês.

A maioria dos founding engineers vai, em algum momento, ter que contratar e gerenciar os próximos dois ou três engenheiros. Nem todos querem. Alguns founding engineers excelentes são profundamente IC e vão silenciosamente ressentir cada hora obrigatória em 1:1. Tudo bem. Mas você precisa saber disso no dia um.

Tem a conversa de forma explícita. “Em doze a dezoito meses, o time vai crescer. Alguns founding engineers crescem para virar engineering manager. Outros ficam IC e a gente contrata um manager por cima. Qual versão é mais parecida com você?” Se ele não tem uma resposta clara, é porque não se conhece o suficiente. É bandeira.

O teste de prontidão de sete dias

Antes de escrever a vaga, roda esse teste em você mesmo. Ele vai te dizer se você está pronto para fazer essa contratação, ou se deveria esperar três meses e continuar trabalhando com um time externo por mais um ciclo.

Passa os próximos sete dias respondendo, por escrito, às cinco perguntas abaixo. Se não conseguir, você não está pronto para contratar um founding engineer. A contratação vai falhar não porque o engenheiro está errado, mas porque a empresa embaixo dele não está pronta.

1. O que o produto precisa fazer, em linguagem simples, daqui a seis meses? Não o deck de visão. O produto entregue. Uma página.
2. Quem são os três primeiros clientes usando o produto, e pelo o quê eles estão te pagando? Se a resposta é “a gente decide isso depois do lançamento”, o founding engineer vai decidir por você. Ele vai tomar as decisões de design de cliente quer você queira, quer não.
3. Qual o orçamento de engenharia para os próximos 18 meses, incluindo salário, equity, infraestrutura e uma reserva para a próxima contratação? Se você não consegue responder com precisão de 20%, você vai ficar sem runway por volta do mês dez, e a conversa com o engenheiro sobre redução de salário ou layoff vai ser a pior do seu ano.
4. Como é o mês 12 se a contratação der certo? O que está entregue, qual a receita, qual o time. Se você não consegue enxergar, o engenheiro também não, e o equity vira só um número no papel.
5. Como é o mês 12 se não der certo? Qual a conversa de saída. Quem fica com o código. Quem é dono dos compromissos com cliente. A conversa mais difícil em qualquer contratação de founding engineer é o desfecho. Fundadores que conseguem nomear isso no início, normalmente não precisam ter a conversa. Fundadores que não conseguem, frequentemente precisam.

Se você consegue responder as cinco com clareza, contrata. Se não, a lacuna está na empresa, não no candidato. Conserta a lacuna primeiro.

Quando não contratar um founding engineer (e o que fazer no lugar)

Tem três situações em que a chamada certa é esperar.

Você ainda não validou o produto. Pré-validação, o que você precisa é throughput em experimentos, não propriedade de codebase. Um time externo capaz ou um freelancer sênior vai andar mais rápido do que um founding engineer, porque não precisa ser embarcado numa visão que ainda muda toda semana. Contrata o founding engineer quando tiver algo que vale a pena defender.

Você não consegue articular o que quer da posição. Se você está escrevendo a vaga e colando texto da vaga de outra empresa, desacelera. O custo de errar essa contratação é alto demais para que descrições nebulosas sejam aceitáveis. Um CTO fracionado por três meses pode te ajudar a escrever o spec, definir a régua técnica e triar candidatos. É um jeito muito mais barato de descobrir que você, na verdade, não precisa dessa contratação ainda.

Você está contratando por medo, não por estratégia. Tem um padrão emocional específico que empurra fundador não-técnico para uma contratação prematura: um conselheiro disse que você devia ter time técnico próprio, um par acabou de contratar um, o time externo não está perfeito e o fundador está perdendo confiança. Contratações por medo falham mais do que contratações por estratégia. A correção quase sempre é uma conversa, não uma vaga. Conversa com dois ou três operadores que contrataram o founding engineer no momento certo e pergunta o que fariam diferente. A resposta raramente é “devia ter contratado antes”.

Se nenhuma dessas três se aplica, e você consegue responder as cinco perguntas com clareza, escreve a vaga. Usa a faixa de equity acima. Evita as três armadilhas. E gasta mais tempo na conversa do que no teste técnico, porque é na conversa que a contratação vive ou morre.

FAQ

Qual a diferença entre founding engineer e a primeira contratação de dev?
Founding engineer é contratado em tempo integral, com equity, para ser dono do build técnico do produto. A primeira contratação de dev costuma ser uma relação transacional: um freelancer ou um funcionário júnior trazido para executar um escopo definido. Founding engineer assina com a empresa; primeiro dev assina com o projeto.

Founding engineer pode virar CTO depois?
Às vezes, mas não por padrão. Os skills se sobrepõem menos do que os títulos sugerem. Um excelente founding engineer é um excelente IC; um excelente CTO é um excelente executivo. Algumas pessoas crescem para os dois. Muitas não. Se você quer que o founding engineer eventualmente vire o CTO, nomeia isso explicitamente na conversa de proposta, e constrói desenvolvimento de skill de gestão entre os meses 9 e 18. Não espera acontecer sozinho.

Quanto tempo demora para contratar um founding engineer?
Planeja dois a seis meses. Os bons não estão no mercado. Estão em conversas via intro caloroso, indicação, rede pequena. Inbound frio raramente produz o hire certo. Reserva o tempo, trabalha a rede e não comprime a agenda para compensar um compromisso de conselho.

Qual o título certo: founding engineer, founding software engineer ou outro?
Para o trabalho, não importa. Para o candidato, importa. “Founding engineer” carrega mais expectativa de equity do que “senior engineer” ou “lead engineer”, e os candidatos vão precificar dessa forma. Escolhe o título que casa com a comp e com o escopo, e não infla o título para vencer o candidato sem inflar o resto do pacote junto.

Devo contratar um founding engineer ou trabalhar com um parceiro de software no lugar?
Depende de onde você está. Um parceiro de software anda mais rápido pré-validação, e te dá opcionalidade se a ideia de produto mudar. Um founding engineer compõe. Fica mais rápido todo mês, e no marco de 18 meses ele conhece o seu negócio melhor do que qualquer time externo vai conhecer. A maioria dos fundadores não-técnicos com quem trabalhamos faz os dois em momentos distintos da empresa. A versão honesta: founding engineer é a contratação certa quando você tem algo que tem certeza de querer compor em cima. Antes disso, você está pagando caro para compor em cima da base errada.