Por Maria-Hendrike Peetz, Luis Quesada Torres e Marilia Melo com Diane Bates 

Quando uma equipe de SRE está funcionando bem, os membros da equipe devem sentir que podem lidar confortavelmente com todo o seu trabalho. Eles devem ser capazes de trabalhar em tickets e ainda ter tempo para trabalhar em projetos de longo prazo que facilitem a gestão do serviço no futuro. 

Mas às vezes circunstâncias atrapalham os objetivos de trabalho de uma equipe. Membros da equipe tiram licenças por doenças de longo prazo ou mudam para novas equipes. Organizações estabelecem novos programas de produção para SRE. Mudanças no serviço ou no sistema maior introduzem novos desafios técnicos. À medida que a carga de trabalho aumenta, os membros da equipe começam a trabalhar mais horas para lidar com tickets e páginas e passam menos tempo em trabalhos de engenharia. Toda a equipe começa a se sentir estressada e frustrada ao trabalhar mais, mas não sentir que estão progredindo. O estresse, por sua vez, faz com que as pessoas cometam mais erros, impactando a confiabilidade e, em última instância, os usuários finais. Em resumo, a equipe perde sua capacidade de regular seu trabalho diário e gerenciar efetivamente o serviço. 

Neste ponto, a equipe precisa encontrar uma saída desse estado sobrecarregado. Eles precisam reequilibrar sua carga de trabalho para que os membros da equipe possam se concentrar no trabalho de engenharia essencial. 

Carga operacional (ou carga de trabalho operacional) é um termo que descreve as tarefas de manutenção contínua que mantêm os sistemas e serviços funcionando com desempenho ótimo. Existem três tipos distintos de carga operacional: páginas, tickets e responsabilidades operacionais contínuas. Páginas geralmente exigem atenção imediata, e tickets relacionados a problemas urgentes podem ter prazos apertados. Tanto páginas quanto tickets urgentes interrompem os SREs de trabalhar em projetos de engenharia que suportam as responsabilidades operacionais da equipe. Por esse motivo, nos referimos a eles como interrupções. O Capítulo 29 de Engenharia de Confiabilidade de Sites discute técnicas para gerenciar as interrupções que naturalmente surgem quando uma equipe está mantendo um sistema complexo em estado funcional. 

Quando a carga operacional ultrapassa a capacidade de uma equipe de gerenciá-la, a equipe acaba em um estado de sobrecarga operacional (também chamado de sobrecarga de trabalho). Uma equipe está em um estado de sobrecarga operacional quando não consegue progredir em direção às prioridades-chave porque questões urgentes continuamente preemptam o trabalho de projeto. Além de prejudicar as prioridades da equipe e melhorias no serviço, a sobrecarga pode aumentar a chance de os engenheiros cometerem erros. 

O limite de sobrecarga operacional pode variar de equipe para equipe. As equipes de SRE do Google limitam o trabalho operacional a 50% do tempo de um engenheiro. Uma equipe de SRE bem-sucedida deve ter confiança de que, a longo prazo, será capaz de concluir os projetos de engenharia necessários para reduzir a carga operacional dos serviços que gerenciam. 

Este capítulo descreve como equipes do Google progrediram de uma situação difícil caracterizada por sobrecarga operacional para uma carga de trabalho bem gerenciada. Dois estudos de caso mostram o efeito prejudicial da sobrecarga operacional na saúde da equipe e como as equipes fizeram mudanças em suas tarefas diárias para poderem se concentrar em projetos impactantes de longo prazo. No Estudo de Caso 1, a sobrecarga ocorre quando os membros remanescentes em uma equipe em declínio não conseguem acompanhar a carga de trabalho. No Estudo de Caso 2, uma equipe sofre de sobrecarga percebida – um estado que tem os mesmos efeitos que a sobrecarga operacional, mas começa como uma percepção errada da carga de trabalho real. 

Embora esses estudos de caso destaquem ações específicas que funcionaram para duas equipes de SRE do Google, a seção “Estratégias para Mitigar a Sobrecarga” na página 366 fornece práticas para identificar e mitigar a sobrecarga que se aplicam a qualquer empresa ou organização. Portanto, este capítulo deve ser útil para gerentes de equipes sobrecarregadas, ou qualquer equipe de SRE preocupada com a sobrecarga. 

De carga para sobrecarga

Independentemente da sua origem, a sobrecarga é um estresse ocupacional que pode prejudicar a produtividade. Deixada sem controle, pode causar doenças graves. Para equipes de SRE, a carga operacional geralmente é uma combinação de tarefas cognitivamente difíceis (como depurar vazamentos de memória ou falhas de segmentação) e muitas tarefas pequenas que requerem trocas de contexto frequentes (trabalhar em solicitações de cotas, iniciar implantações binárias, etc.). 

A sobrecarga de trabalho geralmente ocorre quando uma equipe não tem tempo suficiente para lidar com todas essas tarefas – uma realidade objetiva quando o número de tarefas atribuídas a uma equipe não pode ser concluído dentro do prazo estabelecido para cada tarefa. A sobrecarga percebida é mais subjetiva e ocorre quando os indivíduos na equipe sentem que têm muito trabalho. Isso geralmente acontece quando várias mudanças organizacionais ou de trabalho ocorrem em um curto período de tempo, mas a equipe tem pouca oportunidade de comunicar-se com a liderança sobre as mudanças. 

Nunca fica claro quais problemas vão surgir quando você está de plantão, ou qual será sua carga de trabalho. Por um lado, um único ticket aparentemente inocente sobre falta de espaço em disco pode levar a uma investigação detalhada de um trabalho de coleta de lixo recorrente. Por outro lado, uma tempestade de pagers com mais de 20 páginas pode se revelar um caso de monitoramento ruim. Quando é difícil estimar ou prever sua carga de trabalho, você pode facilmente cair em vítima de vieses cognitivos e julgar mal sua carga de trabalho – por exemplo, você pode avaliar uma fila de tickets como muito grande para ser concluída durante seu turno de plantão. Mesmo que você consiga concluir todos os tickets rapidamente e a carga de trabalho real seja baixa, você se sente sobrecarregado quando olha pela primeira vez para a fila de tickets. Essa sobrecarga percebida tem um componente psicológico que afeta sua abordagem e atitude em relação ao seu trabalho. Se você não começar o dia com a preconcepção de que há muito trabalho, é mais provável que mergulhe e comece a trabalhar na fila de tickets. Talvez você trabalhe o dia todo e não termine sua carga de trabalho (enfrentando assim uma sobrecarga de trabalho), mas faz muito mais progresso do que se tivesse começado o dia se sentindo sobrecarregado. 

Acumular muitas interrupções pode levar à sobrecarga de trabalho, mas não precisa ser assim. No entanto, quando interrupções frequentes são combinadas com fatores de estresse externos, uma carga de trabalho grande (ou até mesmo pequena) pode facilmente se transformar em sobrecarga percebida. Esse estresse pode derivar do medo de desapontar outros membros da equipe, insegurança no trabalho, conflitos relacionados ao trabalho ou pessoais, doenças ou questões relacionadas à saúde, como falta de sono ou exercício. 

Se o seu trabalho não estiver adequadamente priorizado, cada tarefa pode parecer igualmente urgente, levando tanto à sobrecarga real quanto à percebida. No caso de sobrecarga real, a urgência de tickets e alertas pode fazer com que os membros da equipe trabalhem até resolver o problema, mesmo que isso signifique horas longas e contínuas. Quando uma equipe enfrenta sobrecarga percebida, a repriorização pode ajudar a diminuir a quantidade de trabalho urgente, criando espaço para que eles enfrentem as fontes de sobrecarga por meio de projetos. 

Ao analisar sua situação específica, você não deve necessariamente assumir que a carga de trabalho em si precisa mudar. Em vez disso, recomendamos quantificar primeiro o trabalho que sua equipe enfrenta e como ele mudou (ou não) ao longo do tempo. Por exemplo, você pode medir a carga de trabalho pelo número de tickets e páginas que a equipe trata. Se sua carga de trabalho realmente não mudou ao longo do tempo, a equipe pode se sentir sobrecarregada simplesmente porque percebe o trabalho como avassalador. Para obter uma visão mais holística da carga de trabalho atual da equipe, você pode coletar uma única captura instantânea pedindo a cada membro que liste todas as tarefas de trabalho que enfrentam. Em seguida, examine os fatores de estresse psicológico enfrentados pela sua equipe, como mudanças organizacionais ou repriorização. Depois de realizar sua pesquisa, você tem uma base estável para tomar decisões sobre a mudança na carga de trabalho. 

“Estratégias para Mitigar a Sobrecarga” aborda mais sobre como identificar a sobrecarga, tanto real quanto percebida. Primeiro, apresentamos dois estudos de caso de equipes que reconheceram que estavam em sobrecarga e tomaram medidas para aliviá-la. 

Estudo de caso 1: sobrecarga de trabalho quando metade de uma equipe sai

Contexto

Uma das equipes de SRE de armazenamento interno do Google era responsável pelos backends de vários serviços, incluindo Gmail, Google Drive e Google Groups, e muitos outros serviços internos ou voltados para o usuário. Experimentamos uma crise em meados de 2016, quando dois terços da equipe – incluindo o engenheiro mais sênior (o gerente) – foram transferidos para outras oportunidades em uma janela relativamente curta, por razões genuinamente não relacionadas. Este evento obviamente levou a um grande problema de gestão de carga de trabalho: menos SREs disponíveis para cobrir o mesmo trabalho operacional e de projetos rapidamente resultaram em sobrecarga. Nosso trabalho também foi prejudicado porque a especialização de cada membro da equipe estava isolada em uma área diferente da produção. Embora a adição de novos membros à equipe e três estagiários melhorasse nossa carga de trabalho a longo prazo, integrar esses engenheiros exigiria um investimento sério de tempo e energia. 

Declaração do problema

Os fatores anteriores diminuíram significativamente a produtividade da equipe. Começamos a ficar para trás no trabalho de projeto, e os tickets relacionados aos muitos serviços que gerenciávamos começaram a se acumular. Não tínhamos capacidade para lidar com esse acúmulo, pois todo o nosso trabalho era consumido por tarefas de maior prioridade. Não demoraria muito para não conseguirmos realizar todo o trabalho crítico e urgente de que precisávamos. Enquanto isso, estava previsto que nossa equipe receberia mais trabalho de alta prioridade em breve. 

Se não transferíssemos parte do trabalho para outras mãos, seria apenas questão de tempo até começarmos a deixar de lado tarefas importantes por acidente. No entanto, assim que começamos a transferir trabalho, encontramos algumas barreiras psicológicas: 

• Desistir de qualquer trabalho em andamento parecia que tínhamos acabado de desperdiçar nossos esforços. A maior parte do acúmulo parecia ser crítica ou valer o esforço para nós, então simplesmente não parecia certo cancelar ou adiar projetos indefinidamente. Não percebemos que estávamos sob o domínio de uma falácia de custo afundado. 
• Colocar esforço em automatizar processos ou corrigir a causa raiz da carga de trabalho não era tão crítico quanto lidar imediatamente com interrupções de alta prioridade. Quando esse trabalho era adicionado ao topo de uma pilha já enorme, todo o trabalho parecia esmagador. 

O que decidimos fazer

Reunimos a equipe em uma sala e listamos todas as responsabilidades da equipe, incluindo backlog de projetos, trabalho operacional e tickets. Em seguida, classificamos cada item da lista. Visualizar cada uma de nossas tarefas de trabalho (mesmo que a lista mal coubesse no quadro branco) nos ajudou a identificar e redefinir nossas prioridades reais. Fomos então capazes de encontrar maneiras de minimizar, repassar ou eliminar itens de trabalho de menor prioridade. 

Implementação

Identificamos automações de baixo esforço que, embora não críticas, reduziriam significativamente a carga operacional uma vez implementadas. 

Também identificamos problemas comuns que poderíamos documentar para possibilitar o autoatendimento. Escrever os procedimentos necessários para nossos clientes não levou muito tempo e eliminou algum trabalho repetitivo de nossa fila. 

Fecharmos o maior número possível de nossos tickets em atraso de forma razoável. A maioria desses tickets acabou sendo obsoleta, redundante ou não tão urgente quanto alegavam. Alguns tickets eram artefatos de monitoramento que não demandavam ação, então corrigimos o monitoramento relevante. Em alguns casos, estávamos lidando ativamente com problemas que não eram críticos. Deixamos esses problemas de lado para trabalhar em tickets mais urgentes, mas primeiro documentamos nosso progresso para não perdermos o contexto antes de podermos voltar a trabalhar neles. 

Quando em dúvida, abandonamos uma tarefa, mas a marcamos para uma segunda fase de triagem. Assim que nossas agendas estavam (quase) vazias, revisitamos essa lista tentativa para decidir quais tarefas retomar. Descobrimos que quase nenhuma dessas tarefas tinha impacto ou importância suficientes para serem retomadas. 

Em dois dias – um dia de triagem intensiva mais um dia de documentação de processos e implementação de automação – nossa equipe muito menor resolveu um backlog de vários meses de interrupções. Em seguida, pudemos lidar com as poucas interrupções restantes, que estavam relacionadas a problemas ativos em produção. 

Lições aprendidas

Nossa equipe aprendeu que identificar e delimitar a sobrecarga é o primeiro passo para resolvê-la. Precisávamos reunir todos em uma sala e reavaliar o backlog antes de ajudar nossa equipe a retornar a um estado saudável. 

Para evitar uma nova acumulação de interrupções, começamos a triar interrupções uma vez a cada duas semanas. Nosso líder técnico verifica periodicamente a fila de tarefas e avalia se a equipe está em risco de sobrecarga. Decidimos que cada membro da equipe deveria ter 10 ou menos tickets abertos para evitar a sobrecarga. Se o líder da equipe perceber que os membros da equipe têm mais de 10 tickets, eles podem realizar uma ou alguma combinação das seguintes ações: 

• Lembrar a equipe para fechar tickets obsoletos. 
• Sincronizar com os membros da equipe sobrecarregados e transferir tickets deles. 
• Incentivar os membros individuais da equipe a lidarem com sua fila de tickets. 

• Organizar um dia de reparo de tickets para toda a equipe. 
• Atribuir trabalho para corrigir as fontes de tickets, ou trabalho operacional para reduzir futuros tickets. 

 Estudo de caso 2: sobrecarga percebida após mudanças organizacionais e de carga de trabalho

Contexto

A equipe de SRE do Google neste estudo de caso estava dividida entre dois locais, com seis ou sete engenheiros de plantão em cada local (para mais discussões sobre o tamanho da equipe, consulte o Capítulo 11 de Engenharia de Confiabilidade de Sites). Enquanto a equipe de Sydney estava operacionalmente saudável, a equipe de Zurique estava sobrecarregada. 

Antes da equipe de Zurique entrar em sobrecarga, estávamos estáveis e contentes. O número de serviços que gerenciávamos era relativamente estável, e cada um deles era variado e exigia muita manutenção. Embora os SLOs dos serviços que apoiamos não estivessem alinhados com os SLOs de suas dependências externas, essa disparidade não havia causado nenhum problema. Estávamos trabalhando em vários projetos para melhorar os serviços que gerenciávamos (por exemplo, melhorando o balanceamento de carga). 

Gatilhos simultâneos levaram a equipe de Zurique à sobrecarga: começamos a integrar novos serviços que eram mais barulhentos e menos integrados à infraestrutura geral do Google, e o líder técnico e outro membro da equipe deixaram nossa equipe, deixando-a com duas pessoas a menos. A combinação da carga de trabalho adicional e da perda de conhecimento desencadeou mais problemas: 

• Monitoramento desajustado para os novos serviços e o monitoramento relacionado à migração resultaram em mais páginas por turno. Essa acumulação foi gradual, então não percebemos o aumento conforme ocorria. 
• Os SREs se sentiam relativamente impotentes com os novos serviços. Não sabíamos o suficiente sobre eles para reagir adequadamente e frequentemente precisávamos fazer perguntas à equipe de desenvolvimento. Embora a sobrecarga talvez justificasse devolver um serviço aos desenvolvedores, nossa equipe nunca tinha devolvido um serviço, então não consideramos realmente essa uma opção viável. 
• Uma rotação de plantão menor, com cinco pessoas, reduziu as horas que normalmente dedicávamos ao trabalho operacional. 
• Novos alertas de tickets estavam revelando problemas que existiam antes das mudanças recentes na equipe. Embora tivéssemos simplesmente ignorado esses problemas no passado, agora éramos obrigados a mover alertas de e-mail ignorados para tickets. O planejamento de projetos não tinha levado em conta essa nova fonte de dívida técnica. 
• Um novo SLO de tickets exigia que lidássemos com os tickets dentro de três dias, o que significa que os plantonistas tinham que resolver os tickets criados durante seu turno de plantão muito mais rapidamente. O SLO visava reduzir o número de tickets adicionados ao nosso backlog (principalmente ignorado), mas criou um efeito colateral que talvez fosse ainda pior. Agora, os SREs sentiam que não podiam descansar o suficiente após um turno porque tinham que enfrentar imediatamente o trabalho de acompanhamento. A prioridade mais alta atribuída a esses tickets também significava que os SREs não tinham tempo suficiente para outros trabalhos 

Durante esse período, nossa equipe foi designada para um novo gerente que também gerenciava outras duas equipes. O novo gerente não fazia parte da rotação de plantão e, portanto, não sentia diretamente o estresse que os membros da equipe estavam experimentando. Quando a equipe explicou a situação ao gerente, nada mudou. Os membros da equipe sentiam que não estavam sendo ouvidos, o que os deixava distantes da equipe de gerenciamento. 

A sobrecarga de tickets continuou por meses, deixando os membros da equipe mal-humorados, até que uma cascata de insatisfação se espalhou pela equipe. 

Declaração do problema

Após perder duas pessoas e receber trabalho adicional e variado, nossa equipe se sentiu sobrecarregada. Quando tentamos comunicar esse sentimento ao nosso gerente direto, o gerente discordou. À medida que as longas horas continuavam, o cansaço se instalava. A produtividade estava diminuindo e as tarefas começaram a se acumular mais rápido do que a equipe conseguia resolvê-las. A sobrecarga percebida agora se tornava uma sobrecarga objetiva, tornando a situação pior. 

O estresse emocional causado pela sobrecarga estava diminuindo a moral e levando alguns membros da equipe ao esgotamento. À medida que os indivíduos lidavam com os efeitos físicos do excesso de trabalho (doenças e produtividade reduzida), outras pessoas na equipe tinham que assumir mais trabalho. O trabalho atribuído nas reuniões semanais da equipe não estava sendo concluído. 

Começamos a assumir que não podíamos depender das outras pessoas para fazerem seu trabalho, o que minava os sentimentos de confiança e confiabilidade dentro da equipe. Como resultado, não nos sentíamos seguros em assumir riscos interpessoais, um fator importante na segurança psicológica (consulte o Capítulo 11 em Engenharia de Confiabilidade de Sites). Os membros da equipe não se sentiam aceitos e respeitados pelos outros membros da equipe, então não colaboravam livremente uns com os outros. À medida que a segurança psicológica diminuía na equipe, a colaboração parava, retardando o compartilhamento de informações e causando mais ineficiências. 

As pesquisas da equipe também revelaram uma perda de segurança psicológica – os membros da equipe disseram que não se sentiam pertencentes à equipe. Eles não se importavam mais com o desenvolvimento de suas próprias carreiras, e a taxa de promoção na equipe caiu para um nível recorde baixo. 

Finalmente, chegamos a um ponto de ruptura quando a alta administração nos atribuiu novos projetos obrigatórios em toda a empresa. Neste ponto, renovamos nossas conversas com a gestão sobre a sobrecarga com renovada energia. Uma série de discussões revelou que nossa situação infeliz não era apenas resultado de muito trabalho – nossas percepções de segurança da equipe nos levaram a parar de confiar e colaborar uns com os outros. 

O que decidimos fazer

A alta administração atribuiu à nossa equipe um novo gerente que não era compartilhado entre três equipes. O novo gerente utilizou um estilo de gestão participativa para melhorar a segurança psicológica na equipe, para que pudéssemos colaborar novamente. Este método capacita os membros da equipe a participarem ativamente da resolução de problemas da equipe. Toda a equipe, incluindo nosso gerente direto, participou de um conjunto de exercícios simples de construção de equipe para melhorar a eficácia de nossa equipe (alguns tão simples como tomar chá juntos). Como resultado, fomos capazes de elaborar um conjunto de objetivos: 

Curto prazo  

Aliviar o estresse e melhorar a segurança psicológica para estabelecer um ambiente de trabalho saudável. 

Médio prazo  

Construir a confiança dos membros individuais da equipe por meio de treinamento.  

Identificar a causa raiz dos problemas que estão causando a sobrecarga. 

Longo prazo  

Resolver os problemas contínuos que contribuíram para a cascata. 

Para estabelecer esses objetivos, primeiro tivemos que alcançar algum tipo de segurança psicológica básica dentro da equipe. À medida que a moral melhorava, começamos a compartilhar conhecimento e desenvolver ideias uns dos outros para descobrir maneiras de controlar nossa carga 

Implementação

Ações de curto prazo 

O estresse a longo prazo, seja causado pelo excesso de trabalho ou percepções de segurança da equipe, diminui a produtividade e afeta a saúde das pessoas. Portanto, nossa ação de curto prazo mais importante foi fornecer alívio do estresse e melhorar a confiança e a segurança psicológica. Uma vez aliviados de parte do estresse, os membros da equipe puderam pensar com mais clareza e participar impulsionando toda a equipe para a frente. Dentro de um mês após identificar a sobrecarga, implementamos o seguinte: 

• Iniciamos uma mesa redonda semiregular para discutir problemas. A equipe liberou a frustração e elaborou possíveis causas da sobrecarga. 
• Encontramos uma métrica melhor para medir a carga. Decidimos melhorar nossa métrica original de número de páginas. Automatizamos a atribuição de tickets aos plantonistas, e o plantonista era responsável por esses tickets mesmo após o término do seu turno. Nossa nova métrica média quanto tempo um plantonista precisava para resolver um ticket após o término do seu turno. 
• Auditamos e removemos alertas de spam. Revisamos os alertas e removemos aqueles que não representavam problemas voltados para o usuário. 
• Silenciamos os alertas generosamente. A equipe deliberadamente não tentou encontrar a origem de cada alerta, mas concentrou-se em aliviar o estresse de ser constantemente acionado e receber tickets por problemas que já conhecíamos. Utilizamos a seguinte estratégia: 
• – Os alertas que surgiram foram silenciados até serem resolvidos. 
• – Os alertas podiam ser silenciados apenas por um período limitado de tempo (geralmente um dia, às vezes até uma semana). Caso contrário, poderiam mascarar interrupções. 

• – Os alertas que não podiam ser corrigidos em poucos minutos eram atribuídos a um ticket de acompanhamento. 
• Adicionamos um gerente direto dedicado a uma única equipe. Ao tornar um membro da equipe respeitado o novo gerente, reestabelecemos a confiança na gestão. Em vez de gerenciar três equipes, o novo gerente podia dedicar mais tempo à equipe e aos seus membros. 
• Reequilibramos a equipe. Introduzimos uma nova perspectiva e alívio do plantão adicionando SREs tecnicamente experientes que não tinham preconceitos sobre a equipe ou organização. Encontrar pessoas adequadas não foi uma tarefa fácil, mas valeu muito o esforço. 
• Instituímos eventos de equipe, como almoços e sessões de jogos de tabuleiro. Conversar sobre assuntos não relacionados ao trabalho e rir juntos aliviou a tensão na equipe e melhorou a segurança psicológica. 

Ações de médio prazo 

Soluções de curto prazo por si só não sustentariam um ambiente saudável – por exemplo, uma de nossas táticas de curto prazo foi silenciar alertas sem realmente resolver a causa. Dentro de três meses, também tomamos as seguintes medidas: 

• Limitamos o trabalho operacional ao tempo de plantão o máximo possível (consulte o Capítulo 29 em Engenharia de Confiabilidade de Sites) para que a equipe pudesse se concentrar em soluções permanentes e trabalho de projeto. 
• Devolvemos a responsabilidade por um serviço à sua equipe de desenvolvimento. 
• Treinamos uns aos outros (e novos membros da equipe). Embora o treinamento exija um investimento de tempo e energia, a disseminação de conhecimento significava que todos os membros da equipe (e futuras contratações) poderiam diagnosticar e resolver problemas mais rapidamente no futuro. O treinamento dos colegas de trabalho aumentou nossa confiança, pois percebemos que realmente sabíamos bastante sobre os serviços. À medida que adquiriam conhecimento, os membros da equipe começaram a encontrar novas maneiras de gerenciar os serviços, melhorando sua confiabilidade e reduzindo a sobrecarga. 
• Trouxemos SREs da equipe remota para trabalhar em alguns de nossos turnos de plantão e participar do treinamento. Eles perceberam a pressão sobre a equipe e forneceram uma valiosa nova perspectiva. 
• Preenchemos as duas vagas abertas na equipe. 
• Lidamos com cada alerta à medida que os silenciamentos expiravam. Discutimos páginas repetitivas e páginas que não resultaram em nenhuma ação detalhadamente na reunião de produção semanal, o que nos levou a ajustar os alertas e/ou corrigir os problemas subjacentes. Embora essas fossem ações importantes (e óbvias), só tínhamos espaço para analisar e tomar medidas quando o alerta estava silenciado e não gerava ruído constante. 
• Organizamos eventos de escuta. A gestão (incluindo o gerente de nível superior e os líderes de equipe) fez um esforço consciente para ouvir os pontos de dor da equipe e encontrar uma solução conduzida pela equipe. 
• Adicionamos perspectiva. A esperança não é uma estratégia, mas certamente ajuda na moral da equipe. Com a promessa de novos membros se juntando à rotação de plantão, uma mudança para prioridades mais claras e o fim de projetos que geram ruído, o humor da equipe melhorou. 

Ações de longo prazo 

Para ajudar a manter nossa estabilidade recém-descoberta, estamos atualmente alinhando nossos SLOs com os SLOs de seus back-ends de serviço e trabalhando para tornar os serviços mais uniformes. A uniformidade tem um benefício duplo: ela diminui a carga cognitiva para os SREs e facilita a escrita de automação que pode ser usada em todos os serviços. Também estamos revisando serviços que existem há muito tempo e os atualizando para os padrões de produção atuais. Por exemplo, alguns serviços estão operando mal sob carga que aumentou significativamente ao longo dos anos. Alguns serviços precisam ser atualizados de acordo com as políticas de seus serviços de back-end. Outros serviços simplesmente não foram atualizados há vários anos. 

Efeitos

Alguns meses após nossa primeira reunião de brainstorming, os resultados começaram a surgir: os turnos de plantão ficaram mais tranquilos, e nossa equipe conseguiu lidar rapidamente e eficientemente com um incidente difícil de forma colaborativa como grupo. Um pouco depois, novos membros da equipe chegaram. Quando discutimos segurança psicológica durante uma sessão de mesa redonda, os novos membros disseram que não conseguiam imaginar que a equipe já tivesse tais problemas. Na verdade, eles viam nossa equipe como um lugar caloroso e seguro para trabalhar. Cerca de um ano após a escalada inicial, pouco da sobrecarga original permanecia e uma pesquisa anônima mostrou que os membros da equipe agora sentiam que a equipe era eficaz e segura. 

Lições aprendidas

As mudanças no local de trabalho podem ter um impacto psicológico nas pessoas da equipe – afinal, seus colegas de equipe não são máquinas. Você precisa prestar atenção nos níveis de estresse da equipe para que as pessoas comecem a confiar o suficiente umas nas outras para trabalhar juntas; caso contrário, a equipe pode entrar em um ciclo vicioso de sobrecarga que causa estresse, o que por sua vez impede você de enfrentar a sobrecarga. 

A sobrecarga percebida é, de fato, uma sobrecarga, e tem tanto impacto em uma equipe quanto a sobrecarga de trabalho causada por outros fatores. Em nosso caso, nossa equipe irmã em Sydney não experimentou os mesmos problemas, e o número de páginas que recebemos na verdade não mudou muito em comparação com os anos anteriores. Em vez disso, a perda de dois membros da equipe, aumento da carga cognitiva, aumento do ruído dos tickets e um novo SLO de três dias nos tickets levaram a equipe a perceber a sobrecarga. No final, a diferença entre sobrecarga objetiva e percebida não importava: a sobrecarga percebida de alguns membros da equipe pode rapidamente levar à sobrecarga de toda a equipe. 

Estratégias para mitigar a sobrecarga

Uma perspectiva externa às vezes pode identificar facilmente quando uma equipe está sobrecarregada. Da mesma forma, é fácil comentar sobre quais ações deveriam ter sido tomadas em retrospecto. Mas como você identifica a sobrecarga quando está no meio dela? O caminho em direção a um ambiente de trabalho saudável, amigável e feliz pode ser difícil de visualizar quando você está atolado em sobrecarga. Esta seção descreve práticas para identificar e mitigar a sobrecarga em sua equipe. 

Reconhecendo os sintomas da sobrecarga 

É bastante fácil identificar uma equipe sobrecarregada se você conhecer os sintomas da sobrecarga: 

Diminuição da moral da equipe 

A sobrecarga pode se manifestar através de desabafos e reclamações. Pesquisas sobre tópicos relevantes (condições de trabalho, satisfação no trabalho, projetos, colegas e gerentes) geralmente refletem a moral da equipe e produzem resultados mais negativos quando uma equipe está sobrecarregada. Sessões regulares de escuta ativa com líderes de equipe podem trazer à tona problemas dos quais você não estava ciente. Um elemento essencial da escuta ativa é ouvir sem julgamento. 

Membros da equipe trabalhando longas horas e/ou trabalhando quando estão doentes 

Trabalhar horas extras sem compensação pode ser um estressor psicossocial. Os líderes devem dar o exemplo: trabalhar as horas contratuais e ficar em casa quando estiverem doentes. 

Doenças mais frequentes 

Membros da equipe sobrecarregados tendem a ficar mais desgastados e doentes com mais frequência. 

Uma fila de tarefas não saudável 

Recomendamos revisar regularmente a fila de tarefas da sua equipe para ver quantos tickets estão atrasados, quem está lidando com quais problemas e quais tarefas podem ser adiadas ou descartadas. Se a equipe estiver perdendo prazos, ou se questões urgentes impedirem você de realizar essa revisão regularmente, é muito provável que a equipe esteja acumulando interrupções mais rapidamente do que pode lidar com elas. 

Métricas desequilibradas 

Algumas métricas-chave podem indicar que sua equipe está sobrecarregada: 

• • Longos períodos para fechar um único problema  
  • Alta proporção de tempo gasto em trabalho operacional  
  • Grande número de dias para fechar problemas originados de uma sessão de plantão 

A equipe deve trabalhar em conjunto para decidir quais medidas usar. Não há uma abordagem única; a sobrecarga de cada equipe se manifesta de maneiras diferentes. Como gerente, não imponha uma medida à equipe sem ter uma ideia da carga de trabalho e dos hábitos de trabalho de cada indivíduo. Os membros da equipe podem sentir que você não compreende o trabalho se insistir em usar uma medida específica. Por exemplo, se você estiver avaliando a carga pelo número de dias necessários para resolver um problema, uma pessoa pode trabalhar um dia inteiro resolvendo um problema, enquanto outra pessoa pode distribuir o trabalho ao longo de vários dias, juntamente com outras tarefas. 

Reduzindo a sobrecarga e restaurando a saúde da equipe

Depois de passar pelos critérios, você pode pensar que sua equipe já está sobrecarregada. Não se desespere! Esta seção fornece uma lista de ideias para levar sua equipe de volta a um estado saudável. 

Em geral, dar aos membros da equipe mais controle e poder reduz a sobrecarga percebida. Embora os gerentes possam ser tentados a recorrer ao microgerenciamento em situações estressantes, é importante manter a equipe informada e trabalhar na priorização juntos para aumentar o nível de desempenho e satisfação no trabalho. Este modelo pressupõe uma base de uma equipe funcional, onde você tem (no mínimo) um relacionamento razoavelmente saudável entre a gerência e os membros da equipe, e entre os próprios membros da equipe. 

Identificar e aliviar os estressores psicossociais 

Quando se trata de corrigir uma equipe disfuncional, em primeiro lugar, os membros individuais da equipe precisam recuperar seu senso de segurança psicológica. Uma equipe só pode funcionar tão bem quanto seus membros individuais. 

Você pode começar identificando e aliviando os estressores psicossociais para cada indivíduo e para a equipe como um todo. Quais desses fatores você realmente pode controlar? Você não pode controlar se um membro da equipe tem uma doença grave, mas pode controlar o tamanho do backlog da sua equipe (como visto no Estudo de Caso 1) ou silenciar as páginas (como no Estudo de Caso 2). 

Comunique-se com as equipes de desenvolvimento de produtos parceiras e informe-as de que sua equipe está sobrecarregada. Eles podem ser capazes de oferecer uma mãozinha, demonstrar compaixão ou até mesmo assumir projetos inteiros. 

Quando os membros da sua equipe dependem uns dos outros e alcançam um certo nível de segurança psicológica (de modo que se sintam capazes de correr riscos interpessoais), você pode atribuir mais responsabilidade a membros individuais da equipe. Descobrir áreas de expertise e designar pessoas-chave e líderes técnicos para tecnologias específicas aumenta a autoconfiança deles e, portanto, os capacita a correr riscos. 

A tomada de decisões deve ser transparente e, se possível, democrática. Cada membro da equipe deve sentir que tem controle sobre a situação. Por exemplo, a sessão de brainstorming no Estudo de Caso 2 ajudou a equipe a identificar e discutir problemas. 

Priorizar e triar dentro de um trimestre 

Uma equipe saudável pode priorizar e triar problemas. O Estudo de Caso 1 fornece um bom exemplo desse exercício: a equipe se reuniu em uma sala e revisou seu backlog. A revisão os ajudou a perceber que estavam sobrecarregados. Eles redefiniram suas prioridades e trabalharam nas tarefas que reduziriam rapidamente parte da sobrecarga. A equipe do Estudo de Caso 2 agora se reúne no final de cada trimestre para planejar e priorizar o trabalho existente e futuro juntos. 

Se possível, recomendamos que os SREs agendem tempo sem interrupções (sem estar de plantão) em seus calendários, para que tenham tempo para trabalhar em tarefas qualitativamente difíceis, como desenvolver automação e investigar as causas raiz das interrupções. No Estudo de Caso 2, quando a equipe remota deu algum alívio ao on-call, os membros da equipe tiveram tempo precioso para se concentrar em seus projetos. 

Se absolutamente necessário, descarte o trabalho: no Estudo de Caso 2, a equipe interrompeu o suporte on-call para um de seus serviços devolvendo essa responsabilidade à equipe de desenvolvimento. 

Proteja-se no futuro 

Recomendamos fortemente estabelecer métricas para avaliar a carga de trabalho da equipe. Revise regularmente as métricas para garantir que estejam medindo as coisas certas. 

Depois que sua equipe sair da sobrecarga, você pode evitar futuras sobrecargas tomando medidas para monitorar ou resolver os problemas subjacentes. Por exemplo, a equipe do Estudo de Caso 1 agora mantém um processo de triagem leve para detectar um aumento do backlog de tarefas. A equipe do Estudo de Caso 2 está atualmente trabalhando em um plano de longo prazo para alinhar os SLOs do backend e do serviço. 

Quando sua equipe estiver em sobrecarga, priorize o trabalho do projeto que reduz o trabalho repetitivo ainda mais do que faria se não estivesse sobrecarregado. Você se beneficiará no futuro. 

Por fim, todos na equipe devem se sentir responsáveis pelos sinais de alerta precoce (consulte “Reconhecendo os Sintomas de Sobrecarga”) que indicam uma possível situação de sobrecarga. Os gerentes devem sentar e conversar com os membros da equipe se sentirem que a equipe está caminhando para a sobrecarga. 

Conclusão 

Em um mundo perfeito, as equipes de SRE sempre seriam capazes de gerenciar interrupções com as táticas descritas em nosso primeiro livro. Mas somos apenas humanos e, às vezes, nossas equipes não alcançam esse ideal. Este capítulo examinou algumas das formas pelas quais a sobrecarga pode consumir uma equipe e discutiu como detectá-la e responder a ela. 

Particularmente quando se trata de trabalho operacional, interrupções excessivas podem facilmente fazer uma equipe passar de uma carga de trabalho normal para a sobrecarga. Interrupções frequentes podem levar à sobrecarga, que afeta negativamente a saúde e a produtividade. A sobrecarga cria estresses psicossociais para os membros da equipe, o que impacta ainda mais o trabalho, criando um ciclo auto-reforçador. 

A sobrecarga percebida é uma forma especial de sobrecarga que não pode ser medida pela quantidade de trabalho ou operações realizadas. É difícil identificar e eliminar essa sobrecarga. 

Para manter o equilíbrio na carga de trabalho da equipe, é importante monitorar constantemente a sobrecarga (percebida ou não). Para servir melhor aos seus usuários e realizar um bom trabalho, é necessário primeiro mostrar respeito a si mesmo e à sua equipe. Manter um equilíbrio saudável em seu trabalho diário ajuda você e sua equipe a alcançar esse objetivo.