A comoditização fracassada do trabalho técnico
(ludic.mataroa.blog)- A expectativa de gestores e vendors de padronizar o trabalho técnico como uma fábrica e transformá-lo em entregáveis reproduzíveis é grande, mas muitos ambientes ainda não conseguiram se commoditizar de forma estável desse jeito
- A operação ao estilo McDonald's está mais próxima de uma disciplina para fazer com que pessoas e locais diferentes produzam o mesmo resultado do que da qualidade em si, e vários livros de gestão também enxergam a operação de TI como esse tipo de fluxo produtivo
- A venda de software enterprise está mais próxima da promessa de substituir trabalho de SQL, dados e desenvolvimento por drag-and-drop e interfaces consistentes para tornar a mão de obra intercambiável
- Nas organizações reais, licenças ruins de software e abstrações mal feitas não resolvem problemas técnicos e, no fim, muitas vezes excelentes engenheiros precisam corrigir diretamente modelos de dados ruins e decisões técnicas equivocadas
- Trabalhos que exigem criatividade, gosto, especialização e conexão entre pessoas não podem ser totalmente reduzidos a quadros do Jira ou pontuações de Agile, e mesmo dentro de uma grande infraestrutura de produção são pessoas individuais que fazem o sistema funcionar
McDonald's mostra a dificuldade da padronização
- O meu primeiro gerente, que era um excelente engenheiro de dados, era alguém profundamente envolvido com culinária e elogiava repetidamente a complexidade da operação do McDonald's
- O valor do McDonald's está menos na qualidade do produto em si e mais na otimização e disciplina para que funcionários com níveis de formação e contextos regionais diferentes façam o mesmo hambúrguer
- Fazer com que mão de obra pouco qualificada em lugares diferentes entregue resultados consistentes não é algo simples, e esse caso leva à discussão sobre a comoditização do trabalho técnico
Livros de gestão tratam TI como uma fábrica
- The Phoenix Project coloca a operação de TI como um problema parecido com o trabalho de uma fábrica, com foco no fluxo de trabalho e na gestão da comunicação dentro da organização
- Livros com uma visão semelhante incluem The Unicorn Project, Investments Unlimited, The Goal
- The Goal é uma história sobre mudar a operação de uma fábrica real e é tratado como uma obra que inspirou os outros livros
- High Output Management também usa como exemplo a forma como o trabalho flui em um restaurante, explicando o fluxo de trabalho com a ideia de que, se você cozinhar os ovos no momento errado, a torrada estará fria quando chegar ao cliente
- Nessa linha de pensamento, temas como economia de escala, throughput e fluxo de trabalho aparecem repetidamente
O ponto central do pitch dos vendors é a substituição, não a tecnologia
- Em uma conferência de vendors, vários pitches de produto focavam menos nos detalhes técnicos e mais na promessa de entregar de forma reproduzível um resultado de trabalho bom o bastante
- Um produto específico era promovido dizendo que era possível definir dependências com um editor de drag-and-drop sem escrever SQL diretamente
- Na prática, como a aplicação se conecta ao Postgres, o SQL não desaparece; em vez disso, uma camada de abstração licenciada escreve o SQL no lugar da pessoa
- Esse tipo de pitch pode soar para executivos como a mensagem de que é possível substituir o “SQL lento e problemático” por uma interface consistente e especialistas de mercado na ferramenta, tornando mais fluida a entrega de dados dentro da organização
- A forma como Agile é implementado em organizações medianamente disfuncionais também revela um problema parecido
- É uma abordagem que conta engenheiros como máquinas, entregáveis como peças, story points como unidades de produção e depois verifica a taxa de cumprimento da meta da semana seguinte
Por que muito trabalho técnico ainda não foi commoditizado
- O McDonald's normalmente consegue entregar batatas fritas de qualidade previsível em cerca de 5 minutos, mas muitas organizações técnicas não conseguem entregar nada valioso e acabam comprando licenças ruins de software
- O caminho para resolver problemas técnicos e modelos de dados ruins com dinheiro se aproxima mais de garantir excelentes engenheiros focados apenas em resolver o problema
- Há muitas áreas que parecem passíveis de comoditização, mas na prática muitas vezes se trata de uma combinação entre empresas que vendem produtos que não funcionam e tomadores de decisão desinformados que os compram
- Alguns tomadores de decisão também podem optar por usar suporte telefônico em regiões de baixo custo em nome do cumprimento regulatório e sem se importar com clientes que querem cancelar
- Também é relatada a experiência de que, quando é preciso entrar em contato com o suporte, vale primeiro ligar para a linha de vendas para tentar ser rapidamente conectado a um responsável local com autoridade
No trabalho técnico criativo, o fator humano permanece
- Hammock Driven Development, de Rich Hickey, trata de um fluxo de trabalho em que a pesquisa é colocada no inconsciente e a resposta de design surge por meio de contemplação, meditação e sono
- Programadores frequentemente vivenciam o fenômeno de encontrar a resposta quando estão longe do problema, e isso é diferente de um trabalho de simplesmente produzir widgets mais rápido
- Na sociedade existem muitos trabalhos do tipo que precisam apenas ser feitos mais rápido, mas muitos resultados valiosos surgem no encontro entre a criatividade difícil de definir e a realidade da produção
- Em exemplos como livros, comida e operação de restaurantes, é possível refinar sistemas de produção em massa ou de entrega, mas resultados belos exigem gosto e cuidado
- Mesmo que se tente reduzir o desenvolvimento de funcionalidades a quadros do Jira e histórias de Agile, é difícil obter resultados valiosos sem conexão com as pessoas
- Como no caso de um conhecido que projeta chips para o iPhone, mesmo com infraestrutura de testes e produção em massa, pessoas individuais continuam sendo tão importantes que, se uma delas ficar doente, o próximo release pode atrasar
- A sociedade de fato funciona sobre a comoditização, mas não é possível operar trabalho técnico apenas com comoditização pura, ignorando o entendimento de um ofício específico e a complexidade, as necessidades e as vulnerabilidades humanas
1 comentários
Opiniões no Hacker News
Acho que o autor deixou passar que uma parte considerável do que antes era chamado de trabalho técnico agora foi comoditizada para uso geral
Antigamente, mala direta era literalmente imprimir um monte de etiquetas de endereço e colá-las à mão em cartas e envelopes; algo como o Word 2.0 resolveu esse problema nos anos 1990, e o MailChimp o transformou em produto no século XXI
Escrituração por partidas dobradas também era um trabalho técnico feito por pessoas altamente treinadas, mas hoje o dono da loja escaneia um código de barras e o cliente paga por aproximação
Ainda não existe uma interface de arrastar e soltar que sirva para algo mais complexo que Scratch, mas a parte difícil não é o trabalho técnico de costurar bibliotecas, e sim levantar requisitos
Inserir uma biblioteca de criptografia de alta qualidade, trazer um mapa interativo para um site ou editar um site em WYSIWYG ficou mais fácil do que nunca
O autor está certo no sentido de que não dá para sentar um jovem entediado de 18 anos na frente de uma IDE e mandá-lo criar um ERP, mas muita tarefa miúda de TI definitivamente virou produto
Vejo o trabalho miúdo da indústria de tecnologia aumentando, não diminuindo: hoje existe uma quantidade X de trabalho miúdo; surge uma nova tecnologia Z que reduz X para 0,1X, mas, ao mesmo tempo, Z viabiliza novas formas de trabalhar e, como subproduto, cria outro trabalho miúdo. Então o trabalho miúdo atual vira Y, e Y fica mais ou menos perto de X
Se o avanço tecnológico tivesse parado nos anos 2000, o trabalho miúdo originado nos anos 90 hoje estaria quase em 0, mas novas tecnologias trazem automação e trabalho miúdo ao mesmo tempo
Um exemplo recente são as ferramentas de IA. Existem ferramentas para gerar som, imagens, vídeo e texto, mas, para criar um produto ou experiência diferenciada, é preciso o trabalho miúdo de combinar ferramentas como ChatGPT e Stable Diffusion
Quanto mais se transforma em produto, mais o problema sobe para um nível de abstração mais alto, e os engenheiros especializados que você contrata também se deslocam para camadas mais altas da stack
Entre os produtos de startups que recentemente viraram SaaS, parece haver uma proporção alta de produtos que ainda não fazem de fato o que você quer. A lógica é cobrar para que usem o serviço, coletar os casos de uso dos clientes como alvos de implementação e depois transformá-los em produto para outros clientes, o que aumenta o lead time e ainda vaza propriedade intelectual
A criação de templates de SQL é algo que a liderança sempre entende errado. SQL sobreviveu por um tempo surpreendentemente longo no setor e, na prática, faz um trabalho bem bom. 99% dos wrappers ou DSLs colocados por cima dele o tornam muito pior, e qualquer tarefa minimamente fora do comum acaba tendo que descer para SQL. Em vez de contratar especialistas em SQL, você fica na situação de ter que formar especialistas em um inexistente wrapper SaaS/DSL de SQL X
O problema fundamental pode estar no fato de esses produtos serem projetados para parecer, aos olhos de compradores que não trabalham naquela área, eletrodomésticos do tipo “compre, plugue e o problema está resolvido”
Muitos produtos na verdade não resolvem o problema; só parecem resolver porque outras pessoas os compram. E você precisa mentir dizendo que a implementação foi um sucesso para conseguir ser promovido. Coisas como mala direta são realmente problemas já resolvidos, como uma chaleira; nesses casos, dá para tentar você mesmo e resolver
O problema maior é que meu empregador comprou o Workday acreditando que fosse algo como uma chaleira, mas não conseguiu corrigir o fato de que a nossa estrutura organizacional é tão horrível que nem dá para modelá-la
Este ano percebi pela primeira vez que, em uma grande empresa, uma estrutura organizacional suficientemente ruim é uma forma de dívida técnica. Você acaba fazendo todo tipo de coisa estranha para descobrir quem trabalha sob quem e o que este usuário pode ver neste banco de dados
Em comparação com 1994 ou 2004, quanto ficou mais simples tocar um negócio, criar um site, planejar uma viagem ou pagar contas hoje?
Às vezes parece que as gerações anteriores tinham um ritmo de vida mais tranquilo e, por isso, uma vida mais plena. Hoje o tempo passa rápido demais e o estresse é alto
Outro dia, no banco, vi pelo menos três pessoas com mais de 60 anos perdidas, sem conseguir resolver coisas simples, pedindo ajuda aos funcionários. Eram coisas que deveriam ser fáceis pelo internet banking, mas, por causa de casos de exceção, o sistema não dava suporte; no fim, elas tiveram que marcar um horário, e a data mais próxima era dali a 3 ou 4 meses
Uma delas precisava sacar dinheiro de uma conta bloqueada para comprar lenha e aquecer a casa, mas o funcionário do banco só dizia para esperar 3 meses
Dois anos atrás, meu pai não conseguiu encontrar uma forma simples de fazer uma ligação da Sicília para casa. Se fosse nos anos 1970, bastaria entrar em um bar próximo e colocar algumas moedas
Antigamente, uma pessoa comum conseguia consertar sozinha uma lâmpada, um carro, o aquecimento ou uma porta que não fosse automática; hoje é preciso chamar um especialista
Tentativas de transformar totalmente o trabalho técnico em commodity são uma má ideia, e espero que continuem fracassando
Dito isso, li The Phoenix Project duas vezes e detesto a maior parte do Scrum, mas não vejo o livro defendendo isso
O ponto central que tirei dele é ter um sistema claro para executar e gerenciar trabalho repetível e automatizar onde for possível; reduzir o trabalho em andamento para que as pessoas não fiquem presas a uma infinidade de tarefas; compartilhar informações amplamente e permitir que vários membros da equipe façam o mesmo trabalho; verificar se estamos de fato fazendo o que o negócio precisa; e reduzir ruído e trabalho não planejado para que os funcionários possam fazer trabalhos de alto valor, dos quais possam gostar, em vez de vagar por um pântano caótico
A essência de The Phoenix Project não é transformar pessoas em autômatos substituíveis, mas criar um sistema que lhes dê folga e tempo para fazer o trabalho realmente valioso que não pode ser automatizado nem sistematizado
Já administrei uma fábrica e também já fui desenvolvedor, então vejo os dois lados: não faz sentido transformar desenvolvedores em operários de linha de produção, mas trabalhos que se parecem com trabalho de fábrica, como tarefas conhecidas e etapas repetíveis, devem ser tratados de forma parecida
s/manufacturing/IT/ge atualizações com referências modernasNão quero dizer que odeio o livro. Li mais ou menos metade e tentei fazer as equipes o lerem para mudar o pensamento para uma visão centrada em sistemas. Só não diria que ele é muito mais profundo ou perspicaz que The Goal
Eu brinquei com o estilo da escrita, mas de fato valeu a pena ler. Não dá para culpar o pensamento à la Phoenix Project por muitas coisas que as pessoas fazem errado em tarefas conhecidas ou etapas repetíveis
Só que, em programação, é raro executar trabalho conhecido em etapas repetitivas. Quando isso acontece, muitas vezes é porque houve um erro tático na gestão de stakeholders e não sobrou tempo para automatizar
Uma leitura cuidadosa leva a conclusões como as do último parágrafo, mas sei com certeza que a maioria dos gestores que encontro não entende a diferença entre produção de widgets e projeto de sistemas
Aprendizado contínuo, automação e instrumentação são as ferramentas que viabilizam os itens 1 a 5 acima
Não recebi de The Phoenix Project a mensagem de “trabalhe mais duro para fazer mais coisas mais rápido”
https://scrumguides.org/scrum-guide.html
O que normalmente é horrível é a miscelânea de coisas que as pessoas colocam em cima dele e chamam de Scrum. A melhor forma de enfrentar Scrum fajuto não era brigar, mas fingir uma lealdade purista à doutrina real. Você parece menos do contra e consegue influenciar com mais facilidade
O título me confundiu. “Commodify” não significa “tornar vendável”, ou seja, comercializar? A tecnologia já não rendeu bilhões de dólares?
O que o autor parece estar falando é de commoditization, isto é, transformar o trabalho técnico em trabalho genérico que qualquer funcionário substituível possa fazer
Segundo https://en.wikipedia.org/wiki/Commoditization, dá para resumir assim: commoditization é quando algo proprietário se torna um bem comum, enquanto commodification é quando algo que não podia ser vendido passa a poder ser vendido
Estou sendo pedante demais? Eu achava que os dois tinham sentidos diferentes
Edit: olhando o Wiktionary, em https://en.wiktionary.org/wiki/commodification aparece que eles às vezes são usados de forma intercambiável. Parece ser só uma confusão comum
https://www.merriam-webster.com/dictionary/commodify
Significa “transformar algo, como valor intrínseco ou uma obra de arte, em commodity”, então commodify tem mais a ver com commoditization
O petróleo é uma commodity porque há muitos produtores e todos fazem a mesma coisa, então não importa de quem você compra
Na analogia do McDonald’s, o desenvolvedor não é o adolescente que trabalha na frente da máquina, mas sim o engenheiro que projetou a máquina. Nessa analogia, o computador é o adolescente
Programar não é trabalho, é metatrabalho. Depois que crio uma lista de instruções, o computador continua executando esse trabalho 24 horas por dia, e eu vou escrever uma nova lista de instruções para outra coisa
Se estou escrevendo a mesma lista de instruções duas vezes, basicamente estou fazendo errado. Por isso acabo sempre fazendo algo novo e, como não faço a mesma coisa duas vezes, fica difícil saber quanto tempo vai levar
TI não é uma fábrica; é o trabalho de construir fábricas
Acho que muitos conflitos entre desenvolvedores e gestores vêm do fato de a palavra “gestor” ser ampla demais. Um gerente do McDonald’s supervisiona se os funcionários seguem o processo que produz o produto. Fica claro quando o processo não é seguido, presume-se que o processo é válido, e também fica claro quando o resultado não foi produzido
Já um programador é contratado para desenvolver o processo que a máquina deve seguir. A pessoa que gerencia esse funcionário também pode ter um processo que o programador deve seguir, e pode ser claro se ele o está seguindo, mas é incerto se esse processo é válido, se uma ação específica levará ao resultado definido, ou se o próprio resultado é claro
Mesmo assim, ambos os papéis são chamados de “gestor”
Nessa analogia da máquina, o programador não gerencia pessoas; ele é outro tipo de gestor, que comanda máquinas. Só que essas máquinas são soltas no mundo, e o programador não fica vigiando o tempo todo
É claro que, como em outro comentário, também há a possibilidade de esse conceito ser uma completa bobagem. Mas, mesmo que daqui a alguns anos eu perceba que isso era uma ideia idiota, é melhor ter alguém para passar vergonha junto do que passar vergonha sozinho
Há cerca de 10 anos, alguns amigos engenheiros mecânicos ficaram surpresos ao ver que eu estudava desenvolvimento de software
Disseram coisas como: “Ainda há muito trabalho a fazer? Não dá para fazer tudo que é necessário com os sistemas existentes?”
O equívoco é achar que criar sistemas para resolver novos problemas é fácil e já foi comoditizado, então não há mais necessidade de escrever código
Na realidade, construir software raramente é tão fácil quanto configurar uma UI. É preciso texto para expressar regras lógicas e fluxos, é preciso controle de versão para acompanhar e reverter mudanças no sistema e, no fim, são necessários programadores
A codificação não desaparece; apenas sobe o nível de abstração
Acho que o setor de tecnologia tenta há muito tempo comoditizar os desenvolvedores, e COBOL e Java também fizeram parte desse movimento
Mas, seja qual for a abstração, há propriedades essenciais que voltam a aparecer. Mesmo quando os requisitos parecem simples e existem frameworks de alto nível, grande parte do nosso software ainda não funciona direito
Como diz o autor, a solução real são desenvolvedores competentes e cuidadosos. Dá para construir uma carreira em cima disso
Se você trabalha por muito tempo na mesma área, os padrões se repetem de forma parecida, mas cada negócio tem requisitos ligeiramente diferentes. Essa diferença cresce em cada camada da stack e, no conjunto, há uma quantidade enorme de trabalho não comoditizado e sob medida
É por isso que dois produtos não são exatamente iguais, e não existe uma única empresa gigante global produzindo tudo
Vi inúmeras vezes desenvolvedores ficarem empolgados quando surge uma oportunidade de autocomoditização, no sentido de dividir a si mesmos de forma taylorista
A área médica é o contraexemplo que costumo usar quando surge a discussão sobre comoditização automática. Há dois apelos emocionais. Pacientes não gostam de ser transferidos de um médico para outro. Entendem que a comoditização vem acompanhada de algum aumento de especialização e que, a cada passagem de bastão adicional, surge também mais um ponto de falha
O segundo é que dá para apresentar o status e o modo de trabalho como algo de status mais alto. Se você põe o primeiro argumento em primeiro plano e deixa o segundo como subtexto, normalmente funciona bem. Os trabalhadores mantêm competências mais generalistas e passam a depender mais de se consultar mutuamente do que de passagens de bastão
A linha de montagem é uma especialização sequenciada; basta olhar para erros de passagem de plantão relacionados às jornadas de residentes na medicina
Operação, inovação, manutenção. Escolha quaisquer três dos três
É melhor que o mesmo time, ou times muito próximos entre si, cuidem disso
Idealmente, cada pessoa do time deveria executar as três funções em graus variados. É daí que vem a inspiração para melhorias
Também dá para dividir essas três funções em três grupos e três camadas de gestão, mas o resultado costuma ser mediano e as pessoas ficam infelizes. Especialmente quem fica preso no time de manutenção faz um trabalho essencial, mas não recebe reconhecimento
Também dá para fazer um time ser responsável pelas três funções, mas muitas vezes se contrata um gestor superadaptado a uma delas. Por coincidência, essa uma é a função que leva a uma remuneração melhor no próximo trimestre
É difícil defender, dentro de uma só cultura, excelência operacional, manutenção diligente e tempo para pensar profundamente ao mesmo tempo. É natural que seja difícil
Ao observar o papel de business intelligence/analista, o setor tenta substituir pessoas que usam SQL por pessoas que usam ferramentas como Tableau
A ideia é algo como: “conecte a qualquer repositório de dados e pessoas não técnicas conseguem fazer com drag-and-drop”
Há alguns problemas. Primeiro, esquece-se que, como a produção só aumenta linearmente, é preciso contratar mais mão de obra de baixa remuneração. Como tudo é baseado em UI, alguém precisa girar a manivela manualmente
Segundo, ainda surge código de transformação de lógica de negócio extremamente complexo e desorganizado, só que agora enterrado dentro da UI. As únicas pessoas que sabem qual é essa lógica são PMs ou o time de negócio
A organização de engenharia fornece conjuntos de dados bastante primitivos, de alta qualidade e testados para responder a perguntas de negócio. A parte difícil era resolver como obter resultados de negócio a partir dos dados de origem por caminhos estranhos
Agora essa solução fica armazenada em uma workbook do Tableau e não pode ser usada como entrada em outro lugar. É preciso copiar e colar pela UI em uma nova workbook do Tableau
Como compraram o serviço em nuvem do Tableau, o time de BI até pode tornar extrações SQL mais rigorosas e mantê-las. O Tableau parece estar tentando abocanhar parte do negócio da Databricks, mas agora quem está fazendo esse trabalho é um time que não é de engenharia. Não sei se vai dar certo
Por exemplo, há a pergunta típica: “de que país são nossos usuários?”. Isso pode significar o país informado no formulário de cadastro, o país de onde estão acessando o serviço agora, o país do meio de pagamento, o país onde nasceram, o país de cidadania, o país onde residem atualmente, o endereço de entrega ou o endereço de cobrança — e tudo isso é diferente
Se o conjunto de dados for grande o bastante, cada uma dessas opções dará uma resposta diferente. No campo de “fintech global”, esses casos estranhos tendem a se tornar a norma
O usuário típico de Tableau de baixa remuneração provavelmente vai encontrar um código de país visível, rodar um count e declarar aquilo como verdade
Um usuário de Tableau um pouco mais esperto vai pedir a um engenheiro que escreva SQL
É preciso haver alguém que conheça o dataset e os sistemas de origem para questionar o negócio e impor a pergunta e o contexto corretos
Ferramentas do tipo Tableau são boas para substituir “trabalho técnico” como colar a mesma query SQL todos os dias no pgAdmin e enviar um CSV por e-mail, mas não fazem trabalhadores de baixa qualificação, guiados por UI, pensarem melhor
A escala linear da produção em relação ao custo pode ser modelada em planilhas e repassada ou cobrada do cliente. Todo mundo na camada de negócios se sente confortável com essa dinâmica
Por outro lado, uma situação em que um especialista dedicado pode produzir 1000 vezes mais com pouco esforço, mas ninguém sabe ao certo se levará um dia ou uma semana, deixa todos incertos e os líderes ansiosos. Se todo mundo quer uma mediocridade confortável, isso é difícil de vender
O item 2, ironicamente, passa a exigir mais especialistas — apenas de outro tipo. Afinal, toda essa lógica precisa ser mantida
No fim, isso funciona como um programa de empregos e ficará mais caro, mas vai distribuir valor proporcionalmente a feudos politicamente influentes, e por isso terá sucesso
Primeiro, demitem todos os backenders dizendo que eles não entendem o negócio e fazem do Tableau o novo backend. Ignora-se o fato de que as pessoas de backend vinham absorvendo e refinando requisitos de negócio
Depois, quando as pessoas de negócio ficam presas na teia caótica que elas mesmas criaram, chamam consultores de Tableau, que sugam dinheiro sem criar nada de valor
Venho da engenharia estrutural, e software me parece mais próximo de planejamento urbano do que de outras áreas da engenharia
É amplo demais. Com o tempo, não surpreende que surjam cada vez mais cargos diferentes para descrever tipos específicos de trabalho, como backend, frontend, firmware, engenheiro de machine learning, cientista de dados, analista de segurança e desenvolvedor de kernel
À medida que os padrões evoluem, acredito que em algum momento talvez seja necessária uma certificação muito específica para trabalhar nesses cargos. Pode assumir outra forma, mas o efeito de cristalização é claramente visível
Pensar em software como uma fábrica também é possível e pode ser útil. Mas nem tudo se encaixa nessa analogia. Por exemplo, quando se pensa em integração de produtos, ou quando se trata de um serviço, não de um app
Uma fábrica implica que algo é produzido, mas em muitos casos o software não é o resultado final; ele é o próprio meio que torna algo possível
Em software, a maior parte do trabalho foi sendo automatizada de forma assintótica. Por isso esquecemos que esse trabalho já foi, um dia, mão de obra
Basta pensar na humilde cópia de arquivos. É, por assim dizer, um “copista automático”
A cópia foi automatizada a ponto de a imensa quantidade de cópias que nossos sistemas realizam ficar invisível, e também desapareceu como ponto de diferenciação econômica
Além disso, ela é útil também em um nível meta. O próprio programa de cópia também é facilmente copiado pelo mesmo algoritmo
O ponto é que escrever software, assim como a matemática, acaba sempre passando tempo na fronteira entre o conhecido e o desconhecido. Isso porque todo domínio completamente conhecido e caracterizado é automatizado de uma forma que resolve o problema para todos e, ao mesmo tempo, queima o solo econômico daquela atividade
O trabalho em software sempre inclui, em qualquer domínio, um elemento de exploração — isto é, pesquisa — de entrar no desconhecido em busca de riqueza. Seja esse novo território glorioso ou tragicamente banal
As áreas que um gerente sem especialização em software consegue automatizar são como árvores frutíferas domesticadas para dar frutos fáceis de colher. Mas essas árvores já não têm mais frutos
Se a definição de problema desse gerente não subir novamente para um domínio difícil de automatizar, que exija a inconveniente criatividade e especialização, ele deixará de fazer algo diferenciado ou valioso