Company Handbook

Por que este documento existe

Este handbook não é decoração de parede. É um contrato bilateral entre você e a C-137 Labs.

Ele define quem somos, como operamos, o que esperamos de você, e o que você pode esperar de nós. Se algo aqui não fizer sentido na prática, é um bug — e bugs a gente corrige rápido.

Leia com atenção. Não porque é obrigatório, mas porque é a forma mais rápida de entender se este é o lugar certo para você.

O que é a C-137 Labs

Somos uma venture builder AI-First. Criamos, financiamos e operamos empresas de tecnologia do zero — em mercados que já existem, com modelos que ainda não existem.

Não somos agência. Não somos software house. Não somos aceleradora. Somos sócios-operadores: entramos com capital, produto, tecnologia e go-to-market. Dividimos risco e resultado.

Nosso modelo funciona porque combinamos três coisas que raramente coexistem: velocidade de startup, disciplina de fundo de investimento e infraestrutura compartilhada de venture builder.

Para quem a C-137 é — e para quem não é

Este é um ambiente de alta performance com autonomia real. Isso significa que funciona muito bem para algumas pessoas e muito mal para outras. Nenhuma das duas coisas é defeito.

A C-137 é para você se você funciona bem com ambiguidade. Não precisa de alguém dizendo exatamente o que fazer — precisa de contexto e espaço para resolver. Você prefere pedir perdão a pedir permissão, mas tem bom senso suficiente para saber quando precisa alinhar antes. Você se incomoda com trabalho medíocre — o seu próprio, especialmente. E você entende que feedback direto não é agressão, é respeito.

A C-137 provavelmente não é para você se você precisa de processos rígidos e supervisão constante para entregar. Você evita conflito mesmo quando ele é necessário. Você trata prazos como sugestões. Ou você prefere ambientes onde a velocidade de mudança é baixa e previsível.

Nenhum desses perfis é errado. Mas encaixe cultural é tão importante quanto competência técnica, e somos honestos sobre isso desde o dia zero.

Nosso DNA

#AwesomePeople — Gente autônoma, curiosa, e que eleva o padrão do time. Na prática: você não espera instrução, busca contexto e age. Quando vê algo errado, conserta em vez de apontar. Quando um colega trava, ajuda em vez de ignorar. Não contratamos para preencher vaga — contratamos pessoas que tornam o time inteiro melhor. Se você é a pessoa mais fraca do squad, ou cresce rápido ou não fica.

#EpicPerformance — Autonomia real com accountability real. Na prática: seu Lead não vai cobrar progresso se você estiver entregando. Vai cobrar se você não estiver. A métrica é resultado, não atividade. Reunião de status sem decisão é desperdício. Card atualizado sem progresso real é teatro. Performance é medida por output, não por presença.

#BetaMindset — Crescimento constante, errar rápido, aprender mais rápido. Na prática: shipar v1 imperfeito > planejar v3 perfeito. Feedback é presente, não agressão. Post-mortems sem blame — o objetivo é aprender, não punir. Se você não está desconfortável com a velocidade, provavelmente está devagar demais.

#DirectByDefault — Comunicação direta é o padrão, não a exceção. Na prática: se você tem um problema com alguém, fala para a pessoa — não para o Slack, não para um terceiro, não para o CEO antes de tentar resolver direto. Feedback é na hora, não acumulado para o quarterly. Más notícias são comunicadas rápido — surpresa negativa é a pior coisa que você pode dar ao time. O que não existe é política, triangulação ou comunicação passivo-agressiva.

#TechLovers — Replace service with software, replace human with agent. Na prática: se você está fazendo manualmente algo que uma IA pode fazer por você, está trabalhando errado. Usamos integrações MCP, Claude, automações — seu tempo é para pensar, decidir e criar. Se o seu primeiro instinto é abrir uma planilha e preencher célula por célula, pare e pergunte: "como uma IA faria isso em 10 segundos?" A plataforma da C-137 existe para que cada nova venture custe menos que a anterior.

O que esperamos de você

Entregue o que combinou, no prazo que combinou. Prazos são definidos em conjunto, mas uma vez acordados, são compromissos reais. Se vai atrasar, avise antes — nunca depois.

Comunique proativamente. Mantenha seus issues no Linear atualizados. Responda no Slack dentro de um turno. Se está travado, peça ajuda. Se terminou antes, puxe a próxima tarefa. Silêncio não é sinal de produtividade — é sinal de risco.

Entregue o seu primeiro. Sua responsabilidade primária é o que você combinou entregar. Antes de se envolver no trabalho de outra pessoa, garanta que o seu está no trilho. Ajudar é bem-vindo — mas nunca como desculpa para não ter entregue o próprio. Se o seu está em dia e você vê alguém travado, aí sim: ofereça ajuda. A ordem importa.

Use AI-first como padrão. Antes de fazer qualquer tarefa, pergunte: "uma IA pode fazer isso melhor ou mais rápido?" Se a resposta é sim, use. Não estamos pedindo que você saiba programar — estamos pedindo que pense como alguém que tem um exército de assistentes inteligentes à disposição. Porque você tem.

O que você pode esperar de nós

Clareza sobre o que importa. Você sempre vai saber qual é o North Star da venture e quais Projects entram no cycle. Se não sabe, é falha nossa — cobre.

Reconhecimento real e skin in the game. Para quem entrega consistentemente e quer construir junto no longo prazo, temos um modelo de Partnership. Não é só fee — é participação real no que estamos criando.

Feedback honesto e rápido. Não guardamos feedback para o quadrimestre. Se algo não está bom, você vai saber agora. Se está excelente, também.

Autonomia com suporte. Você é um manager of one, mas não está sozinho. Tem Lead, tem liderança, tem o squad inteiro. A iniciativa é sua — o suporte é nosso.

O Modelo Operacional

A C-137 opera com um time fulltime dedicado, organizado por thesis areas, com cultura async-first e um workflow de desenvolvimento já definido (bets → Shape Up → cycles). A plataforma da C-137 — scaffold de código, deploy pipeline, analytics padronizado, shared libs — existe para que cada nova venture custe menos que a anterior. Decisões estratégicas vivem no Venture Builder System (Notion); execução vive nos Platform Modules (código). Detalhes da arquitetura estão no Platform Vision doc.

O que este handbook cobre é a camada de gestão de pessoas que dá sustentação a tudo isso: como garantir que as cerimônias aconteçam com consistência, que cada pessoa saiba onde está e para onde vai, que metas estejam claras e mensuráveis, e que a compensação esteja alinhada com resultado real. Se você tem e-mail da C-137, é tratado igual e cobrado igual — independente de modelo de contratação.

Dois problemas específicos precisam ser resolvidos: accountability fraca (gente que some ou desacelera sem aviso) e cerimônias sem ritmo (existem no papel mas não na prática).

Princípios de Design

Visibilidade como mecanismo de accountability. Não precisamos de controle — precisamos que o trabalho de cada pessoa seja visível. Quem entrega consistentemente se destaca. Quem some, também.

Cerimônias mínimas mas inegociáveis. Poucas cerimônias, mas as que existem são obrigatórias. Faltar sem aviso é sinal sério. A consistência do ritmo é mais importante que a perfeição do formato.

Compensação como alavanca de alinhamento. O fee fixo garante estabilidade. O bônus quadrimestral é o que diferencia quem entrega de quem só cumpre horário. A conexão entre performance e recompensa financeira precisa ser direta e previsível.

Cultura é o que acontece quando ninguém está olhando. Valores escritos na parede não mudam comportamento. Consequências reais sim.

Iterate to Greatness. A primeira versão não precisa ser perfeita, mas precisa existir. Ship v1 rápido, depois melhore obsessivamente. Deadline agressivo expõe complexidade escondida. Se não tem deadline, vai demorar 3x mais. Se o deadline é de 2 semanas e demora 1 mês, ainda shipou 3x mais rápido do que sem deadline nenhum.

Handbook-First. Se algo é perguntado duas vezes, a resposta vira documentação. Se uma decisão é tomada em call, o resultado é escrito no Notion dentro de 24h. Se um processo existe só na cabeça de alguém, ele não existe. Otimizar para a velocidade de knowledge retrieval (qualquer pessoa encontra a informação sozinha), não para knowledge transfer (depender de alguém te explicar).

Managers of One. Cada pessoa na C-137 é esperada a ser capaz de definir sua própria direção, identificar o que precisa ser feito, e executar sem ser mandada. Contratar pessoas que precisam de supervisão constante é um erro de contratação, não um problema de processo.

Founder Mode. Coexiste com Managers of One — não é contradição. Managers of One significa que ninguém precisa ser gerido. Founder Mode significa que os projetos, produtos e entregas precisam ter curadoria de qualidade e consistência. São coisas diferentes: uma é sobre pessoas (autonomia), a outra é sobre o trabalho (padrão). O Venture Lead — o CEO para algumas ventures, um EIR para outras — está nos detalhes do produto, revisa entregas voltadas ao cliente, e garante que o que shipa tem o nível certo. Não está gerenciando pessoas. Está garantindo que o output coletivo tem a qualidade que a venture exige. A premissa do Manager Mode ("contrate gente boa e saia do caminho") destrói ventures em estágio inicial porque confunde autonomia de pessoas com ausência de curadoria sobre o trabalho. Na C-137, as pessoas são autônomas E o trabalho é curado. Na holding, o Business Lead opera como braço operacional do CEO, garantindo que a máquina funcione sem centralizar tudo no CEO.

1. Estrutura de Papéis

A C-137 opera em dois níveis: a holding (C-137 Labs) e as ventures (Alana Shopping, Noma Guide, etc). Cada nível tem papéis distintos com responsabilidades claras. A holding existe para criar, financiar, e dar suporte às ventures — não para gerenciá-las no dia a dia.

Princípio de design: papéis humanos existem para decisões que exigem julgamento. Tudo que é cobrança, tracking, reminder, pattern detection, e compilação de dados é responsabilidade de agents automatizados, não de pessoas. Nenhum humano na C-137 deveria gastar tempo fazendo trabalho de bot.

Papéis Humanos

CEO — Holding + Ventures selecionadas

Dono da visão, das teses e da mesa de apostas da C-137 Labs. Define quais ventures criar, matar, ou escalar. Último recurso de decisão em conflitos de prioridade entre teses. Dono do capital e da alocação de recursos entre ventures.

Na holding, o CEO define a estratégia do portfólio, conduz a Betting Table, decide compensação, e garante que a cultura da C-137 se mantenha coerente conforme o número de ventures cresce. O CEO não gerencia o dia a dia da holding — o Business Lead existe para isso.

Nas ventures, o CEO é Venture Lead de ventures selecionadas — tipicamente as mais estratégicas ou em estágio inicial onde a presença direta do fundador é crítica (ex: Alana Shopping). Nessas ventures, segue a cadência descrita abaixo no papel de Venture Lead. Nas ventures onde um EIR é Venture Lead, o CEO mantém governança via Betting Table, Initiative Reviews, e skip-level quando necessário — mas não está no dia a dia do produto.

A decisão de quando o CEO entra ou sai como Venture Lead de uma venture é estratégica: ventures novas ou pré-PMF geralmente precisam do CEO diretamente. Ventures que atingiram PMF e têm EIR forte podem transicionar. O handoff é um milestone, não um default.

Business Lead (BL) — Holding

Braço operacional do CEO na C-137 Labs. Garante que a máquina da venture builder funcione sem que tudo passe pelo CEO.

Perfil: experiência em startups e/ou consulting (McKinsey, Bain, BCG, ou equivalente em velocidade e rigor). Confortável com ambiguidade. Capaz de montar um board deck de manhã e debugar um processo de onboarding à tarde. Generalista senior que sabe quando ir fundo e quando delegar.

Responsabilidades:

Operações cross-venture: shared services (payments, auth, AI core), processos de contratação, onboarding, legal, contabilidade, compliance. Tudo que é infraestrutura da holding, não de uma venture específica. O primeiro nível de operações administrativas (invoices, expenses, time-off, onboarding checklist, contratos) é automatizado por agents — o BL intervém apenas em exceções e decisões que exigem julgamento.

GTM e validação de novas teses: antes de uma venture ter Venture Lead, o BL pode conduzir discovery, validação de mercado, e montagem do pitch inicial. Prepara a tese para que um Venture Lead (CEO ou EIR) assuma.

Handoff: o BL monta a estrutura, documenta, e passa para o time da venture. Não fica permanentemente dentro de uma venture — opera na holding e "empresta" tempo para ventures conforme necessidade. Se o BL fica mais de 50% do tempo em uma venture por mais de 2 cycles, algo está errado: ou a venture precisa de um Venture Lead, ou o BL está compensando falta de autonomia do squad.

Governança e métricas: mantém dashboards de portfólio, prepara material para Betting Table, acompanha unit economics cross-venture, monitora health de cada venture.

Reporta ao CEO. Trabalha em parceria com Venture Leads, mas não tem autoridade sobre a direção de produto de nenhuma venture — isso é do Venture Lead.

Venture Lead — Por venture (Founder Mode)

A pessoa responsável pelo sucesso de uma venture específica. Pode ser o CEO (para ventures estratégicas) ou um EIR que assumiu a venture. Mesmo título, mesma accountability. O Venture Lead opera em Founder Mode: está nos detalhes do produto, conhece cada feature, revisa cada entrega voltada ao cliente, e mantém o padrão de qualidade.

Presença na venture, não na holding. O Venture Lead revisa o trabalho da venture diretamente — features, releases, UX, comunicação com o mercado. Se algo shipa para o cliente sem review do Venture Lead (ou sem ter escolhido conscientemente não revisar), o processo falhou. Isso não significa que aprova cada commit — significa que nenhuma decisão de produto significativa, nenhuma entrega voltada para o cliente, e nenhuma comunicação externa sai sem que o Venture Lead tenha visto e aprovado.

Review Cadence (por venture). Cada venture tem a seguinte frequência de review conduzida pelo Venture Lead:

O Venture Lead começa nos detalhes e gradualmente recua conforme o Lead desenvolve muscle memory e ganha trust. Mas o recuo é conquistado, não presumido. Venture nova ou Lead novo = Venture Lead mais presente. Venture madura com Lead de track record = Venture Lead delega mais.

Skip-Level Access. O Venture Lead tem relação direta com qualquer membro do squad, não apenas o Lead. Participar de calls de squad, fazer deep dives (2-4 semanas de audit focado), e manter conversas informais com Builders. O objetivo não é bypassar o Lead — é ter informação de primeira mão sobre o produto e a execução. Leads que se sentem ameaçados por skip-level provavelmente estão escondendo algo.

Co-Hire. O Venture Lead participa de toda contratação para a venture. Não como rubber stamp, mas como entrevistador ativo e decision-maker. Num squad de 2-4, cada contratação muda a dinâmica inteira.

Deep Dives. Uma ou duas vezes por ano, o Venture Lead faz um deep dive na venture: 2-4 semanas de audit completo — produto, entregas, processos, qualidade, pessoas. "Ninguém vai ser demitido por ser honesto, me mostre o bom e o ruim."

Functional Org, não Divisional. Se uma venture crescer a ponto de criar sub-times com "managers of managers," algo está errado. Engineering, design e produto são disciplinas transversais, não silos. O Lead gerencia o trabalho da venture, as pessoas através do trabalho — não o contrário.

Quando o CEO é o Venture Lead: opera exatamente como descrito acima, acumulando com as responsabilidades da holding. Quando um EIR é o Venture Lead: opera com a mesma cadência e padrão, com governança do CEO via Betting Table e Initiative Reviews quadrimestrais.

EIR (Entrepreneur in Residence) — Programa, não role permanente

Perfil de fundador alocado ao programa da C-137. O EIR que recebe uma venture se torna Venture Lead dela — mesmo título, mesma accountability. O programa EIR é o pipeline de talentos para Venture Leads.

O EIR tem mais autonomia que qualquer outro papel. Participa da definição de apostas (não só da execução), tem voz na Betting Table para a sua venture, e potencialmente phantom equity significativa na venture que estiver construindo.

Caminho típico: o CEO ou o BL valida a tese → EIR assume como Venture Lead → se a venture atinge PMF e o EIR prova capacidade, pode se tornar CEO permanente da venture (com ajuste de equity). Se a venture pivota ou morre, o EIR pode ser realocado para outra tese ou sair da C-137.

Diferença entre EIR e BL: o BL opera na holding e "empresta" tempo para ventures. O EIR vive dentro de uma venture e é dono do resultado dela. O BL constrói a máquina. O EIR dirige o carro.

Lead — IC sênior do squad (Player-Coach)

IC sênior que acumula coordenação do squad. Não é role separado — é o que IC3+ faz naturalmente quando assume responsabilidade pelo output do grupo. Garante que as Initiatives estejam progredindo, faz code review, conduz cerimônias do squad quando necessário. Reporta ao Venture Lead da venture.

Accountability: se o squad não entrega, o Lead é o primeiro a responder. Não é culpa individual de um membro — é responsabilidade do Lead por não ter escalado o problema antes.

Coordenação é uma responsabilidade do Lead, não seu cargo principal. A maioria do tempo é IC — no código, no design, no produto. Se um Lead está gastando mais de 30% do tempo em coordenação pura, algo está errado: ou o squad cresceu demais, ou os membros não são autônomos o suficiente. Managers entediados viram micromanagers. Um Lead que não sabe fazer o trabalho que está coordenando é "um general de cavalaria que não sabe montar a cavalo" (Chesky) — não deveria ser Lead.

O objetivo de longo prazo é Make Yourself Obsolete: compartilhar contexto máximo, em formato escrito, em canal público. Se o Lead pode tirar férias de 1 semana e o squad continua operando normalmente, está acertando. Se é gargalo de informação, está falhando.

Relação com Founder Mode: o Lead é um Manager of One — opera com autonomia plena sobre como organizar seu trabalho e o do squad. Mas o Venture Lead está nos detalhes do produto. Isso significa que o Venture Lead vai revisar entregas, questionar decisões de produto, e fazer deep dives na qualidade. Não é gestão de pessoas — é curadoria do trabalho. A reação correta é: "ótimo, mais olhos no produto = melhor resultado." A reação errada é confundir review de qualidade com falta de confiança. Trust é construído pela qualidade das entregas, não pela ausência de curadoria.

Builder

Executa dentro do squad. Fulltime dedicado. Tem autonomia total sobre como e quando organizar seu dia (ver Filosofia de Horário abaixo), mas não sobre o que entregar nem quando entregar — isso é combinado no planning. Comunica progresso diariamente. Escala bloqueios imediatamente.

Agents (Automação Operacional)

Tudo que é tracking, cobrança, reminder, pattern detection, compilação de dados, e backoffice de primeiro nível é feito por agents, não por humanos. Nenhum Lead deveria gastar tempo fazendo trabalho de bot. Nenhum Business Lead deveria processar invoices manualmente. Os agents operam nos canais e escalam para humanos apenas quando julgamento é necessário.

Squad Ops

Standup Agent: Monitora se cada membro postou o update diário até 11h. Se não postou, envia DM automático perguntando se está tudo bem. Detecta padrões: 3+ faltas em 2 semanas sem aviso prévio → notifica o Lead para 1:1 de alinhamento. O agent cobra; o Lead decide o que fazer com a informação.

Deadline Agent: Monitora cards no Linear. Se um card não se move por 2+ dias, envia reminder ao owner. Se não se move por 3+ dias, notifica o Lead. Deadline approaching sem progresso → escalation automático.

Feedback Agent: Compila feedback quinzenal. Envia reminders na sexta 13h para quem não preencheu. Compila respostas para o Lead e Venture Lead.

ACK Agent: Para comunicações que exigem leitura (mudança de processo, decisão estratégica): monitora reações no post. Sem ACK em 24h → reminder no canal. Sem ACK em 48h → DM direto.

Metrics Agent: Coleta e compila métricas operacionais automaticamente: cycle time, deployment frequency, standup compliance, card health. Alimenta dashboards sem que nenhum humano precise compilar dados manualmente.

Backoffice / DP

Invoice Agent: Monitora recebimento de invoices no 1º dia útil do mês. Se não recebeu, envia DM automático ao membro. Valida formato e dados obrigatórios (valores, dados bancários, período). Encaminha para processamento. Confirma pagamento ao membro. Humano só intervém em exceção (valor divergente, dados inconsistentes, primeira invoice de novo membro).

Expense Agent: Recebe submissions de expense via canal ou form. Valida: tem comprovante? Está dentro da policy (sem classe superior, sem upgrades)? Valor dentro do range esperado? Se OK, aprova automaticamente e agenda reembolso na próxima invoice. Se fora do padrão, escala para Business Lead.

Time-off Agent: Recebe pedidos de time-off. Registra no tracking (Notion DB). Verifica conflitos (outro membro do mesmo squad no mesmo período). Se sem conflito e com 2+ semanas de antecedência, confirma automaticamente e notifica o Lead. Se há conflito ou é em cima da hora, escala para o Lead decidir. Mantém saldo atualizado.

Onboarding Agent: Quando novo membro é confirmado, dispara checklist automatizado: criação de contas (email, Slack, Linear, Notion, GitHub), envio de documentos obrigatórios, agendamento das cerimônias da primeira semana (papo com CEO, technical assignment, team meeting), envio do template de Personal README, e tracking de conclusão de cada etapa. Lead e Business Lead são notificados do progresso, não precisam gerenciar o checklist.

Contract Agent: Monitora vigência de contratos. Alerta 30 dias antes de vencimento. Compila dados para renovação (performance score, fee atual, banda salarial do nível). Gera draft de termos atualizados para review do CEO. Humano decide; agent prepara.

Princípio: se um agent pode fazer, um humano não deveria estar fazendo. Quando em dúvida, automatize primeiro, reverta se não funcionar. O primeiro nível de qualquer processo administrativo é sempre agent. Humano entra no segundo nível — quando há exceção, julgamento, ou decisão que afeta pessoas.

DRI (Directly Responsible Individual) — por Project

Cada Project no Linear tem um DRI — uma pessoa, não "o squad." O DRI é responsável pelo outcome, não só pela execução. Se o Project deu errado, a primeira pergunta é para o DRI. Se deu certo, o mérito é do DRI (e do squad que suportou). Elimina a difusão de responsabilidade que mata entregas em times pequenos.

O DRI pode ser qualquer membro, não só o Lead. Project leads rodam — não é sempre a mesma pessoa liderando. Isso desenvolve ownership em todo o squad.

Implementação: campo "DRI" em cada Project do Linear. Lead define em cada Cycle Kickoff.

Como, Quando e De Onde Trabalhamos

Remote-first, de qualquer lugar do mundo. A C-137 é 100% remota. Não existe escritório, não existe expectativa de presença física. Você pode trabalhar de casa, de um café, de outro país. Onde você está é irrelevante — o que importa é o que você entrega e se está acessível nos momentos que combinamos.

Resultados, não relógio. A C-137 não controla horário. Não existe horário de entrada, horário de saída, expectativa de estar online em horário comercial, nem monitoramento de atividade.

Quer ir à praia no meio do dia? Vai. Quer trabalhar de madrugada? Trabalha. Quer tirar a terça-feira e compensar no sábado? Faz. Quer trabalhar no domingo porque a ideia não sai da cabeça? O laptop é seu.

O que controlamos: entregas e combinados. Cada pessoa combina metas com o Lead no planning semanal. Como, quando, e de onde cumprir essas metas é decisão 100% individual. A única restrição é respeitar as cerimônias obrigatórias (standup diário até 11h, Squad Sync segunda, etc) — porque cerimônias existem para sincronizar o squad, e sincronização exige compromisso de presença nos momentos combinados.

Dito de outra forma: autonomia total sobre o tempo e o local, accountability total sobre o resultado. Se você entrega consistentemente, ninguém vai questionar como organiza seu dia. Se não entrega, o problema não é o horário — é a performance, e será tratado como tal (ver Seção 3).

Essa filosofia é possível porque contratamos "managers of one" — pessoas que não precisam de supervisão para produzir.

1.1. Career Ladder

A C-137 tem dois tracks de carreira: IC (Individual Contributor) e M (Management). Ambos são legítimos e valorizados. Não existe hierarquia entre tracks — um IC4 Staff e um M1 Lead podem ter compensação equivalente.

A maioria das pessoas na C-137 é IC. O track M existe porque coordenar squads é uma responsabilidade real que consome tempo e energia, e deve ser reconhecida separadamente — não absorvida como "extra" no dia a dia de quem já está contribuindo tecnicamente.

IC Track — Tech

Baseado no modelo de engineering levels de Google/Amazon/Meta, adaptado para o contexto de venture builder.

IC Track — Non-Tech (Design, Ops, Growth, Content, Analytics)

Mesmo princípio de progressão por scope de impacto, não por tempo de casa. Começa em IC1.

M Track — Management

O track M existe para quem quer e sabe amplificar o trabalho dos outros. Não é promoção — é mudança de track. Pagar M1 ou mais não é reward por bom trabalho técnico; é reconhecimento de que a pessoa gera mais impacto coordenando do que contribuindo individualmente.

Todo M opera como Player-Coach. Não existe gestor puro na C-137. A divisão craft/coordenação muda conforme o nível, mas craft nunca chega a zero.

Transição entre Tracks

IC → M: você precisa demonstrar que sabe amplificar o trabalho dos outros, não só o seu. Evidência: feedback que muda comportamento, remoção de blockers antes que se tornem problemas, disposição para ser accountable pelo resultado do squad. A transição é discutida no People Committee.

M → IC: legítimo e sem estigma. Nem todo mundo quer ficar em management. Se um M1 descobre que prefere contribuir diretamente, volta para IC no nível equivalente. Isso não é rebaixamento — é realinhamento.

O que muda de nível para nível

A progressão é por scope de impacto, não por tempo de casa. Cada nível é definido por: o tamanho do problema que você resolve sozinho, a quantidade de ambiguidade que você absorve sem supervisão, e o número de pessoas que se beneficiam do seu trabalho.

IC1 → IC2: Você resolve issues sem precisar que alguém defina cada passo. Você contribui para code review e qualidade. Você escala problemas proativamente.

IC2 → IC3: Você define a solução, não só executa. Você é DRI de Projects e eles são entregues no prazo. Outros membros vêm até você para tirar dúvidas. Você mentora naturalmente.

IC3 → IC4: Seu impacto vai além do Project que você está liderando. Você define padrões que a venture segue. Você resolve os problemas que ninguém mais consegue. O Venture Lead consulta sua opinião em decisões técnicas.

IC4 → IC5: Seu impacto vai além da sua venture. Você define como shared services funcionam, ou cria padrões que múltiplas ventures adotam. Você é referência da C-137 inteira na sua área.

IC para M1: Você quer e sabe amplificar o trabalho dos outros. Você dá feedback que muda comportamento. Você remove blockers antes que se tornem problemas. Você está disposto a ser accountable pelo resultado do squad, não só pelo seu.

Promoção

Promoções são discutidas no People Committee (CEO + Lead + pelo menos 1 outro lead). Não existe "ciclo de promoção" — quando a evidência está clara, a promoção acontece. Mas o critério é retrospectivo: você é promovido quando já está operando no próximo nível de forma consistente, não quando promete que vai operar.

O Lead é responsável por trazer a recomendação com evidências concretas: Projects entregues, feedback de peers, impacto documentado. O CEO valida.

Promoções são comunicadas no #c137-hq. Transparência de carreira é parte do #DirectByDefault.

Fee por Nível

Cada nível tem uma banda salarial. Dentro da banda: 75% = entrada no nível, 100% = referência, 125% = top performer pré-promoção. O midpoint é benchmarkado contra o top 10% do mercado remoto LatAm para roles equivalentes. Não pagamos pelo custo de vida local — pagamos pelo valor da contribuição. Uma IC3 em Florianópolis ganha o mesmo range que uma IC3 em São Paulo.

As bandas são comunicadas internamente. Não são publicadas externamente, mas qualquer membro pode perguntar qual é a banda do seu nível e onde está dentro dela.

Total compensation (fee + bônus quadrimestral + Venture Pool + phantom equity) mira o top 1% para os melhores performers. O fee sozinho é competitivo. As camadas variáveis são o que diferencia.

2. Cadência de Cerimônias

O ritmo abaixo é o mínimo viável. Cada cerimônia tem um dono, uma duração máxima, e uma consequência se não acontecer.

Princípio 5-Hour Meeting Rule: antes de agendar qualquer call síncrona, calcular o custo real. 5 pessoas × 1 hora = 5 horas de trabalho consumidas. Perguntar: "Isso vale 5 horas de produção? Pode ser resolvido async em um post de 15 minutos?" Se a resposta é sim para async, não vira meeting. Qualquer pessoa pode questionar "isso precisa ser uma call?" sem que seja falta de respeito — é bom senso operacional.

Calls síncronas usam o formato "Speedy Meeting": 25 min em vez de 30, 50 min em vez de 60. O tempo que sobra é buffer para a pessoa respirar entre calls.

Diário

Async Standup (obrigatório) Formato: cada membro posta no canal do squad (Slack) até as 11h no fuso do squad. Não é um status report — o Linear já mostra o que cada pessoa está fazendo. O standup captura o que o Linear não captura: momentum, confiança, e sinais de que algo precisa de atenção.

Três perguntas:

• Qual issue/project avancei e o que descobri? (Progresso real + aprendizados — não "trabalhei no card X")
• Qual é meu nível de confiança de que o Project atual shipa no prazo? (alto/médio/baixo) (Se baixo, diga por quê em uma frase)
• Preciso de alguém? (sim/não) (Se sim, marque a pessoa diretamente — não espere a weekly)

Regras:

• Bloqueios não esperam o standup. Se algo te trava, escala imediatamente no canal ou DM do Lead. O standup é para visibilidade do squad, não para resolver blockers.
• Se o Linear está atualizado e o dia foi execução pura sem novidade, "Execução normal, confiança alta, não preciso de ninguém" é um standup válido. Ninguém precisa inventar drama.
• Se não tem nada para reportar porque não trabalhou, diga isso. Transparência > performance de produtividade.

Dono: cada pessoa é dona do seu update. O Standup Agent monitora compliance — o Lead intervém apenas quando o agent detecta padrão.

Consequência de não postar: o Standup Agent envia DM automático perguntando se está tudo bem. Se virar padrão (3+ vezes em 2 semanas sem aviso), o agent notifica o Lead, que puxa 1:1 de alinhamento.

Update de cards no Linear (obrigatório) Cards devem refletir o status real no fim do dia. Se um card não se move por 2+ dias, o Deadline Agent envia reminder ao owner. Se persiste por 3+ dias, notifica o Lead. Não é micromanagement — é visibilidade automatizada.

Semanal

Squad Sync — Segunda-feira, 25 min max (obrigatório) Formato: call síncrona. O Lead conduz. Conteúdo: o que entra no cycle dessa semana, quem está fazendo o quê, dependências entre membros, riscos identificados. Não é status report — é planning.

Dono: Lead.

Technical Alignment — Quinta-feira, async ou call de 25 min O Lead revisa entregas técnicas em andamento. Code review, arquitetura, qualidade. Pode ser async (comments no PR) ou síncrono se houver discussão relevante.

Dono: Lead.

Weekly Project Update — automático O Lead publica um update por Project ativo direto no Linear. Status, progresso, blockers, health (The Needle: On Track / At Risk / Off Track). Auto-posted no canal do squad via integração Linear → Slack. Todo mundo acompanha progresso sem precisar de meeting adicional.

Quinzenal

Feedback Bidirecional — Sexta-feira Formato: formulário assíncrono ou mensagem estruturada. Builder envia feedback sobre o squad e o Lead (sexta 14h). Lead responde com feedback individual para cada membro (sexta 20h).

Conteúdo mínimo do feedback:

• O que está funcionando bem
• O que precisa melhorar
• Reconhecimento (Clappys — ver seção de cultura)

Feedback crítico deve ser dado rápido, não guardado para a sexta-feira. "Quando você atrasa feedback crítico, você rouba da pessoa a chance de melhorar." O quinzenal é o backstop, não o único canal.

Release Review — Sexta-feira (quando aplicável) Validação interna antes de ir para produção. O squad revisa junto o que está sendo entregue. Funciona como quality gate.

Leads Sync — Quinzenal, 25 min (síncrona) Apenas Leads, sem CEO. Grooming cross-thesis: o que cada squad está construindo que pode impactar outro, oportunidades de reuso de shared services, dependências cruzadas, troca de contexto técnico. Não é decision-making — isso fica na betting table. Isso é preparação e alinhamento lateral.

Dono: Leads (rotativo — um diferente conduz a cada sessão).

Mensal

1:1 Venture Lead ↔ Lead — 45 min Conversa individual. Não é status report — é desenvolvimento, desafios, alinhamento estratégico, e saúde do squad. O Lead traz:

• Progresso das Initiatives e North Star Metric
• Qualquer risco de people (alguém desengajando, conflito, etc)
• Pedidos de recurso ou decisão

1:1 Lead ↔ Builder — 25 min (frequência adaptável) Novo membro: semanal durante os primeiros 45 dias. Após 45 dias: quinzenal. Após 90 dias: mensal. Se em algum momento o membro ou o lead sentir necessidade de aumentar a frequência, aumenta sem burocracia.

O Builder traz:

• Como está se sentindo sobre o trabalho
• O que precisa para ser mais efetivo
• Feedback sobre o squad e a liderança

O Lead traz:

• Feedback direto sobre performance
• Expectativas claras para o próximo período
• Reconhecimento específico (não genérico)

Perguntas fixas em toda 1:1 (template no Notion):

• "O que você precisa para fazer seu trabalho melhor?"
• "O que eu posso fazer melhor como seu lead?"
• "Teve alguma informação que você precisou e não conseguiu encontrar no Notion?"

Heartbeat (Cycle Summary) — async, publicado no Notion No fim de cada cycle, o Lead escreve um resumo: o que foi shipped, o que aprendemos, o que ficou de fora e por quê, o que muda para o próximo cycle. Publicado no Notion, visível para toda a C-137. Substitui o Monthly Review quando o cycle e o mês não coincidem — o Heartbeat é ancorado no ritmo real de entrega, não no calendário.

Social Question Bot — mensal Bot mensal no Slack (#cultura ou #random) com uma pergunta social: "O que você está lendo?", "Experimentou algo novo esse mês?", "Qual foi a última coisa que te inspirou?", "Melhor refeição que você comeu essa semana?" 100% opcional, sem pressão. Serve para manter conexão humana e descobrir quem são as pessoas além do trabalho.

A cada Cycle

Cycle Kickoff — início do cycle (async) No primeiro dia de cada cycle, o Lead publica um post escrito no canal do squad com: o que foi apostado neste cycle, quais Projects entram, quem é DRI de cada um, qual é o appetite (tempo alocado), e o que NÃO entra. Qualquer pessoa pode comentar ou fazer perguntas. Se não está no Kickoff, não entra no cycle.

Radical Deadline Compression aplicada aqui: antes de definir o appetite, perguntar "O que seria necessário para shipar isso em metade do tempo?" O appetite de cada Project no cycle (Shape Up) já serve como deadline — o princípio é sempre questionar se pode ser menor.

Cooldown — 2 semanas entre cycles Após cada cycle de 6 semanas, o squad entra em cooldown de 2 semanas. É o momento dedicado a tudo que não cabe numa aposta shaped: tech debt, refatoração, bugs menores, code review mais profundo, UX polish, melhoria de testes, exploração técnica, small fixes, e pair building cross-squad.

O cooldown é o mecanismo de qualidade da C-137 — não existe dia fixo dedicado a debt durante o cycle. Durante as 6 semanas, o squad está 100% focado nos Projects apostados. Durante o cooldown, o tipo de trabalho muda: o foco é "o que está errado" em vez de "o que está faltando."

O que acontece no cooldown:

• Tech debt e refatoração anotados durante o cycle (label "Cooldown" no Linear)
• Bugs P2 acumulados
• Exploração: spikes técnicos, protótipos, ideias que alguém quer testar antes de virar candidate project
• Atualização de documentação (Notion, READMEs, runbooks)
• Pair building sessions cross-squad
• Heartbeat (cycle summary) — escrito no cooldown enquanto o contexto está fresco

O cooldown não é férias — é trabalho com cadência diferente. O Lead publica uma lista priorizada (async, no canal do squad), e cada membro escolhe o que pegar. Autonomia máxima, expectativa de output se mantém.

Cadência macro: 6+2, 6+2 = 1 quadrimestre. Cada quadrimestre contém exatamente 2 cycles completos (16 semanas). O ano fiscal (abr-mar) contém 3 quadrimestres, totalizando 6 cycles por ano.

Quadrimestral

Culture Check-in — 25 min, síncrono (Venture Lead ou Lead ↔ cada membro) Conversa separada da 1:1 de performance. Foco exclusivo em como a pessoa está se sentindo no time, se os valores da C-137 estão vivos na prática, se algo está incomodando que não aparece nos feedbacks quinzenais. Perguntas-guia:

• Você se sente parte do time ou está operando solo?
• Tem algo na cultura que te incomoda mas você nunca falou?
• O que a gente deveria parar de fazer? O que deveria começar?
• Você consegue tomar decisões no seu trabalho sem precisar esperar aprovação do lead?

Esse check-in pega sinais de desengajamento e erosão cultural antes que virem desligamento. É o mecanismo de early warning mais subestimado que existe.

Initiative Review & Planning — Call de 50 min com CEO + Venture Leads + Leads Review do quadrimestre: como a North Star moveu? Quais Initiatives progrediram, quais travaram, quais precisam pivotar? Em seguida, define novas Initiatives ou ajusta as existentes para o próximo quadrimestre. Cada venture traz seus candidate Projects para a betting table. BLs apresentam métricas consolidadas do portfólio.

Quadrimestral Sync — Call de 50 min com todos (CEO + Business Leads + Venture Leads + Leads + squads) Compartilhamento cross-squad: o que cada tese entregou, o que aprendemos, o que muda. Não é review de performance — é alinhamento e contexto.

Performance Review Individual Avaliação formal da contribuição de cada pessoa. Baseada em dados, não em impressão. Ver seção de KPIs.

Meeting Audit O Lead revisa todas as cerimônias do squad: esta meeting ainda é necessária? Pode ser async? Quais participantes são realmente essenciais? Alguma cerimônia nova surgiu informalmente e deveria ser formalizada? Aplica o 5-Hour Meeting Rule retroativamente.

Cerimônias se acumulam naturalmente. A auditoria previne "meeting bloat" antes que ele mate a produtividade.

Hack Day (1 dia por quadrimestre) Um dia por quadrimestre onde todo mundo para o trabalho regular e constrói algo por conta própria. Pode ser feature, tool interno, protótipo de nova tese, integração, qualquer coisa. Apresentação rápida no final do dia (5 min por pessoa, async vídeo também aceito). Sem julgamento, sem expectativa de produção.

O Hack Day serve três propósitos: gera ideias que às vezes viram projetos reais, dá espaço criativo que o trabalho diário não dá, e cria um momento compartilhado que fortalece o time.

Cadências de Portfólio (Holding)

As cerimônias acima são de squad/venture. Abaixo estão as cadências da holding — onde se decide o que construir, o que matar, e como o portfólio evolui. Mesmo que você não participe diretamente de todas, entender que existem explica por que certas decisões acontecem.

Triagem Idea Box — Semanal, 30 min, Leads Toda segunda, os Leads revisam submissões na Idea Box (Notion). Qualquer pessoa pode submeter uma ideia — a fricção é mínima. A triagem classifica cada entrada pelo PMF Framework: Hair on Fire (cliente já busca solução ativamente, prioridade máxima), Hard Fact (problema aceito como normal, precisa convencer que vale mudar), ou Future Vision (mercado precisa ser criado, C-137 geralmente evita). Regra: mesmo que a ideia proposta seja fraca, se o problema é Hair on Fire + Core AI, explorar soluções alternativas. Priorizar o problema, não a solução.

Betting Table — Bi-semanal, 2h, CEO + Venture Leads + EIRs A cerimônia mais importante do venture builder. Onde se aprovam novas apostas, se decidem transições de stage, e se matam ventures que não passaram nos kill criteria. Funciona como Shape Up adaptado: candidatos a bet são apresentados com thesis fit, acquirer fit score, shared assets, approach (Replacement / Augmentation / Net New), e kill criteria. O exit path é pensado antes de construir.

Portfolio Review — Mensal, 1h, CEO + Business Lead Primeira segunda do mês. Visão consolidada de todas as ventures ativas: MRR, clientes, gross margin, NRR, CAC payback, health status. BLs preparam o material. O objetivo é identificar rapidamente quais ventures performam e quais precisam de intervenção ou kill decision.

EIR Review — Mensal, 1h, CEO + Venture Leads + EIRs Segunda segunda do mês. Foco nas pessoas, não nos números: como cada EIR está performando, o que precisa de suporte, se alguma realocação faz sentido. É o mecanismo que garante que EIRs não fiquem presos em ventures que deveriam ter sido killed.

M&A Intelligence Review — Mensal, 1h, CEO + Leads Terceira segunda do mês. Atualização do mapa de strategic acquirers: novos players, mudanças de estratégia de aquisição, fit scores atualizados. Alimenta a Betting Table com contexto de exit.

Thesis Review — Trimestral, 2h, CEO + Leads Revisão profunda de cada tese do portfólio: TAM atualizado, acquirers mapeados, bets ativas vs. alvo, performance agregada. Pode resultar em nova tese, pivot de tese existente, ou encerramento de tese. Shared Assets Review (1h, Leads + Tech Leads) segue na semana seguinte — quais assets podem ser reusados, quais precisam de investimento.

Kill Decision Meeting — Ad-hoc, 1h, CEO + Venture Lead + Lead Quando uma venture atinge seus kill criteria pré-definidos. Não é negociável adiar. Checklist: documentação de learnings, shared assets preservados, EIR realocado ou desligado, Linear Initiative arquivada, post-mortem documentado. Matar rápido é tão importante quanto construir rápido.

Anual

Annual Offsite (presencial, 3-5 dias) Uma vez por ano, o time inteiro se encontra presencialmente. Agenda intencionalmente leve: algum alinhamento estratégico, mas principalmente tempo desestruturado juntos. Coworking, explorar a cidade, refeições juntos. O objetivo é construir confiança que sustenta o restante do ano remote.

Para time de 6-12 pessoas, uma cidade hub no Brasil funciona. Combinar com o Initiative Review & Planning do T1 ou T3. Quando o time crescer e houver concentração geográfica, considerar coworking meetups nos clusters.

3. Metas e Acompanhamento de Performance

Framework: Initiatives + North Star Metric + Projects

Não usamos OKRs. OKRs criam burocracia de cascateamento, ficam desatualizados no meio do quadrimestre, e forçam métricas artificiais em times que deveriam estar focados em shipping. Em vez disso, usamos o modelo que o Linear pratica internamente e que já se alinha com nosso workflow de bets e Shape Up:

North Star Metric (por venture) — O único número que importa para a venture neste momento. Muda conforme o estágio. Exemplos: Alana Shopping em early-stage pode ser "merchants com integração ativa"; uma venture pós-PMF pode ser "MRR". Cada venture tem apenas uma. Sem exceção.

Initiatives (no Linear) — Goals estratégicos de alto nível. Representam as apostas aprovadas na betting table. Cada Initiative tem um owner (Lead), um target date, e um health status. Não são métricas — são direções.

Projects (no Linear) — A unidade real de planejamento e execução. Cada Initiative contém vários Projects. Cada Project tem escopo definido, DRI atribuído, prioridade (High / Medium / Low / No priority), e issues concretas. Isso é o que o time vê e trabalha no dia a dia.

Project Updates (semanal) — O Lead publica um update por Project ativo, direto no Linear, com The Needle (On Track / At Risk / Off Track). Isso substitui a necessidade de um "goal review" separado — o progresso é visível em tempo real. O CEO e outros Leads podem ver todos os Needles de uma vez (Mission Control view) sem entrar em cada squad.

A hierarquia fica assim:

North Star Metric (por venture)
└── Initiative (aposta estratégica)
    ├── Project A (workstream com escopo definido) — DRI: [nome]
    │   ├── Issue 1
    │   ├── Issue 2
    │   └── Issue 3
    ├── Project B — DRI: [nome]
    └── Project C — DRI: [nome]

Continuous Planning (em vez de ciclos rígidos de OKR)

Em vez de parar tudo a cada quadrimestre para definir OKRs, usamos continuous planning:

Ideias viram candidate projects o tempo todo — quando um insight de cliente, uma oportunidade técnica, ou uma ideia do time surge, ela é triada e organizada como um candidate project no Linear. Não espera o próximo "planning cycle".

A cada ciclo de Shape Up (6 semanas), revisamos prioridades — quais Projects promover para execução? Quais manter como candidatos? Quais descartar? Isso acontece na betting table, que já existe no workflow.

A cada quadrimestre, revisamos a North Star e as Initiatives — a direção estratégica está correta? A North Star ainda é a métrica certa para este estágio? Alguma Initiative precisa ser adicionada, pausada, ou encerrada?

Isso elimina o "blank page problem" do planejamento quadrimestral. Quando você senta para decidir o que fazer no próximo ciclo, já tem uma lista curada de Projects candidatos esperando.

KPIs do Squad (coletivos)

Cada squad acompanha métricas operacionais que indicam saúde da execução. Não são metas formais — são sinais.

Squad de Produto (ex: AI Commerce)

• Entregas no prazo do cycle (% de Projects completados dentro das 6 semanas)
• Velocidade de ciclo (tempo médio de issue aberta → merged)
• Cobertura de qualidade (% de PRs com review aprovado antes de merge)
• Bugs em produção (tendência — deve cair com cooldown dedicado + Zero-Bug Policy)
• Tech debt resolvido por cooldown (items fechados vs acumulados)
• North Star Metric da venture (a que realmente importa)

Squad de Plataforma (ex: C-137 Platform)

• Uptime dos shared services
• Tempo de onboarding de nova venture (dias de setup inicial → primeiro deploy)
• Issues de infraestrutura escaladas (menos = melhor)
• Reuso efetivo (% das ventures usando shared services vs construindo do zero)

KPIs Individuais (accountability)

Não são metas formais — são sinais de saúde operacional. Medidos automaticamente ou pelo Lead.

Consistência de presença

• Async standup postado no prazo (% de dias)
• Cards atualizados no Linear (% de dias)
• Participação em cerimônias obrigatórias (% de presença)

Entrega

• Issues completadas dentro do cycle commitment
• Qualidade do código (PRs aprovados em first review vs revisions necessárias)
• Blockers escalados proativamente vs descobertos pelo Lead

Colaboração

• Clappys recebidos (reconhecimento dos pares)
• Contribuição em code review de outros membros
• Comunicação proativa em caso de problema
• Participação em Pair Building Sessions (ver seção 9)

Scoring Quadrimestral

A cada quadrimestre, cada pessoa recebe um score baseado em 3 dimensões:

Scores são calibrados pelo Lead e validados pelo CEO.

Performance Rating (Quadrimestral)

Além do score numérico (0-100), cada membro recebe um rating qualitativo no Performance Review quadrimestral. O rating é uma avaliação holística do Lead, validada pelo CEO.

O cap de ~5% no "Excepcional" existe para evitar inflação de rating. Se todo mundo é excepcional, ninguém é. A disciplina de manter distribuição realista é o que torna o rating significativo. Quando um Lead quer dar "Excepcional" para alguém, precisa justificar com evidência concreta no People Committee.

Rating "Abaixo das Expectativas" por 2 quadrimestres consecutivos aciona automaticamente o Improvement Plan (ver Progressive Discipline).

Bi-Weekly Feedback Template

O feedback quinzenal do membro para o Lead segue esta estrutura. Responda cada pergunta com substância — "tudo bem" ou "nada a dizer" não é aceitável.

Sobre sua entrega:

1. Qual foi sua contribuição mais significativa nestas 2 semanas?
2. O que ficou abaixo do que você esperava entregar? Por quê?
3. Quais foram suas maiores dificuldades e como solucionou?

Sobre o squad:

1. Alguém te ajudou de forma significativa? Quem e como?
2. Algum processo ou ferramenta está te atrapalhando?
3. Algo está impedindo o squad de performar melhor?

Sobre crescimento:

1. O que você aprendeu nestas 2 semanas?
2. Em que área quer se desenvolver no próximo mês?

Clappys: Distribua até 2 Clappys para colegas que se destacaram (nome + motivo específico).

3.1. Progressive Discipline

Quando a performance não atende ao esperado, o processo é claro, documentado, e justo. Ninguém é pego de surpresa.

Estágio 1: Feedback Direto O Lead identifica o gap e dá feedback direto no 1:1. Específico, com exemplos. "Nos últimos 2 cycles, 3 dos 4 Projects que você liderou atrasaram. O squad está compensando, e isso não é sustentável." Documentado no Notion (nota do 1:1). Prazo para melhoria: próximo quadrimestre.

Estágio 2: Improvement Plan (30 dias) Se após o feedback direto não houve melhoria visível, ou se o rating quadrimestral é "Abaixo das Expectativas" por 2 quadrimestres consecutivos, o Lead formaliza um Improvement Plan escrito.

O Improvement Plan contém: gaps específicos documentados, objetivos mensuráveis para os próximos 30 dias, check-ins semanais com o Lead, e consequência explícita ("se os objetivos não forem atingidos em 30 dias, o caso vai para o People Committee").

O membro assina (ACK) o Improvement Plan. Não é punição — é última oportunidade estruturada.

Estágio 3: People Committee Se o Improvement Plan não foi cumprido, o caso vai para o People Committee (CEO + Lead + 1 outro lead). O Committee decide: extensão do plan (raro, só se houve progresso parcial claro), realocação para outro squad ou role (se o problema é fit, não competência), ou desligamento.

Estágio 4: Offboarding Se o People Committee decide pelo desligamento: comunicação direta e respeitosa, cumprimento das condições contratuais, e processo limpo. Ninguém é humilhado na saída. O Lead comunica ao squad de forma factual, sem drama.

Aceleradores: Algumas situações pulam estágios. Fraude, violação de confidencialidade, assédio, ou abandono de trabalho sem aviso levam diretamente ao People Committee (Estágio 3), sem necessidade de Improvement Plan.

4. Compensação: Partnership, não Emprego

Filosofia

Existe trabalho e existe a obra da sua vida. O tipo de trabalho que tem a sua impressão digital. O tipo que você não aceita fazer pela metade. Que te faz abrir o laptop no domingo porque a ideia não para de te puxar.

Na C-137, você constrói ventures que não existiriam em nenhum outro lugar. Não são projetos de consultoria. Não são features dentro do produto de outra pessoa. São empresas reais, com clientes reais, que resolvem problemas que ninguém mais está resolvendo da forma como nós resolvemos. Ninguém vem para a C-137 para jogar seguro. Vem para que o trabalho represente algo grande.

A compensação é construída para refletir isso. A C-137 opera como partnership: quem constrói, ganha junto quando o negócio cresce. Não existe teto de upside. Quanto mais as ventures crescem, mais todo mundo ganha — inclusive quem está em outra venture, porque fazer parte da rede já te conecta ao sucesso do portfólio inteiro.

A contrapartida é clara: a C-137 exige excelência. A carga de trabalho é alta, a intensidade é real, e espera-se que cada pessoa opere no limite do que consegue entregar. Quem entra sabe no que está entrando. Quem fica, é porque quer construir algo que importa e ser recompensado por isso.

O prêmio por resultado excepcional não é "trabalhar menos." É ganhar mais, e ter construído algo que você pode apontar e dizer: isso existe por minha causa.

Estrutura de Compensação (4 camadas)

Camada 1: Fee Fixo Mensal (estabilidade) A base contratual. Paga contra invoice, primeiro dia útil do mês. Revisada anualmente ou em caso de mudança significativa de escopo.

Cada nível da Career Ladder tem uma banda salarial. Dentro da banda: 75% = entrada no nível, 100% = referência, 125% = top performer pré-promoção. O midpoint é benchmarkado contra o top 10% do mercado remoto LatAm para roles equivalentes, ajustado anualmente. Location-independent: uma IC3 em Florianópolis ganha o mesmo range que uma IC3 em São Paulo.

O fee é o piso. Garante que ninguém se preocupe com subsistência enquanto constrói. Mas não é o que torna a C-137 financeiramente interessante — as camadas 2, 3 e 4 são.

Camada 2: Performance Bonus Quadrimestral (execução) Variável atrelada ao score quadrimestral individual (ver Seção Performance). É o mecanismo que separa "cumprir contrato" de "gerar resultado."

Multiplicador por nível (aplicado sobre o bônus base):

Exemplo: IC3 Senior Builder com fee de R$ 20.000 que atinge score 92 recebe bônus de R$ 20.000 × 100% × 1.25 = R$ 25.000 ao fim do quadrimestre.

O bônus é pago no primeiro mês do quadrimestre seguinte, junto com a invoice regular.

Bônus Anual Consolidado: no final do ano fiscal (março), a média dos 3 scores quadrimestrais determina um bônus anual adicional para quem manteve consistência. Piso: média ≥ 70 para ser elegível. O multiplicador por nível também se aplica.

Camada 3: Venture Pool (crescimento compartilhado) A cada quadrimestre, o CEO define pools financeiros que recompensam tanto quem está construindo a venture que está crescendo, quanto quem faz parte da rede C-137 como um todo.

O princípio: estar na venture certa no momento certo deve ser recompensado. Mas fazer parte da C-137, compartilhar infra, conhecimento e cultura, também vale algo.

Pool da Thesis (multiplicador maior). Distribuído entre os membros do squad da venture que gerou resultado. Pool Geral da C-137 (multiplicador menor). Distribuído entre TODOS os membros, independente da venture.

Multiplicadores de distribuição por nível:

O CEO define o tamanho de ambos os pools a cada quadrimestre, considerando: receita das ventures, margem, estágio, cash position, e milestones atingidos. Não é fórmula fixa — é decisão do CEO calibrada pela realidade do negócio. Os pools e a lógica de distribuição são comunicados com transparência.

Ventures pré-receita podem ter pool de thesis baseado em milestones (lançamento, primeiro cliente, PMF signals). Os pools crescem conforme o portfólio cresce.

Camada 4: Phantom Equity (upside de longo prazo) Para membros com contribuição de fundador na venture. Phantom equity é atrelada a evento de liquidez (venda, fundraise, etc). Vesting padrão: 4 anos, cliff de 1 ano.

Rebalanceamento anual: A cada ano fiscal, o phantom equity pode ser ajustado com base na performance. Quem consistentemente supera expectativas pode receber grants adicionais. Quem está abaixo pode ter o vesting pausado. Isso garante que equity flua para quem está gerando valor — não para quem simplesmente permaneceu.

Phantom equity é formalizada por contrato específico de phantom equity/SAR (Stock Appreciation Rights). Funciona como bônus atrelado a evento de liquidez sem criar vínculo societário.

Revisão de Fee

Fees são revisados uma vez por ano, no início do T1 (abril). Critérios:

• Score médio dos últimos 3 quadrimestres ≥ 80
• Promoção de nível na Career Ladder (ajuste automático para a banda do novo nível)
• Benchmark de mercado (se está abaixo da banda, ajusta independente de score)
• Inflação acumulada (IPCA) — a revisão deve considerar poder de compra

Não existe aumento automático. Existe revisão baseada em dados.

O que NÃO oferecemos (e por quê)

Não oferecemos benefícios corporativos tradicionais (VA, VR, plano de saúde). A proposta de valor é diferente: ventures que não existiriam sem você, autonomia real para construí-las, upside financeiro direto quando elas crescem, e a rede de uma venture builder que te expõe a múltiplos negócios simultaneamente.

O que investimos para que todo mundo opere no melhor nível: acesso a ferramentas e plataformas pagas pela C-137 (as melhores do mundo — AI tools, dev tools, design tools), flexibilidade real de horário (async-first, sem horário fixo), Annual Offsite presencial (3-5 dias, empresa paga), Hack Day quadrimestral (tempo para exploração criativa e inovação), e Birthday Off.

5. Cultura na Prática

Os valores da C-137 (#AwesomePeople, #EpicPerformance, #BetaMindset, #DirectByDefault, #TechLovers) estão definidos no início deste handbook. Esta seção define como eles se materializam no dia a dia operacional.

Reconhecimento

Clappy System — Reconhecimento peer-to-peer. A cada feedback quinzenal, cada pessoa distribui até 2 Clappys para colegas que se destacaram. Isso cria visibilidade sobre quem realmente impacta o squad, direto da perspectiva dos pares — não do gestor.

Clappys não têm reward material direto. O reconhecimento é público e registrado — aparece no histórico e alimenta a dimensão "Cultura & Colaboração" do score quadrimestral, que por sua vez impacta o bônus. O caminho do Clappy até o dinheiro passa pela performance, não pelo atalho.

Fast Feedback — Feedback crítico é dado na hora, não guardado para a sexta-feira. "Quando você atrasa feedback crítico, você rouba da pessoa a chance de melhorar." O feedback quinzenal é o backstop, não o único canal.

Feedback bom é específico ("a forma como você refatorou o módulo X economizou 2 dias de trabalho do squad"), honesto ("você travou por 3 dias sem escalar, e isso atrasou a release"), e construtivo ("sugiro que na próxima vez, se travar por mais de 4 horas, poste no canal do squad").

A qualidade do feedback que você dá é tão importante quanto o que recebe. Feedback genérico ("tá tudo bem", "nada a dizer") é pior que não dar feedback. Se alguém consistentemente dá feedback sem substância, o Lead endereça no 1:1.

Comunicação

Low-Context Communication — Ao comunicar por texto, sempre fornecer o máximo de background possível. Assume que a pessoa não tem nenhum contexto. Não diga "sobre aquilo que conversamos" — diga "sobre a decisão de usar Stripe para o checkout da Alana, que discutimos na call de segunda." Em time remote e async, ambiguidade mata velocidade.

ACK Process — Para comunicações que exigem que todo mundo leia (mudança de processo, novo modelo de compensação, decisão estratégica): postar no Slack + pedir reação explícita (emoji 👀 = "li e entendi"). O ACK Agent monitora: sem ACK em 24h, reminder automático no canal. Sem ACK em 48h, DM direto. Ninguém pode dizer "não vi."

HQ Channel — Canal central no Slack (#c137-hq) para announcements que afetam a empresa inteira: novas contratações, mudanças de processo, milestones alcançados, decisões estratégicas, comunicação de Venture Pool quadrimestral. É o canal da C-137 como organização.

Suggestion Box — Canal assíncrono (#improvements no Slack) onde qualquer membro pode sugerir melhorias. CEO ou Leads revisam quinzenalmente e respondem a cada sugestão. Sugestões sem resposta em 2 semanas = falha do processo, não da pessoa que sugeriu.

Disagree and Commit — Todo mundo pode discordar durante a discussão, mas uma vez que a decisão é tomada (pelo DRI, Lead, ou CEO), todos comprometem com a execução. Não existe sabotagem passiva. Se a decisão provar-se errada, o grupo aprende junto — não existe "eu avisei."

JOMO (Joy of Missing Out) — Em time async, é impossível e desnecessário acompanhar tudo em tempo real. Se algo é realmente importante, vai chegar pelo ACK process ou pelo standup. Ninguém precisa estar online o tempo todo, ninguém precisa ler todas as threads.

Quando usar o quê — guia rápido de ferramentas:

Regra: se a informação precisa sobreviver mais de 1 semana, vai pro Notion ou Linear. Se é efêmero, Slack. Se envolve código, GitHub. Se é externo, email. Se precisa de voz, call — mas documente o resultado em texto depois.

Qualidade como Disciplina

Zero-Bug Policy com SLA — Bugs em produção são prioridade imediata, não vão pro backlog.

Dashboard semanal de bugs revisado pelo Lead. Debt técnico acumulado é o assassino silencioso da velocidade.

Internal Dogfooding com Feature Flags — Toda feature nova é shippada primeiro atrás de feature flag para o time interno. O squad usa o produto antes de qualquer usuário externo: Ship → internal flag → time testa por 2-3 dias → release para beta users → release geral.

Conexão Humana em Time Remote

Personal READMEs — Cada membro cria um README pessoal (template no Notion): como prefere se comunicar, horários de trabalho, o que te irrita, o que te motiva, como dá e recebe feedback, timezone, interesses fora do trabalho. Usado no onboarding e quando dois membros começam um projeto juntos pela primeira vez.

Coffee Chats — Call informal de 25 min entre dois membros antes de começarem um projeto juntos pela primeira vez, ou entre membros de squads diferentes para construir relações cross-thesis. Não é cerimônia formal — é prática encorajada quando faz sentido.

Pair Building Sessions — Sessões opcionais de 60-90 min onde dois membros resolvem um problema juntos em tempo real (call com screen share). Pelo menos 1x por semana por squad recomendado. Especialmente valioso para onboarding (sênior + novo) e problemas complexos.

Informal Communication Channels — Canais de Slack opcionais: #random, #off-topic, e quaisquer canais temáticos que o time quiser criar. A existência desses canais sinaliza que a empresa valoriza as pessoas como pessoas. Leads dão o exemplo participando.

Functional Cross-Pollination — Quando houver 2+ membros com o mesmo role em squads diferentes, criar um canal de troca (#engineering no Slack). Não é reporting line — é comunidade de prática informal.

Regras Inegociáveis

Regra do "Não Desapareça" Se vai ficar offline, avise no canal do squad antes. Não precisa dar detalhes — só precisa avisar. Desaparecer sem aviso afeta o squad inteiro.

Onboarding e Avaliação Inicial (45 Dias)

Vamos ser diretos: muita gente assume que as primeiras semanas são para "se ambientar". Na C-137, não são. Os primeiros 45 dias são o período de avaliação mais rigoroso que a pessoa vai viver aqui — mais intenso do que qualquer review quadrimestral que venha depois. A velocidade com que alguém absorve contexto, entrega resultado real, e se integra ao squad diz mais sobre fit do que qualquer entrevista.

Cada dia conta. No dia 15 há uma avaliação formal. No dia 45, uma decisão binária de continuar ou não. Não existe margem de cortesia, e não existe "vamos dar mais tempo pra ver." Quem entra na C-137 sabe que está sendo avaliado desde a primeira hora.

Novo membro entra como fulltime desde o dia 1. Full ownership from day 1. Não existe versão leve das primeiras semanas — a versão leve é a saída.

Semana 1 (Dia 1-7): Contexto + Primeira Entrega

O Lead é responsável por:

• Antes da chegada: issue real pronta para o novo membro, acesso a Linear/Notion/Slack configurado
• Dia 1: Papo com CEO (25 min) + Technical Assignment + Squad meeting + leitura do README dos colegas
• Dia 1: Novo membro cria seu Personal README
• Dia 2: Ambiente configurado (clone do template, primeiro deploy). Pode fazer merge em produção com review.
• Dia 2-3: Pair Building Session com membro sênior do squad
• Dia 3-5: Primeira entrega real (issue pequena, fim a fim)
• Dia 7: Check-in com Lead — está entendendo o contexto? Está produzindo?

Se no dia 7 a pessoa não completou nenhuma entrega real, é sinal de fit problem. Melhor endereçar cedo do que arrastar.

Marco de 15 Dias: Primeira Avaliação Formal

O marco de 15 dias não é um "check-in informal." É uma avaliação estruturada onde o Lead confronta dados reais: quantas entregas a pessoa completou, com que qualidade, com quanta autonomia. As perguntas são diretas: a pessoa está entregando no ritmo esperado? Absorveu o contexto da venture e do squad? Opera com autonomia ou precisa de hand-holding constante? A qualidade do output está no nível que o squad precisa?

Se a resposta a qualquer dessas perguntas é "não", o Lead comunica com clareza: "Você tem 30 dias para demonstrar mudança concreta. Se no dia 45 a situação não mudou, encerramos." Sem rodeios, sem ambiguidade. Esse aviso é a oportunidade real — quem leva a sério, corrige. Quem não leva, confirma a decisão do dia 45.

Marco de 45 Dias: Decisão Go/No-Go

No dia 45, Lead e CEO revisam juntos. A decisão é binária: a pessoa fica ou sai. Não existe "vamos dar mais uma chance." Não existe "está melhorando aos poucos." Se em 45 dias a pessoa não demonstrou capacidade de operar no nível da C-137, manter é injusto com o squad inteiro que está compensando. O custo de arrastar uma decisão de fit por mais 30-60 dias é altíssimo — para o squad e para a pessoa.

Se a decisão é "fica", o membro entra na cadência normal: 1:1 quinzenal, feedback quinzenal, performance review quadrimestral. Se a decisão é "não fica", comunicação direta e respeitosa, cumprimento das condições contratuais, e encerramento limpo.

A mensagem no onboarding é explícita: "Os primeiros 45 dias são avaliação mútua — e nós levamos isso a sério. Dia 15 tem avaliação formal. Dia 45 tem decisão de continuidade. Nós avaliamos você, e você avalia a C-137. Aqui a carga de trabalho é alta, buscamos excelência, e distribuímos o resultado financeiro com quem constrói. Se isso te motiva, você está no lugar certo. Se em algum momento perceber que não é, nos diga — é melhor para todo mundo."

Visibilidade de Performance

O progresso das Initiatives e da North Star é público. Heartbeats são visíveis para toda a C-137. Project Health (The Needle) é visível em Mission Control. Scores quadrimestrais são compartilhados com o squad (não o detalhe individual, mas o resultado coletivo e tendências). Venture Pool quadrimestral é comunicado com transparência: tamanho do pool e lógica da distribuição.

Isso cria alinhamento: todo mundo vê o progresso, todo mundo entende a conexão entre resultado e recompensa.

6. Fluxo de Escalação

Quando algo dá errado, o caminho é claro:

Nível 1: Squad resolve internamente Membro trava → posta no canal do squad → colega ou Lead destrava. A maioria dos problemas morre aqui.

Nível 2: Lead intervém Problema persiste por 2+ dias, ou é conflito entre membros, ou é risco para a Initiative. O Lead puxa 1:1 ou squad sync extraordinário.

Nível 3: CEO decide Conflito entre teses (prioridade de shared services), decisão de desligamento, pivô de aposta, ou qualquer coisa que envolva dinheiro ou estratégia.

Regra de ouro: escalar cedo é sinal de maturidade, não de fraqueza. O Lead que escala um problema no dia 2 é mais valioso do que o que "absorve" e entrega tarde no dia 15.

People Committee (Contratação, Desligamento e Processos)

Decisões de pessoas não são unilaterais. Para contratações e desligamentos, existe um comitê mínimo:

Composição: CEO + Lead do squad afetado + pelo menos 1 outro Lead (visão externa).

Quando se reúne:

• Antes de qualquer contratação: para validar que o perfil, o scope, e o fee fazem sentido para a tese
• Antes de qualquer desligamento: para confirmar que o processo foi justo (feedback dado, improvement plan oferecido se aplicável, dados sustentam a decisão)
• Quando há mudança de processo que afeta todos os squads (ex: novo formato de cerimônia, mudança na política de bônus)

Por que isso importa: evita contratação impulsiva, evita desligamento emocional, e cria registro formal de decisões de pessoas. Em um time pequeno, cada contratação ou saída tem impacto desproporcional. O comitê adiciona 30 minutos de governança para decisões que afetam meses de operação.

Filosofia de Contratação (Founder Mode)

A contratação é a decisão mais importante e a mais fácil de errar. A maioria das empresas opera com "presunção de inocência" — procura ausência de fraquezas. Nós operamos com "culpado até prova contrária" — procuramos evidência concreta de excelência. Candidatos precisam provar que são excepcionais, não apenas que não têm red flags.

Start with the results, work backwards to the people. Não comece pela marca no currículo ("trabalhou no Google"). Comece pelo produto: "qual produto eu admiro? Quem construiu? Quem realmente construiu?" É um trabalho de detetive descobrir quem de fato fez o trabalho vs. quem estava no time quando o trabalho foi feito.

CEO como co-contratante. O CEO entrevista todo candidato. Não como etapa final cerimonial — como avaliador ativo. A lógica: se um Lead consegue contratar alguém sem a ajuda do CEO, essa pessoa provavelmente não é boa o suficiente. Num time de 6-12, cada pessoa que entra muda a dinâmica inteira.

Entrevista: a regra dos 2 follow-ups. Nunca aceite a primeira resposta. Peça para elaborar. Depois peça de novo. Na terceira camada, quem não sabe o que está fazendo fica sem detalhes. Quem fez o trabalho de verdade consegue ir fundo indefinidamente.

A abordagem Shackleton. No final do processo de contratação, em vez de vender a C-137 como um lugar incrível, fale sobre por que a pessoa NÃO deveria aceitar: a carga de trabalho é alta, as expectativas são brutais, o CEO está nos detalhes, não existe coast mode, e os padrões de qualidade são altíssimos. Isso resolve dois problemas: filtra quem quer conforto (essas pessoas vão sair em 3 meses de qualquer forma) e atrai quem quer desafio real. As melhores pessoas querem o equivalente do Navy SEALs, não do navy.

Proxy de scaling. Para avaliar se alguém interno está escalando ou não (e se contratações externas são necessárias): quem está fazendo hoje o que deveria fazer daqui a 6 meses está escalando. Quem está fazendo o que deveria estar fazendo agora está on track. Quem está fazendo hoje o que deveria ter feito 6 meses atrás não está escalando — e a tendência quase nunca se reverte.

Always be recruiting. Mesmo sem vaga aberta, o CEO e Leads devem manter uma rede de talentos ativa. Recrutar apenas quando tem vaga cria pipeline de vendas. Recrutar continuamente cria network. A diferença entre contratar rápido e contratar bem é ter o pipeline pronto antes de precisar.

Kill Process (Ventures)

Matar ventures é tão importante quanto criá-las. A C-137 define kill criteria antes de construir — na Betting Table, no momento da aprovação do bet. Se uma venture atinge os kill criteria, o Kill Decision Meeting é convocado (ad-hoc, 1h). Não existe "mais um mês para ver se melhora."

Stages de uma venture:

Shaping → Building → Validation → Traction → Growth → (Exit ou Killed)

Timelines de referência: 2 semanas (ideia → MLP), 4 semanas (MLP → 10 clientes), 6 semanas (10 → R$100k MRR path). Total: 12 semanas até sinais claros de traction. Se na semana 12 não há sinais, a conversa de kill começa.

Essas timelines não são absolutas, mas são a referência contra a qual medimos velocidade. Se um Builder ou Lead acha que "estamos indo bem" mas a venture está na semana 10 sem MLP, a timeline resolve a ambiguidade.

Checklist de Kill:

• Kill Decision Meeting realizado com CEO + Venture Lead + Lead
• Learnings documentados no database de Apostas
• Shared assets identificados e preservados para futuras ventures
• EIR realocado para outra tese ou desligado
• Linear Initiative arquivada
• Post-mortem documentado e compartilhado com o time

O post-mortem não é blame — é aprendizado. Todo kill gera insights que melhoram a próxima aposta. A C-137 que mata rápido e aprende é mais valiosa que a que mantém ventures zumbis por medo de admitir o erro.

7. Políticas

Time-Off

A C-137 não controla horário e não funciona como CLT. Mas descanso é obrigatório — não como benefício, mas como requisito de performance. Ninguém opera no máximo por 12 meses seguidos sem pausar.

Descanso anual: 20 dias corridos por cada 12 meses de contrato. Pode ser fracionado (mínimo 5 dias corridos por vez). Antecipação permitida até metade (10 dias) após 6 meses de contrato.

Coordenação: Registre via Time-off Agent com pelo menos 2 semanas de antecedência. Não precisa justificar. O agent verifica conflitos automaticamente. Se dois membros do mesmo squad querem o mesmo período, resolva entre vocês — se não resolver, o agent escala.

Feriados: Irrelevantes. Não controlamos dias ou horários. Se quer trabalhar no Natal e folgar em fevereiro, faz sentido para você. Se quer folgar no Natal, também. O que importa é que o squad saiba quando você não está disponível.

Fim de ano (23/dez a 01/jan): A C-137 opera em modo reduzido. Não conta dos 20 dias. Você só será acionado se for realmente necessário. Se você é liderança, use esse período para builder mode de verdade — é o momento mais silencioso do ano para pensar, prototipar, e trabalhar no que normalmente não cabe no dia a dia.

Birthday Off: Dia de folga no mês do seu aniversário. Escolha qualquer dia útil do mês. Avise o squad com 1 semana de antecedência. Não desconta dos 20 dias.

Licenças especiais: Situações como licença médica, luto, licença parental, ou emergências pessoais serão analisadas caso a caso com o máximo de empatia e bom senso. Não temos uma tabela rígida de dias porque cada situação é diferente. O que garantimos: ninguém vai ser penalizado por precisar de tempo para cuidar da saúde, da família, ou de si mesmo. Registre o pedido via Time-off Agent assim que possível — quanto antes o sistema registrar, melhor conseguimos reorganizar o squad e te dar o suporte necessário. Para licenças mais longas (acima de 5 dias), alinhamos um plano de cobertura para que o squad não fique descoberto e você não volte com acúmulo.

Equipment

A C-137 é remote-first e opera com contractors. Cada pessoa é responsável pelo seu equipamento de trabalho.

O que a C-137 fornece: acesso a todas as ferramentas e plataformas necessárias (Claude, Cursor, Vercel, Linear, Notion, Slack, Figma, e qualquer outra ferramenta aprovada). Sempre as melhores ferramentas do mundo — sem economizar em software.

Se você precisa de uma ferramenta ou plataforma que a C-137 não fornece atualmente, proponha no #improvements. Se faz sentido, aprovamos e adicionamos ao stack.

Specs mínimos recomendados:

Se seu equipamento atual não atende aos specs mínimos e isso está impactando sua produtividade, abra um pedido via #improvements. Avaliamos caso a caso.

Expense Policy

Princípio: mesma política para todos os níveis, incluindo CEO. Se quer upgrade pessoal (classe executiva, hotel melhor), paga a diferença do próprio bolso. A C-137 cobre o necessário, não o luxuoso.

Viagens a trabalho (quando aplicável):

• Passagem aérea: classe econômica, tarifa mais eficiente disponível
• Hospedagem: até R$ 350/noite (mercados caros como SP/Rio podem ser ajustados)
• Alimentação: até R$ 80/dia (contra comprovante)
• Transporte local: Uber/táxi com comprovante

Annual Offsite: Todas as despesas cobertas pela C-137 (passagem, hospedagem, alimentação, atividades). O orçamento é comunicado antes.

Reembolso: Envie comprovantes (NF/recibo) via canal combinado. Reembolso processado junto com a próxima invoice. Sem comprovante = sem reembolso. Sem exceção.

Segurança

Segurança de dados é obrigação de todos. Como remote-first com acesso a código, dados de clientes, e propriedade intelectual de múltiplas ventures, a superfície de ataque é ampla. Cada membro é um vetor potencial.

Obrigatório para todos (dia 1):

• 2FA ativado em todas as ferramentas (Slack, GitHub, Linear, Notion, Google, etc)
• Password manager (1Password, Bitwarden, ou equivalente) — senhas únicas por serviço
• Disk encryption ativado no laptop (FileVault no Mac, BitLocker no Windows)
• Tela bloqueada quando longe do computador — mesmo em casa

Obrigatório para Tech:

• Nunca commitar secrets, API keys, ou credenciais no repositório
• Usar variáveis de ambiente para configuração sensível
• SSH keys em vez de passwords para Git

Se perder ou tiver equipamento roubado: Reporte imediatamente no canal #security (mesma hora). Acessos serão revogados antes de qualquer outra coisa.

Código de Conduta

A C-137 é um ambiente de alta performance, com feedback direto e comunicação franca. Isso não é licença para desrespeito. A linha é clara:

Tolerância zero para: assédio (sexual, moral, ou qualquer forma), discriminação por raça, gênero, orientação sexual, religião, nacionalidade ou qualquer outra característica pessoal, bullying ou intimidação, retaliação contra quem reporta problemas.

Como reportar: DM no Slack ou email para o CEO ou qualquer Lead. Se o problema envolve seu Lead direto, escale para outro Lead ou para o CEO. Reports são tratados com confidencialidade e investigados. Retaliação contra quem reporta é tratada com a mesma gravidade que a ofensa original.

Conflitos de trabalho (discordâncias técnicas, prioridades, estilo de comunicação) são normais e esperados. Resolve-se via Disagree and Commit, 1:1, ou escalação ao Lead. Conflito produtivo é saudável. Conflito pessoal é inaceitável.

Moonlighting

Trabalho paralelo é permitido, com regras claras.

Permitido sem aviso: freelance/consultoria em áreas que não competem com nenhuma venture da C-137, projetos open-source, atividades acadêmicas ou de ensino.

Permitido com aviso prévio ao CEO: trabalho que envolve mais de 10h/semana, projetos em áreas adjacentes às teses da C-137 (para evitar conflito de interesse), advisory boards de outras empresas.

Proibido: trabalho direto para concorrentes de qualquer venture do portfólio, uso de propriedade intelectual da C-137 em projetos externos, qualquer atividade que comprometa sua disponibilidade ou performance.

Regra de ouro: se você não teria problema em contar para o CEO no café, está liberado. Se sentiria desconforto, pergunte antes.

Social Media & Representação Pública

A C-137 opera com múltiplas ventures, propriedade intelectual sensível, e parcerias estratégicas. O que qualquer membro publica online pode impactar a reputação de toda a organização e do portfólio. Isso não é paranoia corporativa — é realidade de um mundo onde qualquer post vira screenshot.

LinkedIn e perfis profissionais: Somente após aprovação no período de experiência (45 dias) você pode adicionar a C-137 ou qualquer venture do portfólio ao seu perfil. Antes disso, não associe publicamente. Depois, pode colocar cargo e empresa — sem detalhes de stack, arquitetura, projetos internos, ou métricas.

Proibido sem autorização explícita do CEO: compartilhar detalhes de stack tecnológico, arquitetura, ou infraestrutura de qualquer venture em qualquer plataforma (LinkedIn, Twitter/X, blog pessoal, fórum, GitHub público, conferência). Divulgar métricas de negócio, número de usuários, receita, ou qualquer dado interno. Falar publicamente em nome da C-137 ou de qualquer venture (entrevistas, podcasts, posts opinativos sobre a empresa).

Perfil pessoal público: Você é livre para ter opinião sobre qualquer assunto. Mas se seu perfil é público e identificável como membro da C-137, evite entrar em temas politicamente sensíveis, polêmicas de internet, ou debates que possam ser associados à empresa. Não porque censuramos opinião — mas porque a associação é inevitável e o risco é desnecessário. Na dúvida: perfil privado resolve.

Quem pode falar pela C-137: CEO para posicionamento institucional. Venture Leads para suas respectivas ventures, com alinhamento prévio. Ninguém mais, a menos que explicitamente designado.

Regra de ouro: se você publicaria aquilo no #c137-hq sem problema, provavelmente está ok. Se não publicaria, não publique fora.

Learning & Development

Aprendizado contínuo não é um benefício — é pré-requisito para trabalhar direito na C-137. Nosso DNA #BetaMindset não é só sobre iterar produto. É sobre iterar a si mesmo. Quem para de aprender para de entregar resultado em meses, não em anos.

A C-137 investe seriamente em educação. Temos budget dedicado e um programa formal de desenvolvimento. Já financiamos mestrado, pós-graduação, cursos de idiomas, especializações técnicas, e certificações profissionais. Não é exceção — é prática recorrente.

Como funciona: Proponha com uma justificativa simples: o que é, quanto custa, quanto tempo leva, e como isso se conecta com o que você faz aqui. Não existe orçamento fixo por pessoa — cada caso é avaliado pelo mérito. Coisas pequenas (curso de $50, livro, ferramenta de estudo) são aprovadas rápido. Investimentos maiores (pós-graduação, programa de meses) exigem conversa mais detalhada e normalmente estão atrelados a permanência mínima.

Conferências e eventos: Avaliados caso a caso. Se você vai apresentar ou representar a C-137/venture, a empresa cobre. Se é para desenvolvimento pessoal, avaliamos junto com o budget de L&D.

Expectativa em troca: Quem recebe investimento em educação compartilha o aprendizado com o time. Pode ser um post no Slack, uma sessão de 30 min, ou documentação no Notion. Conhecimento que fica na cabeça de uma pessoa não escala.

8. Ciclo Anual Completo

Por que o ano fiscal vai de Abril a Março

A C-137 adota o ano fiscal de 1º de abril a 31 de março, dividido em 3 quadrimestres de 16 semanas cada. Não é arbitrário — é uma decisão operacional baseada em como o Brasil realmente funciona e em como nossos cycles se encaixam.

O calendário convencional (janeiro-dezembro) tem um problema estrutural: janeiro é mês de retorno lento, fevereiro tem Carnaval, e dezembro morre com festas e férias coletivas. Você perde meses inteiros para sazonalidade.

Com o ano fiscal começando em abril, ganha-se três coisas concretas:

Planejamento estratégico acontece em março — quando o time está presente, focado, e já passou o período de festas e férias. Em vez de competir com dezembro (quando ninguém está prestando atenção) ou janeiro (quando todo mundo está voltando), o planning anual acontece no momento de maior clareza mental do ano.

T1 fiscal (abr-jul) é quadrimestre produtivo real — ninguém está de férias, não tem feriado prolongado relevante, e o time entra no ano já com momentum. Compare com tentar arrancar em janeiro com metade do time ainda retornando.

T3 fiscal (dez-mar) absorve a sazonalidade — dezembro é o primeiro mês do T3, não o final do ano. O impacto das festas é diluído no início de um quadrimestre, com 3 meses de execução plena pela frente (jan-mar). E o Annual Review + Offsite acontecem em março, quando é possível refletir sobre o ano inteiro com lucidez.

Esse modelo é usado por UK, Japão, Índia e Austrália. No contexto de venture builder, tem um benefício adicional: o reporting para LPs segue a mesma cadência quadrimestral, desalinhado do calendário corporativo convencional — menos competição por atenção de investidores no mesmo período que todo mundo está fazendo annual review.

Encaixe matemático perfeito: cada quadrimestre = 2 cycles de Shape Up (6 semanas build + 2 semanas cooldown = 8 semanas × 2 = 16 semanas = 4 meses). O ano fiscal contém exatamente 6 cycles, sem semana órfã, sem sobra.

Calendário

Com continuous planning, não existe um "big bang" quadrimestral. Candidate Projects são triados e priorizados o tempo todo. Os momentos quadrimestrais existem para revisar a direção estratégica, não para começar do zero.

9. Implementação: Onde Vive Cada Coisa

10. Fontes e Inspirações

Este modelo absorve práticas de dez fontes com culturas e filosofias compatíveis com a C-137:

Founder Mode (Paul Graham + Brian Chesky/Airbnb) — Coexiste com Managers of One. Venture Lead nos detalhes do produto, review cadence, skip-level como norma, co-hire, functional org, deep dives. Filosofia de contratação: "guilty until proven innocent", abordagem Shackleton, always be recruiting.

Linear (99 pessoas, 15+ países) — Cooldown entre cycles, zero-bug policy com SLAs, weekly written updates, hack weeks, rotating project leads, dogfooding com feature flags, annual offsite.

PostHog (~100 pessoas, full remote) — Small teams como startups, management spread thin, "make yourself obsolete", 1:1s adaptáveis, functional cross-pollination.

Basecamp/37signals (~70 pessoas, remote-first) — Heartbeats, cycle kickoffs, The Needle, 5-hour meeting rule, managers of one, JOMO, disagree and commit.

GitLab (1.600+ pessoas, all-remote) — DRI, handbook-first, meeting audit, ACK process, low-context communication, personal READMEs, coffee chats, suggestion box.

Vercel (~175 pessoas, remote-first) — Iterate to Greatness, radical deadline compression, full ownership from day 1, pair building sessions, fast feedback.

BTG Pactual (maior banco de investimento da América Latina) — Partnership culture escalável: Player-Coach model (gestores mantêm craft ativo), Performance Rating com forced distribution (~5% cap em "Excepcional"), equity rebalancing anual por performance, bonus pool como % de receita, expense policy igualitária (CEO = junior), grow-your-own-talent (90%+ promoção interna), deferral de ganhos para retenção.

Google/Amazon Engineering Levels — Framework de Career Ladder com tracks separados para IC e Management. Progressão por scope de impacto (issue → project → venture → portfólio), não por tempo de casa. Equivalências de mercado para calibrar seniority e compensação.

Rocket Internet — Provou que venture building escala (100+ empresas, Zalando, HelloFresh, Lazada). Tech platforms por vertical, IT service centers, analytical excellence, business infrastructure pré-constituída, people machine (pipeline de empreendedores de execução). Colapsou porque escalava linearmente com headcount. A C-137 tem o mesmo playbook mas com custo marginal próximo de zero porque cada camada da plataforma é software, não pessoas.

Stanford University (PMF Framework) — Classificação de oportunidades por tipo de mercado: Hair on Fire (cliente busca ativamente), Hard Fact (problema aceito como normal), Future Vision (mercado precisa ser criado). Usado na triagem da Idea Box e na Betting Table para priorizar bets.

11. Glossário

Changelog

Esta é a v3.0 pública do Culture & Operations Handbook da C-137 Labs. Versões anteriores existiam como documentos internos fragmentados, práticas orais, e decisões acumuladas ao longo do tempo. Esta é a primeira vez que consolidamos tudo em um único documento estruturado.

v3.0 — Fevereiro 2026 (esta versão)

Primeira publicação oficial. Consolida em um único documento: missão e DNA da C-137, modelo operacional completo (Shape Up + cycles + agents), estrutura de papéis e Career Ladder (IC1-IC6, NT1-NT5, M1-M4), cadência de todas as cerimônias (squad e portfólio), sistema de metas e performance (Initiatives + NSM + Projects + score quadrimestral), modelo de compensação (fee + bônus + Venture Pool + partnership), cultura na prática (comunicação, qualidade, conexão humana, onboarding de 45 dias), fluxo de escalação e People Committee, políticas completas (time-off, licenças especiais, equipment, expenses, segurança, código de conduta, moonlighting, social media, L&D), ciclo anual, mapa de implementação (ferramentas + agents), e glossário de termos.

*Próxima revisão planejada: Q2 FY26 (Jul-Set 2025) ou quando houver mudança estrutural relevante.*

*C-137 Labs · Culture & Operations Handbook v3.0* *Founder Mode nas ventures. Partnership culture. A obra da sua vida.* *Absorve práticas de Airbnb/Chesky, Linear, PostHog, Basecamp/37signals, GitLab, Vercel, BTG Pactual, Google/Amazon Engineering Levels, Rocket Internet e Stanford University.* *Este é um documento vivo. Se algo aqui não funciona na prática, muda.*