Quando a estrutura salarial bloqueia a autonomia dos times

A autonomia de times pode fracassar antes de chegar ao organograma quando o sistema de carreira recompensa exatamente o comportamento que a transformação quer abandonar. Na conversa do Adaptive Organizations meet Architecture, Michael Ploed trata Team Topologies menos como um conjunto de rótulos para equipes e mais como uma mudança sociotécnica concreta. O ponto mais revelador aparece quando ele descreve um caso em que um conselho de trabalhadores questionou a criação de times habilitadores: se arquitetos eram promovidos por dar instruções a outros times, como progrediriam ao passar a habilitar esses times a tomar suas próprias decisões?

O mecanismo é simples e difícil de contornar. Um time habilitador de arquitetura não deveria funcionar como uma torre de controle que define Kafka, integração ou decisões técnicas para os demais. Sua função é criar capacidade: coaching, comunicação, programação em par, tutoriais, workshops, segurança para experimentar. Mas, se a faixa salarial do arquiteto de nível superior exige autoridade formal sobre outros times, a organização coloca a carreira contra o desenho operacional. Ploed relata surpresa inicial com a objeção, mas reconhece que ela era legítima: a aceitação de Team Topologies tende a zero quando as pessoas percebem que a nova forma de trabalhar reduz suas possibilidades de crescimento.

A mesma tensão aparece no lado de negócio, quando especialistas antes premiados por escrever requisitos para engenheiros passam a participar de modelagem colaborativa. A mudança parece saudável do ponto de vista do fluxo, mas altera poder, responsabilidade e reconhecimento. Por isso, Ploed insiste em envolver RH e conselhos de trabalhadores cedo, não como bloqueadores burocráticos, e sim como partes capazes de revelar conflitos escondidos. A ressalva importa: ele situa parte dessa experiência no mercado alemão, mas o padrão é mais amplo. Sistemas de salário, orçamento e gestão carregam uma teoria implícita sobre como o trabalho deve acontecer.

A consequência prática é que Team Topologies não pode ser implementado apenas com novos nomes para times, diagramas coloridos e uma expectativa genérica de autonomia. Antes de pedir que equipes assumam mais decisões, a organização precisa verificar se carreira, orçamento e gestão intermediária suportam essa responsabilidade. Caso contrário, o discurso de autonomia produz medo nos gestores, sobrecarga nos times e punição indireta para quem deveria viabilizar a mudança.

Assistir ao episódio original

Referências encontradas

Livros

• Team Topologies, 2nd Edition: Organizing Business And Technology For Fast Flow Of Value (English Edition), de Matthew Skelton; Manuel Pais — Ver livro na Amazon
• Domain-Driven Design: Atacando as Complexidades no Coração do Software, de Eric Evans — Ver livro na Amazon
• Flow Engineering: From Value Stream Mapping To Effective Action, de Steve Pereira; Andrew Davis — Ver livro na Amazon
• Learning Systems Thinking: Essential Nonlinear Skills And Practices For Software Professionals, de Diana Montalion — Ver livro na Amazon

Este post contém links de afiliado. Se você comprar por eles, eu posso receber uma pequena comissão sem custo adicional para você.