A Lei da Menor Fricção Possível
Três princípios para reduzir o atrito entre ICs e EMs, sem fingir que ele não existe
Atualmente estou na minha segunda experiência como Engineering Manager de um time de SRE. Já tinha liderado tecnicamente outros times antes, mas nunca de uma forma tão profunda quanto agora. Sair do técnico para a gestão não foi uma transição simples nem fácil, mas enquanto o desafio está a frente, sempre tentei ser o gestor que eu gostaria de ter tido no passado.
Isso significa prestar atenção em algo que raramente aparece em treinamentos e workshops para gestão, a forma como ICs e EMs se comunicam no dia a dia, principalmente quando as coisas não saem como esperado.
Todo time de engenharia já vivenciou uma cena parecida com essa: um Engineering Manager, tentando ser útil, entra no código e faz um ajuste rápido que conflita com o que o IC responsável já vinha desenhando há um tempo. Ou o contrário, um IC, sem visibilidade completa da carga e das prioridades combinadas com outras áreas, aceita um pedido extra em nome do time, tirando do Engineering Manager a decisão que era dele de negociar prazos e expectativas.
Em nenhum dos dois casos há má intenção. Mas em ambos, alguém cruzou uma fronteira de responsabilidade que não era sua, e o resultado é sempre o mesmo, alguém paga depois, em confiança ou em retrabalho, pela decisão que foi tomada por quem não tinha o contexto completo pra tomar.
Esse tipo de atrito raramente aparece em métricas de engenharia. Não existe métrica para “problema de comunicação”. Mas ele consome tempo, energia e paciência de forma tão real quanto um incidente de produção, só que sem alerta, sem post-mortem, sem SLO.
Depois de observar esse padrão se repetir em contextos bem diferentes, cheguei a uma formulação que tenho chamado, meio de brincadeira e meio a sério entre amigos, de Lei da Menor Fricção Possível, onde:
Em qualquer interação entre pessoas com responsabilidades distintas, a comunicação deve buscar o caminho que resolve o problema com o menor atrito interpessoal possível, o que quase sempre significa falar com quem tem autoridade sobre o problema, no momento certo, e não com quem está e não com quem está mais próximo ou disponível no momento.
Não é uma lei da física, obviamente. É mais parecida com uma heurística, mas assim como as leis de Newton simplificam um sistema complexo em regras aplicáveis, essa formulação tenta simplificar um problema humano recorrente em times de engenharia, como ICs e EMs se comunicam sem gerar desgaste desnecessário.
Por que isso não é óbvio
Times de engenharia lidam muito bem com verdadeiro ou falso, passou ou não passou. Comunicação humana não é binária, e tratá-la como se fosse é onde a fricção começa. E o motivo é (quase sempre) estrutural, EMs e ICs têm responsabilidades diferentes, mas trabalham no mesmo espaço físico e social, o que cria uma tentação constante de opinar sobre tudo, porque parece que dá, mesmo quando não deveria.
Esse fenômeno já foi documentado por quem pensa seriamente sobre a interface entre pessoas e organizações em engenharia. Vale trazer três fontes que ajudam a sustentar essa lei com mais rigor do que só intuição.
Os três princípios
1º - A inércia da responsabilidade
Um problema tende a permanecer sob a responsabilidade de quem tem responsabilidade sobre ele, a menos que uma força externa e formal o mova dali.
RH resolve questões de RH. O tech lead resolve decisões de arquitetura. O EM resolve questões de carreira e alocação de recursos. Quando alguém de fora dessa responsabilidade entra “para ajudar”, o efeito raramente é ajuda, é ruído. A pessoa com responsabilidade perde contexto sobre o que já foi combinado, e a pessoa que decidiu “ajudar” assume um risco que não é dela para assumir.
Isso conecta diretamente com o conceito descrito no Team Topologies, que formaliza modos de interação entre times, como collaboration, X-as-a-Service e facilitating, justamente para deixar claro quem deveria estar conversando com quem, e de que forma, com intuito de reduzir a carga cognitiva de “preciso ficar de olho em tudo”. A ideia central do livro é organizacional, mas o princípio vale igual dentro de um único time, fricção nasce quando os limites de responsabilidade não estão claros, e cada intromissão bem-intencionada é, na prática, uma violação silenciosa desse limite.
Antes de intervir em um problema, se questione: “esse problema tem um dono claro que não sou eu?” Se a resposta for sim, o seu papel é apoiar esse dono, não substituir a pessoa.
2º - Fricção é inversamente proporcional à clareza
Quanto mais ambíguo o critério de decisão, maior o atrito gerado ao tentar resolvê-lo.
Boa parte da fricção entre ICs e EMs não vem de discordância real, vem de papéis mal definidos. Quando ninguém sabe quem decide o quê, toda decisão vira uma negociação implícita de poder, e toda negociação implícita de poder gera desgaste. Isso é fato.
Ferramentas como RACI (ou DACI) existem exatamente para isso, tornar explícito quem é a pessoa Responsável, o Aprovador (ou Accountable), Consultado e o Informado. Parece burocracia, mas na prática é o oposto e é a forma mais barata de evitar fricção, porque elimina a ambiguidade antes que ela vire conflito.
Lara Hogan, em sua talk “Navigating Friction in Your Engineering Team”, propõe uma ferramenta parecida, mas mais visual, um diagrama de Venn com os papéis do time, como Product Manager, Engineering Manager e Tech Lead, por exemplo e mapeia o que é responsabilidade exclusiva de cada um e o que é compartilhado. As bordas propositalmente não são nítidas, porque responsabilidade real nunca é 100% dividida, mas o exercício de colocar isso no papel já elimina boa parte da ambiguidade que vira fricção depois. E assim como o RACI framework, só funciona se for revisado sempre que o time muda.
Na mesma talk, ela argumenta algo bem parecido sobre o resto do problema, fricção é parte normal e necessária do processo de crescimento de um time, mas ela só se torna saudável quando existe um canal claro para dar feedback acionável sem escalar para o drama (e haja drama hoje em dia). Sem essa clareza de “para onde vai esse feedback”, a fricção não se resolve, ela se acumula.
O que eu recomendo é sempre que perceber fricção recorrente em um mesmo tipo de decisão, pare de tratar como problema de relacionamento e trate como problema de processo. Provavelmente falta um dono claro ou um critério explícito.
3º - Todo desacordo técnico precisa de um mecanismo de fechamento
Discordância sem fechamento não gera alinhamento, gera fricção crônica.
Discordar é saudável. Um IC discordar de uma decisão do EM, ou vice-versa, é sinal de que as pessoas estão pensando, não de que o time está quebrado. O problema não é a discordância, é a ausência de um mecanismo para encerrá-la. É quem bate o martelo na decisão.
A Amazon formalizou isso no princípio de liderança “disagrees and commits”, onde você tem o direito e a responsabilidade de discordar abertamente, mas, uma vez tomada a decisão, todos remam na mesma direção, inclusive quem discordou. Sem esse “commit” explícito, a discordância vira uma ferida aberta que reaparece a cada sprint.
E quando a discordância acontece, o como ela é comunicada importa tanto quanto o conteúdo. Aqui entra a base do livro Comunicação Não Violenta, de Marshall Rosenberg, a observação sem julgamento, a expressão do sentimento, a identificação da necessidade por trás de uma posição e um pedido claro. Trocar o “você não entendeu o problema” por “eu não vi essa dependência no design proposto, pode me mostrar onde ela está documentada?” já elimina boa parte do atrito antes que ele comece. Não vai mudar a discordância técnica da conversa, só vai remover a carga emocional desnecessária.
Um livro que li, a primeira vez que exerci o papel de liderança há uns anos atrás, foi o Radical Candor, que resume bem por que isso tudo é importante, fricção mal calibrada, seja evitar o confronto por educação excessiva, seja confrontar sem cuidado, destrói a confiança dos dois lados. O ponto é desafiar diretamente, mas a partir de um lugar de cuidado genuíno pela pessoa e pelo problema.
O que eu acredito é que toda discussão técnica difícil deveria terminar com uma pergunta claríssima: “temos uma decisão e um dono para ela?” Se a resposta for não, a discussão não terminou, só parou.
O paralelo com Engenharia de Confiabilidade
Se você trabalha com SRE, essa lei vai soar familiar por outro motivo, ela funciona quase como um error budget de confiança organizacional.
Todo time tem uma tolerância finita a atrito. Fricção pontual e bem resolvida, como um desacordo técnico saudável, um feedback direto mas cuidadoso é o equivalente a gastar uma fração pequena e aceitável desse budget.
Já fricção repetitiva e crônica, gerada por responsabilidades “invadidas” ou decisões nunca tomadas, é dívida técnica organizacional, você não paga a fatura na hora, mas ela acumula juros em confiança, em engajamento, em retenção, até que o time inteiro sinta o peso. E aí, meus amigos, você sabe onde isso vai dar, conflitos, pedidos de demissões, pessoas com a moral baixíssima e desanimadas.
Diagnosticando rápido
Se você quiser diagnosticar o nível de fricção no seu time, montei um checklist com algumas perguntas que podem ajudar:
Existe alguma decisão recorrente cujo dono muda dependendo de quem está mais engajado naquele momento?
Quando alguém discorda tecnicamente, existe um momento claro em que a discussão se encerra e vira uma decisão?
As pessoas dão feedback difícil diretamente para quem precisa ouvir, ou ele circula como fofoca antes de chegar lá?
Questões de pessoas (carreira, RH, conflito interpessoal) são resolvidas por quem tem responsabilidade para isso, ou qualquer pessoa próxima se sente no direito de opinar?
Se a resposta a qualquer uma dessas revelar ambiguidade, você já tem o próximo passo, não é uma conversa difícil que falta, é um critério ou um mecanismo de fechamento que ainda não existe.
A Lei da Menor Fricção Possível não elimina o atrito e nenhum time saudável deveria querer isso. Ela só garante que o atrito que existe seja o atrito certo, o da discordância técnica verdadeira e genuína, não o de responsabilidades trocadas ou de decisões que nunca são tomadas.