O risco nao comeca com a carta de demissao. Comeca semanas antes, quando o engenheiro ainda esta com sessao aberta em todos os repositorios, ainda tem acesso total aos documentos de design, e ja comecou a pensar no proximo passo. Essa janela de tempo e discreta, nao aciona nenhum alerta, e parece uma terca-feira qualquer. Tambem e o momento em que uma startup perde o registro mais claro de quem realmente construiu o que.
O que realmente sai pela porta
Raramente e o produto final. O repositorio de producao costuma estar bem: tem historico de commits, um changelog real, e mais de uma pessoa que pode atestar por ele. O que desaparece e tudo ao redor disso. Um repositorio privado criado para um primeiro prototipo antes mesmo de existir o repositorio "oficial". Um documento de design colado num e-mail pessoal porque o Slack caiu naquele dia. Uma branch que ninguem fez merge porque a funcionalidade foi adiada, mas que ainda guarda a primeira versao funcional de uma ideia que a empresa lancou depois sob outro nome. Nada disso parece importante enquanto a pessoa ainda esta na equipe. Tudo isso vira motivo de disputa no dia em que ela nao esta mais.
Um cofundador tecnico que sai apos um desentendimento e a versao mais aguda desse problema. Duas pessoas podem se lembrar dos mesmos seis meses de forma completamente diferente, e uma vez que a relacao se rompeu, nao existe mais um relato compartilhado de quem escreveu qual linha primeiro, de quem fez o esboco que virou arquitetura, ou de quando uma determinada ideia realmente tomou forma. O que resta e memoria contra memoria, o que nao e prova.
Isso nao afeta apenas fundadores. Um prestador de servico que construiu a primeira versao de uma funcionalidade antes de ser contratado em tempo integral. Um estagiario cujo projeto de verao virou, sem que ninguem percebesse, uma peca central do produto. Um freelancer que desenhou o diagrama de arquitetura original. Todos eles deixam o mesmo tipo de lacuna para tras, geralmente sem que ninguem perceba ate que uma disputa obrigue alguem a procurar uma prova que nunca foi guardada.
Por que selar "nos grandes marcos" deixa a brecha aberta
A maioria das equipes tecnicas que pensa nisso, pensa no momento errado. Uma versao e marcada com tag. Um contrato e assinado. Isso e o que se sela, se e que algo se sela. A branch exploratoria que deu forma a versao, o primeiro prototipo que provou que a ideia sequer era viavel, o documento de design interno no qual a versao realmente se baseia: tudo isso raramente recebe o mesmo tratamento, porque ninguem pensava numa saida enquanto ainda escreviam codigo juntos. Isso e exatamente ao contrario. O material com o rastro documental mais fraco e justamente aquele do qual um engenheiro que esta saindo tem a lembranca mais clara, e muitas vezes o instinto mais forte de reivindicar o credito.
O que o selamento continuo realmente estabelece
A solucao nao e uma equipe juridica maior. E tratar o selamento como parte rotineira de como o trabalho tecnico e guardado, nao como uma etapa reservada para lancamentos e assinaturas. Na pratica isso significa um habito tao simples quanto um merge para a branch principal: codigo-fonte selado em ritmo regular em vez de apenas no lancamento, um documento de design selado no dia em que e compartilhado com a equipe em vez do dia em que e finalizado, um primeiro prototipo selado na semana em que roda pela primeira vez em vez de meses depois, se e que chega a acontecer. Nada disso depende de lembrar que uma saida pode acontecer. So precisa ja ser a forma como a equipe trabalha. Nos termos do artigo 41 do eIDAS, um carimbo de tempo eletronico qualificado goza de presuncao de exatidao quanto a data e hora que registra, e da integridade dos dados que cobre. Na Suica, uma assinatura emitida por um provedor credenciado pela ZertES tem o mesmo peso juridico de uma assinatura manuscrita. Nenhum dos dois regimes se importa com quem ainda esta empregado quando uma disputa finalmente surge. Ambos se importam com o que foi registrado e quando, que e justamente a parte da historia que nao muda dependendo de quem a conta.
Imagine dois fundadores que constroem juntos a primeira versao funcional de um produto, e depois se separam mal dezoito meses depois. Se o primeiro prototipo e o documento de design que levou a ele foram selados na semana em que foram escritos, existe um registro datado e a prova de adulteracao, independente da memoria ou da relacao atual de qualquer um dos dois. Se nao foram, a disputa se resume a quem for mais convincente, uma posicao em que nenhum dos dois fundadores deveria querer estar.
O que isso nao faz
O selamento nao substitui um contrato de trabalho nem uma clausula de cessao de propriedade intelectual, e nao decide uma disputa sozinho. Uma empresa ainda precisa dos acordos subjacentes que estabelecem, antes de tudo, a quem pertence o trabalho produzido. O que o selamento acrescenta e o registro probatorio de que uma disputa realmente precisa depois que esses acordos existem: a prova do que existia, em que forma, e quando, que nenhuma das partes pode reescrever discretamente depois que a relacao termina.
Torne isso um habito antes da saida, nao depois
No momento em que alguem pede demissao, ja e tarde demais para comecar a selar o trabalho que mais importava. As startups que evitam esse conflito sao as que fizeram do selamento parte de como guardam seu trabalho tecnico desde o inicio, assim como fizeram do controle de versao parte de como o escrevem. Veja como isso funciona para equipes de software e de propriedade intelectual antes que a proxima saida, planejada ou nao, torne a questao urgente.
