Mas há um grande dilema: Como consigo o feedback sincero dos membros do meu time?

A resposta parece simples, afinal, não bastaria apenas perguntar? Bom, é quase por aí, mas deve-se tomar muito cuidado com o tipo de pergunta a se fazer.

A primeira regra que deve-se ter consciência é que nunca será possível conseguir feedback sincero com perguntas idiotas. Uma pergunta idiota geralmente é uma pergunta da qual você não quer ouvir a resposta, ou uma pergunta que você espera ouvir aquilo que você quer ou, até mesmo, uma pergunta cuja resposta é óbvia.

Pergunta idiota: No meio de um jogo de futebol, pergunta-se para a árbitro: Você está ocupado?

Qualquer ser vivo pensante saberá a resposta do árbitro. Se a pergunta é idiota a resposta é tola.

Isso não significa que a pessoa não queira te dar feedback, mas que há outras maneiras mais eficazes de se conseguir feedback. Não faça uma solicitação em forma de ordem pergunta direta.

Lembre-se sempre destas palavras pois elas serão a chave para o seu sucesso como líder de qualquer time em qualquer área ou empresa, especialmente para se obter feedback sincero e colaboração das pessoas. Estas são as palavras mais poderosas que existem para obter cooperação: “Eu preciso de”. Essas simples palavras são capazes de mágicas e feitos surpreendentes.

Pedir feedback não significa que você irá consegui-lo, especialmente se o pedido começar com “eu quero”. Quando você diz a alguém de seu time que você “quer” algo, a primeira coisa que essa pessoa pensa é: “ah, claro, todos queremos algo que não podemos ter”. Mas se você começa com “Eu preciso de”, significa que você pensou sobre o que é necessário para alcançar o que você está pedindo e, para tal, precisa da ajuda desta pessoa. É incrível como as pessoas adoram sentir-se necessárias, saber que podem ajudar com algo, isso faz toda a diferença entre escutar uma resposta tola e conseguir um feedback sincero.

Aprendendo a obter feedback: Preciso de feedback específico sobre meu plano para que a próxima iteração dê certo.

Simples e indolor, certamente você terá muito a ouvir e aprender.

Um líder é qualquer pessoa que possa lhe dar apoio e orientação necessárias para alcançar seu objetivo. Às vezes o seu maior desafio como líder é saber onde e quando cada pessoa do seu time executará este papel, e cabe a você conseguir obter o feedback necessário destas pessoas.

Infelizmente já vi muitos profissionais donos de diplomas, certificações e títulos vistosos importantes que só se preocupam em administrar, e não em liderar. Que se preocupam mais com os processos e esquecem das pessoas. Profissionais assim só se preocupam em manter a ordem e o controle, deixando em segundo ou terceiro plano coisas como: qualidade do trabalho, qualidade do ambiente de trabalho, convivência entre as pessoas e muitos outros aspectos sociais.

Na maioria das vezes as pessoas que estão sendo administradas por este tipo pedem demissão de seu chefe, isso mesmo, não pedem demissão da empresa, mas sim do chefe. Estão, de certa forma, dizendo basta à um gerente ineficaz ou incompetente.

Liderar é servir. Liderança está longe de ser uma forma de comando e controle, um líder não controla as pessoas, um líder deve favorecer a criação de um ambiente para que as pessoas criem, evoluam e tomem decisões por elas mesmas sem medo de serem repreendidas ou podadas, o líder deve inspirar confiança. Liderar significa conquistar as pessoas e envolve-las para que coloquem toda sua criatividade, emoção e coração para a realização de um objetivo em comum.

Liderar não é necessariamente o papel do seu chefe. Não é preciso ser chefe ou hierarquicamente superior para ser um líder e influenciar as outras pessoas a terem mais empenho e dedicação. Liderança é a capacidade de influenciarmos as outras pessoas para um bem comum.

Se você está disposto a se tornar ou melhorar como líder, lembre-se que precisa estar mais disposto ainda a mudar e aceitar mudanças. É impossível evoluir e melhorar sem mudar, seria loucura esperar um resultado diferente fazendo a mesma coisa de sempre. Você está disposto a mudar?

É muito fácil responder que sim, que se está disposto a mudar, mas a prática é muito difícil. Conseguir sair do seu pequeno universo, sua zona de conforto e entrar num mundo completamente novo e desconfortável é um desafio enorme e requer muita força de vontade e dedicação. Um líder não nasce líder, um líder se faz com muita dedicação, sinceridade, honestidade e força de vontade.

Lembre-se sempre: Gerência é o que fazemos, liderança é quem somos!

Será que você tem sido um bom líder? Olhe a sua volta, veja como estão as pessoas que você liderou, estão bem? Evoluíram e cresceram? Se tornaram pessoas ou profissionais melhores? Ou será que pediram demissão de você? Você saberá o resultado da sua avaliação rapidinho.

As inscrições já estão abertas e o curso será ministrado nos dias 05 e 06 de novembro, em Vitória, dependendo do número de inscritos atingir a quantidade mínima. Ele será ministrado num lugar compatível com o número de inscritos e tem duração de 16 horas.

O curso inédito no Espírito Santo será ministrado pelo instrutor Alexandre Magno, da AdaptWorks, único instrutor certificado pela Scrum Alliance no Brasil. O curso é um sucesso no Brasil inteiro e altamente requisitado em vários estados, tanto pelo fato de ser um curso oficial quanto por ser a porta de abertura para quem deseja não apenas conhecer mas também se certificar nessa metodologia ágil.

O participante ganha ao final do curso um certificado de Scrum Master, que é o início para a especialização na metodologia e associação na Scrum Alliance.

Para garantir sua vaga, envie um e-mail para contato@giran.com.br com seus dados de contato. Entraremos em contato para informar sobre o curso, preço, modos de pagamento e outros detalhes.

Mais detalhes sobre o curso no blog da Giran.

O pior é que ultimamente com tanta mídia gratuita por aí eu tenho notado muita gente se empolgando e embarcando na onda de “crítico matador”, e simplesmente querendo fazer o papel do grande sábio e conhecedor de todos os assuntos, criticando a tudo e a todos sem o menor pudor – e na maioria das vezes, sem a menor autoridade para tal.

Alguns pensam que girando a metralhadora e disparando críticas para todos os lados serão mais respeitados, ou sair logo criticando com todas as forças algo novo e recém lançado é um grande negócio para auto-promoção e até mesmo que a crítica é a melhor forma de “falar que sabe tudo do assunto”.

Mas assim como a síndrome do seniorismo, onde muita gente se tornou consultor senior de negócios após 1 ano de estágio, a síndrome do criticismo está se alastrando rapidamente. Hoje em dia todo mundo acha bonito criticar, todo mundo acha bonito fala mal, chamar o código alheio de porcaria (adoraram fazer isso com o twitter, recentemente) e por aí vai. E o pior, o que está alimentando essa nova síndrome é o comportamento da maioria que tem respeitado e tem até sentido uma pontinha de medo de quem adora criticar tanto.

É muito fácil criticar, aliás, qualquer idiota pode criticar, condenar e queixar-se – e a maioria dos idiotas faz isso. Por vezes é muito mais simples e não requer esforço e nem conhecimento, basta disparar qualquer asneira e pronto. HEI! Pessoal, acordem!

Já do outro lado nem é preciso ser conhecedor do assunto criticado para entender a crítica, afinal, célebres frases como: “- Odeio o framework X”, “- A API de fulano é horrível, deplorável” e “- O serviço do João é cheio de bugs”, são muito fáceis de serem compreendidas e são ótimas para causar uma má interpretação do assunto. Mas eu me pergunto, por que a pessoa odeia o tal framework, será por algum motivo que justifique a crítica ou seria apenas porque antes da síndrome do criticismo esta pessoa já passou pela síndrome do seniorismo e agora além de não saber a ferramenta ainda a crítica. Ou por que a API do fulano de tal é tão ruim, não seria por que a API é REST e o crítico só sabe fazer integrações usando stored procedures? Ou quais seriam os tais bugs no serviço do João, será que existem de fato?

Eu não quero que este post seja visto como uma crítica aos críticos, não é. De certa forma estou usando este espaço e escrevendo sobre isso exatamente aqui no meu blog pois tenho visto que muitos amigos e pessoas próximas que mantenho contato estão sofrendo de tal síndrome do criticismo. E isso é muito mais do que simplesmente chato, é frustrante.

A intenção é dar uma dica: estudem; estudem, ESTUDEM SEMPRE! Saibam ser humildes, tenham respeito pelo próximo e aprendam a admirar o trabalhos dos outros. Você será verdadeiramente respeitado e admirado ao dizer “- Parabéns pela sua implementação, sua idéia para resolver aquele problema foi ótima” do que criticando sem conhecer por pura falta de vontade e empenho em aprender, criticar de forma irresponsável somente vai trazer respeito e admiração de outros irresponsáveis e alienados.

Um exemplo simples e clássico

Eu estudei por muitos anos (há muito tempo atrás) seguidos e tive cerca de 4 anos de experiência profissional com Struts 1.x e até hoje penso duas vezes antes de formular uma crítica a este velho conhecido e tão calejado framework. Tenho consciência que não sei sobre todos os detalhes do Struts e que posso ter compreendido ou até utilizado de forma errada um ou outro recurso, por isso sempre penso se sou a pessoa mais adequada para aquilo, principalmente quando estou inserido num cenário que sei que a minha opinião, por exemplo, poderá repercutir ou influenciar a opinião de outras pessoas. É preciso ter humildade para reconhecer que não se sabe tudo e responsabilidade para criticar.

Mas mesmo assim eu escuto/leio muita coisa ruim do Struts que vem de pessoas que estão começando a aprender JSF sem nunca ter tido qualquer experiência com outra ferramenta/framework antes, que credibilidade dar a pessoas assim? Que credibilidade dar a uma pessoa que desdenha do código alheio sem nunca te-lo visto?

Responsabilidade, humildade e maturidade devem estar sempre juntas para te ajudar a manter-se em seu lugar e saber quando e como expor a sua opinião.

A empresa já está registrada há algum tempinho e, também, em atividade. Porém, hoje está sendo o seu lançamento oficial, basicamente com a marca e o site temporário pois a sede ainda está em fase final da reforma da sala e o site em ajustes finais para ir ao ar, muito em breve escreverei sobre a sede e como ela ficou.

Há algum tempo, muita gente não entendeu o meu pedido de saída da globo.com, mesmo tendo eu, acabado de entrar. O principal motivo que me trouxe de volta a Vitória foi exclusivamente pessoal e particular, não cabem comentários aqui no blog. Com o retorno, aproveitei o tempo ocioso e dei início ao trabalho que era também um sonho antigo, assim como entrar na globo.com, e agora o sonho saiu do papel e, literalmente, caiu no mundo real.

Giran Soluções e Ensino

Giran é o nome da nossa empresa. Durante quase 2 meses nós procuramos um nome, inventamos códigos e nomes estranhos, nomes ao contrário, nomes em japonês, em chinês, enfim, tentamos de um todo, mas nenhum deles tinha o domínio livre. Apesar de se tratar do nosso lado profissional e de ser agora a nossa cara, nossa marca e identidade ‘na rua’, o nome é algo muito especial, e não poderia deixar de ser algo nerd, afinal somos nerds. Darei uma pista e quem descobrir a origem do nome ganhará o direito de disputar uma partida de xbox na nossa nova sede; a dica: é um nome retirado de um rpg, mais especificamente de um mmorpg!

Conheça: Giran Soluções e Ensino

Na Giran o nosso foco de trabalho serão contratos de consultoria e coaching em projetos java e rails, gerenciamento de projetos com Scrum e, também, ensino e treinamento especializados em java, php e rails. Quando o site estiver no ar muitas outras informações e detalhes sobre nossa área de atuação serão disponibilizadas.

A criação e lançamento da Giran ocorreu, antes de tudo, após uma longa conversa sobre valores, princípios, visão e expectativas para a empresa e sobre como faríamos para criar e manter uma empresa jovem e descontraída e ao mesmo tempo profissional e comprometida. Nós não poderíamos simplesmente abrir uma outra ‘old big company’ baseada em velhas e obsoletas idéias e trabalhar de forma caótica e improdutiva, na nossa empresa usaremos o que há de ponta para o desenvolvimento e gestão dos nossos projetos e treinamentos, estudaremos cada caso com o máximo de detalhes, cada cliente, cada projeto afim de aplicar o que for melhor para cada situação, exatamente igual fazemos em nosso dia-a-dia e em nossa evolução pessoal+profissional.

Na Giran todo o nosso trabalho será pautado e muito fortemente baseado nos valores e princípios de Extreme Programming, especialmente em alguns que temos uma certa predileção:

• Respeito – Pois este é a base para todos os outros valores e princípios, é o motivo pelo qual nascemos e pelo qual prosperaremos.
• Coragem – Não seremos reativos à mudanças, não cortaremos a nossa criatividade e de nossos funcionários. Lidaremos com o risco de forma aberta, transparente e responsável; e erraremos o quanto for preciso para chegar o mais próximo possível da perfeição e continuar sempre no caminho da evolução e da melhoria contínua.
• Simplicidade – Seremos pragmáticos, sempre! Não queremos fazer mais do que a concorrência, não queremos fazer o desnecessário, não queremos ser ‘grande e flácido’, nós queremos resolver o seu problema.
• Comunicação – Somos emocionais, queremos olhar nos seus olhos, conversar e sentir as suas emoções, tom de voz, expressões faciais, gestos e postura, não vamos trocar uma visita por um e-mail ou telefonema.
• Qualidade – Não pode haver desperdício. Não pode haver software ruim ou de má qualidade. Prezamos fortemente pelo código que escrevemos e sabemos que ele é o nosso produto, não se trata de nível de qualidade, o objetivo é a altíssima qualidade, e é isso que importa.

Outro ponto de grande realização para nós com a abertura da Giran é poder participar e atuar de uma forma ainda mais forte e ativa no desenvolvimento de projetos open source e nos grupos e comunidades da nossa região. Poder agora, como empresa, dedicar tempo remunerado a estes projetos, incentivar e bancar a participação dos nossos funcionários, poder viabilizar eventos e outras atividades e muito mais. Hoje nós já participamos fortemente como membros e coordenadores no ESJUG, Agile-ES, PHP-ES, Linux-ES e EESL e estamos iniciando a participação no Vitória Perl Mongers.

E é isso, agora é correr atrás e tentar aplicar tudo que eu disse para meus antigos chefes/gerentes e ver, na prática, se será bom ou ruim, fácil ou difícil, lucrativo ou não e por aí vai. Agora o sonho acabou, virou realidade!

O que muitos não vêem é que, com isso, a receita para o fracasso já está praticamente concluída. O trabalho e esforço de semanas ou até meses onde o arquiteto deu tudo de si, não passa, simplesmente, da pura arte da adivinhação, de previsão do futuro, de achismo e nada mais. O que ele achou que o cliente desejaria, o tempo que ele achou que iria demorar, os prazos que ele tirou da cartola e os resultados que ele sonhou acontecer dificilmente serão alcançados. Isso não acontece por falta de capacidade do arquiteto, pelo contrário, em alguns casos ele é realmente O cara da empresa e possuidor de vasta experiência, mas tentar prever o futuro não é uma ciência exata.

Apenas uma observação aqui: Não sou contra o levantamento de requisitos e especificação de escopo, pelo contrário, acho que é um trabalho de extrema importância, apenas não concordo com a forma que este trabalho é feito na grande maioria dos projetos, onde o pensamento e a organização em cascata impera.

O fracasso numa situação dessas poderá vir quando o cliente, no meio do projeto, resolver mudar tudo. O arquiteto terá que trabalhar mais alguns meses em um novo escopo? O cliente entenderá que deverá pagar por mais alguns meses de replanejamento de escopo? Como o seu escopo reagirá a mudanças, ele foi preparado para isso?

Ou quando ao final do projeto, somente ao final do projeto, uma versão usável for apresentada ao cliente e ele achar que você se enganou e apresentou a solução de um outro cliente a ele, tamanha a discrepância entre as expectativas do cliente e da empresa. E agora, como fica a situação? Inicia-se um novo projeto!? E quem pagará por isso?

Ou no pior dos casos, durante o desenvolvimento do projeto vê-se que o que o arquiteto previu para 10 meses de trabalho com uma equipe de 5 pessoas estava completamente furado, você vai precisar de 20 meses. Então qual é a brilhante ideia? Aposto a minha sacola de mendorato: “- Vamos dobrar a equipe, com 10 pessoas conseguiremos diminuir o prazo pela metade e assim ficaremos dentro do esperado”. É tiro-e-queda, será um grande fracasso. Ter um escopo flexível e incremental seria muito melhor do que incrementar a equipe para seguir o escopo. Afinal de contas, desde quando nove mulheres juntas são capazes de gerar um filho em um mês? Manusear prazos, expectativas e custos de um produto desta forma, definitivamente não dá certo.

Existe ainda um outro lado, aquelas pessoas que não querem se preocupar com problemas de escopo, que não querem ter problemas ao final do projeto se tiverem que discutir com o cliente sobre determinada funcionalidade está certa ou errada ou se deveria existir ou não, estas pessoas são as adeptas do escopo fixo.

Eu costumo dizer que, em projetos com escopo fixo só têm uma certeza: ele irá fracassar!

O fracasso nestes projetos não precisa ser necessariamente a não entrega do produto. Isso quase sempre acontece, mas milagres podem acontecer e o projeto pode ser concluído e entregue no tempo, mas ainda assim será um fracasso. Será um fracasso para o seu cliente, que demandou o projeto. Assim como dois mais dois são quatro, eu aposto o meu mendorato de novo que o seu cliente certamente mudou de idéia em vários pontos durante o desenvolvimento do projeto, mas você, esperto que é, já tinha o seu escopo fixo e para não sacrificar a “entrega” e seguir o maldito escopo, esfregou na cara do seu cliente que ele não poderia mudar nada, que ele não tinha esse direito, que estava escrito no escopo assim como é gravado em pedra e nada daquilo poderia mudar, em hipótese alguma, e mais, se ele fosse teimoso e insistisse em mudar teria uma saborosa multa à sua espera.

Sem dúvida esse cliente não estará com você num próximo projeto. Este é um tipo de fracasso que é muito pior que o anterior, certamente. Seria preferível não entregar tudo o que estava no escopo, renegociar o escopo, incrementá-lo ou decrementá-lo, mas entregar tudo o que o cliente pediu durante o projeto do que ignorar e trocar a sua opinião por um documento que foi feito em alguns dias ou horas numa tentativa de prever o futuro, que acaba quase sempre de modo frustrante para ambas as partes – para a empresa que trabalha desta forma, nem tanto, pois a essa altura ela já terá recebido todo o orçamento do projeto.

Trabalhar com o escopo de forma iterativa e incremental não é nenhum bicho de sete cabeças, seu pescoço não estará na corda desde que todas as expectativas estejam alinhadas, insira o seu cliente no projeto, faça-o participar de todas as etapas e ele mesmo verá e terá consciência de que em determinados pontos o escopo precisa mesmo ser alterado – para mais ou para menos. Aprenda a negociar e gerenciar expectativas com o cliente e o escopo passará a ser o grande amigo do seu projeto.

Além dos links dos artigos no último parágrafo, o Manoel Pimentel disponibilizou uma ótima apresentação sobre Gestão de Requisitos através de práticas Ágeis e Enxutas, que mostra extamente algumas das formas de se trabalhar com escopo incremental e iterativo.

Geralmente os gerentes e diretores (na maioria das vezes) serão duros e contra qualquer tipo de mudança simplesmente pelo fato de a empresa ter gastado centenas de milhares de dinheiros, logo, pensarão por muito tempo que isso (metodologia customizada) deverá dar algum resultado, o que acaba não acontecendo na maioria da vezes. Essa negligência e fraqueza em assumir logo o prejuízo e tentar mudar – para melhor – acaba acarretando em prejuízos muito maiores no futuro, demissões em larga escala, troca de diretoria e por aí vai, já vi isso antes.

Outra justificativa muito usada para evitar mudanças será a falácia de que “em time que está ganhando não se mexe“. Grande parte das vezes falta coragem ou maturidade para enxergar que o time não está ganhando e que precisa ser modificado, sim. Também não é incomum encontrar situações onde a mudança não é vista com bons olhos pois as metodologias pra inglês ver, as certificações (de parede) e demais honrarias são mais valorizadas do que às pessoas e o produto que a organização entrega, então, nesses casos pouca importa se está bom ou ruim.

Mas onde eu quero chegar com esse post? Todas estas situações que falei até agora são conhecidas pela maioria dos desenvolvedores e sabemos que são situações difíceis de serem vencidas, eu mesmo já fracassei em algumas tentativas de mudança diante de tais situações e felizmente já obtive muitos sucessos também.

Recentemente, almoçando com um grande amigo acabamos caindo no papo sobre as nossas empresas e clientes e falamos sobre um caso em especial. Um cliente em que já haviámos trabalhado, onde enfrentamos todas aquelas situações anteriores de uma só vez – acreditem! – continuava na mesma. Com os mesmos problemas de sempre (atraso), mesmos gerentes/diretores e as mesmas pseudo-metodologias e regras internas, a única coisa que não era a mesma eram os clientes, nem preciso dizer o porque.

Mas a disucssão não chegou a ser prática ao ponto de “seja ágil”, “você precisa praticar TDD/BDD”, “agarre-se ao PMBok” ou “se você não aderir ao Scrum não vai ter jeito”, nada disso, não estávamos questionando a metodologia, nem as regras em si, mas sim a resistência em mudar. Fazendo uma breve retrospectiva vimos que 100% dos últimos projetos não haviam sido entregues na data prevista, desses 100%, 100% tiveram o orçamento o estourado e, desses 100%, 100% não atenderam a todas as expectativas do cliente e foram entregues com features a quem do esperado.

Diante de um cenário como esse, por que não deveríamos tentar mudar? Por que não tentar fazer alguma coisa diferente? Se estamos “sendo ágeis com scrum+xp” por que não tentar um modelo mais lento!? Se o RUP/MPS.Br/QualquerCoisa não está dando certo, por que não mudar e tentar outro? Se as metodologias e regras internas não estão sendo suficientes, por que não deveríamos tentar outra? Com um histórico de atrasos e fracassos, o que poderia acontecer de pior, atrasar 9 semanas ao invés de apenas 7!?

Não fique na mesma por muito tempo, mesmo que o seu time esteja ganhando e esteja realmente na frente, experimente mudar, tente melhorar, evoluir. Avalie sempre não só as mudanças, mas veja o que elas poderão fazer por sua organização, por seus projetos, se algo pode ser melhorado, vá em frente, se algo pode piorar, avalie o seu presente e passado e veja se vai, de fato, piorar, ou se você já estava “na pior” e não estava se dando conta. Não seja cético correndo atrás do que está na moda, na crista da onda, isso nem sempre será bom pra você, mas procure sempre avaliar sua situação e ver o que você pode tentar melhorar e o que pode, sem prejuízos, continuar na mesma.

Nota: Esta história, assim como milhares de histórias que recebemos por e-mail todos os dias, não tem um autor oficial, ou tem um “novo” autor a cada semana ou uma versão diferente ou uma adaptação diferente. Numa rápida pesquisa no google eu encontrei dezenas de variações da história e principalmente do autor, então como eu não sei quem é o autor verdadeiro e como no e-mail que eu recebi também não havia citação para o autor, deixarei sem referências, mas que fique claro que se alguém souber o autor verdadeiro pode dizer que eu atualizarei o post com as referências.

A história: A Corrida de Canoas

Duas empresas (de acordo com a história, uma brasileira e outra japonesa) criaram um desafio que consistia numa corrida anual de canoas, onde, em cada canoa iriam até 8 homens de cada empresa.

Então as equipes treinaram arduamente e estavam em sua melhor forma no dia da corrida. No entanto, os japoneses venceram com mais de 1km de vantagem.

Após a grande derrota a equipe brasileira ficou muito desanimada e chegou a pensar em desistir, mas o diretor geral da empresa brasileira decidiu que venceriam no próximo ano e, para tal, criou um grupo de trabalho para examinar o que houve de errado na corrida.

Depois de muito tempo de estudos, análises e relatórios, o grupo que examinava os fatos da corrida concluiu que a equipe japonesa possuía em seu barco um capitão e sete remadores enquanto a equipe brasileira possuía sete capitães e um único remador. O diretor geral tomou uma decisão e contratou uma terceira empresa para analisar a estrutura de sua equipe.

Depois de longos meses de trabalho os especialistas contratados concluíram que a equipe possuía capitães de mais e remadores de menos, e informou isso ao diretor geral. Este, por sua vez, decidiu então que a estrutura da equipe deveria ser alterada imediatamente.

A estrutura da equipe foi então reformulada e ao invés de sete capitães, teria agora apenas 4 capitães, dois supervisores de capitães, um chefe de supervisores e um remador. Mas agora o remador teria atenção especial, toda a equipe funcionaria a seu favor, o remador deveria ser melhor qualificado, ter mais treinamento, ser constantemente motivado e principalmente ser conscientizado de sua inviável responsabilidade.

Chegou o próximo ano e ao final da corrida a equipe japonesa venceu mais uma vez, porém com mais de 2km de vantagem, o dobro da vantagem do primeiro ano de corrida.

O diretor geral em conjunto com toda a diretoria da empresa brasileira decidiu que o remador deveria ser demitido pelo seu péssimo desempenho na corrida. E decidiram também, que para não desmotivar o resto da equipe todos seriam recompensados com um prêmio por sua enorme dedicação e motivação que tentaram, sem sucesso, incutir na equipe.

O diretor geral preparou um relatório da situação, no qual ficou demonstrado que: A melhor tática havia sido escolhida, a equipe estava bem organizada e que havia motivação suficiente mas que o material utilizado ainda deveria ser melhorado e, por último, que um remador mais qualificado e empenhado deveria ser contratado.

Hoje a empresa está cogitando a idéia de trocar ou construir uma nova e mais moderna canoa.

Fim da história! =D

Apesar de parecer engraçado, esse cenário é, na verdade, trágico quando acontece na vida real. Não é difícil encontrarmos situações como essa em nosso dia-a-dia. Aqui no Espírito Santo costumamos dizer essa é uma situação onde temos muitos caciques para poucos índios.

Muitas boas conclusões podem ser tiradas dessa história: os muitos caciques para os poucos índios, inabilidade para detectar a causa raiz de um problema, agir onde não está a causa problema, superestimar os problemas (vide o grupo para analisar a corrida e em seguida os consultores especialistas) e principalmente, foco no processo e não nas pessoas.

A verdade é que com o tempo, evolução pessoal, crescimento e maturidade, experiência técnica e profissional estarão sendo agregadas constantemente em todos nós, em nosso perfil, e precisamos ser capazes de identificar o momento correto para realizar uma mudança e saber quando estamos deixando de ser importantes em uma área ou função para ser mais importante em outra área ou função, aplicando esse novo conhecimento adquirido.

Pensando exatamente nisso, não exatamente só por pensar nisso, mas dado a diversos outros fatores que também me desmotivaram, comecei a fazer um tipo de auto análise e observação diária do meu trabalho, atitudes e de como estava resolvendo as coisas, agregado com isso comecei a ler sobre o assunto (liderança) e pra minha surpresa identifiquei vários pontos entre a minha real e atual situação com a minha primeira leitura nessa área: Know-How, de Ram Charan. Este post não é uma propaganda do livro, obviamente. Mas quem quiser comprar eu aconselho fortemente. Empolgado com o assunto estou lendo atualmente The World’s Most Powerful Leadership Principle: How to Become a Servant Leader, do mesmo autor do conhecido Monge e o Executivo, James C. Hunter, (que já estou gostando muito, do livro) e Moments of Truth, de Jan Carlzon.

Com base no último livro que li, e seguindo as premissas do próprio, tomei a liberdade de resumir as oito competências que todo líder deve ter, ou pelo menos saber como praticá-las com perfeição e habilidade:

• Posicionar e reposicionar – Encontrar uma idéia central para os negócios que atenda às necessidades do cliente e que seja lucrativa para a empresa.
• Identificar mudanças externas – Detectar tendências externas para colocar a empresa na ofensiva, sempre.
• Comandar o Sistema Social - Reunir as pessoas certas com comportamentos e informações corretos para tomar decisões melhores e mais rápidas afim de alcançar bons resultados.
• Avaliar pessoas – Aferir pessoas com base em suas ações, decisões e comportamentos, comparando-os com os critérios inegociáveis da função que cada pessoa deverá ocupar.
• Moldar equipes – Conseguir que líderes altamente competentes e com ego (geralmente) enorme trabalhem em perfeita harmonia e cooperação.
• Estabelecer objetivos – Determinar o conjunto de metas que equilibram o que a empresa pode vir a ser com o que ela pode alcançar de modo realista.
• Estabelecer prioridades precisas – Definir o caminho e alinhar recursos, ações e energia para realizar os objetivos da empresa.
• Enfrentar forças externas ao mercado – Prever e reagir às pressões sociais fora de seu controle, mas que podem afetar a empresa e às pessoas.

E, apesar de não ser exatamente o título do livro e nem ser a idéia central, ele também aborda de forma muito eficiente os principais traços de personalidade que podem ajudar ou interferir com as competências (acima) inegociáveis de um líder:

• Ambição – Para conquistar algo notável, MAS NÃO vencendo a qualquer preço.
• Determinação e tenacidade – Para buscar, persistir e realizar, MAS NÃO persistir em um plano que não está dando resultado.
• Autoconfiança – Superar o medo do fracasso, da reação ou a necessidade de ser amado; usar o poder criteriosamente e NÃO se tornar arrogante ou narcisista.
• Abertura psicológica - Para ser receptivo a idéias novas e diferentes E NÃO impedir o progresso de outros profissionais.
• Realismo – Para ver o que pode de fato ser alcançado E NÃO se esquivar dos problemas ou presumir o pior.
• Vontade de aprender – para continuar a crescer e aprimorar seu know-how E NÃO repetir os mesmos erros.