- O líder de engenharia da Apple Michael Lopp enfatiza que, quanto mais entramos em uma era em que produtos podem ser criados rapidamente, mais importantes se tornam operações centradas nas pessoas e capacidade de julgamento
- “Quem toma as decisões, e como essas decisões são executadas?” é a verdadeira essência da engenharia
- Mais do que a capacidade de escrever código, organizações centradas nas pessoas e liderança determinam o desempenho da empresa
- Com base em experiências acumuladas em ambientes diversos como Borland, Netscape, Palantir e Slack, ele apresenta de forma concreta estrutura organizacional, cultura de colaboração e competências centrais de liderança
- Em vez de focar em liderança técnica, o destaque está em operação da organização, colaboração entre pessoas e compreensão humana
- Esta entrevista não é uma simples discussão técnica, mas se concentra em como desenhar organizações de engenharia sustentáveis e eficazes, oferecendo a fundadores e líderes técnicos conselhos práticos sobre a relação com times de produto, competências centradas nas pessoas e o que define um bom líder
Como desenhar a estrutura de uma organização de engenharia
- Mesmo em setores diferentes, ele aponta como fatores comuns de sucesso confiança na engenharia, crescimento rápido e contratação de pessoas talentosas
- Com base nisso, propõe três dicas práticas para montar uma organização de engenharia bem-sucedida
Dica #1: incentive o “Wolf Time”
- Divida o tempo dos engenheiros em 71% de trabalho efetivo / 29% de tempo livre para criar
- Os 29% são um “tempo impossível de medir e que não precisa ser justificado”, um espaço onde criatividade e iniciativa crescem
- Na Palantir, a tentativa de formalizar isso fracassou → encorajamento informal e comunicação funcionam melhor do que formalização
- Exemplo: propor um momento informal toda sexta-feira para compartilhar ideias
> “Se o time não perceber que esse tempo é permitido, vai acabar fazendo isso escondido entre reuniões, e nada vai florescer”
Dica #2: quanto mais regulares forem os debates, melhor
- Grandes produtos nascem da colaboração entre engenharia, design e produto
- Essa colaboração frequentemente envolve conflitos, mas é justamente esse debate que eleva a qualidade do produto
- É importante que haja discussões ativas no time sobre “é um problema de design, de produto ou de entendimento da funcionalidade?”
- Líderes devem incentivar o questionamento de opiniões não só de baixo para cima, mas também de cima para baixo
- Frequentemente há momentos em que debates entre fundadores e funcionários mudam o rumo da empresa
Dica #3: construa um sistema operacional escalável
- Bom julgamento + capacidade operacional são a base de um produto escalável
- Julgamento não é apenas chegar ao resultado, mas ter a capacidade de explicar “por que essa decisão foi tomada”
- Accountability significa ter uma história que possa ser relatada
- Para que o julgamento de poucos se expanda para o sistema inteiro, é preciso um processo claro
- Só de observar o processo de contratação já dá para ver a qualidade operacional (velocidade de resposta, clareza do cronograma etc.)
- Não ignore processos usando o fato de ser uma startup como desculpa → construir uma empresa é, em essência, construir operações
Como fortalecer a relação entre engenharia e produto
- A tensão e os mal-entendidos entre o time de produto e o de engenharia são uma história antiga, mas
lapidar bem essa relação é essencial para criar produtos de alta qualidade que também sejam escaláveis
- Um PM ruim faz com que engenheiros apenas sigam instruções sem senso de dono sobre o produto,
- Um bom PM ajuda os engenheiros a entenderem plenamente “por que estamos construindo isso”
- Lopp define engenheiros como pessoas do “como (how)” e PMs como pessoas do “porquê (why)”
- O time de produto deve levar a história do cliente e delegar a engenheiros e designers a forma de construir
- O ponto central é compartilhar o “porquê”
> Pergunte diretamente ao engenheiro, e não ao PM: “por que estamos construindo esta funcionalidade?”
- Se a resposta for “porque o PM mandou”, isso é motivo de indignação
- O verdadeiro problema não é necessariamente que o julgamento do time de produto esteja errado, mas sim que o engenheiro não entendeu o contexto
> “O engenheiro é quem constrói o produto com as próprias mãos. Uma organização em que essas pessoas trabalham sem entender ‘por que estão construindo isso’ está fadada ao fracasso”
- Quando perguntaram por que o Slack não tinha um recurso de bloqueio, Stewart explicou claramente a filosofia de que “é importante que a informação seja visível para todos”
- Compartilhando a visão de que se trata de uma questão de visão, e não de funcionalidade
- Um bom product manager deve ser capaz de contextualizar cada funcionalidade ou ideia dentro da visão geral do produto
- Isso é justamente parte do ‘why’ em que todos devem se concentrar
O que define um grande líder?
- Liderança de engenharia de verdade vai muito além de competência técnica
- “No fim das contas, liderança é a habilidade de lidar com pessoas”
-
Característica de liderança #1: tem flexibilidade (Malleability)
- Líderes trabalham com pessoas de perfis diferentes e precisam ser capazes de ajustar o próprio estilo de acordo com isso
- Ele reforça esse ponto usando como exemplo a própria experiência de liderar times de formas completamente diferentes no Pinterest e no Slack
- Para novos gestores, ele sempre faz a mesma pergunta: “O que você mudou depois de receber feedback?”
- A composição do time também não deve seguir critérios fixos, mas ser reorganizada com base em pontos fortes e fracos que aparecem no trabalho real em conjunto
- Para isso, ele faz reorganizações a cada 6 meses
-
Característica de liderança #2: excelente capacidade de contar histórias
- Ele demonstra forte rejeição a microgerenciamento: “Não há nada mais irritante do que ficar dando ordens a engenheiros”
- Em vez disso, o líder deve oferecer “Box e Soup”
- Box: o espaço preenchido com ideias e contexto
- Soup: a base de informações que as pessoas podem consumir ou combinar livremente
- Em vez de instruções, quando o líder oferece histórias que inspiram, as pessoas passam a julgar por si mesmas e a crescer
- Algumas pessoas dizem “só me diz o que eu tenho que fazer”, mas até isso no fim é interpretado à maneira delas
> O papel do líder é oferecer a sopa. Beber, ou decidir o que colocar nela, é escolha de cada um.
-
Característica de liderança #3: entende as motivações e objetivos das pessoas
- O líder precisa saber o que faz cada integrante crescer e se motivar
- Um exemplo: para um engenheiro movido por desafio técnico, ofereça oportunidades constantes de resolver problemas
- Outro exemplo: a assistente na Palantir deixou claro que sua motivação era centrada em recompensa → isso torna a gestão mais objetiva
- O essencial é identificar “a única motivação central” de cada pessoa e investir continuamente nisso
- Para isso, curiosidade e perguntas constantes de “por quê?” são indispensáveis
> O líder deve descobrir motivações que a própria pessoa talvez ainda não conheça e criar oportunidades de crescimento.
Conclusão: a essência da engenharia bem-sucedida é entender pessoas
- Organizações de engenharia bem-sucedidas dependem de uma dinâmica humana que funcione bem
- Grandes produtos não nascem de indivíduos brilhantes isolados, mas de grupos de pessoas que colaboram bem
- O papel do líder começa em dar poder às pessoas que compõem a organização
- “Times de engenharia são uma grande tapeçaria de seres humanos complexos e incríveis”
- O esforço para entender a estrutura e o fluxo dessa tapeçaria é a chave para fazer com que o valor do produto seja transmitido de forma eficaz por toda a organização
> “Quando você tem a motivação para entender como as pessoas interagem, sua empresa passa a estar pronta para entregar o valor do produto em escala.”
6 comentários
Existe um Slack para líderes técnicos administrado por Michael Lopp.
RLS - Rands Leadership Slack
Se você tiver interesse, vale a pena entrar. Atualmente, é um Slack enorme com mais de 36.000 participantes.
Para se inscrever, leia com atenção o conteúdo no link acima e envie um e-mail para o Lopp.
Nome/profissão/por que você quer entrar/onde ouviu falar do RLS/sua conta do LinkedIn ou Twitter etc.
Então, se contrataram um engenheiro caro, em vez de tratá-lo como um LLM só porque ele "fica escrevendo", ou ficar dando ordens como se fosse o Doraemon montando coisas num passe de mágica e dizendo até os mínimos detalhes do que fazer, a ideia é compartilhar apenas a sua visão e deixar que a abordagem de engenharia para implementá-la — que é justamente a especialidade dessa pessoa — fique por conta dela, certo?
Parando para pensar, por que isso me faz lembrar do vai e vem de discussões entre clientes e empreiteiros, construtoras ou arquitetos no interior da Coreia, quando alguém quer construir uma casa de campo ou reformar um apartamento antigo?
Nesse último caso, não seria um contexto um pouco diferente?
Reformar uma casa de campo ou um apartamento antigo,
antes de tudo, é uma área mais próxima de realizar um sonho pessoal do que de um negócio,
e, como estranhamente acontecem muitas situações em que se confia a obra a uma construtora/empresa de reforma e acaba-se levando uma rasteira...
Se o dono não fizer diretamente e mandar outra pessoa fazer, acho que vai acontecer a mesma coisa.
Por melhor que se explique, sempre há mal-entendidos, e por mais cuidadoso que se seja, sempre existem áreas que não foram previstas.
Se forem fazendo e perguntando um por um sobre as partes que o dono não explicou, isso toma muito tempo e é frustrante, então há muitas coisas que o especialista resolve por conta própria, e acho que é justamente aí que surgem muitos atritos.
Aliás, tenho inveja de você, parece que ainda não levou tantas facadas nas costas de empresas de SI.
Isso também me lembra o livro Modern Software Engineering que li recentemente. Ele também fala sobre equipes e organizações, não apenas sobre desenvolvimento em si.
Existem várias opiniões e métodos sobre liderança em engenharia, mas acho que todos concordam que a essência está em compreender as pessoas da equipe. Entender os membros da equipe é fácil de dizer, mas parece que isso exige construir confiança com base na empatia entre liderança e equipe por meio de feedback mútuo. Não é algo que se constrói de uma vez só. Obrigado pelo ótimo conteúdo, que dá bastante o que pensar.