Estreamos nossa série de entrevistas com a interessante Camille Fournier, autora de The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change, um livro que nossos desenvolvedores têm devorado nos últimos tempos sobre crescer como um líder na área de produto e tecnologia. Ela também é diretora de gestão na Two Sigma, onde lidera Engenharia de Plataforma, e anteriormente foi CTO da Rent the Runway, uma startup de moda baseada em Nova York. Foi lá que Camille publicou a "escada de engenharia" da empresa, um conjunto de comportamentos e competências que serviu de benchmark para muitas empresas, inclusive brasileiras, na estruturação dos seus modelos de gestão de desempenho.
Conversei com a Camille sobre a incrível carreira dela, liderança e gestão de performance em times de tecnologia. Tenho certeza que você vai gostar!
Sobre sua trajetória
Kiko: Você pode nos contar um pouco sobre você? Como você começou a trabalhar com tecnologia?
CF: Eu me interessei por tech minha vida toda. Decidi ir pra faculdade pra estudar ciência da computação e frequentei a Carnegie Mellon, então minha decisão de trabalhar com tecnologia foi tomada bem cedo.
Sobre a estrutura organizacional de times de produto:
Kiko: Há muitas empresas no Brasil se organizando "do jeito Spotify": em times multidisciplinares ágeis, em que não há de fato um "gestor". Alguém lidera as iniciativas (normalmente um PO ou líder de tech), mas tem pouca ou nenhuma responsabilidade em termos de gestão de pessoas (avaliações de performance, aumentos, férias, promoções, etc). Por outro lado, temos o Mark Zuckerberg nos dizendo para inovar em produtos, e não na estrutura organizacional. Considerando sua experiência, qual é a estrutura ideal?
CF: Em geral, acho que você provavelmente vai querer ter alguma estrutura de gestão depois que sua equipe de dev/produto tiver mais de 10 funcionários, e especialmente quando você tiver gente no time em começo de carreira, que portanto precisa de mais direcionamento e mentoria. Eu gosto de dar espaço à flexibilidade quando se trata de projetos dados a um time. Algo que definitivamente compartilho com a Spotify é o desejo de agrupar as pessoas em times orientados para problemas de negócio, e não apenas porque reportam ao mesmo gestor. Faz muito mais sentido.
Eu não acho que você absolutamente tem que ter a gestão como forma de determinar quem trabalha em qual projeto. No entanto, a gestão de pessoas é um fator importante ao escalar uma empresa. A maioria das pessoas quer saber que tem um gestor no qual podem confiar para ter feedbacks e coaching em todos os aspectos, e não apenas técnicos.
Kiko: Nessas estruturas organizacionais, quem absorve as responsabilidades de gestão de pessoas? Um líder do chapter?
CF: Na minha experiência, times multidisciplinares ainda podem reportar para gestores funcionais. Então, você pode ter um time formado por pessoas de áreas diferentes, e essas pessoas têm gestores nas suas diversas especialidades (como tech, marketing, etc.), mas trabalham juntas para atingir um objetivo de negócio comum. Isso demanda que gestores saibam detalhes de alguns projetos, por que é difícil gerir pessoas quando você não sabe como o dia a dia de trabalho delas efetivamente é.
Uma estrutura que funciona bem aqui é ter um líder/gestor de tech para a parte de engenharia de um time multidisciplinar, reportando para um gestor mais sênior de engenharia que é responsável por supervisionar os engenheiros desses times.
Sobre a relação de ódio entre gestão e desenvolvedores
Kiko: O Google tentou eliminar a média gestão completamente (na época, o CTO tinha mais de 200 liderados diretos), e descobriu depois de muito sofrimento que gestores - bons gestores - são necessários e muito úteis para ter uma organização de engenharia de sucesso. Qual é sua opinião sobre a necessidade de gestores (aqueles que nos ajudam com remuneração, avaliações de desempenho, férias, promoções, etc.) em times de produto/tech?
CF: Eu acho que gestores têm um papel valioso em times de produto/tech, e que vai além da necessidade de alguém se certificar de que as pessoas dos times estão recebendo cuidados e atenção. Isso é essencial, e algo que você obviamente perde sem gestores. A maioria das pessoas quer ter alguém com quem podem discutir sobre sua carreira, ter feedback, que possa explicar a organização como um todo e que pode ajudar a dinâmica do time, o que é difícil sem gestores.
Mais do que isso, bons gestores têm um bom entendimento sobre qual deve ser o foco do trabalho, ajudando a manter o nível técnico do time e fazendo com que o time esteja em harmonia com o restante da empresa. Eles desenvolvem novos líderes, contratam pessoas incríveis, e trabalham para garantir que todo o time seja produtivo. Quando vejo times sem gestores ou com gestores fracos, o que mais percebo é a falta de clareza e foco, do ponto de vista de engenharia.
Kiko: O que torna alguém um bom gestor de times de produto/tech?
CF: Isso sempre depende, de alguma forma, do time e suas necessidades. Eu tenho um grupo de ótimos gestores que reportam para mim, e cada um tem diferentes pontos fortes. Todos são bons comunicadores, o que é uma qualidade essencial de gestão. Todos eles se importam com os produtos que estão construindo, e entendem as pessoas para quem estão criando esses produtos. Alguns são mais fortes operacionalmente, e muito bons em disciplinar suas equipes para produzir sistemas escaláveis e de fácil manutenção. Alguns são bons em construir relacionamentos, não só dentro dos times, como na organização como um todo. Alguns são pensadores criativos que inspiram engenheiros ao seu redor a pensarem no futuro. A maioria é bastante detalhista, tem um conhecimento profundo do que está acontecendo em seu time e onde estão os riscos.
Eu diria que os melhores gestores são muito bons em priorizar o trabalho de seus times, em identificar o que é importante e enxergar padrões tanto para o sucesso, quanto o fracasso de suas equipes. Principalmente se você está num time focado em produto, você precisa ser bom em priorizar o trabalho, e em tornar seu time altamente produtivo. Produtividade em engenharia muitas vezes se resume a uma combinação de dividir o trabalho em pedaços menores, lançar mudanças regularmente, se atentar à qualidade técnica (mas não permitir que isso se torne um obstáculo) e agressivamente priorizar as atividades.
Kiko: Nós vemos muitos engenheiros altamente qualificados evitando cargos de gestão. E também vemos que os melhores engenheiros - de um ponto de vista técnico - tendem a ter mais legitimidade com seus liderados quando ocupam posições de líder. Como você resolveu esse paradoxo em suas empresas?
CF: Honestamente, eu não sei se posso afirmar que resolvi. Em geral, não tenho visto uma falta de pessoas interessadas em se tornar gestoras. Muitos engenheiros chegam a um certo nível de senioridade e ficam frustrados pelo desafio de liderar pela influência, o que frequentemente os leva a concluir que devem se tornar gestores. Eu acho que é difícil criar um bom plano de carreira para pessoas que querem crescer mas não querem gerir pessoas diretamente, especialmente para aquelas que querem ser promovidas rapidamente. Quase sempre é uma progressão de carreira mais lenta, com a exceção de um pequeno número de indivíduos que possuem muito talento e muita sorte.
Para aqueles que querem ser gestores, eu tento ser firme, por que não quero que façam gestão até que eles tenham trabalhado como um colaborador individual por um tempo razoável (pessoalmente, considero ideal um período de 5 anos). Isso é para garantir que as pessoas que você coloca em cargos de gestão já possuam uma fluência técnica significativa antes de se tornarem gestoras, para que elas tenham as melhores condições para reter essa força técnica mesmo quando não estão construindo sistemas.
Sobre competências e gestão de desempenho
Kiko: Você é conhecida por ter publicado a Rent the Runway's engineering ladder, um conjunto de competências que permite que uma desenvolvedora e sua gestora possam destrinchar o desenho da progressão de carreira em termos de habilidades e contribuições para o time, e onde ela está em relação a esse plano. Nós começamos a usar ela na Qulture.Rocks, e nossos desenvolvedores amam a clareza que isso traz para discussões sobre performance. Uma das tensões que sentimos é, por um lado, tentar manter o modelo o mais simples possível, e por outro, detalhar níveis e competências ad nauseam para ter resultados mais "precisos". Só para ilustrar, nós separamos o primeiro nível em dois, para dividir aprendizes e estagiários (ainda não é o ideal). Como vocês equilibram essas necessidades conflituosas?
CF: Essas coisas estão em constante evolução, o que é normal. Eu sempre aviso as pessoas que não existe uma checklist que garante uma promoção, e tentar criar algo assim não é uma boa ideia. Ao mesmo tempo, você deve ser o mais claro possível sobre as principais áreas que são importantes para o sucesso em cada nível. A primeira "escada" que usei era muito vaga, e isso causou muita confusão, o que fez ela não ter muito valor. A segunda escada tem uma versão em planilha e em texto para poder ter uma visão melhor das descrições em cada nível.
O que eu descobri é que as pessoas focam muito nas qualificações técnicas, mas acima de um nível médio, são a execução, a comunicação e liderança que fazem a diferença, e esses aspectos dificilmente podem ser transformados numa checklist. Então encorajo líderes a aceitar alguma ambiguidade, mas ao mesmo tempo sempre questionar se você realmente deixou o mais claro possível o que é importante em cada nível, e se é capaz de fazer pequenas alterações à medida que sua empresa evolui.
Kiko: Avaliar competências em uma avaliação de desempenho é uma prática bastante popular com o pessoal de RH: uma gestora avalia seus liderados a partir de várias competências em uma escala que pode ir, por exemplo, de "1 - abaixo do esperado" até "5 - superou expectativas". Como, exatamente, vocês utilizaram a "escada"? Foi dessa forma?
CF: Não. Uma parte do meu time fez isso em avaliações de desempenho, onde utilizaram várias categorias para avaliar pessoas e deram notas de acordo com como estavam se saindo. Mas nunca estabelecemos algo formal.
Kiko: Em muitas empresas com quem trabalhamos há uma tensão entre times de produto/tech e o RH. Os times de tech parecem não gostar de nada que vem do RH e rejeitam a maioria das iniciativas gerais da empresa. O RH, por outro lado, quer unificar processos como gestão de performance e contratações. Como você lida com esse conflito?
CF: Não posso dizer que tive que lidar muito com esse conflito. Eu aconselharia que líderes que estão tentando lidar com isso devem certificar-se de que o RH está explicando suas decisões diretamente ao time. Às vezes, quando há um esforço para esclarecer o que está sendo feito, você consegue maior compreensão e melhores resultados.
Kiko: A escada foi utilizada para decisões de bônus/remuneração/promoção? Se sim, como você diferenciou um "ótimo" nível 4 e um nível 4 "mediano"?
CF: Promoções, com certeza. O propósito da escada era de avaliar em qual nível a pessoa está atuando. Quando fizemos comitês de promoções, utilizamos a escada pra nos perguntar, em cada categoria, se determinada pessoa já está tendo um desempenho em um nível acima do que seu cargo atual necessita para justificar uma promoção. Isso deu algo concreto, serviu de âncora, durante as conversas sobre promoções. Os níveis também estavam atrelados à remuneração, já que cada nível tinha uma faixa de salários e uma fórmula que se aplica a bônus, então uma pessoa que acaba de ser promovida para o nível 4 provavelmente recebe menos do que alguém que já está nesse nível há mais tempo.
Se interessou pelo assunto? Confira também esse artigo sobre como entrevistar Engenheiros de Software, em parceria com a Triplebyte.
