O que jogar de Presidente do Conselho numa simulação de MBA me ensinou sobre vender tecnologia

Semana passada, na disciplina Technology in the Boardroom do meu MBA, a aula virou uma simulação de reunião de conselho. Cada aluno recebeu um personagem, uma sala e um caso fictício — mas com números de balanço, indicadores e pressão de tempo real o suficiente pra doer. Eu caí como Roberto Almeida, Presidente do Conselho de Administração de uma varejista fictícia em crise, numa sala onde o Diretor de Tecnologia (recém-contratado há 60 dias) tinha que defender R$ 25 milhões em 18 meses pra um Programa de Transformação em Cibersegurança.

Não escrevo isso pra resenhar a aula. Escrevo porque saí de lá com uma régua nova pra avaliar como eu mesmo apresento investimento em tecnologia — inclusive dentro do Viajaflux, onde sou sócio e CTO ao mesmo tempo.

O caso, resumido

A empresa da simulação — Retail Tec Brasil S.A., capital aberto, sem controlador, Novo Mercado da B3 — estava no que dá pra chamar de crise dupla: financeira e de confiança. Dívida líquida sobre EBITDA em 5,1x (o razoável seria 2x), caixa de R$ 90 milhões, ações caindo 38% em 12 meses, e o gatilho da reunião extraordinária: um incidente cibernético relevante três meses antes.

O ex-CIO tinha acabado de ser demitido por um combo bem específico: atraso de 14 meses num projeto de ERP, estouro de custo, e — o motivo que mais me marcou — comunicação excessivamente técnica com a Diretoria e o Conselho. Não foi demitido por incompetência técnica. Foi demitido por não saber traduzir tecnologia pra linguagem de negócio.

O novo Diretor de Tecnologia (Fernando Lopes, personagem de outro colega na minha sala) herdava essa desconfiança inteira. Meu trabalho como presidente não era defender nem atacar o projeto dele — era conduzir a reunião, garantir que os quatro conselheiros perguntassem dentro do próprio perfil, e fechar com uma decisão dentro do tempo.

A régua que todo conselho preparado usa

Antes da simulação, o professor (Antônio Edson Maciel dos Santos, conselheiro de administração de carreira) tinha passado os 5 princípios de governança do Código IBGC 2023:

A dica de ouro do professor foi: ao apresentar qualquer projeto, nomeie explicitamente a qual desses princípios ele atende. É a diferença entre soar como “mais um pedido de budget” e soar como alguém que fala a língua do conselho.

Mas o insight que mais serve fora da sala de aula foi outro, ainda mais direto: numa empresa em crise de caixa, o argumento que convence não é inovação, é mitigação de risco e proteção de receita. Das quatro salas da turma, a que defendia Cibersegurança (a minha) era, segundo o próprio professor, a mais fácil de sustentar — não porque o projeto fosse melhor, mas porque o risco já era fato consumado: o incidente já tinha acontecido, então ninguém discutia “se” o problema era real, só “quanto” investir. Comparado com isso, a sala que defendia trocar um ERP já pago e 14 meses atrasado (dilema clássico de custo afundado) sofreu muito mais — porque soava a “mais dinheiro pro mesmo buraco”.

Onde isso bate direto no Viajaflux

Um dia antes dessa aula, eu tinha acabado de levantar um diagnóstico de infraestrutura do Viajaflux depois da virada pra AWS Fargate. Não corrigi nada ainda, só documentei os gaps. E ao reler essa lista depois da simulação, percebi que ela é literalmente um caso de “Sala 2” esperando por um pitch:

• Deploy sem CI/CD — hoje é um script disparado manualmente do terminal de quem está fazendo o deploy, sem workflow do GitHub Actions a partir de merge em main. Zero histórico auditável de quem deployou o quê e quando.
• Terraform sem backend remoto — o state vive só na máquina de quem rodou terraform apply, sem lock. Dois apply simultâneos corrompem a infra.
• RDS sem Multi-AZ e Redis sem failover — e esse Redis não é só cache: serve sessão de usuário logado e as filas do Horizon ao mesmo tempo. Se o node cai, some sessão e job em andamento juntos.
• Nenhum CloudWatch Alarm configurado — hoje a detecção de problema em produção depende de reclamação de cliente ou de alguém olhar o console manualmente.

Se eu tivesse que levar isso pra uma reunião de sócios amanhã, o erro mais fácil de cometer seria apresentar como “modernização de infra” — um jargão técnico que soa exatamente como o tipo de comunicação que derrubou o CIO fictício da simulação. A régua que aprendi diz o contrário: isso não é modernização, é risco operacional já identificado, sem incidente ainda registrado — o que é ainda mais fácil de defender que o caso da simulação, porque dá pra agir antes do incidente, não depois. O framing certo é: “essas cinco lacunas, se não corrigidas, geram downtime, perda de sessão de usuário pagante e zero visibilidade de quando algo quebra — e o custo de corrigir agora é uma fração do custo de corrigir depois de um incidente real”. Isso é proteção de receita e de reputação, não feature nova.

O que eu levo disso pra fora da sala de aula

Três coisas que já mudam como eu vou preparar a próxima conversa de investimento técnico com os sócios do Viajaflux:

1. Nomear o princípio, não só o problema. Em vez de “precisamos de CI/CD”, testar a frase “isso é uma questão de accountability — hoje eu não consigo te dizer com certeza quem deployou o quê, quando, nem reverter isso com segurança”. Muda o registro de pedido técnico pra responsabilidade de governança.
2. Descontar o custo de oportunidade, sempre. O professor citou um caso real de migração de cloud na aula anterior em que um ROI de US$ 8 milhões caía pra ~US$ 1 milhão quando alguém finalmente contava o custo de parar o time de engenharia pra fazer a migração. Eu não faço essa conta hoje — deveria fazer em qualquer proposta de infra que tire gente de feature nova por semanas.
3. Ler o momento da empresa antes de escolher o enquadramento. Um pedido de corte de risco cai bem numa empresa apertando o cinto; o mesmo pedido soa defensivo demais numa empresa em modo crescimento agressivo. Antes de escrever o pitch, a pergunta não é só “o que eu preciso”, é “que fase o Viajaflux está vivendo agora, e qual enquadramento essa fase pede”.

Minha conclusão

Uma simulação de MBA não substitui uma reunião real de conselho — ninguém vota capital de verdade numa sala de aula. Mas o exercício expôs algo que eu já sentia na prática sem ter o vocabulário pra nomear: quando eu falo de tecnologia com quem decide orçamento, o que pesa não é o quão sofisticada é a solução técnica, é o quão claro fica o risco que ela mitiga e o quanto isso conecta com o momento da empresa. Documentar os gaps de infra do Viajaflux foi trabalho técnico. Saber apresentar isso como proteção de receita — antes que vire incidente — é trabalho de governança. E essa segunda parte, antes dessa aula, eu fazia de ouvido.