[Off-Topic] Obediência à Autoridade

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. Ele demonstra como as pessoas entram em conformidade com um grupo, mesmo sabendo que o grupo pode estar errado. Por diversas razões, elas se conformam mesmo assim.

Para nós, agilistas, pense numa equipe fazendo Planning Poker ou Retrospectiva. Quando a maior parte responde de um jeito, a minoria tende a ir com a opinião do grupo. Alguns mantêm a posição com mais firmeza, mas o padrão é a conformidade, e isso precisa ser levado em conta. Assistam para entender:

Experimento da Conformidade de Asch from Fabio Akita on Vimeo.

Mais do que isso, funcionamos hoje em organizações com estruturas antiquadas. Hierarquias, cargos, chefes, procedimentos, políticas. Tudo isso, como eu falo nas palestras, não funciona mais e só limita a organização como um todo. Traz resultado de curto prazo? Com certeza, por isso todo mundo ainda usa. No longo prazo, cria uma organização doente.

Um dos fatores tem a ver com autoridade. Nesse tipo de organização, quando existe um “chefe”, o efeito é simples: a responsabilidade pela tarefa executada migra do subordinado para quem deu a ordem. É o que todo mundo já ouviu antes: “eu só estava seguindo ordens”, ou “eu só trabalho aqui”.

Isso vale até para atrocidades (nazistas torturando judeus, por exemplo). Uma teoria diz que a pessoa até entende que aquilo está errado, mas como a decisão veio de uma autoridade, ela não sente o mesmo remorso, não pensa em alternativas, nem cogita simplesmente parar.

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:

• as pessoas se conformam com muita facilidade
• as pessoas não gostam de parecer que estão erradas, portanto não arriscam
• as pessoas obedecem autoridades, sejam chefes, sejam pessoas com status maior de alguma forma

Esse é um dos motivos pelos quais tantos projetos de agilidade falham. Não adianta dizer “a equipe decide o melhor caminho” se ainda existe alguém com poder de veto. Basta o veto ser usado uma vez para ninguém mais levar nada a sério.

As organizações atuais limitam as pessoas, o potencial delas, qualquer chance de motivação, qualquer individualização, e no fim transformam gente em robô. Quanto mais o indivíduo se conforma a essa estrutura, mais ele fica amorfo, quase um pedaço de carne ambulante.

Portanto, a única saída é eliminar as hierarquias de poder. Assista minha introdução sobre essa ideia 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 e fechados, tendem a estagnar e colapsar. Pode levar dez anos, mas é o que acontece, naturalmente. Sistemas complexos adaptativos, ao contrário, seguem em evolução, aprendem com as pequenas falhas e refinam os próprios processos.

Isso exige heterarquias no lugar de hierarquias, grupos formados espontaneamente, com controle descentralizado. Difícil de engolir? Concordo, e por isso mesmo quem está hoje em posição de autoridade deveria ser um pouco mais letrado antes de sair executando. Aliás, esse é outro ponto:

• as pessoas de hoje lidam com o conhecimento de forma superficial: elas preferem “fazer” em vez de “perder tempo” aprendendo.

Dan Pink deu uma palestra no TED sobre motivação. Relembrando o ponto de partida: ninguém consegue motivar outra pessoa, então nem tentem. As pessoas se motivam sozinhas ou não se motivam, e o máximo que empresa e gerente conseguem é desmotivar. O principal, portanto, é parar de atrapalhar.

O que o Dan mostra é o óbvio: as empresas continuam usando técnicas arcaicas, baseadas mais em folclore do que em ciência. O sistema de recompensa e punição não funciona. Entenda:

Ele afirma que as pessoas precisam de três coisas para se motivar: Autonomia, o desejo de controlar a própria vida; Maestria, o desejo de ficar cada vez melhor no que faz; e Propósito, fazer parte de algo maior do que elas mesmas. O que ele descreve, no fundo, são Agentes dinâmicos e interativos de um Sistema Complexo Adaptativo. Esses agentes interagem entre si, cooperam e competem, e evoluem ao redor de “Atratores Estranhos”, que são o propósito ou a identidade do grupo ou da empresa.

Agilidade é uma evolução natural dos processos antigos de gestão. Organizações Democráticas são o passo 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 prazer de assistir ao Fred Brooks no Latinoware deste ano. Fiquei um pouco frustrado com a plateia rala: a palestra dele deveria estar cheia e tinha pouquíssima gente. Sinal de que a maioria nem sabe quem ele é ou não tem interesse no assunto, o que é bem triste.

O Fred falou sobre uns dois capítulos do livro que está escrevendo. Fica a ressalva de que ele não apresentou o conteúdo completo, então muita coisa que eu especular aqui pode estar explicada nos outros capítulos.

O tema foi 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 algo parecido para manter a integridade do produto final. Deu exemplos como a construção de um avião por equipes separadas, com pessoas conversando com todas elas o tempo todo para garantir que o conjunto permanecesse íntegro e consistente.

Eu concordo com a explicação. Ela é satisfatória, e de fato arquiteturas complexas de sistema não aparecem “do nada” a partir de várias pessoas ou equipes trabalhando separadas.

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

Um arquiteto é, no fim, um líder, uma condição conquistada por mérito. Posição, certificação ou ordem de alguém não entram nessa conta. Pega o exemplo do kernel do Linux. Ninguém nomeou o Linus Torvalds ao posto de “ditador benevolente” do projeto. Ele emergiu de uma necessidade, as pessoas aceitaram sua liderança e, se ficassem muito descontentes, bastaria fazer um fork para outro líder assumir.

Líderes de verdade emergem por conta própria. Conforme um projeto assim cresce, outros líderes surgem naturalmente em cada parte dele. Aparecem os que o Linus chama de seus “tenentes”, como o Andrew Morton já foi.

Esse ponto é importante: liderança se adquire de baixo para cima, e não é um posto de autoridade ditado de cima para baixo. Líderes evangelizam seu ponto de vista, convencem as pessoas e, até certo grau, chegam a impor algumas posições.

Mas quando existe abuso dessa posição, a equipe em volta pode e deve reforçar seus valores. E se a briga terminar sem vencedores, o caminho é sair do projeto, em vez de se conformar e seguir, como os experimentos de Asch e Milgram mostram.

Isso funciona muito bem no mundo open source porque ele é um ambiente distribuído, sem hierarquias nem cargos fixos. As pessoas circulam entre os vários setores do projeto, existe discussão, as opiniões contam e novas ideias são testadas na prática. É o extremo oposto de como se faz software numa empresa tradicional. Uma descrição mais densa está no clássico The Cathedral and the Bazaar, de Eric Raymond.

Alguém que se acha capaz de resolver um problema começa a assumir as rédeas. As pessoas em volta enxergam valor nisso e passam a colaborar. A arquitetura inicial vai sofrendo revisões e evolui. Esse “líder”, em geral o autor, continua garantindo a visão inicial e incorpora as mudanças propostas, mesmo quando elas são melhores que as ideias dele, em vez de cair na posição retrógrada do “não fui eu quem fez, então não aprovo.”

Entender o mundo open source é a chave para entender agilidade e organizações democráticas. Elas nasceram assim por causa das limitações do ambiente: gente espalhada pelo mundo, voluntários, ausência de contato físico, necessidade de manter a integridade do código.

Liderar é diferente de chefiar. Um líder não tem o direito de só gritar ordem. Um líder de verdade é um líder servil: colabora e ajuda a equipe em vez de mandar e dizer como fazer. Ele influencia, evangeliza, expõe outros pontos de vista e busca consenso.

Às vezes ele precisa tomar decisões mais duras, como ir contra a maioria para preservar a integridade do projeto. Mas se fizer isso da maneira errada vezes demais, a equipe deve tirá-lo da posição. Aqui, Inteligência Emocional importa tanto quanto, ou mais que, o mero QI.

Então sim, projetos precisam de uma visão de integração. Isso não justifica, porém, nomear alguém autocraticamente como o “arquiteto”. Nos melhores projetos, essa posição emerge sozinha. Se a equipe não consegue fazer um líder emergir e alguém precisa ser nomeado, ela já está fundamentalmente quebrada. Boa sorte com esse projeto.