Stripe, Uber e Digg: como dimensionar e avaliar times de desenvolvedores
Este artigo foi publicado originalmente no First Round Review.
Traduzimos com autorização da marca.
Vamos imaginar que sua startup tenha um time técnico de plantão que se reveza. Sete dias por semana e 24h por dia, sempre tem alguém online. Um dia, o desenvolvedor de plantão recebe um alerta dizendo que o espaço em disco de um servidor primário PostgreSQL vai acabar em duas horas. Uma hora depois, ele recebe o pedido de desenvolvimento de uma nova página. Mais 30 minutos depois e o espaço em disco acaba, derrubando seu site inteiro. Por 18 horas. O lado positivo é que sua arquitetura em dois níveis pode manter seu site e seu app online, mas o backend caiu. Seu CTO está furioso. Ele diz que você deve demitir o desenvolvedor que estava de plantão quando o primeiro alerta foi enviado.
Esta já é uma situação difícil, mas está prestes a ficar pior. Esse erro não foi cometido por um de seus melhores funcionários, alguém que possa ser repreendido, mas defendido pelo seu bom histórico de entregas. O desenvolvedor que estava de plantão não é um grande destaque e não tem feito um bom trabalho recentemente. Em um movimento precipitado, você poderia responsabilizá-lo pela queda do servidor, desencadear uma provável demissão e seguir o pedido do seu gestor. Mas isso está certo? O que você diria para o seu CTO?
Essa história foi vivida por Will Larson e o desfecho é Larson assumindo a responsabilidade e pedindo ao CTO para ser demitido. Ou então para que os empregos dele e de seu subordinado fossem mantidos, com a condição de que o desenvolvedor que cometeu o erro seria instruído e melhor treinado. Essa situação mostra o quão complexa a gestão pode se tornar — e porque, quando feita de forma correta, é uma função profundamente ética.
O racional por traz da resposta de Larson para o CTO foi o seguinte: se eu demitir o desenvolvedor, a mensagem que vou passar para o time é que nós punimos erros de forma implacável. Agora, vamos considerar que o desenvolvedor iria ser mandado embora em breve de qualquer maneira. Demiti-lo agora seria fazer a coisa certa pela razão errada. Além disso, passaríamos uma mensagem parcial para todos os envolvidos. Se isso acontecesse, os danos para o time seriam tantos que eu não me sentiria mais confortável em liderá-lo.
Essa forma de pensar é mais comum em textos filosóficos do que em cases de negócio. Enquanto essa abordagem de gestão é mais experimentada em momentos de contratação e demissão, no crescimento e na liderança de times de desenvolvedores, ela tem sido colocada de lado por mais de uma década. Alguns destaques: na Digg, Larson contratou e liderou um time de 14 engenheiros de infraestrutura e de UI e UX, que eram responsáveis pelo Digg.com, pelas APIs e pelos aplicativos mobile. No Uber, ele liderou e escalou a SRE (Site Reliability Engineering) e o time de Engenharia de Plataforma de cinco pessoas para mais de 70, levando a equipe de engenharia a crescer em 10 vezes para mais de 2 mil pessoas. Agora na Stripe, Larson lidera o time de Foundation Engineering, que cria ferramentas de desenvolvimento internas e externas, além de dados e infraestrutura. Hoje, seu time soma 170 desenvolvedores baseados presencialmente em Dublin, São Francisco e Seattle e, remotamente, em mais de 18 cidades.
Nesta entrevista exclusiva, Larson mergulha em dois componentes críticos do design organizacional. Ele compartilha seu sistema para avaliar o tamanho e o estado dos times de engenharia, por meio de uma abordagem não somente muito eficiente e efetiva, como também profundamente empática e ética. Larson dedicou trechos do seu livro (An Elegant Puzzle: Systems of Engineering Management) a trazer proporções e estruturas para definir o tamanho do time, combinar e revezar membros de diferentes equipes e avaliar e acelerar o progresso do grupo. Ele faz um estudo preciso e minucioso sobre o design de times por gestores novos e experientes. Vamos mergulhar nisso.
É fácil fazer a coisa certa para as pessoas de quem você gosta. É fácil fazer a coisa certa quando é barato. Mas o que mais importa é como você age quando a decisão é difícil.
Dimensionar times é o coração do design organizacional
Quando gestores mergulham no design organizacional, eles frequentemente atingem algo abstrato, como uma missão, para criar e orientar a equipe. “Muitos gestores formam times em torno de uma visão coesa e unificada. Quem nunca passou pelo exercício de criar a missão, seja de um time ou de uma empresa? Primeiro, você considera o que está tentando fazer; depois, como você quer fazer”, afirma Larson. “Inevitavelmente, alguém trará os valores de Enron — e como os princípios que parecem seus próprios podem ser usados de forma mais genérica. Então, você começa a trabalhar e raramente revisita esses posicionamentos e princípios novamente.”
O outro caminho que os gestores normalmente escolhem é desenhar times conforme o produto ou a tecnologia que esteja disponível. “Existe a lei de Conway, que basicamente define que o produto reflete a organização. Bem, esse fenômeno pode acontecer em ambas as direções”, diz Lerson. “O contrário disso é que a organização é construída para refletir o produto. Mas se você exagerar no design em torno da sua tecnologia ou oferta atual, você vai se colocar numa mudança repetitiva, especialmente à medida que o produto se replica, evolui, se divide ou envelhece. Isso pode inserir uma equipe num mesmo ciclo eterno.”
Ao contrário, Larson acredita que a mudança fundamental — e de base — para o design organizacional está no dimensionamento dos times. “A mais poderosa unidade de trabalho é uma equipe consistente. Pessoas que sabem como trabalhar juntas e que estão habituadas a trabalhar juntas podem alcançar resultados verdadeiramente notáveis”, afirma Larson. “Quando os gestores desenham times seguindo literalmente os produtos ou a arquitetura atual, eles deixam as pessoas agitadas e perdem o que eu acho que é a única fonte de energia renovável do mundo: pessoas que amam — e sabem como — trabalhar juntas.”
Existem por aí muitos bons guias de recrutamento e seleção que falam sobre a qualidade das pessoas em um time, mas Larson notou que a quantidade de pessoas em uma equipe é um fator igualmente crítico para se chegar lá. Ele reconheceu totalmente a importância de dimensionar times. Tanto, que deixou de liderar um time para liderar uma empresa. Foi quando uma nova lista de desafios — e perguntas — surgiu:
- Quantas equipes nós devemos ter?
- Nós precisamos criar uma nova equipe para essa iniciativa ou delegá-la para uma outra já existente?
- Qual é a fronteira de atuação entre esses dois times?
Para Larson, todas essas questões o levaram de volta para a importância do dimensionamento das equipes — não apenas na formação dos times, mas também na resposta a reorganizações, nas ondas ou no congelamento de contratações e nos lançamentos. Embora admita que não existe uma regra unificada para o dimensionamento de equipes, Larson desenvolveu uma estrutura que resolveu a maioria das situações que ele enfrentou e também as consequências de um time que se torna grande ou pequeno demais.
Confira o manual de Larson, em suas próprias palavras, apresentado com trechos do seu livro:
Gestores devem liderar de seis a oito engenheiros.
Dessa forma, eles têm tempo para oferecer um treinamento mais ativo para seus funcionários, coordená-los melhor e estimular a missão do time através da criação de estratégias, fomento de mudanças e assim por diante.
- Tech Lead Managers (TLMs). Gestores que lideram menos de quatro desenvolvedores tendem a agir como TLMs, assumindo uma parte da criação e da implementação dos trabalhos. Para algumas pessoas, esse papel pode alavancar seus pontos fortes, mas oferece oportundiades de carreira limitadas. Para evoluir como um gestor, eles vão precisar de mais tempo para focar em desenvolver suas habilidades de gestão. Como alternativa, para evoluir na função de desenvolvedor, eles encontrarão dificuldades em empenhar tempo suficiente para os detalhes técnicos.
- Coaches. Gestores que lideram mais de oito ou nove desenvolvedores agem tipicamente como coaches e como uma rede de segurança para problemas. Eles são ocupados demais para investir ativamente no time ou na sua área de responsabilidade sobre a equipe. Essa situação é razoável durante um período de transição rumo a uma configuração mais estável, mas, como situação definitiva, é uma má escolha.
Gestores de gestores devem liderar de quatro a seis gestores.
Essa disposição reserva tempo suficiente para instruir os liderados, alinhar-se com stakeholders e fazer uma quantia razoável de investimento na organização. Por outro lado, também os mantém tão ocupados que não se sentem estimulados a gerar novas demandas para a equipe deles.
- Aceleradores. Gestores que lideram menos de quatro outros gestores devem estar em um período de aprendizado ativo, seja sobre como dominar problemas seja sobre como passar a liderar gestores em vez de desenvolvedores. Se essa situação perdurar, eles podem passar a se sentir subutilizados ou tentados a entrar nas operações do dia a dia.
- Coaches. Assim como acontece com a gestão de um time muito grande de desenvolvedores, gerir um número muito grande de gestores faz você funcionar unicamente como um coach de resolução de problemas.
Equipes de plantão demandam oito desenvolvedores.
Para assumir as responsabilidades do ambiente de produção que surgem a qualquer momento, descobri que uma equipe de suporte 24/7 de dois níveis demanda oito desenvolvedores. À medida em que é cada vez mais comum que as equipes tenham seus próprios programadores, essa se tornou uma importante restrição de tamanho da equipe de plantão. Eu tento assegurar que todo time de desenvolvedores tenha oito pessoas fixas.
- Rodízio de turnos de plantão. Às vezes é necessário alocar múltiplos times em conjunto para chegar aos oito desenvolvedores necessários para os plantões 24/7. Esse é um passo intermediário para criar equipes que possuam seus próprios times de plantão, mas essa não é uma boa solução de longo-prazo. A maioria das pessoas que receberam tarefas urgentes em plantões, com as quais elas não estavam familiarizadas, ficaram estressadas demais.
Equipes pequenas (com menos de quatro pessoas) não são equipes.
Eu liderei alguns poucos times de uma ou duas pessoas e me arrependi em cada uma das vezes. Repetindo: eu me arrependi todas as vezes. Uma propriedade importante das equipes é que eles abstraem as complexidades dos indivíduos que as compõem. Equipes com menos de quatro indivíduos funcionam da mesma forma que indivíduos. Para avaliar a entrega de uma equipe pequena, você terá que avaliar a escala de plantão, as férias e as interrupções de cada um dos membros.
Esses times também são frágeis, de modo que uma demissão facilmente tira-os do ritmo da inovação e coloca-os de volta à manutenção de dívidas técnicas.
Mantenha a inovação e a manutenção juntas.
Uma prática frequente é acelerar uma equipe nova para inovar, enquanto as equipes existentes ficam atoladas em manutenções. Eu mesmo já fiz isso, mas mudei e deleguei a inovação para times já existentes. Para isso, é necessária uma tomada de decisão bastante deliberada e um pouco de coragem, mas em troca você terá uma moral mais alta e uma cultura de aprendizado, além de evitar criar um sistema dividido em duas classes: inovadores e mantenedores.
Unindo todos esses princípios guias, o manual que eu desenvolvi é surpreendentemente simples e efetivo:
- Equipes devem ter entre seis e oito membros;
- Para criar um novo time, expanda uma equipe existente para oito a dez pessoas e depois divida-a em dois times de quatro a cinco pessoas;
- Nunca crie equipes vazias;
- Nunca deixe gestores liderando mais do que oito pessoas.
Como em todos os guias, essa é apenas uma estrutura para ajudar a endereçar problemas de dimensionamento de equipes e não uma camisa de força para restringir todas as exceções. O contexto de qualquer situação merece um exame cuidadoso, mas gradualmente descobri que os custos de longo-prazo das exceções superaram o que considerei serem suas forças.
Eu chego a acreditar que dividir as organizações em oito permite que você veja o futuro. Descubra qual a carga sobre os gestores e você poderá prever com confiança o que está à frente.
A estrutura básica de Larson para dimensionar times resulta não apenas em saúde organizacional, como também em uma prática administrativa mais eficiente e ética. Confira o que esse sistema pode trazer:
Clareza sobre trilhas de carreira.
“A meta primária de liderança nas empresas é dar acesso ao que é escasso. Tempo e orçamento são exemplos frequentes, mas oportunidades de gestão também são escassas — e, particularmente, fazem parte do papel dos gestores de gestores. Considere a proporção de gestores para engenheiros de 1:8 e a proporção de gestores de gestores para seus engenheiros subordinados de 1:40. Ou existem poucos líderes de tecnologia por time ou existem poucos engenheiros por organização”, afirma Larson.
“Quase toda oportunidade de carreira é desenhada quando o tamanho padrão das equipes é definido. Haverá novos tipos de funções, mas os grupos irão crescer, fazendo com que aquelas proporções de tamanho de equipe sejam resetadas. Considerando isso, os líderes — e suas equipes — têm uma ideia clara de como e quando as oportunidades de gestão se abrem em uma empresa. Essa consistência e essa transparência servem a todos os envolvidos. Combinado com conversas sobre carreira, esse sistema abre um caminho mais harmonioso para determinar as expectativas de carreira.”
Investimentos significativos em reuniões.
“Em uma empresa em crescimento acelerado, as proporções de tamanho dos times irão oscilar. Gestores podem gastar mais tempo com novas contratações do que com a equipe já existente. A abordagem clássica, como conta o livro High Output Management, de Andy Grove, defende que os líderes devem reservar metade de um dia por semana com reports para o time. Esse não é unicamente o tempo gasto por pessoa, já que também inclui o tempo livre do gestor para revisar, desenvolver e refletir sobre o trabalho que cada pessoa vem fazendo”, afirma Larson. “O tempo mínimo que você deve gastar com reports é de uma hora por semana com cada pessoa do seu time, especialmente quando você está gerenciando filas. Além disso, dependendo da estrutura da sua empresa, você terá três ou quatro pares mais críticos, como os gestores de projetos. Você gastará cerca de meia-hora com cada um desses pares.”
Agora vamos calcular como isso impacta a rotina de um gestor de oito desenvolvedores — e como o calendário desse gestor fica, considerando todos os seus compromissos. “Oito desenvolvedores no time demandam oito horas de reuniões individuais com o gestor. Considerando que você tenha cinco pares com quem gaste meia-hora por semana, agora você tem mais 10 horas. Somando as reuniões de equipe semanais, como check ins de sprints e uma outra reunião mais longa, agora você tem 12 horas da sua semana comprometidas. Você, com certeza, está entrevistando, porque está crescendo rápido. Com três horas de entrevistas por semana, você chegou a 15 horas. Acrescentando as reuniões gerais e com outros times, você totaliza 20 horas da sua semana comprometidas”, destaca Larson.
“De repente, metade da sua semana se vai apenas em reuniões. É um percentual alto para alguém que queira pensar primeiro e fazer depois. Se você lidera um mesmo time há bastante tempo, você pode conseguir condensar as reuniões individuais para 30 minutos por semana ou fazer encontros de uma hora, semana sim, semana não”, ele diz. “Mas quando os negócios estão crescendo rapidamente, existem sempre contextos para serem comunicados, que geram novas ações. Ainda não encontrei alguém que topasse se comprometer com tudo isso, sem enfrentar ineficiência e pressão. É por isso que além de produtivo, é também ético para esse líder manter o tamanho da sua equipe em oito pessoas. O tempo que esse gestor tem é crítico para informar, alinhar, treinar, preparar-se para liderar de forma precisa e adequada e ainda representar o próprio trabalho. Menos investimento de tempo em cada reporte ou maior quantidade de reports podem ser viáveis no curto-prazo, mas eu descobri que isso prejudica o time no longo-prazo.”
Movimentar-se e criar espaço.
“Falamos bastante sobre a trajetória de carreira dos liderados, mas um gestor também precisa arrumar tempo para se desenvolver e ser promovido. Gestores conseguem isso trabalhando para além do próprio time. Entretanto, um líder ético vai além, apenas se seu próprio time estiver operando de forma harmônica — mais uma razão para um dimensionamento disciplinado –, já que ainda precisará arrumar tempo para empenhar esforços em outros setores da companhia”, afirma Larson.
“Para gestores ocupados, o trabalho com outros setores da companhia permanece, no final da semana, na lista de coisas a fazer, mas isso não deveria acontecer. Com certeza, o gestor quer crescer, como qualquer funcionário, mas o líder ético reconhece que é necessário para seus liderados — e para a organização — que ele cresça para uma nova posição, para que sua função anterior se transforme em uma oportunidade aberta para outras pessoas do seu time ou da própria empresa.”
Como mensurar e acelerar o progresso
O dimensionamento padrão traz uniformidade para o time como unidade de medida, mas o que e como o time constrói em conjunto demanda um sistema diferente, além de uma linguagem própria. Na estrutura a seguir, Larson mostra os quatro diferentes estágios das equipes — e como um gestor pode identificar o estágio atual do próprio time, guiar sua equipe para transitar entre os estágios e oferecer um suporte diferente a cada nova etapa. Confira o sistema de Larson, apresentado em seu livro:
Quatro estágios de uma equipe
A apresentação dessa estrutura começa com um glossário que descreve os momentos das equipes e sua performance, dentro de um determinado contexto. Os times podem ser encaixados em quatro estágios contínuos:
Um time está “falling behind” se toda semana seu backlog é maior do que o da semana anterior. Tipicamente, as pessoas estão trabalhando duro, mas não estão fazendo muito progresso. A moral está baixa e os usuários estão externando que estão insatisfeitos.
Um time está “treading water” se consegue concluir o trabalho crítico, mas não consegue começar a pagar as dívidas técnicas ou iniciar novos projetos grandes. A moral está um pouco mais alta, mas as pessoas continuam trabalhando duro. Seus usuários podem parecer mais felizes porque aprenderam que pedir ajuda não vai levar a lugar algum.
Um time está “repaying debt” quando consegue pagar a dívida técnica e começa a se beneficiar do fim da bola de neve desse pagamento: cada parte da dívida que é paga gera mais tempo para pagar mais dívidas.
Um time está “innovating” quando sua dívida técnica é sustentavelmente baixa, a moral é alta e a maioria do trabalho realizado está atendendo às necessidades dos novos usuários.
As equipes querem evoluir do estágio “ficando para trás” para chegar ao “inovando”, mas a entropia as empurra para trás. Por isso, cada estágio demanda um tratamento diferente.
Como consertar o sistema e dar suporte técnico para os times
Neste fluxo, as equipes conseguem transitar para o próximo estágio somente se adotarem a solução de sistema apropriada para seu estágio atual. Como gestor, sua obrigação é identificar a solução correta para a transição, implantar essa solução e, então, dar suporte à equipe da melhor maneira possível para criar espaço para que as soluções façam sua mágica. Se você deixar de dar suporte à equipe taticamente, você vai estar exausto, sem promessa de salvação, antes mesmo de implantar a solução correta.
Confira agora a solução estratégica que considero mais efetiva para cada estágio, junto a algumas ideias sobre como dar suporte à equipe enquanto cada solução ainda não deu frutos:
1. Quando o time está “falling behind”, para consertar o sistema, é necessário contratar mais pessoas até que a equipe entre no estágio “marcando o passo”. Forneça suporte tático gerenciando as expectativas dos usuários, celebrando as pequenas vitórias que conseguir e injetando otimismo. Como um alerta, o conserto do sistema é contratar novas pessoas, aumentando a capacidade geral da empresa. Eventualmente, alguns líderes buscam mais recursos dentro da própria empresa. Acho isso bastante negativo. Sou cético em relação a reanimar funcionários antigos para que comecem a agir de maneira otimizada. Por natureza, é impossível que esse tipo de discussão não se torne política, mesmo quando todos os envolvidos têm profunda confiança e respeito uns pelos outros.
2. Quando o time está “treading water”, para consertar o sistema, é preciso consolidar os esforços da equipe para que ela consiga concluir mais tarefas e reduzir as atividades simultâneas, até que esteja pronta para entrar no estágio “pagando a dívida”. Taticamente, o foco aqui é ajudar na transição da mentalidade das pessoas de uma visão de produtividade pessoal para uma coletiva.
3. Quando o time está “repaying debt”, para consertar o sistema, é necessário ganhar tempo. Tudo já está funcionando e você precisa apenas achar espaço para permitir o pagamento da dívida técnica. Taticamente, tente achar formas de dar suporte a seus usuários enquanto está pagando a dívida, para evitar desaparecer na perspectiva deles enquanto está no meio desse processo. Especialmente para um time que começou “ficando para trás” e está agora “pagando a dívida”, seus stakeholders estão provavelmente esperando ansiosamente pela hora em que a equipe vai começar a entregar novos projetos. Sua obrigação como líder é prevenir que essa impaciência cause um recuo.
4. Já a fase “innovating” é um pouco diferente, porque o time efetivamente alcançou o fim desse ciclo contínuo, mas ainda existe um sistema para ser consertado. Nesse caso, o conserto é manter o cronograma da equipe com espaços suficientes para que ela possa trabalhar com qualidade, operar continuamente em inovação e evitar retrocessos. Taticamente, assegure que o trabalho que seu time está fazendo seja valorizado: a forma mais rápida de sair do caminho da inovação é passar a ser visto como um time que constrói projetos de ciência. Essa situação inevitavelmente afasta os recursos para o time.
Eu não consigo enfatizar o suficiente o quanto todos esses consertos são lentos. Isso acontece porque os sistemas acumulam períodos estáticos que duram meses ou anos e você, como gestor, precisa drenar tudo isso. Por outro lado, as mesmas propriedades que tornam essas mudanças lentas, fazem com que elas tragam efeitos extremamente duráveis.
A parte mais difícil é manter a fé no seu plano — tanto a sua própria fé, quanto a fé da empresa como um todo. Em determinado momento, você pode querer fazer uma reorganização ou talvez mudar de emprego, mas se você fizer isso, vai pular a parte do aprendizado que essa situação pode gerar. Persista no caminho.
Uma das partes mais difíceis da gestão é esperar por uma boa escolha que vai levar à mudança. Para sistemas complexos, como humanos e equipes, existe um intervalo de tempo que é maior do que nós queremos esperar. Depois de tomar uma decisão, tenha com você mesmo a mesma dose de paciência que teve antes de tomar a decisão.
Para além dos quatro estágios
O sistema de Larson para formar equipes e avaliar sua performance já pode ser colocado em prática, mas há algumas dicas que podem ajudar os gestores a acelerar seu sucesso com essa estrutura.
Busque taxas de escoamento e não pontos de inflexão.
Larson admite que a evolução de um passo para outro pode se tornar mais parecida com saltos do que passos, mas isso só acontece por uma razão: quando os gestores dão tempo suficiente para cada transição ocorrer. “Sim, são necessários grandes saltos entre os estágios. Mas é preciso considerar a paciência que os times devem ter à medida que transitam entre eles”, diz Larson. “Isso faz ainda mais sentido para os gestores, os tomadores de decisão que esperam resultados rápidos. O que gera medo em quem vai trabalhar com gestão é que a diferença entre o sucesso e a falta está frequentemente em ter ou não confiança no que você está fazendo para esperar um pouco mais. Talvez isto seja o mais aterrorizante: o tempo é normalmente o ingrediente que falta.”
Para ilustrar este ponto, Larson destaca um exemplo da sua carreira. “Certa vez, nosso time de infraestrutura de dados estava tendo muitas interrupções e vínhamos furando nossos SLAs frequentemente. Tínhamos um grande grupo ali, mas eles estavam se sentindo realmente sobrecarregados. Parecia que não havia esperança. Eles continuavam sendo chamados no meio da noite. Nós estávamos fazendo todo o trabalho técnico… por que as coisas não estavam funcionando?”, relata Larson. “Acabou que nós apenas mantivemos essa estratégia pelos dois meses seguintes e, então, algo mudou. Fazendo uma retrospectiva, nós não contamos com a redução da dívida técnica. Um número suficiente de resoluções de incidentes precisa acontecer antes de a situação melhorar.”
A tentação é procurar por pontos de inflexão e buscar suas causas. Novamente, Larson conta uma história: “Como líderes, sempre temos que justificar por que agimos de determinada forma: fizemos o upgrade do Hadoop e tudo melhorou”, afirma. “Quando, na verdade, foi o conjunto de algumas ações tomadas em um determinado período que levou tudo a se transformar ‘de repente’.”
Pontos de inflexão são apenas a sustentação de uma implementação de algo bastante razoável. Frequentemente, o papel de um grande líder não é criar uma estratégia brilhante, mas convencer as pessoas de continuar com uma estratégia muito básica.
Pontos de inflexão entregam melhores narrativas para equipes e são mais fáceis de acompanhar. Mas Larson aconselha os gestores a preferencialmente ajudarem as equipes a navegarem entre os estágios para acompanhar a taxa de “redução de dívidas pendentes” ou o intervalo de tempo entre os estágios, em vez de se amarrar a um único ponto de transição.
“Considere o exemplo de migrar do estágio de “pagando a dívida” para “inovando”. Nessa situação, eu me dedicaria muito a pensar sobre os incidentes de escoamento. Mas você não sabe quantos incidentes que não aconteceram estão lá fora”, afirma Larson. “No caso das interrupções, você pode olhar para as vezes em que a causa raiz dos incidentes efetivamente aconteceram — e se o tempo da causa raiz dos incidentes está diminuindo. Você pode criar uma proxy para avaliar se você está drenando os últimos incidentes. Uma vez que você tenha confiança de seguir nesse caminho, pode direcionar energia para encontrar proxies para validar e prever quando o resultado de uma decisão é encontrado. E quando uma equipe entra em um novo estágio.”
Moral no trabalho e satisfação do usuário não andam em paralelo.
No sistema de Larson, ele percebe que tanto a moral do time e quanto a satisfação do usuário flutuam entre os estágios. Uma premissa pode ser que a satisfação do time e do usuário andam em conjunção. “Frequentemente quando você começa a fazer um trabalho mais técnico, a equipe fica realmente motivada porque sabe que isso precisa acontecer, mas seus usuários tendem a ficarem instatisfeitos porque você está fazendo menos para ajudá-los”, afirma Larson. “Esse é especialmente o caso dos estágios mais iniciais, como quando seu time está “ficando para trás” ou “marcando o passo”. Imagine que você precisa contratar 10 pessoas para conseguir concretizar o que seus usuários desejam. Frequentemente nessa situação, você tem menos trabalho com seus usuários, temporariamente, para conseguir chegar a um ponto em que você consiga fazer mais coisas para eles.”
Essa pode ser uma discussão difícil — tanto para seu time quanto para os usuários. “Se você não tem feito muito pelos seus usuários até então, pode ser difícil explicar porque eles têm que esperar, especialmente se eles confiarem em você. Mas se o seu time está no estágio “ficando para trás” ou “marcando o passo” não existe outro movimento à vista”, afirma Larson. “É quando você precisa fechar o difícil compromisso de não fazer nada. Continuar falhando hoje para poder ser bem-sucedido amanhã é uma escolha, assim como continuar falhando para sempre. É por isso que um líder deve saber como guiar uma transição de equipe por esses estágios. Se ele fizer isso, tanto os usuários quando a equipe confiarão na sua palavra.”
Amarrando tudo
Os gestores estão certos em focar em encontrar profissionais de qualidade, mas eles devem prestar a mesma atenção no tamanho do time que eles lideram. Gestores de engenharia, por exemplo, devem liderar de seis a oito desenvolvedores e gestores de gestores devem responder por quatro a seis líderes. Manter essa uniformidade traz consequências não apenas para o gestor e para a equipe — como trajetórias de carreira, administração de tempo e desenvolvimento de habilidades –, mas para toda a empresa. Uma vez que um tamanho padrão de equipe seja determinado, os líderes devem avaliar e acelerar o progresso de suas equipes. Existe um fluxo contínuo de estágios de um time, começando em “ficando para trás”, indo para “marcando o passo”, passando por “pagando a dívida” e finalizando em “inovando”. As equipes querem evoluir do primeiro estágio para o último, mas a entropia as puxa para trás. Cada estágio demanda uma atuação diferente por um gestor — além de paciência e confiança para acompanhar o trabalho em andamento. Considerados juntos, tanto a estrutura de dimensionamento de equipes quando o sistema de avaliação de performance, levam a uma prática de gestão não apenas mais eficiente, como também mais ética.
“Certa vez, me encontrei liderando 28 pessoas. Não havia maneira de me encontrar com todas essas pessoas em um horário previsível, sem deixar de fazer todo o restante do meu trabalho. Olhando para trás, eu me cobrei muito para conseguir passar por isso. Encontrei alguns líderes de tecnologia para assumir parte da gestão e dediquei uma hora por semana a eles. Falava com o restante do meu time uma hora por mês”, afirma Larson.
“Para alguns, essa pode não ser obviamente uma escolha errada. Mas eu percebi que a comunicação e minha percepção de contextos começou a funcionar mal. Eu não conhecia mais os contextos que me possibilitariam dar um bom feedback para meus liderados. Nessas situações, os gestores ou dão feedbacks ruins ou muito genéricos, conselhos prescritivos. Se você observa a si próprio, você dá um passo para trás, mas então você não tem utilidade. Utilizar um dimensionamento padrão de equipes e escolher um sistema para desenvolver times não são apenas ferramentas. É como se o gestor fizesse um juramento de Hipócrites. Ele se compromete em não trazer danos na construção de uma equipe de forma efetiva e consciente.”
Trechos e ilustrações de An Elegant Puzzle: Systems of Engineering Management como cortesia de Will Larson. Fotos tiradas por Everett Katigbak.
