- A ideia central de “Seeing Like A State” de James C. Scott é que as organizações tentam aumentar a “legibilidade” dos sistemas, transformando tudo para que possa ser medido e reportado
- Porém, na prática, o “trabalho ilegível”, que não pode ser rastreado nem previsto, é essencial, e focar apenas na legibilidade pode acabar reduzindo a eficiência
- Em especial, grandes empresas tornam o trabalho legível por meio de processos como planejamento trimestral, OKRs e Jira, mas isso paradoxalmente reduz a eficiência, e empresas pequenas podem ser 20 vezes mais eficientes do que grandes corporações
- Para responder a situações urgentes, as organizações permitem áreas temporárias de ilegibilidade, como “tiger teams”, e a colaboração informal por meio de backchannels entre engenheiros desempenha um papel tão importante quanto os processos oficiais
- O sucesso das empresas de tecnologia depende de manter o equilíbrio entre processos legíveis e o trabalho prático ilegível, e a organização não funciona direito com apenas um dos dois
Introdução: a ideia central de “Seeing Like A State”
- A ideia central do livro “Seeing Like A State”, de James C. Scott, pode ser resumida em três pontos
- Organizações modernas transformam sistemas em formas de “legibilidade” máxima, para controlar tudo de modo que cada parte possa ser medida e reportada
- Mas essas organizações dependem de uma enorme quantidade de trabalho “ilegível”, ou seja, trabalho essencial que não pode ser rastreado nem planejado
- Aumentar a legibilidade frequentemente prejudica a eficiência, mas outros benefícios disso, como controle, planejamento e transparência, são vistos como muito valiosos
- Legibilidade é o trabalho previsível, cujo resultado pode ser rastreado e que não depende de pessoas específicas. Exemplos: gestão de cronograma, OKRs, Jira etc.
- Ilegibilidade é o trabalho improvisado ou baseado em conhecimento tácito: colaboração que não pode ser documentada ou formalizada, mudanças repentinas, trabalho dependente de relações humanas etc.
O caso de “Seeing like a state”
- Scott usa o exemplo da “floresta ordenada” da Alemanha do século XIX para explicar a tentativa das organizações de controlar e padronizar em nome da eficiência
- Havia a expectativa de que, ao administrar a floresta de modo que todas as árvores pudessem ser vistas de uma só vez, seria possível aumentar a eficiência do planejamento, das transações e da alocação de recursos
- Na prática, a diversidade da floresta e o papel da vegetação inferior foram ignorados, a produtividade caiu e a floresta ficou mais vulnerável a doenças e parasitas
- Em outras palavras, buscava-se eficiência e transparência ao mesmo tempo, mas a busca excessiva por legibilidade acabou prejudicando justamente a eficiência
Legibilidade e ilegibilidade em empresas de software
- Em empresas de software, acontece a mesma coisa: equipes pequenas ou indivíduos podem ser mais eficientes
- Entre engenheiros de software, é quase senso comum que um único engenheiro trabalhando sozinho pode ser mais eficiente do que quando trabalha como parte de uma equipe
- Trabalho conduzido por engenheiros avança muito mais rápido do que trabalho imposto de cima para baixo, porque não precisa ser traduzido para um formato significativo nem exige comunicação ativa em todas as direções
- A razão pela qual pequenas empresas de software podem entregar software muito melhor do que grandes corporações é que, mesmo que uma empresa grande coloque 10 vezes mais engenheiros, isso não importa se a empresa pequena for 20 vezes mais eficiente
- Em grandes empresas, vários procedimentos e ferramentas são introduzidos para tornar o trabalho dos engenheiros “legível”
- Isso ajuda no planejamento, na medição e no reporte do trabalho, mas pode reduzir a produtividade real de software
- Empresas pequenas conseguem responder imediatamente a problemas ou absorver mudanças com rapidez, uma capacidade ilegível
- O motivo de grandes empresas manterem procedimentos complexos em vez dessa eficiência está ligado a grandes contratos enterprise. Clientes grandes exigem previsibilidade e confiabilidade de seus fornecedores
- Para trabalhar com esses clientes, a legibilidade é indispensável: planejamento de longo prazo, promessas de funcionalidades e documentação de progresso
- Esses processos continuam existindo porque o valor que a legibilidade gera em dólares é maior do que a capacidade de produzir software com mais eficiência
O valor prático da legibilidade para grandes empresas
- Em uma grande empresa de software, legibilidade significa
- Ser possível entender todos os projetos em andamento, até no nível de cada engenheiro individual
- Conseguir gerar imediatamente uma lista dos projetos concluídos no último trimestre
- Poder planejar o trabalho com pelo menos um trimestre de antecedência — ou mais
- Em situações críticas, mobilizar todos os recursos do departamento para trabalho imediato
- Empresas pequenas de software quase nunca conseguem atender a esses requisitos, exceto pela capacidade de responder com flexibilidade imediata
- Grandes empresas são fortes em registro, classificação e planejamento de longo prazo, mas podem enfraquecer justamente na capacidade de resposta rápida, isto é, na mobilização imediata de recursos organizacionais
- Garantir essa legibilidade é especialmente importante para confiança, contratos e colaboração de longo prazo com clientes enterprise
As premissas necessárias para obter legibilidade — e seus limites
- No processo de buscar legibilidade, grandes empresas adotam premissas simplificadoras como
- Pressupor que todos os engenheiros do mesmo nível têm desempenho aproximadamente equivalente
- Pressupor que realocar ou reorganizar engenheiros não causa perda de produtividade
- Pressupor que se o número de engenheiros da equipe continuar igual, o nível de produtividade também será mantido ao longo do tempo
- Pressupor que projetos podem ser estimados com antecedência, dentro de uma margem de erro
- Mas, na prática
- Mesmo no mesmo nível, há grande diferença de habilidade, e especialização e interesses podem alterar muito a produtividade de um projeto
- O tamanho da equipe e a produtividade têm apenas correlação fraca
- Estimativa de projetos é quase uma fantasia, e muitas vezes a forma de trabalhar muda apenas para caber no cronograma estimado
- Ainda assim, essas premissas são úteis para comunicação dentro da empresa, acordos com grandes organizações externas e planejamento de negócios
Áreas temporárias de ilegibilidade autorizada
- Em grandes empresas, os processos criados para gerar legibilidade causam atrasos severos
- Ideia de produto → etapa de planejamento da organização de produto → revisão técnica da organização de engenharia → negociação entre VPs e gerentes seniores sobre alocação de equipes → entrada no backlog de planejamento da equipe → backlog de tickets da equipe → entrada no sprint → início do trabalho real
- Essa estrutura é totalmente incompatível com trabalho que precisa ser feito imediatamente
- Para resolver esse problema, são permitidas áreas temporárias de ilegibilidade, como “equipes virtuais”, “strike teams” e “tiger teams”
- Formadas por engenheiros selecionados em quem a organização confia
- Muitas vezes sem gerente algum designado, com um engenheiro muito sênior tocando o projeto
- Recebem uma missão vaga e têm permissão para fazer basicamente qualquer coisa para atingir o objetivo
- Isso é um compromisso inteligente entre ilegibilidade total e legibilidade total
- Elas contornam o processo oficial, mas não operam de forma permanente, apenas temporária
- Mesmo a ilegibilidade autorizada coexiste de forma desconfortável com o restante da organização, e outros engenheiros podem sentir inveja ou considerar arriscada a liberdade de trabalhar sem o peso do processo
Áreas permanentes e não autorizadas de ilegibilidade
- A forma oficial para um engenheiro do time A pedir trabalho ao time B é criar uma issue no backlog de “planejamento”, passar por um processo de 12 etapas e esperar até que ela entre no sprint, o que leva de semanas a meses
- A solução oficial é que o time A deveria antecipar o trabalho do time B durante o processo de planejamento, algo absurdo, já que não é possível prever todas as mudanças meses antes de escrever o código
- A solução real é o backchannel ilegível
- Um engenheiro do time A pede a um engenheiro do time B: “você pode fazer essa mudança de uma linha?”
- O engenheiro do time B faz isso imediatamente, e criar ticket é opcional
- Isso é ilegível porque depende de relações interpessoais entre engenheiros
- Backchannels existem continuamente em todos os níveis da empresa
- Backchannels entre equipes de engenharia, dentro das equipes, entre gerentes, entre gerentes de produto
- Quando uma pergunta é feita em um espaço oficial, muitas vezes a resposta já foi ensaiada e revisada em privado com antecedência
- Backchannels podem dar errado e, às vezes, são usados para beneficiar alguém à custa de um engenheiro ingênuo
Sociopatas, clueless e losers
- O “Princípio de Gervais”, de Venkatesh Rao, divide as organizações em três grupos
- Os “sociopatas” no topo usam cinicamente as regras da organização em benefício próprio
- Os “clueless” da gerência intermediária acreditam nas regras oficiais da organização e não percebem que existe um jogo mais profundo por trás delas
- Abaixo deles, os “losers” reconhecem que esse jogo existe, mas não querem participar
- Essas categorias podem ser lidas em termos de legibilidade
- Sociopatas e losers estão ambos envolvidos no mundo ilegível da organização
- Os “clueless” se envolvem apenas com processos legíveis e, quando querem promoção, consultam a trilha oficial de carreira e planejam como demonstrar cada valor do próximo nível
- Chamar essas pessoas de “clueless” é cínico demais
- Processos legíveis continuam sendo muito importantes e representam uma grande parte do que a organização faz
- Melhorar processos oficiais continua sendo um trabalho de altíssima alavancagem
- Pensar nas pessoas a partir dessas categorias ajuda a entender que áreas frequentes de conflito em empresas de software surgem do atrito entre esses grupos
Considerações finais
- É importante reconhecer e usar o mundo ilegível dentro das organizações
- Eu já escrevi bastante sobre reconhecer e usar a ilegibilidade em empresas de tecnologia
- Conselhos sobre processos ilegíveis entram na categoria de “conselhos perigosos”
- Se você anunciar publicamente que conclui trabalho por backchannels em vez de seguir o processo oficial, será punido pela organização
- Mesmo que a cadeia de gestão quisesse que você agisse assim, ainda assim haverá punição
- O autor recebe muito feedback negativo dizendo que nunca se deve contornar o processo oficial, mas considera essa visão ingênua
- Toda organização tem um lado legível e um lado ilegível
- O lado legível é importante a partir de certo porte, pois viabiliza planejamento de longo prazo e coordenação com outras grandes organizações
- O lado ilegível é igualmente importante: permite trabalho de alta eficiência, funciona como válvula de segurança para processos que não se encaixam na situação atual e atende à necessidade humana natural de gossip e consenso informal
1 comentários
Comentários no Hacker News
Concordo com a maior parte, mas questiono a suposição de que a liderança automaticamente considera que a "legibility" vale qualquer custo. Se o CEO tivesse mesmo de se preocupar com cada detalhe do trabalho (por exemplo, paralelização de testes unitários), seria como o cérebro ter de estar consciente de cada movimento de um dedo, e aí não conseguiria fazer mais nada. Na prática, o CEO, isto é, a pessoa no topo de uma empresa, só consegue controlar algo como 7% do todo. O resto é preenchido por cada funcionário, e ele funciona apenas como cérebro, não como o corpo inteiro. Mas líderes tendem a cair na ilusão de que são a parte mais importante e passam por cima de áreas para as quais não têm tempo ou expertise suficiente (por exemplo, a diferença entre um excelente engenheiro do MIT e um engenheiro mediano vindo de bootcamp). Quando se fala do sucesso do Google, também existe uma tendência de dar o crédito apenas aos dois fundadores ou ao CEO, em vez de às dezenas de pessoas excelentes que fizeram o trabalho na prática
Parte disso está certa, mas também não me parece algo tão extremo assim. Trabalho numa empresa com cerca de 5.000 pessoas — não é pequena, mas também não é do porte da Amazon. A maioria das regras existe por um motivo razoável. Por exemplo, exigir dois revisores de código ajuda a evitar erros. Quase nunca há rejeição de revisão, mas se fosse possível fazer deploy sem revisão, os incidentes aconteceriam com mais frequência. Essas regras forçam a checagem, ainda que seja meio no automático. Claro que às vezes surge uma situação em que a regra precisa ser quebrada (por exemplo, quando a maior parte do time está ocupada correndo atrás de um incidente). Nesses casos, faz sentido permitir exceções de acordo com a intenção da regra. Mas, se o lugar estiver cheio de regras puramente burocráticas que ninguém entende (tipo alguém insistindo no próprio processo e só repetindo "o seu jeito está errado"), eu saio. Se o ambiente valoriza mais processo ou ego pessoal do que progresso e resultado reais, a resposta é trocar de emprego
Desde o TDD, ficou muito forte a tentação de pensar que "se não dá para testar, então ainda não foi implementado". A palavra "legibility" descreve isso muito bem. No Tritium, colocamos centenas de testes unitários, mas foi só ao construir de fato o blog que apareceram bugs qualitativos que os testes unitários não capturavam — coisas difíceis de verificar por teste. Veja https://tritium.legal/blog/eat. Acho que isso também explica por que o desenvolvimento indie de jogos resiste tão bem à lógica de mercado. Desenvolvedores de jogos usam o próprio produto (food-dogging) e assim alcançam melhorias qualitativas. Não precisam da mesma superfície excessiva de legibility que software corporativo grande exige. O ponto central é que precisamos tanto de métricas qualitativas quanto quantitativas
Testes, especialmente testes unitários, são vulneráveis ao "efeito poste de luz". Quanto mais trivial ou menos importante uma parte é, mais fácil costuma ser testá-la — então você acaba testando só o que é fácil. Se a organização fica obcecada por métricas fáceis de medir, como line coverage, existe o risco de deixar de lado validações realmente significativas, que são as difíceis. Avaliações qualitativas, como a revisão feita por engenheiros experientes, também são importantes
O desenvolvimento de jogos tem um ciclo de feedback muito mais curto do que outras áreas de software. Por exemplo, se houver vazamento de memória, o problema aparece imediatamente, centenas de vezes por segundo. Código lento vira travamento visual perceptível na hora, então você acaba tendo de pensar também em desempenho, como coerência de cache, uso de GC etc.
Gosto de TDD, mas no fim das contas teste manual também é indispensável. Se você não testa diretamente, problemas inesperados aparecem com frequência. Isso vale especialmente para aspectos como usabilidade, que só ficam realmente evidentes no uso real
Gosto muito dos textos do Sean, e este também me tocou bastante em toda a área de produto. Por exemplo, cerca de um ano atrás, vários PMs e engenheiros tentaram criar algo que pudesse ajudar outros times também. Conseguir aprovação pelo canal oficial (legible channel) não era realista na estrutura da época, então seguimos de forma informal (illegible channel), com base em confiança e respeito. Foi um movimento de base (grassroots), e justamente por isso ganhou tração interna rapidamente, no boca a boca. No fim, agora a liderança usa esse caso como se fosse uma história de sucesso deles, mas em compensação passou a correr atrás de todos os processos oficiais (legible channel) e da documentação posterior, e isso tem sido bem doloroso. Ainda assim, como o risco de fracasso caiu bastante, também ficou mais fácil. Foi um dos projetos mais gratificantes e divertidos em que trabalhei nos últimos anos
Quanto mais tempo passo na vida corporativa, exposto à política de escritório, mais acho que isso se parece com geopolítica ou diplomacia. Indo além, também vejo paralelos com relações sociais e amorosas. Talvez seja meu lado meio matemático, que gosta de criar modelos abstratos
Política é justamente um dos meus temas favoritos. Gosto de livros, revistas e todo tipo de material sobre isso e, para falar a verdade, política interna de empresa não me incomoda tanto. No fundo, a chave é que seres humanos se comportam como seres humanos. Toda pessoa — e toda organização também — tem coisas que deseja e coisas que teme, e equilibrar isso acaba sendo quase divertido. É como resolver um problema de engenharia, só que com "pessoas" como requisito. O próprio processo de resolver esse tipo de problema é interessante
Só recentemente percebi isso. No começo, eu via diplomacia como o resultado de um sistema complexo produzido por centenas de diplomatas, mas na prática é basicamente só um conjunto de relações humanas entre algumas figuras poderosas. Dá até para abordar de forma parecida com o que acontece numa creche
Isso é algo instintivamente natural. As semelhanças são mais claras entre grandes empresas e governos do que entre empresas e relações sociais, como namoro. Empresas costumam ser muito mais autocráticas ou feudais. Há muitas diferenças também, mas, quanto maiores ficam, mais tendem a se parecer com governos. Uma dessas semelhanças é justamente a burocracia sofisticada
Teoria dos jogos na Wikipédia
Se considerarmos que hoje muitos políticos começaram em empregos comuns de escritório, esse fenômeno também não deveria parecer tão estranho
Trabalho com segurança de TI, e aqui isso fica ainda mais evidente. Fico me perguntando se existe alguma alternativa ao back channel quando "nosso time precisa aceitar pedidos que não ajudam nas nossas métricas diretas". Se alguém souber, adoraria ouvir
É um bom texto, mas quero falar de uma coisa que quase nunca aparece. O artigo me incomodou um pouco por retratar o engenheiro de software (SWE) apenas como a folha da árvore, ou seja, como um operário de linha de montagem. Mas, como o próprio trecho sobre "legible assumptions" sugere, na prática o engenheiro também exerce um papel gerencial, expandindo conexões na estrutura organizacional por meio de "código". O objeto de aplicação muda, mas os dilemas acabam sendo parecidos
Mais alguém concorda com o trecho que diz: "Por que empresas pequenas não precisam disso, mas grandes empresas de software precisam? Não é minha área, mas imagino que isso seja por causa de projetos para grandes corporações"? Queria ouvir opiniões
Acho que não é tanto por causa de vendas para grandes corporações, mas por causa do fluxo interno de informação em escala. Dá para pensar numa organização com m funcionários como uma matriz de comunicação m*m. Quando há poucas pessoas, quase todas as células são 1 (comunicação próxima), mas, à medida que a empresa cresce, a maioria vira 0 (desconexão) ou 0,5 (comunicação informal). Só que informação é, no fim, a própria empresa. Por isso, é essencial ter gestores e processos formais responsáveis por esse "fluxo". Planejamento, promoção, revisão — tudo isso existe para garantir essa legibility
Trabalho numa empresa pequena que assume projetos de grandes corporações, mas isso não exige legibility rígida dentro da empresa para fechar negócio. Diante do cliente, é preciso ter legibility na gestão do projeto, mas isso não significa interferir minuciosamente no modo como o desenvolvimento interno acontece. Em resumo, empresas grandes ficam obcecadas por legibility porque já são grandes ou porque querem se tornar grandes
Trabalhei por muito tempo com imagem médica, e a maioria dos empresários não entende direito que está no setor de serviços/soluções de TI. A capacidade de entregar serviços de TI era o verdadeiro fator de sucesso. Mais do que o diagnóstico em si, pesou muito mais o esforço de pessoas não radiologistas para melhorar a usabilidade e a eficiência da plataforma
Não importa o tamanho da organização: você precisa estar sempre preparado para várias auditorias internas e externas. Auditores tendem a querer ver o máximo possível de documentação de processo. No pior caso, como neste exemplo, o auditor pode até "demitir" o cliente: este caso
Essa parte — a ideia de que é por causa de negócios com grandes corporações — também me parece um pouco peculiar. Vim de startup e hoje sou gerente intermediário numa empresa média, e acho que, conforme a organização cresce, sempre passa a ser necessário algum nível mínimo de estrutura para ensinar como o trabalho deve ser feito. Você pode odiar processo o quanto quiser, mas depois do Dunbar’s Number empatia e comunicação informal já não bastam. Um caso extremo de exceção seria a Steam, mas ali também há seleção de um tipo muito específico de talento e uma política interna bastante intensa
A escolha da palavra legibility já é interessante por si só. Parece uma dicotomia entre processos formais e informais. Quando a empresa é pequena, métodos informais funcionam bem, mas, depois de certo ponto, não há como evitar a introdução de regras e processos formais. No longo prazo, essas regras acabam gerando rigidez e incapacidade de acompanhar mudanças. Aos poucos, a obsessão passa a ser o processo em si, e não mais o objetivo. Não é fácil escapar da rotina e preservar a novidade. Na empresa, costuma-se dizer que dinheiro é como sangue, mas raramente o dinheiro é a raiz real da motivação. Ele é uma condição necessária, mas não o próprio sentido de existir
No fim, é sempre uma questão de equilíbrio. Fui gerente de engenharia por 25 anos e trabalhei em empresas muito orientadas a processo. Era sufocante, mas também havia vantagens nisso, como a capacidade de produzir hardware de nível mundial com consistência (software, nem tanto). Documentação e afins são necessárias, mas, se o rigor passar do ponto, há o risco de o projeto endurecer. O overhead de comunicação é o problema mais grave. É por isso que um pequeno grupo de pessoas competentes, trabalhando junto por muito tempo, pode alcançar produtividade enorme, e por que o "conhecimento tribal" realmente é um facilitador muito importante. Escrevi Concrete Galoshes justamente para tratar desses elementos estruturais e de rigidez. A principal lição é: "não vista todo projeto com a mesma roupa". Projetos diferentes exigem estruturas e overheads diferentes