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

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

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

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.

Esse post é baseado em um dos melhores artigos que li esse ano e que tenho tentado seguir. Sim, é um exercício constante e para mudar esse comportamento leva tempo. Afinal, somos humanos e reclamar é inerente.

No texto do Marc Brooker, ele toca em um ponto que a maioria das pessoas prefere ignorar (ou que não se atentaram ainda), que são as pessoas e grupos que você escolhe ouvir, dar atenção e participar moldam de forma silenciosa a sua ambição, a sua energia e a sua capacidade de evolução.

E uma grande verdade é que se você passa tempo demais em ambientes e/ou grupos onde o normal é reclamar, você vira parte do problema, mesmo achando que está só desabafando.

Evitando o ruído negativo

“If I could offer you a single piece of career advice, it’s this: avoid negativity echo chambers.”

Grupos onde a reclamação reina vão drenar sua capacidade de pensar com clareza e será criada uma distorção onde todo desafio parece muito complicado, toda empresa é tóxica e todo líder é incompetente.

Você pode não perceber, mas a sua ambição é enfraquecida por osmose.

E a verdade é simples, pessoas que vivem reclamando não progridem e também não querem que você progrida.

E é aí que o pessimismo em grupo vira identidade.

“Sometimes, it becomes a cultural norm… pessimistic people end up dominating.”

Essa é a real, quando a negatividade vira a linguagem comum, quem tenta construir algo novo se torna o ingênuo que não conhece o ambiente que trabalha.

E na minha opinião, esse tipo de grupo/comunidade é bem confortável para quem desistiu silenciosamente da própria evolução. Se você está cercado disso, você com certeza já sabe. E sabe também que, quanto mais tempo passa, mais difícil se desligar dessas comunidades.

Outra grande verdade é que reclamar com pares também não adianta e essa é uma das frases mais verdadeiras do texto:

“DMing away about how much things suck doesn’t make change.”

Sair mandando mensagem privada para seus pares pode criar a sensação de ação, mas a real é que não. Ainda mais se é um problema cultural e/ou estrutural da empresa. No fim, é autoengano com um custo emocional alto.

Quando você passa um tempo demais alimentando essas conversas de bastidores, está tentando dizer para si mesmo que está tentando melhorar… mas, na prática, só está mantendo o status quo. É um vício que parece inofensivo, mas destrói clareza e motivação.

Vale ressaltar que o oposto também é prejudicial:

“Positive echo chambers can be bad too.”

Sim, entusiasmo e positivismo cego é tão tóxico quanto o pessimismo crônico. O ponto central não é ser positivo e good vibes o tempo todo. É ter clareza da situação.

Todo esse otimismo sem ação gera ilusão e a negatividade sem ação gera corrosão e entre esses dois extremos está o único caminho que importa, a realidade com movimento.

E como sair desse ciclo?

O Marc propõe algo bem direto:

“If more than 20% of the content is negative, I move on.”

Marc também define um limite objetivo para se livrar desses ambientes e você não precisa se explicar, não precisa convencer ninguém, é só sair. Se você está consumindo e interagindo de forma negativa mais de 20% do seu tempo ou mais de 20% das conversas são só reclamações, você já sabe o que isso está fazendo com seu cérebro e com seu ânimo.

Meu conselho aqui é fazer uma reflexão do que você consome em mídias sociais (principalmente LinkedIn) e em grupos/comunidades que você participa hoje e se você achar que é tóxico, saia. Novamente, você não precisa se explicar, nem convencer ninguém.

Outra saída é onde você vai e deve colocar sua energia:

“Spend your energy at work doing great work and improving. Or, do the minimum and disconnect.”

Em uma tradução livre “Gaste sua energia no trabalho fazendo um trabalho bacana e sempre melhorando, ou faça o mínimo e desconecte” e ponto final.

Esse clima morno onde você nem cresce, nem descansa e nem se preserva não leva a nada, só estagnação.

Se quer evoluir, aprenda, construa, se exponha ao que te desafia. Se aproxime de pessoas que constroem, que tentam, que erram, que corrigem e que seguem nesse ritmo. Isso vale para pessoas no seu trabalho ou de comunidades.

O que não dá é tentar justificar essa estagnação com discursos sobre “como o mercado é cruel” ou “como ninguém sabe o que faz”. Infelizmente, esse discurso só te faz continuar na mesma.

Pontos finais

Como disse inicialmente, é difícil quebrar esse ciclo e a maioria das pessoas subestima o impacto das comunidades que fazem parte e o conteúdo que consomem.

Você pode ser super competente, ser ótimo tecnicamente, mas se a sua referência diária são grupos onde as pessoas são frustradas e beiram o cinismo, não existem atalhos, mentoria e nem ajuda profissional que ajude.

Meu conselho é, se quiser evoluir, remova todo o ruído negativo, saia de grupos, faça uma boa limpa em suas redes sociais, não dê bola para aquele colega de trabalho que só sabe ver o lado negativo das coisas e comece a se aproximar de quem está construindo e evoluindo.

Imagine você, como Engenheiro/a DevOps ou Engenheiro/a de Software, como você mediria seu desempenho, do seu time ou da engenharia como um todo? Existe algum framework ou método para isso? A resposta é “sim”, como o SPACE e o DevEx, mas o framework que vou abordar hoje é o DORA Metrics.

Medir a eficácia das práticas de DevOps vai além de apenas implementar CI/CD e afirmar que se está praticando DevOps. As DORA Metrics, desenvolvidas pela DevOps Research and Assessment, são fundamentais para obter uma visão precisa e baseada em dados sobre o desempenho de entrega de software. Elas se concentram em quatro métricas principais que revelam o desempenho real das equipes de engenharia, destacando de forma clara as áreas que precisam de melhorias. Com essas métricas, você consegue ir direto ao ponto, identificando gargalos e oportunidades para otimizar processos e entregar mais valor.

Além disso, as DORA Metrics podem ser alinhadas com os objetivos estratégicos da empresa, garantindo que as práticas de DevOps estejam em sintonia com as metas de negócio. Por exemplo, ao melhorar a Frequência de Deploys e reduzir o tempo médio de recuperação de um incidente, a empresa pode acelerar o tempo de lançamento de novos produtos no mercado e consequentemente aumentando sua competitividade e satisfação do cliente.

As quatro métricas

Entendido o que são as DORA Metrics, vamos passar por cada uma delas e dar mais contexto:

Deployment Frequency

Deployment Frequency mede quantas vezes novas versões de código sobem para produção em um determinado período. É um indicador que mede a agilidade da equipe de desenvolvimento e da capacidade de entregar valor continuamente aos usuários e ao negócio. Ou seja, uma alta frequência de deploy corresponde a equipes que respondem rapidamente a feedbacks (feedback loops) e mudanças nas regras de negócios.

Para medir, basta calcular o número de deploys realizados em um período específico, como por dia ou semana. Um processo importante, que minimiza dependências e “burocracias” no processo de deploy e que já é bem difundido é o CI/CD. Vale ressaltar que CI/CD não é ter um Jenkins ou GitHub Actions rodando, CI/CD é de fato o processo contínuo e sem intervenções manuais para rodar uma suíte de testes, processo de build e deploy.

Lead Time for Changes

Mede o tempo que leva desde o commit inicial até o deploy para produção. Essa métrica reflete a eficiência das pipelines, fluxos de desenvolvimento e a capacidade e velocidade de entregar valor.

Diferente do deployment frequency, a ideia é ter essa métrica com indicadores baixos, ou seja, subir pequenas alterações para produção e com mais frequência. A utilização de metodologias ágeis, também ajuda muito no processo.

Mean Time to Recovery ou MTTR

O MTTR mede o tempo médio que um time leva para recuperar um sistema após uma falha em produção. É um indicador da resiliência e estabilidade do sistema. Adotar práticas SRE, como a criação de playbooks para incidentes, observabilidade, e chaos engineering, pode melhorar significativamente o MTTR.

Ter um bom processo de gerenciamento de incidentes, com revisão de post-mortems e ferramentas que alertem a qualquer comportamento anômalo e que possam indicar uma possível falha, ajudam na identificação de melhorias e recuperação/correção mais rápida.

Change Failure Rate

Mede a porcentagem de deploys que resultam em falhas em produção. É um indicador importante para avaliar a qualidade do processo de desenvolvimento e a estabilidade do sistema.

Implementar suíte de testes automatizados, realizar revisões de código de forma mais regular e utilizar pipelines de CI/CD para validação contínua são métodos eficazes para reduzir a taxa de falhas.

Como implementar

A maior parte das ferramentas de CI/CD e observabilidade atualmente conseguem demonstrar os indicadores das quatro métricas. Por exemplo, a Datadog possui em beta uma funcionalidade para extração e análise, a Harness tem algo um pouco mais sólido, porém mais simples. Já o GitLab oferece uma análise bem mais completa, porém apenas no plano Ultimate.

Porém, ambas soluções são pagas e isso vai muito da ferramenta que você utiliza, por isso, recomendo uma ferramenta que tenho estudado há algumas semanas, o Apache DevLake. Nela, é possível plugar várias soluções de mercado e centralizar a extração e visualização de métricas em um só lugar. Outro ponto bem positivo, é que caso na sua empresa seja utilizado alguma ferramenta desenvolvida internamente, o DevLake aceita Webhooks.

Além das quatro métricas, o DevLake consolida várias outras adicionais, como tamanho das Pull Requests, duração dos builds, linhas adicionadas ou deletadas em um commit e por aí vai.

Obviamente, que conseguir integrar a medição das métricas no dia a dia, requer práticas e processos bem definidos. Uma dica é incorporar revisar essas métricas durante as dailies ou em retrospectivas. Criar uma dashboard para que todo time possa acompanhar as métricas pode aumentar a transparência e incentivar a responsabilidade compartilhada.

Estabilidade e Velocidade

Todo mundo quer uma baixa taxa de erros e que sistemas sejam restaurados rapidamente em caso de falha, é uma verdade que todo mundo também quer colocar features de forma mais rápida em produção. E inicialmente, parece que há uma divergência entre elas, certo? Se o time colocar mais features em produção sem bons testes ou controle de qualidade, a taxa de erros pode aumentar.

Algo muito importante, é que observabilidade vai muito de encontro com o tema. Quando há um incidente em produção, é possível entender de forma mais rápida, o problema olhando para qual foi a mudança. Com um lead time mais curto, a compreensão da mudança é mais fácil e consequentemente, sabemos qual é o problema. Ou seja, entender a causa raíz reduz o MTTR, que também reduz a taxa de falhas em mudanças (Change Failure Rate).

O contexto e os recursos são importantes nesses momentos. Porém, essas quatro métricas se influenciam mutuamente e muitas vezes ajudam dar insights que seriam mais difíceis de compreender de outra forma. Analisar essa “dualidade” entre velocidade e estabilidade é uma abordagem eficaz para avaliar o desempenho das práticas DevOps.

Vou deixar alguns livros que recomendo demais para quem quer se aventurar mais na melhoria de fluxo de entrega de software e DevOps.

• Accelerate: The Science of Lean Software and DevOps (Versão Kindle)

• The DevOps Handbook (Versão Kindle)

• Measuring Continuous Delivery

• Observability Engineering (Versão Kindle)

Boa leitura e até a próxima.