Semana passada, compartilhei esse princípio extraído de uma fonte inesperada, o Manual do Corpo de Fuzileiros Navais dos EUA: "A responsabilidade de um indivíduo para a liderança não depende da autoridade". Vou utilizar essa afirmação como nosso ponto de partida dessa semana para continuar minha tese: a premissa arraigada de que autoridade deveria ser igual a responsabilidade é a fonte de muitos males organizacionais. Acredito que o mal entendido em torno dessa questão é algo crescente, problemático e tão arraigado na nossa consciência que nem mesmo o percebemos.
A afirmação do Corpo de Fuzileiros Navais tem paralelos fascinantes com a maneira na qual enxergo a dinâmica da responsabilidade e autoridade na Toyota no Japão na década de 1980, que já discutimos aqui antes, vamos debater de novo hoje, e novamente no futuro (aparentemente está claro que considero essa questão importante).
O local mais evidente para ver como isso funciona na organização Toyota - ou em qualquer lugar que conheço - está materializado na função do Engenheiro Chefe (ou EC) da Toyota, o "sistema shusa" de desenvolvimento de produtos. Vamos analisar a aparência do sistema tradicional de Engenheiros Chefe da Toyota (houve mudanças nos últimos 15 anos, mas a essência de como o sistema funciona certamente continua a mesma).
Como você pode ver, ele tem um aspecto de matriz. E é uma matriz. Mas o "software", ou o sistema operacional organizacional, por trás dele é radicalmente diferente.
Ao longo da parte inferior você verá as várias funções operacionais. Silos. Tubos de aquecimento. As mesmas funcionam como depósitos vitais de profundos conhecimentos técnicos e competências (portanto, muitas empresas as chamam de "centros de excelência"). Transversalmente estão as linhas de produto ou fluxos de valor, agregando valor do ponto de vista do cliente, enquanto asseguram a lucratividade para a empresa, para a linha de produtos. Quando me deparei com esse cenário (conforme mencionei, houve mudanças desde então), havia cerca de 15 departamentos funcionais de engenharia e, coincidentemente (?) cerca de 15 programas de veículos em andamento simultaneamente. Para um determinado programa, um EC precisaria direcionar os esforços de cerca de 10 departamentos funcionais principais. Por outro lado, o gerente geral de um departamento funcional tinha que dar apoio ao trabalho de todos os 15 programas, mas somente metade deles exigia suporte intenso em um determinado momento específico. (Vide capítulo 8 do Sistema de Desenvolvimento de Produtos da Toyota, de James Morgan e Jeff Liker, da Productivity Press, para uma excelente descrição de como o sistema de Engenheiros Chefe da Toyota funciona. Vide Chasing the Rabbit de Steven Spear, publicado pela McGraw Hill, para uma discussão esclarecedora da realidade que os sistemas matriciais modernos agora possuem silos demais que são demasiadamente especializados para qualquer pessoa gerenciar de uma maneira tradicional.)
O que é único sob o ponto de vista estrutural na matriz de desenvolvimento de produtos da Toyota é que quase ninguém se reporta diretamente aos Engenheiros Chefe (somente uma pequena equipe de apoio). Toda a força de trabalho está nos silos funcionais. As avaliações de desempenho dos engenheiros que realizam o trabalho são realizadas pelos gerentes funcionais (no entanto, com insumos do Engenheiro Chefe).
E qual é o aspecto fundamental?
Em questão aqui está um tópico extremamente fundamental: como as decisões são tomadas. Em uma organização funcional/hierárquica tradicional:
- O cargo estabelece (ou parece estabelecer) autoridade para tomar decisões.
Mas, em organizações interfuncionais - onde praticamente todos nós estamos - esse modelo mental causará confusão, frustração e o colapso do processo de tomada de decisões. Esse raciocínio causará precisamente a frustração e confusão que muitos de nós vivenciamos diariamente nas nossas organizações:
Em uma organização de fluxo de valor ou que aprende os conceitos lean:
- O cargo estabelece a responsabilidade para tomar decisões.
Descoberta
Trabalhar na Toyota freqüentemente me expôs a aspectos que pareciam muito simples na aparência, mas que com uma reflexão mais aprofundada revelaram insights profundos sobre como as organizações e processos funcionam. Em 1991, fui transferido da Toyota do Japão para me tornar gerente geral de administração do Centro Técnico da Toyota nos EUA em Ann Arbor, MI, que acabara de se expandir. Minha nova posição exigia um curso intensivo no entendimento do mundo de desenvolvimento de produtos da Toyota, que era bem diferente da Toyota que eu conhecia. Dessa forma, comecei minha jornada com um mergulho profundo nos centros técnicos na Cidade Toyota e Higashi Fuji.
Um aspecto que julgava conhecer sobre o desenvolvimento de produtos da Toyota era que os Engenheiros Chefe eram reis. A Toyota é notavelmente igualitária uma vez que você ingressa na empresa. Certamente existe uma hierarquia. Mas o processo de promoção da Toyota recompensava a experiência, assegurando que praticamente todos iriam, com o tempo, atingir uma posição de destaque. Em resumo, muito esforço era despendido para assegurar que todos nós soubéssemos que estávamos no mesmo barco. No entanto, os Engenheiros Chefe eram certamente diferentes. Ou pelo menos eu pensava dessa forma. (A propósito, falando em "tratamento igualitário", os Engenheiros Chefe fascinantes recebiam aproximadamente o mesmo salário dos humildes supervisores das linhas de montagem que fabricavam seus carros.)
Portanto, imagine minha surpresa a primeira vez que ouvi um Engenheiro Chefe dizer, "Não tenho nenhum poder". Ouvi isso pela segunda vez e considerei que essa afirmação poderia realmente ser verdadeira - Eu já estava familiarizado sobre como a dinâmica "responsabilidade versus autoridade" funcionava em outras partes da empresa. Mas, ao mesmo tempo, o Engenheiro Chefe era certamente a pessoa mais poderosa da empresa. A terceira vez que ouvi isso foi de um gerente de departamento funcional que afirmou "Podemos dizer 'não' ao Engenheiro Chefe se consideramos que ele está indo na direção errada". Isso era fascinante - um verdadeiro modelo ideal da dinâmica de liderar sem nenhum poder, da responsabilidade clara sem a simples autoridade baseada no cargo.
Portanto, o Engenheiro Chefe não tinha outra opção a não ser liderar com base nas suas habilidades pessoais de liderança verdadeira. Por habilidades pessoais, entende-se o conjunto de habilidades descritas nos livros sobre liderança ou livros de administração e ensinado no treinamento de liderança - características tais como "liderar por meio da influência" ou "liderança de servidor" ou "negociação ganha-ganha". Escolha a sua favorita. Para o EC, essas características e habilidades não são opcionais. Ele não pode simplesmente impor sua autoridade, adotar uma postura firme e fazer com que os departamentos ajam conforme ele exige. Os recursos funcionais podem e realmente lhe dizem "não" se e quando tiverem um bom motivo. Ele só pode liderar sendo bem informado, propondo boas idéias, negociando habilmente múltiplas prioridades e desejos, e sendo muito forte. Em resumo, ele tem que liderar exercendo verdadeiras habilidades de liderança, e não se baseando na autoridade que lhe é atribuída em virtude do seu cargo em um organograma.
Uau. Parece uma mentira deslavada, ainda assim, os programas de veículos da Toyota, pelo menos até agora, quase sempre saem no prazo e com a lucratividade e desempenho de mercado desejados. Como isso ocorre?
Criando um processo
O primeiro Engenheiro Chefe da Toyota, que liderou o desenvolvimento do primeiro veículo de passageiros verdadeiro da empresa, o Crown de 1966, era um homem notável formidável conhecido por Kenya Nakamura. Segundo a opinião de todos, ele se irritava com facilidade e era exigente, assim como o muito mais famoso Taiichi Ohno na produção. Da mesma forma, assim como Ohno, ele era patrocinado por Eiji Toyoda - tanto Ohno quanto Nakamura afirmaram em diversas ocasiões que nunca teriam obtido sucesso sem o total apoio de Eiji. Além disso, como Ohno, outros ao redor dele não estavam necessariamente tão entusiasmados com suas idéias exigentes e pouco convencionais. Nakamura certa vez enfureceu tanto um membro do conselho (acusando o executivo, na frente dos outros membros do conselho, de "não ter expectativas mais elevadas" para a empresa) que foi rebaixado hierarquicamente, levando-o a se tornar um membro do sindicato. Como membro do sindicato, ele imediatamente acusou a liderança do sindicato de tentar destruir a empresa por que "tudo o que fazem é reclamar". Os líderes do sindicato responderam ordenando que os membros se recusassem a conversar com Nakamura. Dessa forma, durante certo tempo, ninguém na empresa sabia ao certo se Nakamura pertencia ao sindicato ou à administração! Um líder apaixonado, certamente.
Mas foi seu colaborador direto Tatsuro Hasegawa que codificou os comportamentos, as características e práticas de liderança que compunham um bom Engenheiro Chefe, o fator fundamental que habilitava um sistema no qual o líder não tinha poder real, e não tinha "autoridade".
Hasegawa ingressara na Toyota vindo do setor aeroespacial, onde aprendeu um processo de "engenheiro chefe" que era similar àquele que a Toyota acabou adotando (embora tenha observado que a Toyota, no decorrer do tempo, levou o processo ainda mais longe que as empresas aeroespaciais). De uma combinação de sua experiência prévia, combinada com suas observações do sucesso de Nakamura (e, arrisco dizer, seus fracassos), Hasegawa nos forneceu outra lista do que poderíamos chamar de "princípios gerenciais" ou características (minha tradução dos velhos documentos em japonês da Toyota):
- Obter um amplo conhecimento e um ponto de vista.
- Desenvolver uma visão clara.
- Realizar pesquisas que sejam amplas e profundas.
- Aplicar conhecimentos e habilidades para atingir resultados concretos.
- Repetir persistentemente cada tarefa conforme necessário - nunca desistir.
- Ter confiança, acreditar em si mesmo.
- Nunca delegar responsabilidade.
- Criar alinhamento com colaboradores diretos e outras pessoas chave.
- Nunca ir pelo caminho fácil para simplificar a sua tarefa.
- E possuir essas características: i. possuir os conhecimentos adequados, experiência nas habilidades; ii. ser firme utilizando um bom julgamento, iii. ter um espírito generoso e pensar grande, iv. ser calmo, sem ser demasiadamente emocional, v. ser vigoroso, vi. ser tenaz, vii. ser um líder que os outros desejam seguir, viii. possuir sólidas habilidades de comunicação e persuasão, ix. ser flexível, x. demonstrar uma dedicação abnegada para o sucesso.
O EC Hasegawa, além de nos fornecer os 10 princípios de um Engenheiro Chefe, também foi o EC do primeiro Corolla. Ele fez uma declaração famosa onde afirmou que a meta da empresa seria:
"Utilizar o Corolla para a felicidade e bem estar de todos na Terra".
A propósito, acredito que Eiji Toyoda sabia exatamente o que estava fazendo quando estruturou as coisas dessa maneira, atribuindo uma enorme responsabilidade ao Engenheiro Chefe enquanto mantinha a autonomia essencial das funções. Eiji criou um novo cargo denominado "Shusa" naquela época (o termo foi oficialmente alterado para o Engenheiro Chefe inglês cerca de um ano antes de eu ingressar na organização de desenvolvimento de produtos em 1991), apenas para Nakamura, um cargo "fora da organização", como descreveu Hasegawa mais tarde. Essa estrutura forneceu enorme flexibilidade e também incutiu controles primorosos para assegurar que os programas ou a empresa não se envolvam em uma situação extrema em função da influência excessiva de uma pessoa, função ou departamento específicos.
E daí?
Dessa forma, aqui está um alerta. Lembre-se que o sistema de Engenheiros Chefe - assim como todos os processos da Toyota - é uma solução para um problema. Para entendê-los adequadamente, é necessário voltar e considerar que problema a Toyota estava tentando solucionar. Essa é a maneira pela qual podemos sempre desenvolver soluções apropriadas para os nossos próprios problemas. Em questão não está apenas como copiar a solução da Toyota para o seu problema (no entanto, algumas vezes copiar é uma maneira interessante de começar - mais sobre esse tópico em uma coluna futura), mas considerar como a solução da Toyota para o seu problema pode informar nossa solução para os nossos.
Primeiramente, vamos revisar o problema. Se o foco de uma organização é o fluxo horizontal de valor, conforme supervisionado por uma pessoa responsável, embora existam funções fortes, como aqueles que realizam o trabalho efetivo evitam o temeroso problema dos "dois chefes"?
Estrutura organizacional - Escolha o seu veneno
- Organização funcional
- Inventada pela GM (inspirando-se em grande parte na DuPont, e, sem dúvida, em algumas outras empresas)
- Oferece excelência funcional
- Incentiva a operação "não funcional" em silos
- Estrutura de Unidades de Negócio
- Alinha recursos sob um indivíduo responsável
- Fornece alinhamento e direção em torno do produto
- Também resulta em silos próprios
- Resulta em redundância de recursos e perda de excelência funcional
Todos nós odiamos a matriz organizacional. E nossa resposta usual é desejar que ela pudesse, de alguma forma, simplesmente ... desaparecer. Ou, se pudermos enfrentar o golpe, tentar fazê-la desaparecer. Dessa forma, nós reorganizamos, talvez movimentando a organização lateralmente, colocando os recursos juntamente com o fluxo de trabalho das linhas de produtos ou serviços.
Mas, no final, tais reparos organizacionais são apenas ataduras ou consertos de curto prazo que levam aos seus próprios problemas. Em vez de uma reorganização, talvez uma contramedida melhor poderia estar no software de como fazermos nossas organizações funcionarem.
Concluindo, e temendo o seu protesto, "Certamente a Toyota pode fazer isso, mas não funcionaria aqui", favor recordar a afirmação do Corpo de Fuzileiros Navais dos EUA com a qual começamos: "A responsabilidade de um indivíduo para a liderança não depende da autoridade". Considero que estas questões são apenas (1) o reconhecimento da necessidade, (2) a decisão de tentar, e (3) a vontade de fazer isso funcionar.