Organizações sofrem um DDoS vindo de dentro, diz artigo sobre perda de atenção
Aprofundamento CEVIU
Aprofundamento
O texto vem de Karri Saarinen, CEO da Linear, e parte de uma observação de quem dirige a empresa: o trabalho muda tão rápido que, quando ele entende algo o bastante para opinar, aquilo já mudou. Ninguém tenta sobrecarregar a organização. Cada pessoa faz o que acha útil, mas tudo isso consome a mesma capacidade limitada de entender, revisar e decidir.
O argumento central é que output não é prova de valor. Uma implementação funcionando mostra que algo pode ser construído, não que deve entrar no produto. Algumas mudanças têm valor negativo, e mesmo pequenas podem colidir com o trabalho de outro time. Reunir todo mundo antes de cada mudança também não resolve: não dá para fazer alinhamento para cada um dos mil PRs que o time abre em um dia.
As saídas que ele descreve são duas. Primeiro, deixar a intenção explícita de antemão (no que a empresa está apostando, o que importa agora, o que está fora de escopo), para que pessoas e agentes conferam o próprio trabalho contra isso. Segundo, ser deliberado sobre quando um experimento vira parte do produto compartilhado. A Linear travou o canal interno de releases porque vários times se sobrepunham. Dá para experimentar atrás de outras feature flags, mas o gate cria um ponto único para avaliar mudanças em conjunto. Ele admite que isso ajuda a acompanhar o que muda, mas ainda não diz se o conjunto leva à direção desejada.
Por que isso importa
Para quem lidera engenharia ou produto, a leitura é que o gargalo deixou de ser produzir código e passou a ser a atenção de quem revisa e decide. Isso sugere investir em contexto escrito, critérios de escopo e pontos de entrada controlados no produto, em vez de só aumentar a velocidade de entrega.
Perguntas frequentes
O que significa dizer que a organização sofre um DDoS interno?
É uma analogia com negação de serviço. Ninguém ataca de propósito, mas o volume de mudanças geradas por times e agentes supera a capacidade de entender, revisar e decidir sobre elas. A atenção da liderança vira o recurso saturado.
Por que um código funcionando não basta para aprovar uma mudança?
Porque ele só prova que algo pode ser construído, não que deveria ser. A mudança pode se sobrepor ao trabalho de outro time ou levar o produto a uma direção não considerada. Segundo o autor, algumas mudanças têm valor negativo.
Como a Linear tenta lidar com isso?
Tenta deixar a intenção mais clara com antecedência: apostas atuais, prioridades e o que está fora de escopo. Também travou o canal interno de releases, criando um gate para avaliar mudanças juntas antes de chegarem ao produto. Experimentos continuam possíveis atrás de outras feature flags.
Reunir o time para discutir cada mudança resolve?
Não. O autor lembra que não dá para fazer uma reunião de alinhamento para cada um dos mil PRs abertos num dia. A proposta é manter a capacidade de decidir quais trabalhos fazer sem discutir cada mudança individualmente.
Fontes
- karrisaarinen.comfonte original
- Categoria
- CEVIU
- Publicado
- 03 de novembro de 2026
- Editoria
- CEVIU

