Três camadas de impacto: a estrutura que evita gargalos nos handoffs de decisão

Quando a Zappos eliminou hierarquias formais em 2014 e adotou a Holacracia, o resultado não foi a agilidade prometida — foi paralisia. Decisões que antes tinham um dono claro passaram a circular sem resolução. A empresa abandonou parcialmente o modelo em 2020, segundo relatos do Wall Street Journal, após anos de alta rotatividade e confusão operacional. O problema não era a descentralização em si: era a ausência de critérios claros para saber quem decide o quê — e quando passa para outra instância.

É exatamente esse vácuo que o framework de três camadas — baixo, médio e alto impacto — tenta preencher. Não é um modelo novo, mas sua aplicação como ferramenta de desenho organizacional ganhou tração à medida que empresas perceberam que o gargalo real não está na execução, mas nos handoffs mal definidos entre níveis de decisão.

O que o framework resolve — e onde costuma falhar

A lógica central é direta: cada decisão é classificada por seu impacto potencial (reversibilidade, custo, alcance) e roteada para o nível correspondente de autoridade. Decisões de baixo impacto ficam com quem executa. Médio impacto sobe para liderança de linha. Alto impacto chega à direção.

O que parece óbvio falha na prática porque as empresas definem as camadas, mas não os gatilhos de handoff. Sem critérios objetivos — valor financeiro, número de clientes afetados, prazo de reversão — cada colaborador usa seu próprio julgamento sobre o que é "médio" ou "alto". O resultado é o oposto do pretendido: ou tudo sobe para o topo (centralização disfarçada de processo), ou nada sobe (autonomia sem governança).

Como a Amazon operacionalizou os critérios de escalada

A Amazon popularizou a distinção entre decisões Tipo 1 e Tipo 2 — irreversíveis e de alto custo versus reversíveis e de baixo custo — na carta de Jeff Bezos aos acionistas em 2016. O ponto central não era a classificação em si, mas a exigência de que equipes documentassem explicitamente *por que* uma decisão era Tipo 1 antes de escalar. Isso inverteu o ônus: quem escalava precisava justificar, não quem resolvia localmente.

Em nossa análise, o mecanismo funciona porque transforma o gatilho de handoff em um ato deliberado — reduzindo escalações desnecessárias sem criar risco operacional real.

Lean, Agile e OKRs como régua de prioridade

Empresas que operam com lean manufacturing ou squads ágeis enfrentam o mesmo problema em contextos distintos. No Lean, a decisão de parar uma linha (andon) é um handoff clássico com critério temporal e quantitativo — o operador aciona, o líder de célula avalia, a gerência só entra se o problema não for resolvido no ciclo. É um exemplo prático de PDCA aplicado à escalada de decisões: o ciclo define quem age em cada etapa.

Em ambientes com gestão agile, times que usam OKRs como balizador conseguem conectar as camadas: resultados-chave individuais ficam no time; objetivos que cruzam squads vão para o chapter lead; mudanças que afetam a estratégia anual chegam ao C-level. O framework de três camadas, nesse contexto, funciona como régua de prioridade — não de hierarquia.

O ponto de falha mais comum: handoffs sem SLA

Em nossa análise, o risco real não é classificar mal uma decisão — é não definir tempo de resposta para cada camada. Quando uma decisão de médio impacto sobe para a liderança sem prazo de retorno, o gargalo se instala independentemente de quão bem desenhado seja o modelo.

Vale perguntar se, na sua operação, os handoffs entre camadas têm SLA definido — e se quem executa sabe o que acontece quando esse prazo não é cumprido. Sem isso, qualquer framework de gestão tende a replicar exatamente o problema que prometeu resolver.