Acho que o Google fez contribuições imensas para a cultura de gestão em empresas de tecnologia. Mas o Google, como qualquer empresa, também poderia ter feito algumas coisas melhor. Pelo menos essa foi a minha impressão do tempo que passei lá, e queria compartilhar alguns desses insights.

O Google foi o primeiro empregador que tive que dava grande importância aos benefícios não salariais oferecidos aos seus funcionários. Você pode imaginar: massagens no local, três refeições preparadas por chefs fornecidas gratuitamente, mesas de ping-pong e sinuca espalhadas pelo escritório. O Google também tinha lavanderias em alguns escritórios, academia gratuita, presentes de Natal e muitos outros benefícios. Em termos de emprego, era praticamente o paraíso.

Na minha opinião e experiência, o Google foi pioneiro em tratar seus funcionários em geral melhor do que jamais tinham sido tratados antes. Isso não só fazia as pessoas quererem trabalhar lá e permanecer lá, mas também falarem muito bem do Google como empregador. Era incrível para o branding do Google como empregador.

Tratar bem as pessoas ia além dos benefícios. Uma vez que você ingressava no Google, você também se sentia muito bem cuidado, o Google como empresa parecia realmente considerar seus funcionários como seu ativo mais importante. Eles tiravam todos os obstáculos do seu caminho para garantir que você (a pessoa super inteligente que – se fosse como eu – sentia que não merecia, mas ainda assim foi contratada pelo Google) pudesse se concentrar em fazer seu melhor trabalho.

Os Googlers tinham acesso ao melhor treinamento disponível no mercado para se desenvolverem: inteligência emocional, MBTI, liderança situacional, outros treinamentos de liderança adaptados à empresa. Liste aí, eu fiz todos. O Google foi, até 2012, a empresa e o trabalho onde mais cresci em minhas habilidades, tanto tecnicamente como SRE quanto nas chamadas habilidades interpessoais, ou “soft skills”. Também aprendi as melhores ferramentas de gestão para ajudar os membros da minha equipe a entregarem seu melhor trabalho. Sinto que no Google eu também cresci como ser humano.

O Google também tinha um conjunto super estruturado de ferramentas de gestão. Tinha feedback 360 a cada 6 meses, os engenheiros deveriam avaliar seus gerentes — isso foi novidade para mim! Fazíamos calibrações a cada 3 meses. Era muito trabalho adicional, mas esse era o custo de ser uma empresa tão grande com pessoas de alta performance, certo?

O Google foi definitivamente um pioneiro, mas a indústria continuou evoluindo para diferentes modelos, e alguns deles eram mais justos e mais de fato orientados para as pessoas do que o Google que eu experimentei.

Foi no Google, em 2008, que aprendi que poderia ser líder técnico de um projeto e ter um colega de equipe, liderado por mim em tal projeto, que ganhava 30% mais dinheiro do que eu. Assim é a vida. Isso foi corrigido no ciclo de avaliação de desempenho subsequente, quando fui promovida e recebi um aumento absurdo de mais de 40%.

Foi também no Google que aprendi que, como mulher na tecnologia, eu precisava aprender sobre o jogo que estava jogando porque mesmo o processo mais bem elaborado, criado com as melhores intenções, pode perpetuar discriminação. Os comitês de promoção, na época em que eu estava no Google, não serviam bem às mulheres e pessoas que não gabavam muito de seu próprio trabalho. O RH até ajudava a organizar workshops para mulheres em Zurique para ajudá-las a escrever autoavaliações com um tom mais enfático sobre suas próprias realizações, porque palavras como "ajudei" ou verbos no gerúndio não ajudavam as mulheres a obter reconhecimento nos comitês de promoção: é sobre o que você fez, não sobre o que está fazendo. Não só participei desses workshops, como ministrei alguns deles.

Os comitês de promoção foram projetados para serem mais justos por não terem contexto sobre as pessoas sendo discutidas. Eles não deveriam ter contexto, pelo menos. Mas o que acontecia de fato era que quem escrevesse as melhores histórias conseguia os melhores resultados, não necessariamente aqueles que faziam o melhor trabalho. Minorias conhecidas por não reivindicarem créditos pelo que faziam não tinham um defensor na sala onde as decisões estavam sendo tomadas.

O Google também me ensinou as consequências de insistir que grandes engenheiros se tornassem gerentes de pessoas. Tive um bom gerente e alguns terríveis durante meu tempo lá. Eu virei gestora para isolar meus colegas das maluquices gerenciais e então pudessem fazer seu melhor trabalho. Não é uma grande motivação, eu sei. Não me arrependo da escolha que fiz e ainda acho, muitos anos depois, que meu trabalho ainda tem um pouco disso na essência.

Nas calibrações, havia algumas regras arbitrárias que não faziam sentido para mim na época: se um engenheiro mudasse de equipe, ele caía um nível em sua avalição anterior de desempenho. Essa era a minha menos favorita.

Muitos engenheiros se voltaram para a gestão como carreira, pressionados por outros gerentes para que a empresa pudesse escalar. Muitos deles se tornaram gerentes terríveis sem muitas habilidades interpessoais.

Eu não gostava do “jeito do Google” de gerenciar as carreiras de pessoas. Acho que os gerentes desempenham um papel importante contextualizando o trabalho de uma pessoa engenheira quando ela não consegue fazer isso bem sozinha. Acho que meu papel como gerente é perguntar ao gerente ao meu lado por que diabos ele está classificando o desempenho de uma engenheira como “excede as expectativas” por dois anos e ainda assim não a está promovendo e responsabilizar o gerente (e o indivíduo, se for o caso) para que essa promoção aconteça.

Demorei muitos anos para perceber, mas o Google que experimentei tinha uma arrogância de engenharia que eu não apreciava nem um pouco e, como consequência, nunca senti que me encaixava lá.

Minha carreira gerencial no Google não estava indo a lugar nenhum. Tinha ótimos mentores entre meus pares, mas minha linha de gestão era terrível. Meu gerente direto perdeu todas exceto uma mulher de sua equipe dentro de 6 meses após minha saída, e ainda assim, não deve sequer ter sido questionado. Se questionaram, provavelmente julgaram não importante, já que ele foi promovido a Diretor logo em seguida da nossa saída da empreasa.

Um ciclo eu recebia feedback de que estava focando demais em gestão, não o suficiente em resultado técnico, no ciclo seguinte eu recebia o oposto: técnica demais, não o suficiente em gestão.

Reuniões de Revisão de Design eram como pedir autorização para gerentes e engenheiros seniores para fazer seu trabalho. Essas reuniões eram extremamente agressivas, e eu sentia que nunca gostaria de apresentar lá. Parecia que, se você não soubesse todas as respostas para todas as perguntas aleatórias que as pessoas fariam, voltaria à estaca zero e seu projeto não aconteceria. Pelo menos não agora, não até que você obtesse esse selo de aprovação.

Tudo isso foi acumulando e me frustrando, e junto com as desculpas eternas sobre me promover, foi a principal razão pela qual decidi começar a procurar um novo emprego.

Uma vez que consegui um emprego e decidi sair, me ofereceram muito dinheiro para ficar. Fiz as contas…Eu tinha certeza de que nenhum dinheiro no mundo me faria feliz continuando na mesma situação em que estava. Recebi duas ofertas de emprego e tive que escolher uma. Uma era na Canonical e a outra no Facebook. Aceitei o emprego no Facebook e foi, de longe, a melhor escolha de carreira e de vida que fiz.

Sinto que todas as oportunidades no Google estavam empacotadas para presente e tinham nomes de quem seria presenteado. Mas meu nome não estava em nenhum desses pacotes. Se eu tivesse que aprender coisas para merecer oportunidades, meu gerente não ajudava em nada, nem meu diretor.

Voltando ao título que escolhi, quando as pessoas me dizem que querem construir o Google do Brasil, eu pauso. Eu não quero. Aprendi coisas no Google, mas de uma perspectiva puramente gerencial, tenho certeza de que há muitas maneiras de fazer as coisas muito melhor do que eram lá. Quero criar formas novas e melhores de fazer engenharia em ambientes de alta performance, e não copiar um sistema do qual conheço bem os defeitos.

Crédito da foto: Anthony Quintano from Mount Laurel, United States, CC BY 2.0, via Wikimedia Commons

Existem muitos frameworks para lidar com essa priorização quando se trata de produto, porém para questões não funcionais de engenharia, a não ser que vire uma crise, os times tendem a sofrer em silêncio e aceitar que a realidade se resume a responder chamados, e fazer as coisas aleatórias que são demandadas no dia a dia. Com isso, acumula-se débito técnico, insatisfação e o risco de burn out no time cresce.

E como sair desse caos?

1. Trate interrupções como parte do trabalho.

2. Foque o resto do tempo em poucas coisas importantes.

3. Aprenda a dizer não.

Tratando interrupções como parte do trabalho

Quando eu comecei a trabalhar no Facebook, eu tinha um time de exatamente 3 pessoas para dar suporte a infraestrutura de caching da empresa. O time passava o tempo inteiro apagando incêndio. Um dos engenheiros do time, que não sabia dizer não, trabalhava dia e noite resolvendo problemas aleatórios de produção, mas além dele, todo mundo passava uma boa parte do seu tempo sendo interrompido em seus projetos para ajudar a resolver problemas aleatórios.

O que eu fiz? Eu estabeleci uma escala de suporte no time. Cada semana teríamos uma pessoa prestando suporte, full time, e as duas outras pessoas engenheiras poderiam então focar nos seus projetos.

“Ah Fernanda, mas nem todo mundo é capaz de resolver qualquer problema aleatório que chega no time!” — tenho certeza que você está pensando isso. Sim, isso é verdade, mas somente temporariamente.

Depois de uns 3 meses, todas as pessoas do time serão capazes de responder 99% das requisições sem precisar de ajuda, desde que todos sejam responsáveis por ajudar a pessoa em escala de suporte a resolver os problemas (e não mais resolver as coisas elas mesmas, como antes).

Quando o time vai planejar, a pessoa gestora do time precisa então contar que 1 pessoa full time vai sempre estar resolvendo interrupções, para deixar o resto do time trabalhar nos projetos de longo prazo. O que nos leva ao próximo ítem…

Focando no que é importante

Focar em projetos de longo prazo é uma maravilha, todos concordarão. Mas o que nem todo mundo concorda é como selecionar o que é mais importante.

Eu tenho um método bem simples para equipes que tem muita carga de interrupções e débito técnico: um dos projetos mais prioritários do time deve ser o projeto que reduza tempo dedicado a tarefas repetitivas.

Voltando ao meu exemplo lá do Facebook, existiam alguns fatores que criavam esses “incêndios” que o time passava muito do seu tempo resolvendo: a) novas versões sendo lançadas em produção, e como esse processo não tinha controle nenhum, haviam MUITAS versões em produção; b) alteração de configuração em produção quebrava o ambiente; e c) shards muito quente causavam instabilidade no ambiente.

O que nós fizemos? Investimos em três coisas. Adivinhem? Automação de deployment para que fossem feitos de forma gradual (e fácil). Melhoria da cobertura de teste do script que criava e distribuía configurações em produção, e criação de mecanismos para fazer “split” de “shards” que eram detectados como ficando muito quentes.

Seis meses depois o time era irreconhecível. Tínhamos conseguido contratar mais 3 pessoas, os projetos já estavam dando muito retorno e diminuíram muito a quantidade de incidentes que tínhamos, e também a quantidade de tickets.

Dizendo não

Tendo nossas prioridades claras fez com que a conversa sobre pedidos aleatórios diminuísse, porque não dizíamos simplesmente não, nós mostrávamos o que estávamos fazendo e porque, e na grande maioria das vezes, era óbvio o que estarmos priorizando isso versus outras coisas. Algumas vezes obviamente existiam outras urgências e adaptávamos o que o time estava fazendo.

O time foi de lugar de “burn out” para um dos times onde as pessoas queriam trabalhar. Fazíamos eventos sociais juntos, nos divertíamos muito, e o time de Production Engineering passou a brigar muito menos com o time de Software Engineering.

Cacheville, como chamávamos a organização, progrediu muito com relação a excelência operacional, empoderamento do time, e também satisfação no trabalho. Aprendi muito tecnicamente, e também como gestora.

Confesso que foi um dos momentos “de ouro” da minha carreira, e sempre me lembrarei com carinho.

Muitas vezes nós gestores pegamos a realidade e aceitamos ela como fato da vida, sem lembrar que é nossa responsabilidade mudar essa realidade, e sair do caos. Sair do caos é possível, é gratificante, e é parte do que faz gestão tão significativa nas organizações: é o nosso trabalho.

Isso acontece porque as engenheiras são responsáveis por criar as soluções que fazem com que essas empresas ganhem usuários, valor e o mundo. Os times de produto criam teses de desafios a serem solucionados, e o time de engenharia então propõe as soluções, valida, quantifica resultados e ajuda a provar essas teses ou desqualificá-las.

Em algumas scale ups, porém, esse nem sempre é o caso. Os problemas e as soluções já chegam definidos para as equipes de engenharia, e essas então precisam tratar da implementação com pouquíssimo espaço para contribuir com o direcionamento dessas implementações, e com priorizações de projetos que não impactem o cliente diretamente (eu argumentaria que sempre impacta, mas isso é outro assunto), como projetos que aumente a eficiência do time de engenharia em si.

Na minha opinião, esse posicionamento deixa muito potencial não realizado para as empresas, e também causam um grande problema de retenção de talento.

Potencial não realizado

Pessoas engenheiras são treinadas, formalmente ou não, para pensar desafios de forma lógica, usar dados para provar teses e também usar metologias que sejam possíveis de reproduzir para quantificar o impacto das soluções que criam.

Além de pensar na solução que é necessária hoje, a equipe de engenharia sabe e deve investir tempo em soluções escaláveis, que não só vão atender a empresa hoje, mas que vão permitir que a empresa continue crescendo 2, 3, 5 ou 10 vezes no futuro.

Quando essas equipes não tem voz e não participam da concepção de produtos, provavelmente esses ítens não são levados em consideração, ou não ganham a prioridade necessária. Isso na prática causa problemas de estabilidade nos produtos e também acúmulo do chamado débito técnico, que fazendo uma metáfora, são puxadinhos para acomodar necessidades de curto prazo, sem considerar o projeto arquitetônico e de engenharia necessário para que “a casa” fique de pé no longo prazo.

Além disso, para a empresa, é um investimento que não faz sentido. É comum um sentimento de que estamos “gastando demais com engenharia” para o retorno realizado. Isso se dá porque o time é tratado como braço, e não como cérebro, e obviamente sem pensar na escalabilidade e longo prazo, a produtividade do time não aumenta proporcionalmente com o seu aumento de tamanho.

O desafio de retenção

Para trabalhar em engenharia, geralmente são necessários anos e anos de dedicação e treinamento por parte dos profissionais. Agora imagine depois de tanto esforço e dedicação, tu chegares num emprego e não ter a oportunidade de contribuir com o seu completo potencial? Não há dinheiro que faça alguém ficar numa posição assim por muito tempo.

Além disso, de um ponto de vista de engenharia, o trabalho braçal de implementação é chato, repetitivo, e não desafiador. As equipes de engenharia vão inevitavelmente passar mais e mais tempo lidando com débito técnico porque os prazos impostos pelos times de venda e produto geralmente são mais curtos do que o necessário pra fazer diligência técnica. Com isso, se torna cada vez mais difícil testar, lançar nossas funcionalidades, monitorar e no geral, ter certeza que o produto que se está provendo está funcionando da forma que deveria.

Como mercado aquecido, é inevitável que as pessoas do time de engenharia que passem muito tempo fazendo trabalhos repetitivos e medíocres procurem outros desafios em curto espaço de tempo. É comum ver profissionais que trocam de emprego com uma frequência muito alta. Além da empresa perder o conhecimento acumulado por esses engenheiros, piora a situação de aquecimento do mercado porque se vive uma espécie de leilão sem fim por profissionais que, por não achar desafios que os retenham, continuam circulando no mercado. E por continuarem circulando no mercado com grande frequência, não se desenvolvem tanto quanto poderiam em senioridade.

Big tech brasileira?

Está na hora das empresas brasileiras, muitas que almejam ser big techs, começarem a pensar grande no que diz respeito a engenharia, começando por tratar os times de engenharia como eles são, de fato, tratados em big techs: como o cérebro da empresa.

A inovação nas empresas de tecnologia do Brasil não pode acontecer só a partir de demandas de clientes e idéias do/s fundador/es. A demanda de cliente é o futuro previsível. O futuro inesperado é onde a mágica acontece, e pra isso, precisamos de muito mais cérebros engajados no desafio.

Está na hora de fechar a fábrica de software e abrir as portas para as possibilidades que se abrem com essa mudança. Daí sim começaremos a criar big techs brasileiras.

Olhando para o time e para o planejamento, estava claro para mim que tínhamos um monte de débito técnico e não tínhamos muito tempo para lidar com estes problemas. Os engenheiros estavam sentindo o peso do trabalho repetitivo e pouco inspirador que acompanha o acúmulo de débito técnico e que consumiam uma quantidade considerável de tempo. Comecei a pensar em como reverter essa tendência.

Nós também precisávamos organizar como a equipe de engenheiros interagia com outras áreas para garantir que qualquer alteração do lado técnico fosse sustentável. Nossa maneira de escalar os problemas do dia a dia entre as equipes era bem orgânica, e isso também fez com o que o peso das operações recaísse, muitas vezes, sobre os ombros das mesmas pessoas. A pergunta de um milhão de dólares era: como fazer com que qualidade da engenharia se tornasse a prioridade de toda a empresa em um curto espaço de tempo?

Eu tive a ideia, mas no começo eu achei que seria difícil de vender, mas eu propus para o time de gestão mesmo assim. Minha tese era simples: se a gente focar o primeiro trimestre de 2021 em qualidade da engenharia, eliminando os débitos técnicos e estruturando melhor o fluxo de trabalho da equipe, nos trimestres seguintes poderíamos entregar o roadmap do produto do ano inteiro.

Foi então que eu propus um lockdown em engenharia: nenhuma nova funcionalidade de produto durante um trimestre inteiro. Se o roadmap de produtos será entregue nos trimestres seguintes eu vou atualizar vocês mais pra frente. Mas o primeiro trimestre certamente motivou o início da mudança que buscávamos fazer na equipe e na empresa. Somos uma empresa de engenharia, com foco no sucesso sustentável de longo prazo.

Para começar, fizemos um planejamento muito simples, perguntando aos times quais problemas eles achavam que deviam ser resolvidos. Pedi que fossem ambiciosos em seu planejamento. A lista não surpreendeu ninguém e tinha um pouco de tudo: desde melhorias de monitoramento, até melhores testes e re-arquitetura de alguns componentes de produtos. Abraçamos tudo e deixamos a equipe fazer sua mágica.

A autonomia fazia parte do design. Acostumados a viver sob a pressão do dia a dia das operações, senti que a equipe estava um pouco perdida no início. Precisávamos que toda a empresa comprasse essa ideia para que funcionasse e, nesse sentido, toda a equipe da unico merece reconhecimento porque com raras exceções todos respeitaram o foco e o espaço da equipe de engenharia, e como gosto de dizer, deixaram a equipe trabalhar.

Enquanto a equipe trabalhava nos desafios técnicos, a gestão estava focada em trazer novas pessoas para a equipe, dando ajuda às equipes que precisavam, incentivando a movimentação interna entre as equipes e cuidando da integração de todos. Só no primeiro trimestre contratamos 17 pessoas para a equipe de engenharia e 100 pessoas no total na unico. Além disso, planejamos e validamos uma grande mudança organizacional seguindo o modelo de tribos e squads com times autônomos e papéis muito bem definidos.

Três meses depois, sentimos que o tempo passou muito rápido. Mas aprendemos muito - e muito além da engenharia. Na pesquisa pós-Lockdown, mais de 83% da equipe classificou a oportunidade de aprendizado como grande ou muito grande no período. Trabalhamos mais próximos um do outro e colaboramos como nunca antes havíamos colaborado. Praticamos o desapego de soluções que já não nos servem mais. Para incentivar a troca de informações e qualidade das soluções, semanalmente tínhamos 2 reuniões de revisões de engenharia e design, onde as pessoas podiam vir pedir feedback sobre o que estavam fazendo. Iniciamos projetos que envolveram toda a equipe, aproximando as pessoas e possibilitando o aprendizado e a troca.

Algumas equipes reduziram os chamados de clientes pela metade. Outros aprenderam sobre ineficiências em sua configuração de back-end. Priorizamos segurança, monitoramento padronizado. Melhoramos a documentação de nossos produtos internamente e externamente e investimos em melhorias de infraestrutura e cobertura de testes. Plantamos muitas sementes que certamente colheremos mais tarde.

Foi um trabalho enorme de faxina, e saímos do Lockdown energizados com os desafios para o resto do ano e também, com a certeza de que ainda temos muito a fazer para minimizar o inevitável débito técnico que tão facilmente se acumula ao longo do tempo.

Como empresa, saímos deste período com o compromisso de continuar dedicando tempo aos itens de excelência da engenharia, e com o compromisso de respeitar os investimentos necessários que eles requerem. Para isso, nosso planejamento de produto e engenharia agora é feito explicitamente mencionando o quanto é investido em novos recursos versus itens de engenharia. No final isto é uma maratona e não uma sprint e precisamos garantir que nossos produtos sejam construídos para o futuro.

Um passo de cada vez, juntos estamos construindo uma equipe de engenharia unida, forte e entregamos qualidade de engenharia, através de produtos simples, confiáveis e escaláveis para nossos clientes.

Esse programa foi baseado no conceito de job share, que é muito conhecido nos Estados Unidos, porém talvez nem tanto no Brasil.

Job share ou trabalho compartilhado funciona a partir da premissa de que duas pessoas vão compartilhar um cargo, cada uma delas trabalhando em tempo parcial.

No caso do Mães na Engenharia, usamos 60% como carga horária para o programa, e a idéia é contratar duas pessoas para cobrir uma posição (também conhecida como headcount). Com isso, de fato temos 120% da vaga preenchida, porque consideramos o custo de overlap como custo que estamos felizes em cobrir.

Como eu falei o salário é proporcional, porém os benefícios obviamente nem todos são. Plano de saúde é integral, e alguns outros que não faz sentido reduzir. Aqui é onde mora o espaço para a criatividade, porém precisamos ter cuidado para não criar benefícios exclusivos para o programa, porque pode criar um problema de senso de justiça (e litígio). Se a tua empresa tem benefícios atraentes para mães e pais, esse problema é resolvido por design.

O mais difícil não é contratar nesse modelo, e sim, adaptar todos os processos. Por isso, eu decidi fazer um experimento com poucas pessoas e assim conseguirmos avaliar como essa dinâmica vai se dar no dia a dia.

Eu espero que as duas pessoas compartilhando um cargo tenham horas de overlap para passar contexto, e assim evitar o “60% de salário mas 100% de trabalho”, que eu admito que é um risco. Também para mitigar esse risco nós abrimos vagas, inicialmente, somente para profissionais com experiência.

O sucesso no número de aplicações fala por si só. Em menos de 1 semana mais de 100 mulheres (e alguns homens) aplicaram para o programa. Eu não poderia estar mais feliz. Possibilitar as mulheres uma jornada de trabalho que caiba na sua vida pessoal é muito importante pra mim.

Alguns CTOs de outras empresas já me contataram para falar que eles também vão criar programas semelhantes. Eu estou empolgada. Parece que é o começo de um movimento que vai ser muito benéfico não só para as mães participantes, mas também o mercado de tecnologia do Brasil que perde com a perda desses talentos.

Se você ama programar e colocar a mão na massa, provavelmente gestão não é para você. Eu digo isso porque nós humanos somos inquietos por novos desafios, e quanto mais você avança na carreira de gestão e assume desafios maiores como gestor, menos trabalho técnico você fará. Algumas pessoas me dizem que querem ser gestores, mas querem permanecer técnicas. Eu digo a elas que isso é muito provavelmente uma contradição e um sinal de que a gestão pode não ser para elas.

Gestão não é um lugar de autoridade. Na verdade, a autoridade é a última ferramenta na caixa de ferramentas de um gestor, e só deve ser usada quando todas as outras ferramentas falharem. E se você a usar, tenho quase certeza de que você falhou em algum lugar ao longo do caminho para acabar em uma situação deste tipo.

Enquanto ser um engenheiro significa que seu objetivo é técnico e as pessoas são o contexto onde isso ocorre, a gestão é exatamente o oposto: as pessoas são o seu objetivo e técnico é o contexto onde isso ocorre.

A melhor maneira de entender o trabalho de um gestor (pelo menos no início de sua carreira) é dividi-lo em três dimensões: pessoas, projetos e equipe.

Você verá que é bastante trabalho e, se achar que ainda tem tempo para fazer o trabalho de um colaborador individual depois de fazer tudo isso, provavelmente está trabalhando demais. Se você não está fazendo tudo isso (e muito mais), provavelmente não está atendendo aos meus elevados padrões de gestão :-)

Pessoas

Resumo (sem ordem específica, no futuro escreverei sobre cada um deles):

• Contratação

• Desenvolvimento de pessoas

• Apoiá-los de forma humanizada

• Gestão de desempenho

• Demitir pessoas e/ou ajudá-las a encontrar seu caminho

Tudo relacionado a pessoas entram nesta categoria: da contratação à demissão e tudo entre estes dois, ou seja, a jornada de cada pessoa na equipe que você gerencia.

Você é responsável por atrair pessoas para sua equipe. Não importa o que algumas pessoas possam lhe dizer, é seu trabalho ter boas pessoas se juntando à sua equipe e, então, mantê-las.

Uma vez que você contrata pessoas, você precisa garantir que elas estejam trabalhando em projetos adequados para seu nível de carreira, garantindo que você continue a desafiá-las para que continuem crescendo (se elas quiserem, não seja uma pessoa chata e insistente), independentemente do nível em que estão.

Você também é responsável por cuidar dessa pessoa e garantir que ela aproveite todos os recursos disponíveis para ela como funcionário quando estiver passando por dificuldades: benefícios como seguros, licenças e tudo mais.

Além disso, enquanto alguém está trabalhando com você, você também é responsável pela sua produtividade, ajudando-os a recuperar o desempenho quando estão com problemas, adquirir novas habilidades e orientá-los para assumir mais responsabilidades e, finalmente, se eles não se encaixam mais no contexto da equipe, também é seu trabalho lidar com isso. Se for o caso, isso inclui demitir.

Projetos

Resumo:

• Entender o papel da sua equipe de forma ampla

• Ouvir as necessidades da sua equipe

• O delicado ato de equilíbrio no estabelecimento das metas

• Garantir que tudo está atribuído em um balé mágico de preferências, capacidades e prioridades

• Dar o crédito e levar a culpa

O gestor não é apenas responsável pelas pessoas de sua equipe, existe também a responsabilidade sobre os objetivos do time. O gestor desempenha o papel de garantir que isto aconteça, começando é claro, por garantir que sua equipe tenha objetivos claros. O gestor não necessariamente precisa fazer este trabalho, mas garantir que alguém irá fazer. Em algumas empresas e dependendo do projeto ou gestor, haverá também um Gerente de Projetos (PM) envolvido, e esta pessoa pode ajudar no gerenciamento de projetos.

Presumindo que não existe um PM envolvido, o gestor precisa construir uma imagem exata das necessidades do negócio e garantir que sua equipe esteja ciente dela. Você precisa então ouvir as pessoas da sua equipe e garantir que todas as coisas importantes sejam feitas para satisfazer os dois lados: o negócio e as pessoas. Ouvir o negócio é importante, pois paga as contas, e ouvir as pessoas é também importante pois se você não ouve, você será um péssimo gestor por não envolver a equipe no processo, mas também por não levar coisas que são menos populares em consideração. Pense, por exemplo, em débito técnico: "Foque na qualidade da engenharia e na dívida técnica, mesmo que isso signifique não liberar recursos" frase jamais dita por um Gerente de Produto. 

Uma vez que as metas estão definidas, é hora de fazer com que os membros da equipe escolham as suas metas com base nos interesses, importância e competências (os engenheiros seniores provavelmente farão o trabalho mais complexo, por exemplo). É um equilíbrio bastante delicado, e eu costumo brincar que é como um prato cheio de coisas gostosas e uma colher de coco. Todo mundo deve fazer o trabalho impopular, porque caso contrário você terá pessoas muito infelizes em sua equipe (a menos, é claro, que gostem do trabalho, mas geralmente existem atividades necessárias que não são populares).

A equipe fica com o crédito, o gestor fica com a culpa. Este é o resumo de como a coisa anda. Seu trabalho é dar crédito onde é devido e também assumir os erros cometidos pela sua equipe de uma forma que não culpe as pessoas individualmente por cometer erros.

Equipe

Resumo:

• Ambiente agradável

• Colaboração entre os membros da equipe e entre sua equipe e outras equipes

• Processos e rituais

O trabalho do gestor é garantir que haja um bom ambiente de trabalho dentro da equipe. O gestor é aquele que facilita a criação da "mágica" que torna as equipes produtivas: oportunidades de aprendizagem, lidar de forma graciosa os conflitos, garantir que todos sejam ouvidos, e fazer sua equipe não perder tempo com bobagens.

Este é o menos objetivo de todos ao meu ponto de vista, mas não é o menos importante. Ninguém gosta de trabalhar em um ambiente tóxico. Colaboração é importante, autonomia é importante, competição geralmente destrói a sensação de bem estar da sua equipe, a menos que seja um exercício para realizar algo específico.

Se suas reuniões de equipe são chatas, mude-as. Garanta que o tempo que você pede da sua equipe seja bem utilizado com um objetivo claro e, uma vez que este objetivo não seja mais atendido, ou tenha mudado, é seu trabalho fazer as mudanças. Isto vai desde a organização de reuniões semanais com pautas bem definidas, até garantir que você tenha um roteiro para definir metas sem gastar um mês inteiro do tempo de todos em discussões inúteis. Basicamente, ter todo o contexto para abstrair a complexidade da equipe é seu trabalho.

Gestão é uma função, e é responsável por garantir que todas as coisas certas estejam acontecendo na equipe em relação às pessoas, aos projetos e, claro, à dinâmica e aos rituais da equipe. Se você é gestor e cuida de todas as coisas relacionadas a esses três itens, provavelmente não terá tempo para se envolver profundamente (muito menos colocar a mão) na execução técnica do time. Certo? Hmmm, não exatamente.

Sempre que um gestor interage com sua equipe 1:1 ou em reuniões, é uma oportunidade de influenciar a direção técnica da equipe. Isso acontece fazendo as perguntas certas e tendo conhecimento técnico bom o suficiente para saber se o time está na direção certa O gestor também é responsável ​​por alinhar a direção do time com a estratégia do departamento ou da empresa.

O gestor traz contexto para a conversa e a teoria aqui é que, se a equipe tiver todos os dados, tomará as decisões certas. Se a equipe não tiver todos os dados, o problema é do gestor. O oposto também é verdadeiro: se a empresa não entende por que o time está fazendo o que está fazendo, é função do gestor preencher a lacuna e garantir que a empresa tenha o contexto.

E o líder técnico do time? Em primeiro lugar, acredito que todos são ou deveriam ser líderes dentro de seu nível de competência. Ser um líder técnico não é um trabalho, mas é uma função e é fluido. As pessoas entram e saem dessa função organicamente. Não acredito em dar o título de líder técnico a alguém, este título deveria ser conquistado não da gestão, mas dos pares. Se você tem um líder técnico no time e essa pessoa tem todas as respostas o tempo todo, provavelmente você tem um problema diferente para resolver.

Se o gestor é quem faz a ponte do contexto  entre  a empresa e o time, os líderes técnicos da time fazem exatamente o oposto: eles trazem o contexto do campo para o gestor e para a empresa, para que o gestor e a empresa entendam a importância de coisas que não são óbvias para eles, mas que também são importantes e precisam de atenção.

Eu digo que o líder técnico e o gestor fazem a gestão da time a quatro mãos, com o líder de tecnologia prevendo os desafios técnicos que surgirão no caminho e se alinhando com o contexto fornecido pelo gestor para garantir que as soluções para tais desafios também respondam à crescente demanda e estratégia da empresa.

Líderes técnicos podem ser aqueles que propõem mudanças técnicas na arquitetura de software para que estes continuem  escalando conforme a necessidade. Líderes técnicos propõem mudanças revolucionárias em vez de melhorias incrementais quando fizer sentido. Eu sou uma grande fã de melhorias incrementais,mas às vezes elas não são suficientes.

Os líderes técnicos geralmente são pessoas experientes que conseguem reconhecer padrões e sinalizar quando os processos técnicos estão atrasando o time. Eles detêm a barra de qualidade do time. Se um líder técnico tem uma barra de qualidade baixa, geralmente o time também terá (e esse é um problema para o gestor resolver). Manter a barra de qualidade alta significa ajudar os outros a crescer em suas habilidades técnicas, tendo conversas técnicas com a time, fazendo revisões de código detalhadas e prestando atenção ao que está acontecendo no dia a dia - incluindo alertando o gestor sobre problemas de desempenho no time para que o gestor possa lidar com esses problemas. 

Os líderes técnicos também tornam as pessoas ao seu redor tecnicamente melhores. Eles fazem isso entendendo, intencionalmente, os limites do conhecimento de outras pessoas no time e ajudando-as a preencher estas lacunas. Alguns líderes técnicos fazem conversas recorrentes com pessoas do time. É importante que essas conversas sejam intencionais e tenham um valor claro para a pessoa e para o time. Eu sempre sou cautelosa ao pedir tempo das pessoas, pois as tiram do foco do seu trabalho (mesmo que o propósito seja apenas "vamos relaxar e comemorar uma conquista"). Nenhuma reunião deve ser parecida com uma conversa enquanto tomamos um café na cozinha. Isto é um bate-papo.

Se os gestores ajudam a criar e manter a conversa sobre pessoas, projetos e seus times com outros gestores dentro da empresa, os líderes técnicos em uma empresa tecem a estrutura de tecnologia em cooperação com seus pares dentro e fora de seus times, dependendo de seu nível de senioridade. Eles criam e mantêm a conversa sobre a tecnologia e, portanto, são donos dos resultados técnicos.

Eu vejo o papel dos líderes técnicos e dos gestores como complementares. Um time sem um bom gestor provavelmente terá dificuldades da mesma forma que um time sem um líder técnico.

Às vezes, quando não há líderes técnicos em um time, o gestor pode temporariamente preencher a lacuna entre a capacidade de seu time e o que precisa ser feito, enquanto trabalha para contratar outras pessoas experientes, que possam preencher essas lacunas rapidamente.

Enquanto o gestor é o único responsável por esclarecer o escopo do time, a direção e a estratégia da empresa, os líderes técnicos são os que ajudam a esclarecer como chegaremos lá. Eles também podem identificar oportunidades que influenciam e mudam a direção e a estratégia da empresa, dependendo de sua senioridade.

Nenhum gestor pode obrigar as pessoas a ouvir alguém que não tem competência técnica e substância, e essas coisas se tornam muito óbvias. Ser um líder técnico não é fácil e não existe uma receita única de como viver essa função. Em algumas empresas, essa função é atribuída às pessoas como um cargo. Eu prefiro não fazer isso.