Tech Lead (PJ/Remoto)

Esta é uma posição de Tech Lead um pouco diferente das que costumamos publicar por aqui. Estamos buscando a primeira pessoa que vai liderar tecnicamente nosso primeiro produto próprio. Por isso, tivemos um cuidado especial em explicar o contexto, os desafios, as responsabilidades e o que esperamos dessa posição. Você vai encontrar abaixo uma descrição mais completa do que o habitual. A intenção é que, antes mesmo de se candidatar, você consiga entender bem o desafio que estamos propondo e avaliar se ele faz sentido para você. O Desafio: Este é o primeiro produto próprio do Lab Secreto — construído com uso intensivo de agentes de IA e um ritmo de execução fora do padrão de mercado, sob a liderança direta do CEO do Lab. Agora chegou a hora de trazer alguém para assumir a propriedade técnica e formar o time que vai levar isso adiante. Se você lê isso e pensa "é esse tipo de desafio que eu quero pegar", continue lendo — o resto da vaga foi escrito para você decidir com informação de verdade, não para parecer bonito. Liderar o produto e a equipe dele, em parceria direta com o CEO e CTO. Na prática, isso quer dizer: Fundamentos de arquitetura de software sólidos, cabeça de maker, e capacidade de executar rápido e com precisão usando IA. Ser dono técnico do produto. Arquitetura, contratos, padrões, qualidade. As decisões estruturais saem de conversa entre vocês, a defesa e a execução são suas. Traduzir visão de negócio em sequência executável, em ordem, escopo e entrega. Escrever código e sustentar velocidade. Formar e liderar o time do produto. Define o perfil, participa da seleção e é o padrão técnico que as pessoas vão seguir. Estabelecer como se valida trabalho aqui. Como a gente sabe que o que foi produzido está certo — essa pergunta é sua para responder e instrumentar. O que precisamos que você já tenha:

• Fundamentos de arquitetura de software — inegociável, você precisa conversar com propriedade sobre:

Modelagem de domínio de verdade. Separar tipo de instância, identidade estável de identificador temporário, propriedade de sinal de estado de evento. Contrato versus implementação. Definir o que existe sem vazar como funciona. Sistemas distribuídos na prática. Idempotência, entrega confiável, reconciliação, compensação, ordenação. Saber que uma chamada bem-sucedida não prova que a operação terminou. Dados em tempo real. Estado inicial mais atualizações incrementais, detecção de perda, ressincronização, contrapressão, latência. Versionamento e compatibilidade. Evolução de contrato sem quebrar quem consome. Saber quando não abstrair. Generalizar cedo demais, dividir serviços cedo demais e transformar todo dado em objeto são erros que custam caro.

• Sobre stack: importa muito menos do que como você pensa. Trabalhamos hoje principalmente com TypeScript/Node e C#/Unity, mas a lista de linguagens no seu currículo não é critério — a disposição de aprender a que o problema pedir, sim.
• Domínio industrial, geoespacial, telemetria, 3D ou vídeo são bem-vindos, mas nada disso é bloqueante — a gente ensina aqui, inclusive levando você a campo. Fundamentos, não.
• Ritmo: O padrão de ritmo desta vaga é o mesmo que aplicamos em outras iniciativas do Lab: entrega rápida, ciclos curtos e uso intensivo de agentes de IA desde o primeiro momento. Dizemos isso porque é a expectativa real de velocidade da vaga. Nosso maior desafio é encontrar quem sustente ritmo executando rápido e com precisão. Velocidade que gera retrabalho não é velocidade.
• Execução com IA (e aqui vale uma distinção) - Usamos IA massivamente. Não como acessório: é o modo de produção. O trabalho hoje não é escrever linha de código, mas sim construir os loops e as ferramentas que validam o que os agentes produzem, revisar planos antes da execução, e interrogar o resultado — fazendo perguntas, não lendo linha a linha. Os agentes não são autônomos aqui; eles operam dentro de um sistema de verificação que alguém precisou projetar. Isso é o oposto de vibe coding. Vibe coding é aceitar o que saiu porque parece funcionar. O que fazemos exige fundamento mais forte, não mais fraco: para especificar bem, para desenhar a verificação, para reconhecer a abstração errada num plano antes que ela vire código, e para saber qual pergunta expõe o problema.

Se você lê essa descrição e pensa "isso é preguiça" ou "isso é brinquedo", não vai funcionar. Se você lê e pensa "é assim que eu quero trabalhar, mas ainda não sei fazer direito" — ótimo, vamos conversar. O método é ensinado no processo. O que não dá para treinar em tempo hábil são os fundamentos. Nossa filosofia de engenharia: output não é outcome Esta parte da descrição foi escrita com bastante cuidado. Queremos que você entenda como pensamos engenharia, produto e entrega — e que possa avaliar se essa forma de trabalhar faz sentido para você. Por isso, recomendamos que leia esta seção com atenção antes de seguir para as demais partes da descrição. Entregar não é resolver. Código escrito, serviço no ar e sprint fechada são output. Outcome é o resultado no negócio — o nosso e o dos nossos clientes. Só a segunda coluna conta. Por isso não nos apaixonamos por framework, por arquitetura perfeita superdimensionada, por uma constelação de microserviços nem pelo ferramental necessário para administrar a complexidade que a gente mesmo criou. Complexidade auto-infligida é a forma mais cara de parecer sofisticado. Acreditamos em arquitetura emergente e em muitos ciclos curtos de iteração. A estrutura certa aparece a partir do problema real, sob pressão de uso — não de um documento escrito antes de qualquer contato com a realidade. Cada ciclo pavimenta caminho seguro e validado para o cliente. Nada disso é licença para fazer mal feito. O que construímos precisa ser robusto e estar à altura do problema que estamos nos propondo a resolver.Uma consequência prática: não procuramos pessoas cuja identidade profissional esteja presa a uma linguagem ou stack específica. A escolha de ferramenta aqui é sempre subordinada ao resultado e muda quando precisa mudar. Procuramos engenheiros e arquitetos de software dispostos a executar, não a admirar as próprias criações. Note que isso não contradiz a exigência de fundamentos forte da seção anterior. É exatamente o contrário: só quem domina os fundamentos consegue decidir com segurança o que não construir. Superengenharia costuma ser insegurança disfarçada de rigor.

6+ anos de experiência na carreira Arquitetura de Software Distributed Systems Inteligência Artificial Liderança Técnica AI Engineering Tarefas e Responsabilidades Esta é uma posição de Tech Lead um pouco diferente das que costumamos publicar por aqui. Estamos buscando a primeira pessoa que vai liderar tecnicamente nosso primeiro produto próprio. Por isso, tivemos um cuidado especial em explicar o contexto, os desafios, as responsabilidades e o que esperamos dessa posição. Você vai encontrar abaixo uma descrição mais completa do que o habitual. A intenção é que, antes mesmo de se candidatar, você consiga entender bem o desafio que estamos propondo e avaliar se ele faz sentido para você. O Desafio: Este é o primeiro produto próprio do Lab Secreto — construído com uso intensivo de agentes de IA e um ritmo de execução fora do padrão de mercado, sob a liderança direta do CEO do Lab. Agora chegou a hora de trazer alguém para assumir a propriedade técnica e formar o time que vai levar isso adiante. Se você lê isso e pensa "é esse tipo de desafio que eu quero pegar", continue lendo — o resto da vaga foi escrito para você decidir com informação de verdade, não para parecer bonito. Liderar o produto e a equipe dele, em parceria direta com o CEO e CTO. Na prática, isso quer dizer: Fundamentos de arquitetura de software sólidos, cabeça de maker, e capacidade de executar rápido e com precisão usando IA. Ser dono técnico do produto. Arquitetura, contratos, padrões, qualidade. As decisões estruturais saem de conversa entre vocês, a defesa e a execução são suas. Traduzir visão de negócio em sequência executável, em ordem, escopo e entrega. Escrever código e sustentar velocidade. Formar e liderar o time do produto. Define o perfil, participa da seleção e é o padrão técnico que as pessoas vão seguir. Estabelecer como se valida trabalho aqui. Como a gente sabe que o que foi produzido está certo — essa pergunta é sua para responder e instrumentar. O que precisamos que você já tenha:

• Fundamentos de arquitetura de software — inegociável, você precisa conversar com propriedade sobre:

Modelagem de domínio de verdade. Separar tipo de instância, identidade estável de identificador temporário, propriedade de sinal de estado de evento. Contrato versus implementação. Definir o que existe sem vazar como funciona. Sistemas distribuídos na prática. Idempotência, entrega confiável, reconciliação, compensação, ordenação. Saber que uma chamada bem-sucedida não prova que a operação terminou. Dados em tempo real. Estado inicial mais atualizações incrementais, detecção de perda, ressincronização, contrapressão, latência. Versionamento e compatibilidade. Evolução de contrato sem quebrar quem consome. Saber quando não abstrair. Generalizar cedo demais, dividir serviços cedo demais e transformar todo dado em objeto são erros que custam caro.

Se você lê essa descrição e pensa "isso é preguiça" ou "isso é brinquedo", não vai funcionar. Se você lê e pensa "é assim que eu quero trabalhar, mas ainda não sei fazer direito" — ótimo, vamos conversar. O método é ensinado no processo. O que não dá para treinar em tempo hábil são os fundamentos. Nossa filosofia de engenharia: output não é outcome Esta parte da descrição foi escrita com bastante cuidado. Queremos que você entenda como pensamos engenharia, produto e entrega — e que possa avaliar se essa forma de trabalhar faz sentido para você. Por isso, recomendamos que leia esta seção com atenção antes de seguir para as demais partes da descrição. Entregar não é resolver. Código escrito, serviço no ar e sprint fechada são output. Outcome é o resultado no negócio — o nosso e o dos nossos clientes. Só a segunda coluna conta. Por isso não nos apaixonamos por framework, por arquitetura perfeita superdimensionada, por uma constelação de microserviços nem pelo ferramental necessário para administrar a complexidade que a gente mesmo criou. Complexidade auto-infligida é a forma mais cara de parecer sofisticado. Acreditamos em arquitetura emergente e em muitos ciclos curtos de iteração. A estrutura certa aparece a partir do problema real, sob pressão de uso — não de um documento escrito antes de qualquer contato com a realidade. Cada ciclo pavimenta caminho seguro e validado para o cliente. Nada disso é licença para fazer mal feito. O que construímos precisa ser robusto e estar à altura do problema que estamos nos propondo a resolver.Uma consequência prática: não procuramos pessoas cuja identidade profissional esteja presa a uma linguagem ou stack específica. A escolha de ferramenta aqui é sempre subordinada ao resultado e muda quando precisa mudar. Procuramos engenheiros e arquitetos de software dispostos a executar, não a admirar as próprias criações. Note que isso não contradiz a exigência de fundamentos forte da seção anterior. É exatamente o contrário: só quem domina os fundamentos consegue decidir com segurança o que não construir. Superengenharia costuma ser insegurança disfarçada de rigor. Sobre a parceria Você vai trabalhar diretamente com nosso CEO, que também está à frente do produto. Ele é criativo, hands-on, rápido e arrojado. Tem uma visão de produto forte e detalhada, gera muitas ideias e aposta alto. Prototipa em vez de discutir por muito tempo. Muda de direção quando a evidência aparece e espera que a dupla atravesse a ambiguidade em vez de esperar que ela se resolva sozinha. Isso é ótimo para quem gosta de construir e pode ser desconfortável para quem precisa de um terreno mais estável. As duas reações são legítimas — só é melhor descobrir qual é a sua antes, e não depois. O que esperamos de quem assume essa posição: Traduzir direção em ordem. Muita coisa vai acontecer ao mesmo tempo. Alguém precisa transformar isso em sequência, prioridades e decisões claras. Segurar o ritmo sem perder precisão. Rápido e certo. Não rápido e depois refazer. Discordar quando necessário. Se uma decisão técnica não fizer sentido, houver um risco importante ou uma escolha de produto comprometer a solução, isso precisa ser dito na hora — não três sprints depois. Concordância automática é o pior resultado possível aqui. Ser o dono técnico. Decisões construídas em conjunto passam a ser responsabilidade de quem assume a liderança técnica: defender, executar e, quando necessário, rever. Talvez essa não seja uma boa vaga para você se: você prefere trabalhar a partir de requisitos fechados, precisa de processos já estabelecidos para funcionar bem, entende velocidade e qualidade como forças necessariamente opostas ou mede o próprio trabalho principalmente pela elegância da solução, e não pelo resultado que ela produz. Sobre o produto É uma plataforma de inteligência operacional voltada para ambientes industriais: conecta dados corporativos, geográficos, históricos e em tempo real, contextualiza tudo em um modelo operacional comum, e sustenta decisão e execução de forma governada e auditável. O primeiro caso de uso é voltado para operações portuárias, mas o padrão se aplica a outros ambientes industriais — mineração, pátios logísticos, plantas industriais, energia e ferrovias. Quem somos O Lab Secreto é uma consultoria estratégica brasileira que se posiciona como alternativa às empresas tradicionais — resultados práticos e tecnologia como ferramenta de transformação para a indústria pesada. Atuamos em três frentes: .TECH (IA generativa e aplicada, dados, digital twins, sistemas complexos, hardware customizado, XR), .EXCELÊNCIA (Lean & Six Sigma, eficiência operacional, produtividade e ROI) e .ESG. Condições Modelo PJ Equity — do produto ou do Lab. Estamos dispostos a dar participação para esta posição e queremos discutir isso abertamente no processo. Benefícios flexíveis via cartão (Caju) e plano de saúde SulAmérica (opcional) — detalhes na proposta. Bônus de permanência equivalente a uma nota fiscal ao completar 12 meses. PTO remunerado a cada ano de contrato — condições detalhadas no processo. Formato flexível. Temos escritório no Centro do Rio, e haverá visitas periódicas à operação em campo.