[Off-Topic] Obediência à Autoridade

2009 November 08, 18:50 h

Atualização: 20/11 Atualizei os vídeos pelas versões legendadas em português no Vimeo.

Atualização: 10/11 Acrescentei uma última seção sobre um assunto recente do Fred Brooks.

Nas minhas últimas palestras sobre organizações eu mostro um vídeo do experimento de Asch. Esse experimento demonstra como as pessoas entram em conformidade com um grupo, mesmo sabendo que o grupo pode estar errado. Mas por diversas razões, elas se conformam. Para nós agilistas, pense numa equipe realizando Planning Poker ou Retrospectiva. Quando a maior parte da equipe dá uma resposta, a minoria “tende” a ir com a opinião do grupo. Claro, alguns mantém sua posição mais firmemente, mas não é o normal. O normal é nos conformarmos, e isso deve ser levado em consideração. Assistam para entenderem:

Experimento da Conformidade de Asch from Fabio Akita on Vimeo.

Mais do que isso, nós funcionamos atualmente em organizações com estruturas antiquadas. Hierarquias, cargos, chefes, procedimentos, políticas. Tudo isso – como eu falo nas palestras – não funciona hoje em dia. Elas apenas limitam a organização como um todo. Trás resultados de curto prazo? Com certeza, por isso todos ainda usam. Em longo prazo, cria uma organização doente.

Um dos fatores é a respeito de autoridade. Em organizações desse tipo, quando se tem um “chefe”, o efeito é: “a responsabilidade das tarefas executadas não é do subordinado, mas do chefe que dá a ordem.” É o que todos nós já ouvimos antes: “eu estava apenas seguindo ordens”, ou “eu só trabalho aqui”. Mesmo quando se está executando tarefas hediondas (nazistas torturando judeus, por exemplo), uma teoria é que as pessoas em si poderiam até entender que o que estavam fazendo estava “errado” mas como a decisão da execução saiu de alguma autoridade, nós não sentimos o mesmo remorso ou pensamos melhor em alternativas ou mesmo de simplesmente parar a execução.

Quem demonstrou isso foi Stanley Milgram, nos anos 60. A BBC refez o mesmo experimento e você pode assistir ao meu resumo legendado:

Estes são todos perigos reais, que acontecem no nosso dia-a-dia:

Que é um dos motivos pelos quais muitos dos projetos de agilidade, em particular, falham. Não adianta simplesmente dizer: “a equipe decide qual o melhor caminho”, se ainda existe alguém com poder de veto. Se o veto for usado, apenas uma vez, ninguém mais da equipe vai levar qualquer coisa a sério. As organizações atuais limitam as pessoas, limitam seu possível potencial, limitam qualquer chance motivação, limitam a individualização, enfim, transformam as pessoas em robôs. E quanto mais um indivíduo se conforma nessa estrutura, mais ele se torna amorfo, praticamente um pedaço de carne ambulante.

Portanto, a única saída, é eliminar as hierarquias de poder. Assista minha introdução sobre essa idéia na palestra que dei no Rails Summit 2009 (créditos do vídeo para @agaelebe, obrigado por ter filmado):

Organizações, enquanto sistemas clássicos, fechados, tendem sempre a estagnar e entrar em colapso. Pode levar 10 anos, mas é o que vai acontecer, naturalmente. Sistemas complexos adaptativos, por outro lado, tendem a continuar em evolução, aprendendo com as pequenas falhas, refinando seus processos naturalmente. Mas isso exige heterarquias, não hierarquias, grupos formados espontaneamente, com controle descentralizado. Difícil de engolir? Concordo plenamente, por isso mesmo quem hoje está em posições de autoridade deveriam ser um pouco mais literados antes de executar as coisas. Aliás, este é outro ponto:

Dan Pink apresentou no TED sobre motivação. Primeiro, relembrando: ninguém consegue motivar pessoas, por isso não tentem. Pessoas se motivam sozinhas ou não se motivam. O máximo que empresas e gerentes conseguem fazer é desmotivá-las. Por isso o principal é parar de atrapalhar. O que o Dan coloca é o óbvio: as empresas continuam usando técnicas arcaicas baseadas mais em folclore do que em ciência. O sistema de recompensas e punições não funciona. Entenda:

Ele afirma que as pessoas precisam de 3 coisas para se motivarem: Autonomia – o desejo de controlar as próprias vidas -; Maestria – o desejo de se tornar cada vez melhor no que faz -; Propósito – fazer algo maior do que elas mesmas. O que ele descreve, na realidade, é nada mais nada menos do que Agentes dinâmicos, interativos em Sistemas Complexos Adaptativos. Agentes interagem entre si, cooperam e competem, evoluem ao redor de “Atratores Estranhos” que é o propósito ou identidade do grupo, empresa.

Agilidade é uma evolução natural dos processos antigos de gestão. Organizações Democráticas são o passo de mais longo e mais abrangente numa organização.

Este artigo é apenas uma introdução. Releia meus artigos off-topic dos últimos meses para entender mais aspectos disso.

Fred Brooks

Tive o grande prazer de assistir o Fred Brooks no Latinoware deste ano. Devo colocar que fiquei um pouco frustrado pela platéia não-presente, pois a palestra do Fred, que deveria estar cheia, tinha muito pouca gente, demonstrando que a maioria nem sabe sobre ele ou não tem interesse no assunto, o que é bem triste.

O Fred fez uma palestra a respeito de uns 2 capítulos do livro que está escrevendo. Portanto fica a ressalva que ele não apresentou o conteúdo completo e por isso muitas coisas que eu especular podem estar explicadas nos outros capítulos.

O tema foi sobre a importância de “alguém” que seja a Guia-Mestra de um projeto. Ele afirma que projetos, especialmente os grandes, precisam de um Arquiteto-Chefe ou coisa parecida para manter a integridade do produto final. Ele deu exemplos como o da construção de um avião por equipes separadas, onde haviam pessoas que se comunicavam com elas o tempo todo para garantir que o todo permaneceria integrado e consistente.

Eu concordo com essa explicação. Ela é satisfatória e de fato arquiteturas complexas de sistema não aparecem “do nada” de diversas pessoas ou equipes trabalhando separadas.

Porém, existe um enorme caveat aqui. Dependendo de como você interpretar essa explicação, se você tiver o cargo de “Arquiteto” ou for certificado em “Arquitetura de Sistemas”, pode se sentir altamente justificado por uma celebridade como Fred dizendo que arquitetos são vitais a um projeto. Bem, você está errado.

Um arquiteto é nada mais nada menos do que um líder. Isso não é um cargo. É uma condição ganha por mérito, não por posição, certificação, ordem ou coisa parecida. Um exemplo: a kernel do Linux. Ninguém assinalou o Linus Torvalds ao posto de “ditador benevolente” do projeto, ele simplesmente emergiu de uma necessidade, as pessoas aceitaram sua liderança e, se estivessem muito descontentes, poderiam apenas ter feito um fork e um novo líder assumiria.

Líderes de verdade emergem, não são colocados. À medida que um projeto como esse cresce, outros líderes emergem naturalmente em cada parte do projeto. Surgem o que o Linus chama de seus “tenentes”, pessoas como Andrew Morton já foi.

Isso é importante: não é um posto de autoridade ditado de cima para baixo. É uma condição adquirida de baixo para cima. Mais do que isso, líderes evangelizam seus pontos de vista, convencem as pessoas, até certo ponto até podem obrigar certas posições, mas em última instância, em existindo abuso dessa posição a equipe ao redor pode e deve reforçar seus pontos, seus valores ou ao final de uma briga sem vencedores, escolher por sair do projeto – e não se conformar e continuar, como mostrei acima nos experimentos de Asch e Milgram.

Isso funciona extremamente bem no mundo open source porque justamente se trata de um ambiente distribuído, sem hierarquias fixas, sem cargos fixos, onde as pessoas podem se movimentar entre os diversos setores do projeto, onde existe discussão, onde opiniões são levadas em consideração, onde novas idéias são testadas e experimentadas. É o extremo oposto de como se faz software tradicionalmente numa empresa. Uma descrição mais densa está no clássico The Cathedral and the Bazaar, de Eric Raymond.

Alguém, que se considera capaz de começar a resolver um determinado problema, começa assumindo as rédeas. As pessoas ao redor começam a enxergar valor nisso e podem começar a colaborar. A arquitetura inicial vai sofrendo revisões, mudanças e ela evolui. O “líder” desse projeto, provavelmente o autor, continua garantindo que a visão inicial continua e que mudanças propostas – que podem ser melhores que as suas – sejam devidamente incorporadas, em vez da retrógrada posição “não fui eu quem fiz, portanto não aprovo.”

Entender o mundo open source é a chave para entender sobre agilidade e sobre organizações democráticas. Elas nasceram assim por causa das limitações do ambientes (pessoas espalhadas pelo mundo, voluntários, falta de contato físico, necessidade de manter a integridade do código, etc). E mais, liderança não é chefia. Um líder não tem o direito de apenas gritar ordens. Um verdadeiro líder é um líder servil. Ele colabora e ajuda a equipe, ao contrário de mandar e dizer como fazer. Ele influencia, ele evangeliza, ele tenta expor mais pontos de vista, tenta buscar consenso. Às vezes precisa tomar decisões mais difíceis, como ir contra a maioria para garantir a integridade do projeto. Mas faça isso muitas vezes da maneira errada e a equipe deve demovê-lo de sua posição. Inteligência Emocional, nessa posição, é tão ou mais importante do que mero QI.

Portanto, sim, projetos precisam de visões de integração. Mas, não, isso não justifica pessoas “assinaladas” autocraticamente como os “arquitetos”. Nos melhores projetos, essa posição irá emergir. Se a equipe não tem condição de emergir um líder e é necessário assinalar um, ela já está fundamentalmente quebrada. Boa sorte com esse projeto.

tags: off-topic principles career management psychology

Comments

comentários deste blog disponibilizados por Disqus