A Segunda Lei do Mal Gerenciamento

No livro de Tom DeMarco Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency” ele discute, entre outras coisas, a Segunda Lei do Mal Gerenciamento, que é se colocar no lugar do faz-tudo. Ou seja, se você deseja que um projeto falhe, se coloque na posição de seu próprio subordinado e faça parte do trabalho, ao invés de cuidar do projeto como um todo. Se você é de TI, vá lá e programe, ao invés de ajudar sua equipe a programar melhor. Já vi isso com tanta frequencia em novos líderes de TI, já que gerenciar é difícil e bons programadores tendem a serem promovidos a posições de liderança, que as pessoas agem como se isso fosse normal ou até esperado. Tem empresas em que a alta gerência até avisa: “Você é o nosso melhor desenvolvedor e está sendo promovido pra gerência da equipe. Mas isso não significa que você vai deixar de trabalhar, digo, programar. ”

Não apenas seus melhores desenvolvedores estarão fazendo um trabalho pior, já que líderes são constantemente interrompidos e não podem se concentrar numa única atividade,  como também afundam junto com o projeto quando são colocados no caminho crítico. Nos casos desses líderes, é a pura visualização do “Princípio de Peter“, que diz:

Princípio: Numa hierarquia, todo empregado é promovido até atingir seu nível de incompetência.

Corolário: Com o passar do tempo, todas as posições tendem a ser ocupadas por incompetentes.

A solução óbvia é contratar gerentes apenas pela sua capacidade de gerenciamento e não pela sua capacidade técnica, certo? Errado! Bem-vindo ao mundo de Dilbert, onde gerentes não são respeitados e não tem conhecimento suficiente para distinguir o certo do errado, não conseguindo controlar um projeto quando os subordinados estão fazendo coisas estúpidas:

Você quer autorização para substituir a rebinboca da parafuseta faltando uma semana para o prazo final e reescrever o sistema usando a rebinboca 2.0 plus? Unh… Tá. Pode fazer.

Na minha opinião, não tem jeito. Você deve promover pessoas com boa bagagem técnica. Dito isso, como evitar o Princípio de Peter? Talvez seguindo essas recomendações na escolha do líder:

  1. O líder não deve ser o melhor codificador do time, mas ele deve ter sido um dos melhores: Para ser respeitado, saber distinguir o certo do errado e avaliar o time.
  2. O líder tem que saber negociar e se comunicar: Para comunicar a visão do projeto, mediar e resolver conflitos, motivar a equipe e ouvir sugestões e reclamações.
  3. O líder deve ser organizado: Boa parte do que um líder faz é organizar e manter o projeto: cuidar do cronograma, listas de riscos e defeitos, etc.
  4. O líder deve ter sido um “ponto focal”: estar acostumado a ser interrompido e consultado e não se importar ou se prejudicar com isso: Se ele era comumente consultado é porque ele já foi um líder na prática, se é que ainda não foi no papel. Além disso, pessoas comumente consultadas estão mais acostumadas a colocarem o próprio trabalho de lado para responder e ajudar o colega. Este é o principal papel do líder: “esquecer” seu próprio trabalho e desenvolver o time.
  5. O líder tem que querer o trabalho e saber suas implicações: Não é qualquer pessoa que está disposta a deixar de “produzir” para passar a liderar e desenvolver pessoas. Liderar é deixar de lidar com coisas concretas, deliverables, e passar a lidar com pessoas e problemas que normalmente não tem começo, meio e fim. Além disso, o líder vai passar a programar por bem menos tempo (ou até deixar de programar). Isso é um problema para o perfil de líder que estamos falando, líderes que são bons desenvolvedores e investiram muito tempo e esforço para aprenderem uma coisa que, muito provavelmente, adoram fazer.
  6. O líder tem que ser aceito como tal pelo time: O líder tem que ser reconhecido e aceito pela equipe. Normalmente, inclusive, é bom que ele seja formalmente aceito. Uma das opções é usar o Decider Protocol na aceitação do líder pela equipe.
  7. O líder tem que passar o que só ele sabe para os desenvolvedores: Ou seja, se você é o único que conhece bem um módulo, faça coaching o tempo que sua equipe precisar para que eles saibam fazer tudo sozinhos.
  8. Tenha um líder mais experiente acompanhando-o de perto: Para ensinar habilidades de gerenciamento, avaliar o novo gerente e, se acontecerem problemas sérios e o novo líder não for adequado, assumir o projeto.

Há situações em que a maneira correta de mostrar ao time que eles podem fazer algo extraordinário é fazendo você mesmo. Mas estas situações são raras. Eu acredito que um líder deve codificar de maneira inversamente proporcional ao tamanho da equipe. Se você lidera uma equipe de uma pessoa (fora você), boa parte do tempo você pode passar codificando. Mas com um time de mais de 5 pessoas, provavelmente você só vai poder pegar uma atividade aqui e outra ali. O resto do tempo você deve estar cuidando de desenvolver a equipe e do “todo” do projeto.

Por fim, é importante ressaltar que o inverso da Segunda Lei não é verdade. Só porque você não está codificando não significa que você está fazendo um bom papel como líder. Ninguém disse que a vida daquele que “sempre dá o crédito pelo sucesso ao time e recebe toda a responsabilidade pelas crises” ia ser fácil.


P.S.

Ah, é verdade… Fiz um post todo falando da segunda lei sem nem comentar a primeira. Comentários sobre ela ficam para outro dia. Antes que o leitor pergunte, no entanto, a primeira lei do mal gerenciamento é:

If something isn’t working, do more of it – Tom DeMarco

5 comments to A Segunda Lei do Mal Gerenciamento

  • JPMagalhaes

    O Princípio de Peter é realmente genial!!! Fiquei uns 15 minutos aqui pensando e tudo que lembrava se encaixava perfeitamente. Depois fiquei preocupado com as implicações disto na minha vida… 😛
    No mais, bom post. Só fiquei um pouco perdido durante a leitura se você estava falando do líder de equipe ou do gerente de projetos (em uma empresa que tenha os dois níveis, claro). Mesmo já tendo passado por várias equipes em que os gerentes não sabiam nada de TI e não concordar com isto, colocar uma pessoa técnica pra assumir toda a gerência pode ser ainda mais arriscado pelo tempo exigido com as tarefas ‘burocráticas’, além das atividades de um líder. Hoje sou mais a favor de um modelo intermediário onde pode existir o gerente leigo em TI (que pode inclusive gerenciar mais de uma equipe) desde que, logo abaixo, exista um líder de equipe, focado no projeto e na equipe. Este líder pode ainda acumular a liderança técnica, ser o arquiteto, sozinho, se o projeto for pequeno, ou dividindo esta função com mais alguém, caso o projeto seja grande.
    []’s

  • Henrique Borges

    João, obrigado pelo comentário. Realmente não ficou claro se eu estava falando do líder de equipe ou do gerente do projeto, talvez porque eu ainda não tenha na minha cabeça muito clara essa distinção. Acho que essa distinção deveria ser deixada apenas para cargos (que levam em consideração experiência) ao invés de papéis (que levam em consideração responsabilidades e tarefas). Acho importante ressaltar que eu não estava falando do líder técnico (arquiteto). Essa função considero um pouco diferente, mais voltada para o projeto e o produto e menos para a equipe. Posso falar um pouco sobre essa distinção em outro post.

    Voltando ao seu questionamento, o que você chama de gerente é a pessoa que passa a maior parte do seu tempo cuidando de reuniões com cliente e a alta gerencia? Chamo esse papel de Gerente de Projetos (o plural é importante) ou Gerente de Conta. A principal função dele é manter a satisfação do cliente, cuidar de parte do portifólio de projetos da empresa e manter o alinhamento com a alta gerência, as estratégias, padrões e políticas organizacionais. Essa pessoa está mais perto da direção e dos níveis estratégico e tático do que da equipe e dos níveis tático e operacional.

    Ou o gerente de projeto (seguindo a definição do PMBOK) é a pessoa que cuida da motivação da equipe, do escopo, do cronograma e de resolver impedimentos do projeto? É deste líder que eu estou falando. É ele que tem noção se as coisas vão sair no prazo, que deve fazer o planejamento inicial do projeto, que sabe se Fulano ou Cicrano estão trabalhando dentro das expectativas, ele que (na prática) termina sendo a pessoa que guia e desenvolve a carreira dos subordinados e que acompanha o dia-a-dia do projeto e seu planejamento. Na minha opinião essa pessoa precisa ter os 8 requisitos que enumerei. E, apesar de em alguns lugares ser chamado de líder de equipe, segundo o próprio PMBOK é chamado de gerente.

    Em muitas empresas esses papéis de gerencia de conta (cliente) e de projeto são misturados e, porque é menos visível, o trabalho de desenvolver a equipe e realmente gerir o projeto acaba sendo relegado em prol do cliente, da alta gerência e da burocracia. Assim, nessas empresas, o que eu chamei de “Gerente de Conta/Projetos” acaba sendo responsável pela equipe, pelo escopo e pelo cronograma, mesmo sem saber o suficiente sobre a parte técnica, sem conseguir acompanhar o dia-a-dia da equipe com a qualidade necessária e sem ser respeitado pelos seus subordinados (o que é mais frequente do que muita gente imagina).

    Eu acho que os dois papeis devem ser separados, com a equipe normalmente se reportando e sendo acompanhada apenas pelo líder da equipe (seja lá qual o nome que ele tenha) e este se reporta ao gerente de projetos/conta ou a um “gerente de gerentes”. A liderança técnica (arquitetura) entra como uma outra carreira, auxiliar e paralela a de gerencia de equipe.

    Qual sua opinião? Esclareci suas dúvidas iniciais?
    []s

  • JPMagalhaes

    Sim. Sim…
    A liderança técnica é um ‘problema’ a parte, vamos esquecê-la, aqui.
    O que acontece algumas vezes (e a maioria dá errado) é que colocam uma só pessoa pra as outras duas funções (já trabalhei em equipes assim) e o resultado não é muito bom, como se pode facilmente imaginar. Acredito assim que sobre esse ponto pensamos da mesma forma. Era só um problema de, digamos, nomenclatura. 😀
    Entretanto…
    Esse seu comentário quase post levantou um outro ponto interessante: o papel do líder de equipe (vamos chamar assim para não entrar em conflito com o gerente de projetos/conta) no acompanhamento do desenvolvimento pessoal dos colaboradores. O que questiono, mais especificamente, é a eficiência e a qualidade deste modelo em uma organização orientada a projetos. Como sabemos, nestas organizações, as equipes mudam muito.
    O que já vi (e muito), na prática, é essa gerência ser quebrada (descontinuada), voltar a estaca zero ou mudar completamente de um líder para outro por simples mudança de líderes ou pelo fim normal de um projeto e os colaboradores se sentirem desmotivados e até perdidos. O que dizer de líderes que prometem mundos e fundos para motivarem suas equipes e, acabando o projeto, seguem suas vidas em outros projetos e esquecem das promessas feitas? Logicamente esta situação é insustentável, mas acontece.
    Neste ponto, de acompanhamento do desenvolvimento pessoal em uma organização orientada a projetos, acredito que a melhor solução é um processo claro e bem definido administrado por uma gerência de engenharia centralizada. Claro que este modelo só pode funcionar se os líderes contribuírem suprindo toda a informação necessária ao projeto e sendo a principal ferramenta de ações e cobranças.
    Bem… acho que me escrevi demais!!!
    O que acha desta última situação?
    Obs.: pondera se é melhor responder aqui mesmo ou escrever um post sobre isso.
    []’s

  • Henrique Borges

    Acho que vale um post sobre o cargo de Supervisor de Engenharia, sim (que é como já vi chamarem o cargo que você descreveu). Ele não é a única “solução ótima”, inclusive 😉 Falo sobre isso no próximo post.

  • Amaze, excellent blog design and style! How much . crédito pessoal rápido e fáciltime have you ever been running a blog with regard to? you make blogs appearance quick. The overall glance of your respective website is wonderful, while logically as the written content!

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>