Engenharia sem ego: lições e insights
Introdução
- Na indústria de tecnologia, ego e paroquialismo (facciosismo) costumam ser fatores centrais que atrapalham o trabalho em equipe
- Compartilho insights obtidos ao refletir sobre como tornar equipes de engenharia mais eficientes e colaborativas
O dilema da distribuição de responsabilidades
- Mesmo com apenas dois funcionários, distribuir o trabalho é indispensável
- Porém, a forma dessa distribuição pode ter impactos imediatos e de longo prazo
- Muitas empresas não pensam profundamente sobre esse problema
A realidade da ciência da computação
- Muitos cientistas da computação só percebem depois que entraram em um campo ligado a trabalho abstrato matemático
- Esse choque inicial faz com que muitos passem a maior parte da carreira sem querer aplicar o que aprenderam a áreas fora dos computadores
- Haveria potencial de melhora se pensassem o ambiente de trabalho com a mesma profundidade com que abordam questões técnicas
Disfunções organizacionais e experiências
- Mesmo empresas bem-sucedidas dificilmente escapam de disfunções organizacionais, e é possível aprender com isso
- Exemplo de uma startup do início da carreira do autor:
- Apesar de estar em estágio inicial e ainda ser pequena, a empresa já havia adotado uma estrutura excessivamente burocrática
- Foi adicionada uma "camada intermediária em Python" com base na teoria equivocada de que isso aumentaria a velocidade das requisições web
- Como resultado, mais hops de rede foram introduzidos e o desempenho piorou
- Para lançar uma única funcionalidade, era necessária uma colaboração complexa entre vários papéis
- O pessoal de banco de dados escrevia DDL e desenvolvia stored procedures
- Os desenvolvedores Python trabalhavam na camada intermediária ineficiente
- Os desenvolvedores PHP escreviam o código de frontend
- Com essa estrutura de divisão de trabalho, nenhum recurso novo foi lançado durante dois anos
- Resultado
- Como consequência da estrutura e do workflow ineficientes, todos os funcionários foram demitidos
- Eu não. Sobrevivi por reclamar
O problema da diferenciação de papéis em grandes empresas
- Contexto: trabalho em uma empresa de produto B2B com mais de 1.000 funcionários
- No início, operava com uma estrutura de feature teams com papéis claramente divididos e times de serviços compartilhados (operações, DBA etc.)
- A princípio, parecia uma estrutura comum
- Com o tempo, os papéis foram se fragmentando demais e a ineficiência aumentou
- Foi criado um novo papel chamado "Release Manager" para gerenciar releases
- A razão para adicionar esse papel não era clara, e a estrutura organizacional foi ficando cada vez mais complexa
- Exemplos de problemas:
- Engenheiros de frontend eram limitados a trabalhar apenas em frontend, e engenheiros de backend apenas em backend
- Essa separação até conseguia se sustentar, mas a política de colocar todo o trabalho de segurança nas mãos do time de segurança gerou problemas graves
- Resultado: ao equiparar papel e tarefa, a eficiência da organização foi prejudicada
- Houve falta de colaboração entre times e duplicação de trabalho
Portfólio de produtos disperso e ausência de uma estrutura de supervisão
- Trabalho em uma empresa que desenvolve principalmente aplicações cliente nativas
- No começo, havia um aplicativo cliente principal de sucesso, mas nos anos 2020 projetos dispersos e inconsistentes passaram a avançar em paralelo
- Problemas na gestão do portfólio de produtos
- A estrutura de supervisão do conjunto dos produtos era fraca
- Não havia qualquer coordenação entre produtos em stack tecnológica ou tomada de decisão
- Cada equipe de produto reportava diretamente ao CEO de forma independente, e o CEO não fazia esforço de coordenação
- Tentativa de criar funções operacionais compartilhadas
- Surgiram dificuldades porque o grupo de operações não participava do processo de decisões de arquitetura
- O time de operações estava ocupado administrando centenas de serviços usados historicamente pelos times de desenvolvimento e não tinha tempo para participar de decisões importantes
- Esse pode ser visto como um caso típico de ineficiência organizacional
[Generalizando padrões de problemas organizacionais]
Padrão 1: confusão entre papel e tarefa
- Há uma tendência a criar uma nova descrição de cargo para cada novo tipo de trabalho
- Exemplo: mesmo quando o trabalho relacionado a IA poderia ser tratado por engenheiros existentes, cria-se um novo papel de engenheiro de IA
- Isso gera conflito dentro da organização e pode enfraquecer a motivação dos membros já existentes
- Essa separação excessiva de papéis leva a burocracia desnecessária
Padrão 2: a distribuição incompleta da revolução DevOps
- Muitas empresas afirmam ter "implementado DevOps", mas na prática a divisão de trabalho e os conflitos continuam existindo
- Fronteiras claras entre time de operações e time de desenvolvimento, ou entre SRE e desenvolvimento, atrapalham a colaboração
- O objetivo original de DevOps era derrubar barreiras por meio de colaboração e empatia, mas isso raramente se concretiza no mundo real
Padrão 3: os limites de uma divisão rígida do trabalho
- Fragmentar e especializar o trabalho pode parecer natural para líderes
- Exemplo: trabalho de IA fica exclusivamente com especialistas em IA, e trabalho de operações exclusivamente com o pessoal de operações
- Mas essa estrutura provoca gargalos
- Engenheiros adicionados tentam acelerar o andamento criando novas tarefas, mas o resultado é que o tempo de espera por análise aumenta de forma não linear
- Quando cientistas de dados ou recursos de análise chegam ao limite, o processo inteiro desacelera
Padrão 4: estruturas organizacionais erradas geram trabalho extra
- Quando as fronteiras organizacionais não são claras ou são mal definidas, a carga de trabalho desnecessária aumenta
- Exemplo: o time de segurança assume todos os problemas de segurança, criando uma fila de tickets de segurança
- Os times de desenvolvimento seguem trabalhando sem considerar segurança, e como resultado o trabalho de segurança aumenta
- Isso pode ser ignorado no curto prazo, mas no longo prazo evolui para um problema sério
Padrão 5: vieses humanos persistentes
- Há uma tendência de superestimar o próprio papel e subestimar o papel dos outros
- Algumas pessoas concluem equivocadamente que trabalho de servidor "não é técnico"
- Em contrapartida, também é comum tratar trabalho de produto como menos técnico
- Essa atitude enfraquece a confiança entre times e prejudica a colaboração
- "Figuras brilhantes e dogmáticas" não entregam valor real de uma perspectiva sistêmica
- Líderes e organizações muitas vezes avaliam esse comportamento de forma equivocada como algo "inteligente" ou "valioso"
[Facciosismo e ego]
- Paroquialismo (Parochialism) e ego (Ego) são causas centrais de ineficiência dentro das organizações
- Paroquialismo: atitude de não querer invadir a área dos outros ou falta de curiosidade sobre o trabalho alheio
- Ego: pode ter efeito positivo como orgulho pelo trabalho, mas também pode se manifestar negativamente na defesa de território ou na subestimação da capacidade dos outros
- Esses comportamentos instintivos geram falta de empatia e prejudicam a colaboração
Um caso melhor: a experiência de uma equipe de engenharia bem-sucedida
- Em uma startup anterior, a estrutura horizontalmente separada em "feudos" foi simplificada e reorganizada em equipes menores
- Líderes que levaram DevOps a sério derrubaram barreiras e promoveram colaboração
- Ao longo de cerca de dois anos de "destruição criativa", todos os membros da equipe passaram a participar de vários tipos de trabalho
- Como resultado, a estabilidade da infraestrutura e a capacidade de lançar software foram recuperadas
- Após a reorganização, a equipe de engenharia ganhou tempo e autonomia
- Com isso, passou a discutir como utilizar a capacidade adicional da equipe
Proposta 1: grandes refatorações (Proposition 1: Boil the Ocean)
- Com frequência, equipes usam recursos ociosos para refatorar em larga escala partes de que não gostam
- Mas esse já era um método tentado e pouco popular
Proposta 2: atividades de "autoexibição" (Proposition 2: Dress Like Big Dorks)
- Tentativas como usar o tempo ocioso da equipe para produzir brindes que reforçassem a cultura do time
- Mas isso não era adequado como estratégia principal
- Incidente decisivo: erro de build de uma designer
- No meio da noite, uma designer quebrou a build, e a equipe teve de restaurá-la
- No início, surgiu a opinião de que seria melhor separar com mais clareza os papéis de designer e programador
- No entanto, alguém da equipe tomou a decisão ousada de entregar diretamente à designer a chave de deploy
- Resultado:
- A designer passou a participar do trabalho de código, e o nível de colaboração melhorou
- A equipe construiu monitoramento, test suite e outros mecanismos para criar um ambiente de trabalho seguro
- A eficiência e a produtividade melhoraram muito
Proposta 3: fortalecer a capacidade das outras equipes (Proposition 3: Empower Everybody Else)
- Foi adotada uma estratégia de usar a capacidade ociosa da equipe para apoiar e fortalecer outras equipes
- Aplicável tanto a equipes técnicas quanto não técnicas
- Isso promoveu colaboração em toda a organização e levou a uma execução mais eficaz
Vontade de colocar em prática
- Depois do caso da designer, experiências semelhantes de sucesso ocorreram em colaboração com vários grupos
- O tempo livre e a autoridade organizacional da equipe foram usados para ajudar cada equipe a colaborar de forma eficaz
- A execução bem-sucedida se baseou em colaboração e empatia em escala organizacional
[A sensação de uma execução bem-sucedida]
- Especialistas vs. proprietários
- A equipe mantinha especialistas de domínio, mas não "proprietários" de tarefas ou domínios específicos
- Exemplo de segurança: em vez de o time de segurança resolver todos os problemas, a equipe inteira assumia responsabilidade pela segurança, enquanto o time de segurança atuava elevando a capacidade dos demais
- Esse modelo deveria ter sido aplicado também em outras áreas, mas a maioria das equipes não conseguiu realizá-lo
- Exemplos de fracasso
- Separação rígida entre engenheiros de frontend e backend
- A falta de colaboração levou a complexidade desnecessária, como GraphQL
- Especialistas em determinados papéis são necessários, mas dividir títulos em "frontend" e "backend" é ineficiente
- Princípio central:
- "Especialistas de domínio, não proprietários"
- Incentivar especialistas a terem tempo para ajudar outros membros da equipe além do próprio trabalho
Promoção de colaboração proativa
- Oferecer folga de capacidade
- Conceder tempo de sobra aos membros da equipe para manter o trabalho em equipe como um todo
- Em vez de apenas esperar por uma colaboração espontânea, injeta-se vitalidade no sistema de forma deliberada
- Segurança psicológica e ampliação do grupo de pertencimento
- As pessoas se sentem psicologicamente seguras no grupo ao qual pertencem e, por isso, experimentam e aprendem coisas novas ali
- Investe-se tempo e recursos para ampliar o "grupo interno" dos membros da equipe
- Bootcamp: trabalhar à força em outro time para criar oportunidades de colaboração
- Hackathon: usado como evento com efeito semelhante
Valores intencionais da equipe
- Estabelecer a filosofia e os princípios do time
- Definir com clareza os objetivos mais altos de várias atividades, como code review, bootcamp e hackathon
- Declarar que o elitismo é veneno
- Construir uma cultura em que todos "fazem diretamente o trabalho necessário"
- Confiança mútua e expectativa de melhoria
- Estabelecer uma forte expectativa de que, ao lidar com o trabalho de outra pessoa, ele sempre será deixado em melhor estado
- Essa cultura faz com que os membros colaborem de boa vontade
Considerações finais
- Problema da indústria de tecnologia: elitismo e liderança dogmática
- Líderes dogmáticos sem humildade prejudicam a colaboração da equipe e incentivam crueldade desnecessária
- A indústria de tecnologia frequentemente confunde esses líderes dogmáticos com pessoas úteis, mas isso é um fenômeno parasitário e nocivo
- Não deveria ser radical agir com respeito pelos outros, mas na prática muitas vezes é
- A colaboração traz resultados melhores
- A colaboração melhora os resultados, e a vida é melhor sem líderes dogmáticos
- É preciso esforço para eliminar o facciosismo e o ego
- A importância de dar autonomia
- Para encorajar os membros da equipe a colaborar com curiosidade, é preciso permissão e apoio da liderança
- Exemplo: mudar o processo para que desenvolvedores façam deploy diretamente, em vez de deixar isso apenas para SREs
- No começo, houve preocupação com erros dos desenvolvedores, mas a maioria resolveu os problemas por conta própria e a experiência foi bem-sucedida
- Engenheiros de produto mostraram disposição para resolver os próprios problemas
- Dar folga ao sistema (slack)
- Programas como bootcamp e hackathon exigem comprometimento contínuo
- Esses programas tendem a desaparecer quando não há folga no sistema
- Não operamos computadores a 100%, mas tendemos a tentar operar a nós mesmos assim
- A importância de valores e recompensas
- Líderes devem recompensar colaboração e curiosidade e consolidá-las como cultura da equipe
- CEOs muitas vezes tentam eliminar programas positivos (bootcamps, hackathons), mas fazem menos esforço para eliminar programas negativos (code review obrigatório)
- É preciso abandonar a crença equivocada de que "dor" produz resultados
- Dor não é um bom indicador substituto de resultado, e colaboração e confiança trazem desempenho melhor
7 comentários
> Para incentivar os membros da equipe a colaborarem com curiosidade, é necessária a permissão e o apoio da liderança.
Parece muito importante incentivar as pessoas a terem curiosidade também pela área dos colegas de equipe, e não apenas pela própria área!
A realidade é...!
Parece uma estrutura impossível em startups "wejail" que pressionam por progresso todos os dias..
Todos os profissionais da linha de frente precisam conseguir manter o interesse do início da contratação, mas nesse aspecto normalmente não há apoio, ou ele é insuficiente.
Tudo o que foi dito está certíssimo..
Mas a realidade é.................. T_T
Parece um texto realmente muito bom!
Ótimo texto.
Comentários do Hacker News
Há quem defenda que é importante deixar o ego do programador de lado no desenvolvimento de software. O ideal é enxergar o produto de software como um resultado da equipe, construído em trabalho conjunto.
Como lição aprendida ao longo da carreira em desenvolvimento, há o conselho de não adicionar processos desnecessários, exigir senso de dono sobre o produto em todas as funções, evitar decisões reativas e incentivar a colaboração entre equipes.
As melhores equipes são formadas por times "pizza" que dominam a stack inteira e por especialistas que oferecem orientação quando necessário.
Embora metáforas esportivas não sejam populares na área de tecnologia, há a visão de que a dinâmica de equipes esportivas é parecida com a de boas equipes de negócios.
O sucesso de uma organização depende de cada integrante agir de forma altruísta para atender às necessidades do grupo.
Destaca-se a importância de definir valores de equipe de forma intencional.
Trabalhando em uma área de growth, no início o gerente revisava e fazia merge de todos os commits, mas depois veio a percepção de que já havia permissão para fazer deploy em produção por conta própria.
Especialistas no domínio são preferíveis a donos do domínio, e uma especialização excessivamente explícita pode causar problemas.