Palestrar em conferências: o que ninguém te conta antes de você subir no palco

Você já assistiu uma talk incrível e pensou "eu também quero fazer isso"? Eu pensei. Mandei minha primeira proposta, foi aceita, e descobri que palestrar é 20% glamour e 80% trabalho invisível que ninguém menciona.

Por que todo mundo fala disso agora

O mercado tech brasileiro cresceu, eventos voltaram presencial, e comunidades estão desesperadas por conteúdo local. CFPs (Call for Papers) pipocam todo mês no LinkedIn. Parece o momento perfeito pra estrear como speaker. E é — se você souber no que está se metendo.

A promessa é tentadora: networking, autoridade técnica, talvez uma viagem paga. A realidade inclui reescrever slides às 2h da manhã, lidar com perguntas que você não sabe responder, e descobrir que o projetor não lê seu formato de arquivo.

A parte que você não vê

Palestrar não é "pegar um assunto que você domina e falar por 40 minutos". É mais como: escolher um ângulo que caiba no tempo, validar que ainda é relevante quando o evento rolar (3 meses depois), montar uma narrativa que funcione pra quem nunca viu o assunto e pra quem já usa em produção, ensaiar até decorar as transições, e torcer pra tech não falhar.

Aqui está o fluxo real, do jeito que ninguém documenta:

const speakerJourney = { week_minus_12: { action: "escrever abstract de 300 caracteres", realidade: "reescrever 47 vezes porque não cabe" }, week_minus_10: { action: "proposta aceita 🎉", realidade: "pânico porque agora tem que fazer" }, week_minus_6: { action: "montar outline dos slides", realidade: "mudar de ideia 3 vezes sobre a abordagem" }, week_minus_2: { action: "finalizar apresentação", realidade: "refazer metade porque saiu uma breaking change" }, day_zero: { action: "subir no palco", realidade: "microfone com feedback + esqueceu a segunda demo" } };

Como estruturar sua proposta (pra ser aceita)

Organizadores de evento recebem 200+ propostas e aprovam 20. O que passa:

Título que entrega valor, não buzzword:

❌ "O Futuro da Web: Uma Jornada Transformadora"
✅ "Como migramos 80 rotas de REST pra tRPC sem derrubar produção"

Abstract com problema + solução + resultado:

# Estrutura que funciona (120-250 palavras)  1. Contexto (1 frase) "Nossa API REST tinha 80 endpoints, tipos duplicados e zero type-safety."  2. O que você tentou (2-3 frases) "Avaliamos GraphQL, jsonapi, e tRPC. Precisávamos de migração incremental e DX que não exigisse reescrever clients."  3. O que você escolheu e por quê (2 frases) "tRPC permitiu coexistência com REST via adapter e inferência automática de tipos no frontend."  4. Como foi (3-4 frases, aqui mora o valor) "Migramos endpoint por endpoint em 6 sprints. Bugs de tipo caíram 90%. Developer experience melhorou: autocomplete em query e mutation, sem codegen. Vou mostrar a estratégia de migração, armadilhas de cache, e como convencer o time a adotar."  5. Pra quem é (1 frase) "Útil pra quem mantém APIs REST grandes e quer type-safety sem big bang."

O que você NÃO precisa:

Bio estendida (organizador lê depois)
Todos os slides prontos (outline basta)
Ser referência mundial no assunto (experiência real > autoridade)

Preparação: quanto tempo você vai gastar de verdade

Primeira talk: 40-60 horas. Não, eu não estou exagerando.

Research + validação: 8h (ler docs, confirmar que o approach ainda é atual)
Outline + narrativa: 6h (estruturar história, decidir o que cortar)
Slides: 12-20h (fazer, refazer, simplificar, refazer de novo)
Demos: 10-15h (montar, testar, ter plano B pra quando falhar)
Ensaio: 8-12h (sozinho, pra alguém, cronometrado, ajustar ritmo)

E isso assumindo que você já domina o assunto. Se for algo que você aprendeu recentemente "pra poder palestrar sobre", adicione mais 20h de estudo.

// Calculadora honesta de horas function horasReaisPraPalestrar(experiencia, complexidade) { const base = experiencia === 'primeira' ? 50 : 25; const demoCost = complexidade === 'live-coding' ? 15 : 5; const ansiolitico = 10; // horas perdidas reescrevendo por insegurança return base + demoCost + ansiolitico; } horasReaisPraPalestrar('primeira', 'live-coding'); // 75h // É um projeto paralelo de médio porte. Planeje.

O que pode dar errado (e vai)

Tech vai falhar. Sempre. Projetor não aceita seu USB-C, Wi-Fi cai no meio da demo, microfone apita. Solução: slides exportados em PDF, demos gravadas como fallback, hotspot no celular.

Você vai esquecer uma parte. Ensaiei 8 vezes, esqueci a transição do slide 12 pro 13 toda vez. No dia, pulei sem perceber. Ninguém notou (exceto eu). Audiência não tem o roteiro na cabeça.

Perguntas que você não sabe responder. Acontece. "Ótima pergunta, não testamos esse cenário. Me passa teu contato que eu valido e te retorno" é resposta válida. Inventar na hora é pior.

Tempo. Você ensaiou em 35 minutos, no palco levou 28 (nervosismo acelera) ou 48 (alguém perguntou no meio). Marque os slides de "corte opcional" antes.

Por que fazer mesmo assim

Porque quando funciona, funciona muito. Você força a si mesmo a organizar conhecimento que tava disperso. Conhece gente que resolve problemas parecidos. E sim, tem empresa que contrata porque viu sua talk.

Mas principalmente: você contribui pra comunidade de um jeito que post no blog não consegue. Tem algo em assistir alguém vivo, errando, se corrigindo, respondendo perguntas, que cria conexão.

Só não espere que seja fácil.