Português

Estilo de Liderança de Camille Fournier: O Manual do Gerente Técnico

Camille Fournier Leadership Profile

Fatos Principais: Camille Fournier

  • Antiga CTO, Rent the Runway (2013–2017)
  • Managing Director & Head of Platform Engineering, Two Sigma
  • Autora, "The Manager's Path" (O'Reilly, 2017) — livro best-seller sobre liderança de engenharia
  • Colaboradora, "97 Things Every Engineering Manager Should Know"
  • Apache ZooKeeper contributor — contribuidora central do serviço de coordenação distribuída
  • Carreira anterior: Managing Director, Goldman Sachs (engenharia de infraestrutura)

The Manager's Path não é um livro de negócios sobre visão ou cultura. É um manual, capítulo por capítulo, de tech lead a CTO, sobre o que o trabalho realmente exige em cada estágio da gestão. Publicado em 2017, tornou-se o livro de gestão de engenharia mais recomendado no Vale do Silício porque respondeu a perguntas que nenhum outro livro havia feito: o que você faz quando seu melhor engenheiro quer ser gerente e provavelmente não deveria? Como você gerencia conversas de skip-level quando seus diretos também são gerentes? Qual é a diferença real entre um Director e um VP de Engenharia?

Camille Fournier escreveu com base na experiência. Ela foi CTO da Rent the Runway de 2013 a 2017, uma das empresas de tecnologia de moda que mais cresceu rapidamente naquela era. Antes disso, passou tempo no Goldman Sachs como Managing Director gerenciando engenharia de infraestrutura, o que significava gerenciar grandes equipes dentro de uma das instituições financeiras mais dependentes de tecnologia do mundo. No início de sua carreira, foi uma colaboradora importante do Apache ZooKeeper, o serviço de coordenação distribuída que sustenta muitos dos sistemas de infraestrutura que ela posteriormente gerenciou em escala. Ela não aprendeu a teoria de gestão em uma escola de negócios. Ela aprendeu gerenciando engenheiros no Goldman, escalando uma empresa de tecnologia de consumo na Rent the Runway, e retornando ao trabalho técnico prático na Two Sigma como Principal Software Engineer.

Essa combinação é o que torna seus frameworks convincentes para pessoas que realmente executam organizações de engenharia.

Análise do Estilo de Liderança

Estilo Peso Como aparecia
Mentor Estruturado 55% A contribuição principal de Fournier é dar aos gerentes de engenharia uma visão clara do que seu trabalho é em cada nível de senioridade, e criticamente, o que não é. A maioria das falhas em gestão de engenharia ocorre quando as pessoas continuam fazendo o trabalho para o qual foram boas em vez do trabalho que agora deveriam fazer: o tech lead que se torna gerente mas não consegue parar de escrever todo o código, o gerente sênior que continua fazendo 1-on-1s com colaboradores individuais em vez de gerenciar seus gerentes. "The Manager's Path" nomeia esses padrões de falha explicitamente, nível por nível, o que os torna discutíveis. Essa é a função de mentor: dar às pessoas um mapa antes de precisarem dele.
Construtor de Sistemas Pragmático 45% Fournier pensa sobre organizações de engenharia como sistemas com entradas, saídas e padrões de falha identificáveis. Seu histórico no Goldman Sachs e Two Sigma se mostra em como ela aborda design organizacional: analiticamente, com atenção às estruturas de incentivos e fluxos de informação. Sua escrita sobre débito técnico o trata não como um problema de qualidade de código, mas como um problema de risco comercial, que é como tem de ser enquadrado para conseguir orçamento. Esse é pensamento em sistemas aplicado à gestão organizacional em vez de arquitetura de software.

A divisão 55/45 significa que Fournier é mais valiosa para pessoas no meio de uma transição de gestão: passando de colaborador individual para tech lead, de tech lead para gerente, de gerente para Director. Seus frameworks são menos sobre o destino final do que sobre as transições. Will Larson começa onde a escada de Fournier termina — seus arquétipos "Staff Engineer" abordam a carreira de IC que "The Manager's Path" deliberadamente deixa de lado.

Traços Principais de Liderança

Traço Avaliação O que significa na prática
Clareza sobre o que cada nível de gestão exige Excepcional A maioria das organizações promove pessoas a gestão sem dizer a elas qual é o novo trabalho. "The Manager's Path" resolve isso definindo cada nível especificamente: que decisões você é responsável, que relacionamentos você é responsável, qual é a aparência do sucesso e qual é a aparência da falha. O capítulo sobre "Managing Multiple Teams" não é sobre a teoria de liderança geral. É sobre o trabalho específico de um Director que gerencia outros gerentes, incluindo como evitar a armadilha de pular os gerentes e fazer seu trabalho por eles. Esse nível de especificidade é raro na escrita de gestão.
Disposição de discutir abertamente os padrões de falha de gestão Muito Alta Fournier não escreve sobre gestão da forma que a maioria dos livros de gestão fazem, de forma aspiracional, focando em padrões de sucesso. Ela escreve sobre padrões de falha: o gerente técnico que não consegue parar de codificar, o novo gerente que se torna melhor amigo de todos seus relatórios, o CTO que não delegará decisões organizacionais porque não confia em seu VP de Engenharia. Nomear explicitamente os padrões de falha é mais útil do que descrever comportamento ideal, porque dá às pessoas uma forma de reconhecer quando estão cometendo um erro antes que ele se agrave.
Profundidade técnica mantida como executivo Alta A maioria dos executivos que foram CTOs param de escrever código real. Fournier retornou a trabalho de Principal Software Engineer na Two Sigma após deixar o Goldman Sachs no nível de Managing Director. A mesma recusa em se afastar do trabalho técnico é visível em Jeff Dean, que continuou entregando pesquisa de sistemas fundamentais no Google mesmo após seu trabalho definir como a infraestrutura da empresa escalou. Esse é um movimento de carreira incomum: para trás em título, para frente em engajamento técnico. Significa que seu conselho de gestão é escrito por alguém que realmente permaneceu perto do trabalho, o que lhe dá uma perspectiva diferente sobre a lacuna entre a teoria de gestão e a experiência diária dos engenheiros do que a maioria dos escritores de gestão tem.
Especificidade sobre abstração Alta Os frameworks de Fournier são checklists e árvores de decisão, não filosofias. O framework de 1-on-1 não diz "construa rapport com seus relatórios." Ele especifica o que cobrir, quais perguntas revelam que tipos de informação, e como distinguir um 1-on-1 que está indo bem de um que está se tornando uma reunião de status. O framework de débito técnico não diz "comunique as preocupações técnicas claramente." Ele lhe dá a tradução: aqui está como renderizar um problema de qualidade de código como um problema de risco e velocidade que um CFO pode tomar uma decisão orçamentária.

Os 3 Frameworks Que Definiram Camille Fournier

The Manager's Path (A Escada de Liderança de Engenharia Fournier)

The Manager's Path, também chamada Escada de Liderança de Engenharia Fournier, é uma definição nível por nível da carreira de gestão de engenharia de colaborador individual através de tech lead, gerente, gerente sênior, director, VP de Engenharia, e CTO. Cada degrau especifica um relacionamento primário distinto, unidade de trabalho e padrão de falha nomeado — mais comumente, fazer o trabalho do nível anterior em vez do atual. A escada é o modelo de referência dominante para caminhos de carreira de gestão de engenharia em organizações de software modernas.

A Escada de Gestão

O framework central de "The Manager's Path" é simples: cada nível da hierarquia de gestão de engenharia tem um trabalho distinto, e o padrão de falha mais comum em cada nível é fazer o trabalho do nível anterior em vez do atual.

Fournier mapeia a escada especificamente: colaborador individual, tech lead, gerente de colaboradores individuais, gerente sênior (gerente de gerentes), director, VP de Engenharia, CTO. Cada nível tem um relacionamento primário diferente e uma unidade de trabalho diferente. O relacionamento primário de um tech lead é com o código e a equipe. O relacionamento primário de um gerente é com os colaboradores individuais. O relacionamento primário de um Director é com seus gerentes. O relacionamento primário de um VP é com sistemas organizacionais e pipelines de contratação. O relacionamento primário de um CTO é com a estratégia técnica da empresa e o board.

O padrão de falha em cada nível está bem definido. O tech lead que se torna gerente continua escrevendo todo o código e não investe em tornar seus engenheiros melhores. O gerente que se torna Gerente Sênior continua fazendo 1-on-1s com todos os colaboradores individuais em vez de desenvolver seus gerentes. O Director que se torna VP continua tomando decisões individuais em nível de equipe em vez de projetar estruturas organizacionais. Cada uma dessas falhas é reconhecível na prática, e nomeá-las é o que as torna corrigíveis.

Para operadores fora de engenharia, o framework da escada se aplica a qualquer organização com hierarquia de gestão. A pergunta em cada promoção é: o que o novo trabalho exige que o trabalho antigo não exigia? Se você não conseguir responder isso claramente, você está promovendo pessoas a papéis que preencherão com as habilidades que os promoveram, não as habilidades que o papel necessita.

O Audit de 1-on-1

Fournier é específica sobre o que 1-on-1s são e o que não são. Não são reuniões de status. Não são check-ins sobre o progresso do projeto. São a principal ferramenta que gerentes têm para aviso antecipado sobre risco de talento, insatisfação de carreira, e problemas de dinâmica de equipe que não surgem em qualquer outro formato.

A agenda específica que ela recomenda tem três partes. Carreira: qual é o destino dessa pessoa, e seu trabalho atual está as movimentando em direção a isso? Desafios atuais: o que está no caminho deles agora, e há algo apenas você pode remover? Dinâmica de equipe: como as coisas estão indo com as pessoas ao redor deles, e há pontos de fricção que não chegaram à superfície ainda?

A razão pela qual a maioria dos 1-on-1s se tornam reuniões de status é que gerentes se sentem mais confortáveis discutindo status do projeto do que tendo conversas diretas sobre satisfação de carreira ou fricção de equipe. Status é seguro. O agenda real de 1-on-1 surfaces problemas que o gerente pode ter de possuir e corrigir. O ponto de Fournier é que o desconforto é a informação. No momento em que um direto para de elevar problemas em 1-on-1s, você perdeu seu sistema de aviso antecipado. No momento em que eles dizem a você em uma carta de renúncia, você já perdeu a janela para corrigir.

Débito Técnico como Decisão de Negócio

Fournier escreveu e falou extensivamente sobre um dos padrões de falha mais comuns para líderes de engenharia: a incapacidade de traduzir preocupações técnicas em linguagem que consegue orçamento.

O enquadramento de engenharia de débito técnico é orientado para qualidade: "o código é desorganizado, torna difícil adicionar recursos, aumenta o risco de bugs." Esse enquadramento é verdadeiro mas inútil para um CFO ou CEO tomando decisões de alocação de recursos. O enquadramento de negócio é diferente: "essa restrição técnica está desacelerando nossa velocidade de release em aproximadamente 30% em relação a onde deveria estar, o que atrasa nossa habilidade de responder a mudanças de mercado, e aqui está como o perfil de risco se parece se não abordarmos isso nos próximos dois trimestres."

O argumento de Fournier é que CTOs que não conseguem fazer essa tradução não conseguem o orçamento para corrigir o problema, o que significa que a dívida aumenta, o que significa que a penalidade de velocidade cresce, o que significa que o próximo argumento orçamentário é ainda mais difícil de ganhar. A tradução não é sobre simplificar questões técnicas complexas. É sobre reajustar em termos de consequências de negócio: tempo, risco, e velocidade. Essas são as três moedas que executivos realmente alocam. Gene Kim aborda o mesmo problema do lado de operações — sua First Way of DevOps reajusta gargalos de deployment como um problema de fluxo e restrição que CFOs e COOs podem se engajar, não apenas engenheiros.

Ela também é direta sobre o que acontece quando o CTO não consegue fazer esse argumento: a dívida se torna invisível para o negócio, a equipe de engenharia fica frustrada que preocupações técnicas legítimas são ignoradas, e a organização fica mais lenta sem entender por quê.

O Que Camille Fournier Faria em Seu Papel

Se você é um CEO, a coisa mais útil que Fournier oferece é um diagnóstico para a qualidade de gestão da sua organização de engenharia. A pergunta não é "temos bons engenheiros?" É "nossos gerentes de engenharia sabem qual é seu trabalho?" Se seu VP de Engenharia ainda está fazendo trabalho em nível de Director (gerenciando equipes diretamente em vez de gerenciar gerentes), sua capacidade em nível de Director está atrofiada ou inexistente. Se seus Directors estão fazendo trabalho de tech lead, seus tech leads não estão se desenvolvendo. O framework da escada lhe diz onde o sistema de gestão está preso, o que lhe diz onde a capacidade organizacional está sendo consumida pelo nível errado fazendo trabalho que deveria pertencer ao nível abaixo.

Se você é um COO, o framework de 1-on-1 de Fournier se aplica a toda equipe com uma hierarquia de gestão. A pergunta para fazer a seus gerentes: quando foi a última vez que um relatório o surpreendeu com uma renúncia? Se a resposta é "recentemente" ou "regularmente," seus gerentes estão executando reuniões de status, não 1-on-1s. O 1-on-1 é o único sistema de aviso antecipado que gerentes têm para risco de talento. Se eles não estão usando, você está operando às cegas sobre retenção até as pessoas saírem pela porta.

Se você é um líder de produto, o framework de débito técnico de Fournier é diretamente útil. Você está em um lado do conflito organizacional mais comum em empresas de produto: engenharia quer tempo para reduzir débito técnico e produto quer features. A razão pela qual esse conflito não se resolve é que nenhum dos lados está falando na linguagem do outro. O enquadramento de Fournier, traduzir débito em velocidade e risco, lhe dá um framework de decisão compartilhado. Em vez de "engenharia precisa de tempo para corrigir débito técnico" versus "produto precisa de features," você pode perguntar: "qual é o custo de velocidade de não abordar isso, e ele excede o custo de oportunidade de atrasar essas features?" Essa é uma pergunta com a qual ambos os lados podem se engajar.

Se você está em vendas ou marketing, a escada de gestão se aplica à sua própria organização. Todo gerente de vendas que foi promovido porque era o melhor rep carrega o risco de continuar fazendo vendas em vez de fazer gestão. O framework de Fournier lhe dá uma forma de verificar se seus gerentes de vendas estão realmente gerenciando: construindo pipeline em toda sua equipe, desenvolvendo reps que estavam lutando, executando forecasts que refletem julgamento em nível de equipe em vez de deals pessoais do gerente. O padrão de falha é o mesmo: promovido pelas habilidades que funcionavam no nível anterior, não equipado com as habilidades que o novo nível exige.

Como Rework Operacionaliza a Escada Fournier

A escada de Fournier apenas funciona se gerentes podem realmente ver a unidade de trabalho que corresponde a seu nível. Rework é construído para essa visibilidade. Pipelines de gestão de engenharia em Work Ops de Rework (a partir de $6/usuário/mês) deixam tech leads e gerentes rastrearem entrega em sua própria altitude — ICs veem tasks, gerentes veem throughput de equipe, directors veem fluxo cross-team — sem forçar todos em uma mesma visão. Templates de escada de carreira podem ser modelados como checklists estruturados por função, então a pergunta "o que esse nível realmente exige" tem uma resposta concreta que engenheiros e gerentes podem referenciar durante 1-on-1s e revisões de promoção.

Para tech leads, Rework suporta a transição exata que Fournier descreve: dashboards de team ops revelam se o lead ainda está carregando muito do código versus desenvolvendo seus engenheiros, e visibilidade cross-team deixa directors identificarem quando um gerente está pulando um nível — fazendo trabalho de IC ou executando o projeto eles mesmos em vez de através de sua equipe. CRM/Sales Ops de Rework (a partir de $12/usuário/mês) aplica a mesma lógica de escada para gestão de vendas, correspondendo ao ponto de Fournier que o padrão de falha se generaliza em qualquer hierarquia de gestão.

Citações Notáveis e Lições Além da Sala de Diretores

Fournier disse em várias talks: "Os melhores gerentes de engenharia que conheço são aqueles que podem claramente dizer a você o que não são responsáveis." Essa é uma declaração contraditória. A maioria do conselho de gestão é sobre expandir responsabilidade. Seu ponto é sobre clareza: um gerente que não consegue identificar as bordas de seu papel preencherá o papel com o que quer que se sinta confortável fazendo, que é geralmente o trabalho que costumavam ter.

De "The Manager's Path": "Como um gerente, seu trabalho é fazer o máximo possível o mínimo." Ela imediatamente clarifica: mínimo possível não significa esforço mínimo. Significa que o trabalho do gerente é criar condições onde engenheiros podem fazer seu melhor trabalho, não fazer o trabalho por eles. Toda task que um gerente tira do prato de um engenheiro forte que o engenheiro poderia ter manipulado é uma oportunidade de desenvolvimento perdida e uma dependência aumentada do gerente. O objetivo é uma equipe que funciona bem quando você não está lá.

Ela também foi direta em escrita pública sobre as limitações do livro: "The Manager's Path" foi escrito para empresas de produto com organizações de engenharia estáveis. Ela reconheceu que o modelo de escada fica complicado em organizações altamente matrixed ou firmas de consultoria onde linhas de reporte e escopo de projeto mudam constantemente. Isso não é um disclaimer. É uma borda útil para saber quando aplicar o framework e quando adaptá-lo.

Onde Este Estilo Falha

O modelo de escada de Fournier funciona de forma mais limpa em empresas de produto com hierarquia de gestão estável: empresas grandes o suficiente para ter uma camada de Director mas não tão grandes que o organograma tenha dezenas de estruturas de reporte concorrentes. Em firmas de consultoria, agências, ou empresas altamente matrixed onde linhas de reporte mudam com cada projeto, o enquadramento "aqui está o que o trabalho do seu nível é" luta porque o trabalho não é estável o suficiente para descrever precisamente.

E a profundidade do livro em transições de gestão individual pode obscurecer as questões de design organizacional que importam mais uma vez que você está no nível de CTO: topologia de equipe, divisão de platform versus product engineering, decisões de build versus buy. "The Manager's Path" o tornará um gerente muito melhor em cada nível abaixo de CTO. No nível de CTO, os problemas se deslocam de gerenciar pessoas bem para projetar o sistema em que trabalham. Esse é um livro diferente.

Para leitura relacionada sobre gestão de engenharia e liderança técnica, veja Estilo de Liderança de Will Larson, Estilo de Liderança de Gene Kim, Estilo de Liderança de Martin Fowler, e Estilo de Liderança de Jeff Dean.