Ultimamente, tenho refletido sobre dois tópicos que compartilham um tema semelhante. O primeiro tópico tem a ver com a infraestrutura pública do estado da Califórnia e como ela se tornou ineficiente ao longo dos anos. A segunda é o fracasso das grandes empresas de tecnologia em inovar e executar mais rapidamente do que as startups estabelecidas. Deixe-me fornecer algumas perspectivas sobre por que esses tópicos estão relacionados, primeiro dando a você dois exemplos para pensar:

• Infraestrutura : A Golden Gate Bridge levou cerca de quatro anos para ser construída (1933–1937) e nos custou aproximadamente US$ 500 milhões em dólares de hoje. Por outro lado, o SDS ( Sistema de Dissuasão do Suicídio ), que basicamente adiciona uma rede ao redor da ponte, levará cinco anos para ser concluído (2017–2023) e está projetado para nos custar ~ $ 217 milhões. Se você fizer uma revisão dos principais projetos de infraestrutura na Califórnia, descobrirá que, para os projetos concluídos antes da década de 1950, o trabalho foi feito mais rápido, mais barato e com maior qualidade do que é feito hoje em pelo menos 5 vezes a magnitude, embora hoje temos mais capital, melhor tecnologia, melhores matérias-primas e um número absoluto maior de engenheiros civis e arquitetos.
• Empresas de tecnologia : a Adobe, apesar de todos os seus recursos financeiros e humanos, precisa adquirir um concorrente por US$ 20 bilhões. Ainda não se sabe se a Adobe pagou demais pelo Figma, mas a questão mais interessante é por que uma empresa com 100x mais pessoal, 100x mais experiência em ferramentas de design e 100x o capital financeiro não conseguiu vencer?

Da mesma forma, se você der uma olhada nas empresas, poderá descobrir que, à medida que crescem, processam e incham se infiltram em qualquer coisa e sufocam o trabalho e a inovação reais. Nesse ambiente, os funcionários que estão mais ansiosos para criar coisas, os fabricantes, descobrem que é mais atraente pular do navio para um lugar menor onde seu trabalho tenha uma saída para se materializar. Tanto as falhas de infraestrutura quanto as falhas de inovação da empresa são, pelo menos em parte, devidas ao inchaço e à lentidão do processo.

Por que ocorre a fluência do processo?

Todo processo começa com boas intenções.

• “Queremos garantir que todas as partes interessadas contribuam para o trabalho final, portanto, todas as propostas de projeto enviadas precisam ser revisadas pelas equipes jurídicas, de design, produto e engenharia.”
• “Queremos garantir que grandes projetos de infraestrutura não causem danos, por isso precisamos realizar estudos ambientais completos antes de iniciar qualquer trabalho.”
• “Queremos minimizar as violações de dados, portanto, qualquer solicitação de dados precisa ser feita por meio das equipes de TI e Segurança.”

O caminho para o perfeccionismo

Lembro-me de ouvir um gerente bem-intencionado dizer a seus subordinados diretos para escrever um software como se fosse durar 100 anos. Embora a observação fosse hiperbólica, o conselho ecoa algo que já ouvi com frequência na indústria de tecnologia por meio de ditados como “meça duas vezes e escreva uma vez” ou “se você não tem tempo para fazer direito, você tem tempo para fazer duas vezes?.” Este não é um mau conselho. Em algumas situações, você precisa escrever código como se fosse durar 100 anos, e ir de cabeça para a execução sem planejamento é um desperdício. No entanto, a ênfase extrema no planejamento pode levar à paralisia e falha em reconhecer os benefícios do aprendizado por meio da iteração. Eu preferiria viver em um mundo onde o software é reescrito todos os anos porque há um forte reconhecimento de que a perfeição não existe e que o pré-requisito para a evolução é a mudança, em vez de um mundo onde as coisas rodam em “ códigos de 50 anos ”.

muita cola

Muitos anos atrás, li a postagem no blog de Tanya Reilly sobre ser Glue (leitura altamente recomendada, aliás). Nesse ponto da minha carreira, o conteúdo realmente ressoou porque eu estava lidando com alguns colegas que, embora tecnicamente competentes, simplesmente não estavam trabalhando nas coisas certas. As pessoas da cola se envolvem em um processo de liderança técnica e orientação que leva a tornar outras pessoas da equipe mais produtivas. Alguma quantidade de cola é necessária, no entanto, descobri que muita cola cria uma série de outros problemas:

• As pessoas que trabalham com cola impedem que outras pessoas melhorem suas habilidades não técnicas. Por exemplo, um líder técnico que não permite que sua equipe fale sobre seu trabalho ou muitas vezes age como um “tampão” está essencialmente tirando oportunidades dos ICs para lutar e, eventualmente, melhorar suas habilidades de comunicação.
• Versões extremas e tóxicas do comportamento de cola às vezes se manifestam em assumir o crédito pelo trabalho de outras pessoas ou em gerar atribuição grosseiramente exagerada (“por exemplo, sem eu atuar como intermediário, o projeto não teria sucesso”). Enquanto Tanya fala sobre as situações em que as pessoas do Glue muitas vezes não são reconhecidas, minha experiência é completamente oposta. Como o pessoal do Glue é um bom comunicador, eles sabem como anunciar seu trabalho e fazer política bem. Em troca, eles acabam com maior visibilidade e mais oportunidades de promoção, enquanto o engenheiro que trabalha nos detalhes da implementação geralmente recebe reconhecimento simbólico ou nenhum crédito.
• Por fim, adicionar muitas pessoas de cola reduz a propriedade e a responsabilidade de engenheiros individuais. Em vez de adicionar pessoas de cola para gerenciar uma equipe tecnicamente competente, eu simplesmente dispensaria engenheiros que parecem não ter intuição de negócios, falta de habilidades de comunicação ou não conseguem montar um parágrafo descrevendo por que o trabalho que fazem é impactante. Sugerir que você precisa de mais cola para gerenciar engenheiros acaba descartando o padrão geral de que pessoas que são tecnicamente brilhantes também têm um alto nível de inteligência geral, leem muito, são aprendizes vitalícios e são muito bons em negócios e não apenas em código.

Quando eu estava na Novell, aprendi que havia pessoas que eu chamo de “pessoas que colam”. As pessoas da cola são pessoas incrivelmente legais que se sentam nos limites intersticiais entre os grupos e ajudam nas atividades. E eles são muito, muito leais, e as pessoas os amam, e você não precisa deles.

Na Novell, continuei tentando me livrar desse pessoal da cola, porque eles estavam atrapalhando, porque atrasavam tudo. E toda vez que eu me livro deles em um grupo, eles aparecem em outro grupo, são transferidos, são recontratados e tudo mais.

Entropia

À medida que as organizações crescem, o conhecimento institucional, o número de partes interessadas, as bases de código e a entropia aumentam. O aumento da entropia leva a alto desperdício, alta carga cognitiva, desorganização e caos.

Como engenheiros de software, acho que fizemos um péssimo trabalho no gerenciamento da complexidade. Por exemplo, há anos ouvimos que monólitos são ruins porque geram bases de código inchadas, dificultam as implantações ou criam problemas de escalabilidade. No entanto, no outro extremo, onde temos que operar em um mundo de microsserviços, descobri que, para enviar coisas básicas, preciso operar em várias bases de código escritas em linguagens diferentes, cada uma com suas peculiaridades de implantação e padrões de arquitetura, com o todo paradigma se transformando em espaguete lambda . Parar e focar no que é importante tem um grande impacto na redução da entropia. Em um nível baixo, orientado para a ação, pode se manifestar da seguinte forma:

• Excluindo código morto que não é executado na produção. Eu interagi com tantas bases de código onde mais de 50% do código era código morto e criava carga cognitiva para colegas. Eu gostaria que houvesse algo no espaço de produtividade do desenvolvedor que gerasse cobertura de código com base nas linhas executadas na produção. A cada trimestre, você para e revisa esses relatórios e simplesmente exclui os arquivos que não tiveram execução.
• Como gerentes de produto, não refletimos o suficiente sobre quais recursos devemos eliminar ou reverter. No entanto, parar e refletir sobre o que deve ser excluído pode ser muito significativo para simplificar e melhorar a experiência do usuário. Eu me considero conhecedor de tecnologia, mas acho que muitos dos produtos criados hoje foram hiperotimizados em um conjunto de usuários existentes, levando a uma experiência de UX confusa e confusa para novos usuários. Perguntar no final do trimestre “Qual recurso podemos cancelar o envio?” pode ser útil para reduzir a desordem.

O ego é o inimigo

Ryan Holiday sugere em seu livro Ego is the Enemy, que existe uma forte “tentação que existe para todos – que a conversa e o hype substituam a ação”. O ego é uma grande razão pela qual o progresso e a inovação podem ser medíocres em muitas instituições. Aqui está como o ego se manifesta:

• Ver as mesmas pessoas ansiosas para lançar seus pensamentos em uma conversa em grupo, mesmo que suas ideias agreguem nenhum ou muito pouco valor marginal.
• Ter pessoas que nunca se envolvem em patrocinar ativamente seus colegas ou que tentam acumular visibilidade. Se você é um gerente ou um gerente de gerentes, pode perceber isso ao ver com que frequência seu subordinado direto fala sobre o sucesso ou as contribuições de outras pessoas em seus 1:1s. A falta de reconhecimento ou patrocínio altruísta de outras pessoas pode ser um sinal de um ego doentio.
• Otimizando para a equipe em vez da empresa ou organização como um todo. Peguei emprestado o diagrama do Staff Engineer's Path de Tanya Reilly e ele exemplifica perfeitamente esse problema em que as equipes otimizam para o máximo local. Por exemplo, você concordaria em dissolver sua equipe e redistribuir funcionários para outras equipes se dentro de seu domínio você estiver entrando no modo de manutenção? A maioria dos gerentes nunca faria isso porque significaria perder qualquer capital social e político dentro da empresa.

• Dependendo da sua função, existe uma dicotomia muito forte em termos de como você vê o valor das reuniões. “ As pessoas mais poderosas estão na agenda do gerente ”. Infelizmente, sua percepção do valor das reuniões cria uma substituição cultural que afeta as pessoas que preferem ter tempo ininterrupto para pensar sobre um problema e uma solução. Mesmo para fins de brainstorming, as evidências sugerem que o brainstorming em grupo é uma perda de tempo . No entanto, por que tantas organizações inchadas acabam gastando metade do tempo dos ICs em reuniões?

Conclusão

O motor da inovação depende da mudança evolutiva. Em última análise, se uma instituição se tornar rígida e não se adaptar à mudança, ela terá uma morte lenta. Na minha experiência, a introdução de um processo geralmente tem custos não intencionais que levam à redução da velocidade. Em vez disso, eu me concentraria no seguinte:

• Favorecer a iteração e aprender com os erros em vez de tentar alcançar o perfeccionismo.
• Pessoas de cola são necessárias, mas tem que haver um limite para o seu número, para que possam atuar com grande alavancagem. Simplesmente contratar pessoas que sejam tecnicamente competentes e tenham boa intuição de negócios pode resolver a necessidade de contratar demais para funções de cola.
• Por fim, eu me concentraria em reduzir a entropia perguntando constantemente o que pode ser descartado e recompensando as pessoas por comportamentos que aumentam a simplicidade.