Menu fechado

Agile Brazil 2016 – Em defesa das “hard skills” de Gestão

No Agile Brazil 2016 em Curitiba debati com Alceu Bravo o assunto “Gestão e Liderança: Mais Soft Skills ou Mais Hard Skills?” – segue aqui neste post um resumo do meu argumento cumulativo em favor das “Hard Skills”.

1. Pessoas não são um ponto de intervenção

Esse argumento não é meu, mas creio que o John Seddon sintetizou a percepção de vários outros consultores na linha de batalha neste video (com a participação de ninguém menos que Jeffrey Liker). Você já deve ter escutado: Pessoas e Interações são mais importantes que processos e ferramentas. É um dos valores ágeis. Em 2001 essa afirmação foi basicamente a resposta a um movimento de burocratização na TI dos anos 90. Esse valor atualmente tem levado empresas de tecnologia a uma exacerbação de abordagens “People Oriented” e uma a tendência anarco-comunista de gestão, que eventualmente será contra qualquer mecanismo de controle ou gestão quantitativa (números, gráficos, estatística), comumente associado a uma interpretação equivocada de Sistemas Complexos. O mote do estilo de gestão “People Oriented” é “deixe as pessoas livres que elas vão saber o que fazer”.

Nos meus estudos a origem do “deixe as pessoas livres que elas vão saber o que fazer” é o livro Virando a Própria Mesa do Ricardo Semler de 1988. Desde então o que vemos no mercado é uma crescente demonização de estrutura e hierarquia, em claro Marxismo, até que chegamos aos desafios atuais de se manter a coesão e escala em estruturas descentralizadas, como a Holacracia, o Management 3.0 e o modelo Spotify.

Você consegue enxergar aonde isso está nos levando? Misture liberdade de movimento, baixas restrições, intervenções nos agentes do sistema e basicamente o que você tem é anarquia e otimização local, exatamente o que Systems Theory, Systems Thinking e Complexity Theory dizem para você não fazer. A intervenção nos agentes do sistema se manifesta de várias formas: necessidade por consenso, retrospectivas, obsessão por trabalho em equipe, coaching, aumentar o engajamento e motivação. Digamos que após você vestir toda roupagem Agile – Sprints, Plannings, POs, quadros kanban, trabalho em equipe – mesmo assim você não está obtendo os resultados esperados. O que acontece? No melhor cenário você vai apontar todas as suas energias na motivação dos indivíduos – já que eles têm todas as outras alavancas em suas mãos – como tem acontecido na maioria das discussões sobre Agile que tenho acompanhado. Isso gera uma exacerbação de soft skills como Facilitação, Coaching, PNL, Modelos de Motivação, Liderança Servidora, Liderança Carismática e etc…

Anarquia não é suficientemente robusta para suportar o fascismo. Anarquia não está funcionando. As evidências mais célebres dessa afirmação foram os recentes episódios acontecidos na Zappos e no GitHub. Sem a falácia do espantalho aqui, esses parágrafos não são um exortação a burocracia, hierarquia e comando e controle, mas sim, um alerta que simplificações sedutoras e apelativas podem ser perigosas.

Uma das formas de se entender as modas de processos e estilos de gestão é vê-las como um pêndulo que vai do comando e controle total até a anarquia total. Nos anos 80 a Ciência da Computação era vista como um trabalho técnico parecido com a engenharia civil ou mecânica. Adotamos deles jargões como projeto, design, construção, testes e gestão… Com o advento das linguagens de 3a. geração e o micro-computador a liberdade e velocidade de desenvolvimento trouxe menos restrições e um afrouxamento da gestão. Nos anos 90 houve uma febre por processos e burocratização. Na virada do século XXI, surge o Manifesto Ágil em resposta a esse aumento do controle. Temo que essas tentativas frustadas de anarquia nos tragam o pior estilo de comando e controle dentro de alguns anos.

Esse primeiro ponto é o que investi mais texto aqui pois acredito que é o mais propenso a má interpretação e pré-julgamentos. Interpretem com parcimônia e respondam ao argumento não ao mensageiro.

2. Para saber a direção você precisa de Hard Skills

Taylor, Shingeo Shingo, Deming, Eliahu Goldratt, Don Reinertsen. O que esses gurus de gestão tem em comum? Todos eles favoreciam o conhecimento científico para melhorar um modelo de gestão. Não temos dúvidas que melhorar um processo ou sistema de trabalho é uma tarefa nobre, mas como decidir sobre o que realmente são problemas, o quanto investir neles e como mensurar se nossas soluções realmente estão funcionando? Melhorar um sistema baseado solenemente no julgamento e percepções das pessoas é mais um ponto cego muito comum no mercado. Como podemos melhorar a vazão do sistema sem atuar nos seus gargalos? Como podemos melhorar a qualidade se não mensuramos quantitativamente seus impactos? Como podemos ser ágeis sem medir nossos lead times? Como gerenciar os riscos e aprender sem aferir seus impactos econômicos?

Como já apresentei no Agile Brazil 2013, retrospectivas ágeis feitas dessa maneira  – baseada somente nas opiniões pessoais – facilmente se transformam em “terapia de grupo”.  Sobre melhoria de processos, ser divertido, ter uma narrativa inspiradora e fazer as pessoas se sentirem melhores não é suficiente. Eu espero muito mais rigor da comunidade ágil nesse quesito.

3. O histórico favorece gestores com mais Hard Skills

Estou longe de afirmar que se focar em Soft Skills tem resultado zero ou necessariamente inferior, porém, o registro histórico de grandes e reconhecidos gestores, aqueles que revolucionaram a forma de pensar gestão em grandes ondas que nos influenciam até hoje, são necessariamente gestores com mais hard skills. O caso mais característico que temos foi citado no vídeo do Jon Seddon linkado no início do artigo: Taiichi Ohno era um chato, obsessivo e tinha um tratamento tosco com pessoas na Toyota. Mas ele era um gênio, e seu estilo de gestão e o que fez no TPS influencia até o hoje o mercado.

Podemos dizer o mesmo de Henry Ford, Bill Gates e Steve Jobs.

Mais sobre o assunto:

O que matou o RUP pode matar o Agile

O mito da Cultura Ágil

Dizer sim ao Lean torna o resto irrelevante

Kanban em 5 minutos!

Scrum e/ou Kanban – Por onde começar?

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *