Pra mim, a primeira pergunta que precisa ser respondida antes de criar um evento recorrente no Google Calendar é qual o custo daquela reunião. Um engenheiro de software sênior no mercado brasileiro custa entre R$ 15.000 e R$ 25.000 por mês em regime PJ, dependendo da especialização e da região. Considerando encargos e benefícios, o custo total por hora produtiva fica entre R$ 120 e R$ 200. Uma reunião de alinhamento semanal de uma hora com oito engenheiros a R$ 150/hora custa R$ 1.200 por ocorrência, o que equivale a R$ 4.800 por mês ou R$ 57.600 por ano. Esse cálculo, que deveria ser trivial, raramente é feito. E o custo direto, na minha avaliação, é a parte menor do problema.
Dados do relatório de benchmarks da Clockwise, plataforma de gestão inteligente de calendários, coletados entre maio de 2021 e maio de 2022 a partir de mais de 1,5 milhão de reuniões de engenheiros de software, mostram que o engenheiro IC médio gasta 10,9 horas por semana em reuniões, enquanto engineering managers gastam 17,9 horas. Isso deixa, em média, 19,6 horas semanais de focus time pra ICs, definido como blocos de duas ou mais horas livres pra trabalho concentrado. O restante, cerca de 6,3 horas por semana, se distribui em fragmentos curtos entre reuniões, períodos insuficientes pra qualquer tarefa que exija carga cognitiva significativa.
O custo indireto de cada reunião se manifesta no tempo de recuperação cognitiva. Pesquisa da UC Irvine, amplamente citada e replicada, estabelece que o tempo médio pra retomar foco profundo após uma interrupção é de 23 minutos. Uma reunião de 30 minutos custa aproximadamente 53 minutos de produtividade quando se contabiliza o período de reengajamento. Uma reunião de uma hora posicionada no meio da manhã destrói um bloco inteiro de focus time, até porque o período anterior já entra em modo de espera e o seguinte fica preso na recuperação.
Organizações que cortaram sua carga de reuniões em 40% observaram aumento de 71% em produtividade e 52% em satisfação, segundo estudo de Ben Laker, Vijay Pereira, Pawan Budhwar e Ashish Malik publicado no MIT Sloan Management Review em janeiro de 2022. O estudo analisou 76 empresas e mediu o impacto em profissionais de conhecimento em geral, o que torna os números ainda mais relevantes pra engenheiros de software, cuja dependência de blocos ininterruptos de concentração é estruturalmente maior que a média.
Na minha análise, o cálculo financeiro completo de uma reunião precisa incluir o custo direto da hora dos participantes, o custo de recuperação cognitiva pós-reunião, o custo de oportunidade do trabalho que não foi feito durante o bloco destruído e o custo de context switching quando a reunião força uma transição entre domínios cognitivos distintos. Uma reunião semanal de uma hora com oito engenheiros seniores a R$ 150/hora tem custo direto de R$ 1.200 e custo de recuperação de aproximadamente R$ 460, considerando 23 minutos adicionais por pessoa. O custo de oportunidade varia conforme o posicionamento na agenda, mas conservadoramente adiciona entre 40 e 60% sobre os custos direto e de recuperação. O custo real mensal dessa única reunião semanal fica entre R$ 9.300 e R$ 10.600 quando todos os componentes são contabilizados.
Equipes com blocos protegidos de focus time apresentam lead times menores e deployment frequency mais alta, as métricas que o framework DORA utiliza pra medir a performance de entrega de software. O mecanismo é direto: trabalho que exige concentração profunda, como design de sistemas, debugging complexo e escrita de código que envolve múltiplas dependências, só progride em blocos ininterruptos. Quando o bloco é fragmentado por uma reunião, o custo de retomada se aplica a cada nova tentativa de avanço.
Na minha avaliação, a intervenção que funciona começa pela eliminação. Auditar todas as reuniões recorrentes do time a cada trimestre e cancelar aquelas cuja ausência não produziu efeito negativo mensurável nas duas semanas de teste. Entre 25 e 40% das reuniões recorrentes de um time de engenharia podem ser eliminadas sem impacto operacional, até porque evoluíram pra rituais de presença sem conteúdo decisório. A reunião que sobrevive ao corte ainda precisa de compressão. Encurtar ao mínimo funcional, com agenda escrita previamente e decisão registrada como artefato permanente. O que sobra depois disso é uma decisão de posicionamento. Concentrar tudo em um ou dois dias da semana cria dias inteiros livres de interrupções, e essa prática, que Paul Graham formalizou em 2009 como maker's schedule, separa o tempo de colaboração do tempo de produção em vez de embaralhar os dois.
Já implementei essa estrutura em três organizações diferentes. Nas primeiras duas semanas após a consolidação de reuniões, o volume de pull requests abertos por engenheiro subiu entre 15 e 30%. O ganho veio dos blocos suficientes pra completar unidades de trabalho inteiras, até porque as pessoas não passaram a trabalhar mais horas. O change failure rate caiu na mesma proporção, porque código escrito com concentração sustentada contém menos erros do que código escrito em fragmentos de 45 minutos entre reuniões. Oito engenheiros com duas reuniões eliminadas por semana recuperam 16 horas semanais de capacidade produtiva, o equivalente a contratar meio engenheiro adicional sem custo de recrutamento, onboarding ou headcount. A decisão de proteger tempo de deep work não exige investimento, ferramenta nova ou reorganização estrutural. Exige apenas que alguém faça a conta e tenha autoridade pra deletar eventos do calendário.