Liderando uma equipe, estou sendo arrogante?

Estou no que me parece uma posição muito estranha. Sou "líder de equipe" na função de um projeto específico, Sr. Engenheiro de Software no cargo. Na minha equipe, tenho 4 desenvolvedores, um dos quais desempenha um papel semelhante em outro projeto, mas agora o meu recebeu prioridade, então ele está trabalhando no meu. Eu também tenho 2 testadores, um dos quais é gerente. Outro membro da equipe é o "Representante do cliente", que faz parte de um departamento completamente não relacionado. Eu também tenho um gerente que está diretamente acima de mim e acredito também acima do gerente de teste que faz parte da minha equipe ... embora não tenha tanta certeza disso.

Tentei obter esclarecimentos sobre por que meu papel é exatamente várias vezes. Tem sido difícil para mim descobrir onde minha autoridade começa e termina, se é que eu tenho alguma. A resposta com a qual estou trabalhando atualmente é que sou o "líder técnico" da equipe. Isso parece significar que minha autoridade está em decisões técnicas relacionadas a arquitetura, design e padrões de processo / codificação, pois pertencem ao próprio código do produto.

Hoje, surgiu algo e os resultados do código que eu delegava a um dos membros da minha equipe eram mostrados ao restante da empresa em nossa reunião de apresentação do Scrum. A pessoa representante do cliente faz a exibição. Algo foi mostrado hoje que eu realmente discordava e ninguém nunca me perguntou se eu queria ter uma opinião sobre o que aconteceu. Em resumo, para fornecer a capacidade de um usuário exibir um valor em um relatório das seguintes maneiras (unidades "doc", unidades de design, arredondadas, não arredondadas), eles forneciam campos de acesso para cada permutação. Portanto, temos o valor em unidades de documento arredondadas, unidades de design arredondadas, unidades de documentos não arredondadas, unidades de design não arredondadas. Cada registro com o qual o usuário deseja trabalhar possui muitos desses valores e cada um é permutado dessa maneira.

Eu realmente odeio isso.

As pessoas que mostramos isso querem ter certeza de que a API que usamos para relatórios é a mesma que a maneira como fazemos coisas como exportar dados para o Excel. Infelizmente, agora estamos ganhando esse impulso em uma direção que eu acho muito, muito ruim.

Fiquei um pouco chateado na próxima reunião e perguntei às duas pessoas que haviam feito isso: "Por que eu não estava envolvido nessa decisão?" É uma questão que continua surgindo e eu tenho dificuldade em parecer que as pessoas da equipe que devo liderar me perguntem se eu quero me envolver. Às vezes não, e acho que tudo o que eles criarem será bom. Outras vezes eu faço. A menos que as pessoas me perguntem, embora seja difícil saber que algo está acontecendo que precisa da minha opinião, elas não me dão essa oportunidade.

Infelizmente, minha autoridade não se estende a dizer às pessoas: "Da próxima vez que você fizer algo assim sozinho, sem sequer falar comigo, você será disciplinado". Essa é uma questão de "relações públicas" que é uma área que claramente não está no meu escopo de autoridade. Isso é bom para mim, na verdade, já que eu não quero ter que lidar com esse tipo de porcaria se alguém estiver disposto.

Hoje, porém, meu gerente, na frente de todos (o que eu acho que também é parcialmente minha culpa por abordá-lo dessa maneira) me disse que não posso me envolver em todas as decisões e preciso delegar.

É claro que acho que estou certo ... sempre faço. Não digo coisas que acho que são BS. Acho que deveria ter sido abordado sobre esse problema e perguntado se eu tinha uma ideia melhor. Minha orientação para isso seria realmente decidir apenas um valor a ser fornecido no momento, já que esse era realmente o estágio inicial de um novo recurso e discutir opções para fornecer acesso adicional no futuro, se desejado. Eu nunca teria aprovado ou recomendado a implementação atual e realmente não acho que deveria ter visto a luz do dia.

A questão é: sou eu quem não é razoável?

Bem, nós dois conversamos sobre isso e concordamos que nós dois "deixamos a bola cair" e parecemos estar na mesma página. Segunda-feira de manhã ... Vamos tentar garantir que meu papel seja claro na equipe e que sim, eu decido quando há uma alteração no projeto ou na tarefa que precisa acontecer; Sou proposto e concordo ou decido que preciso olhar mais profundamente. Depois, há alguns outros bits em que posso tentar trabalhar para garantir que eles saibam que podem vir até mim.

Parece que você precisa monitorar as confirmações de origem. O Perforce tem essa capacidade de forma nativa, o Git a usa através de ganchos, outros, com certeza, têm seus próprios métodos. Você não precisa escolher cada commit, mas pelo menos ter uma notificação e diferenciá-lo fornecerá um breve vislumbre de tudo o que está acontecendo no seu projeto.

Quanto ao seu gerente dizendo que você precisa delegar, não tenho tanta certeza de que concordo - com uma equipe de quatro desenvolvedores, você será capaz de lidar com isso. Mais, eu posso estar do lado dele (ou dela). Obviamente, mesmo em tarefas delegadas, você deve solicitar atualizações de status ou orientações sobre alterações de design, etc.

Nada negativo deve sempre ser levantada em reuniões - soa como você e seu gerente deixou a bola cair em um presente. A pior coisa que você pode sempre fazer para um peer é constrangê-los. Como líder (como no seu gerente), você precisa ser acessível e confiável. Desprezar alguém levará a ressentimento, que manchará sua capacidade de liderar sua equipe (além de levar funcionários descontentes).

Eu odeio ouvir a palavra "disciplina" de alguém em um papel principal. Disciplinar (pelo menos nesse contexto) é negativo e não é produtivo. Trabalhar com alguém (pessoalmente e não em um ambiente de reunião), descobrir por que eles fizeram algo e fornecer alternativas se você não concorda com as soluções propostas é o que deve ser feito. Às vezes, você descobrirá que a pessoa com quem está trabalhando está certa e seu instinto está errado. Por quê? Eles passaram mais tempo com esse problema específico do que você.

Outra coisa que me preocupa é "sempre acho que estou certo". OMI, essa é a pior atitude possível de qualquer liderança. Obviamente, você deve estar confiante em suas habilidades, mas percebe que, se você não está envolvido profundamente em um problema específico, mais vezes do que não, suas sugestões estão saindo da sua retaguarda (não importa quanta experiência você tenha) e talvez não seja o melhor. Se alguém que está se concentrando em um problema específico oferece uma alternativa, então é seu trabalho (assim como o deles, dependendo do nível de experiência deles) provar por que o seu é melhor, e não apenas dizer "Eu sou o líder e Eu sempre acho que estou certo ", que é o que sua sentença me leva a acreditar.

Para finalizar

Sim, você está sendo irracional em alguns pontos, mas outros não. Como líder, espero que, se houver alterações de recursos ou arquiteturais, elas sejam pelo menos passadas por você.

No entanto, também é seu trabalho garantir a qualidade geral do sistema e do código, o que você precisa fazer por conta própria. Sua empresa emprega revisões de código? Seus programadores projetam o que eles estão trabalhando antes de entrar no código? Caso contrário, você pode começar a empregar esse tipo de mecanismo de controle de qualidade.

Você pode estar fazendo check-out para gerenciamento e, se estiver, está falhando (o que pode não ser uma coisa ruim; muitos de nós somos bons desenvolvedores e seriam maus gerentes, e eu prefiro programar do que gerenciar programadores).

Os gerentes freqüentemente não têm autoridade para tudo o que se espera que eles façam. Fazer as coisas de qualquer maneira é um sinal de um bom gerente. Você precisa encontrar maneiras de levar as pessoas a fazerem as coisas sem realizar nenhum tipo de ação disciplinar. (Nota: depreciar as pessoas em público não é isso. Elogie em público, critique em particular e mostre algum interesse em seus subordinados como pessoas.)

Os gerentes também precisam delegar, mesmo quando dói. É provável que você gaste mais tempo lidando com esse problema do que gastaria escrevendo você mesmo, e tudo bem. Depois que você lida com isso, as pessoas que fizeram isso devem ter aprendido alguma coisa e têm menos probabilidade de fazer as coisas da maneira errada no futuro.

A maneira correta de lidar com algo assim é em particular, primeiro perguntando aos desenvolvedores por que eles exibiram dessa maneira. Não em uma reunião, e não assumindo antecipadamente que você está certo e que eles estão errados (mesmo se você estiver certo e eles estão errados). Dê a eles uma chance de explicar. Isso não significa que você tenha que concordar com a decisão deles; afinal, você é o líder técnico. Isso significa que você precisa dar a eles motivos para fazê-lo do seu jeito e deve resolver quaisquer problemas fundamentais que sejam mostrados durante a reunião privada.

Além disso, os gerentes são responsáveis ​​pelo que sai do seu pessoal. Você deve tentar não ser pego de surpresa por qualquer coisa que ele faça, principalmente na frente de um cliente. Isso pode envolver o controle de check-ins de código ou a realização de mini-conferências rápidas com seus desenvolvedores (embora você precise ter cuidado com isso, não deseja interrompê-los quando eles estiverem na zona). Possivelmente, você deve conversar com todos os desenvolvedores na tarde anterior à reunião com o representante do cliente.

Não leve para o lado pessoal

É um esforço de equipe. Você é o líder técnico, não o único cara no projeto. Você deve se concentrar em aprender com os erros ou mudar o processo.

Liderar e aprender

Parte de qualquer posição de liderança, incluindo um líder técnico, é entender que você faz o melhor que pode com as pessoas que possui. Quanto mais a equipe trabalha em conjunto, mais eles sabem quando apresentar as coisas e quando não. Apenas certifique-se de não cair na armadilha de ditar para sua equipe. Revise o que deu errado e o que correu bem semanalmente. Comunique-se com sua equipe se desejar que eles façam as coisas de maneira diferente. A medida punitiva deve sempre ser o último recurso e geralmente significa que você precisa demitir alguém ou falhou em seu papel.

Revisar antes da apresentação do cliente

Se você é o líder de um projeto, por que você não revisou o recurso e a implementação antes de ele ser apresentado?

Se estiver errado, conserte

Explique claramente por que algo está errado e mude. É mais caro, mas se estiver realmente errado, corrija-o. Se não estiver errado, apenas diferente de como você queria que as coisas fossem feitas; entenda que você não é o único que trabalha no projeto.

Havia alguma especificação documentando o que deveria ser implementado? Dado um requisito aberto demais, os desenvolvedores costumam preencher os espaços em branco (ou exigir microgerenciamento) com o que acharem apropriado.

Então você acaba indo ao seu gerente com "Então, em vez de trabalhar no que está na especificação, eles decidiram fazer o [recurso]. Agora estamos atrasados, por causa de um recurso que não foi aprovado em primeiro lugar".

Em seguida, você pode começar a trabalhar para remover o recurso depois que os desenvolvedores forem redesignados.

editar> E não, eu não acho que você esteja sendo arrogante. O trabalho deles acaba sendo seu traseiro.

Encontro-me muitas vezes na mesma posição e levantá-lo em reuniões e discussões parece não chegar a lugar algum. Às vezes, como último recurso, antes de me resignar a seguir a decisão tomada (embora não seja minha), envio um e-mail para as partes relevantes, declarando isso em preto e branco com minhas razões.

Em seguida, arquivava esse e-mail para garantir que eu o tenha para referência futura, caso seja necessário mais adiante quando um gerente ou cliente pergunta por que algo foi feito dessa maneira ou por que uma mudança está custando tanto para corrigir.

Eu acho que você estava errado em trazer isso à tona como você reconheceu. Você não está errado ao dizer que deve ter alguma entrada no design nesse nível, mas não tenho certeza de como você espera implementar isso é razoável. As pessoas não vão executar um design por você se considerarem simples; como eles podem estar tão facilmente errados quanto a ser direto quanto ao próprio design, você não encontrará pessoas se voluntariando para mostrar todos os designs errados. Neste ponto, estou mais curioso sobre seus hábitos de trabalho e padrões de comunicação, mas realmente não importa como tudo isso seja feito, algumas vezes você será surpreendido por essas coisas. Com falta de revisar diligentemente todos os commit, não tenho certeza de como você prova isso.

Muitas vezes me sinto assim emocionalmente:

 I of course think I'm right....I always do. 

mas tenho o bom senso de saber que às vezes estou errado. Eu também sei quando escolher uma briga - você não pode discutir sobre tudo, e às vezes um acordo inesperado da sua parte pode fazer maravilhas.

O que é um verdadeiro líder?

É alguém que pode demitir um subordinado, qualquer subordinado. (mas não precisa contratar um novo)

Às vezes, a maioria das pessoas é "identificada" como líder de algum projeto, mas, sem o poder de disparar alguém, é mais uma "orientação" / "professor" do que um verdadeiro líder.

Mas, novamente, pode acontecer que você possa ser um líder de equipe, mas não liderar seu projeto atual. O pior caso é quando o cliente está liderando o projeto. Nesse ponto, se o projeto falhar (e falhará), não será de sua responsabilidade.

E o pior caso é quando existem dois líderes de projeto.

Como militar, as cadeias de comando são tudo (não tão radical como "morrer por um projeto", mas próximo o suficiente). Por esse motivo, seu gerente quebrou seu status, diminuiu a moral do "seu" pessoal e não ajudou em nada.

Sim, seu chefe está certo - você não pode se envolver em todas as decisões. Na verdade, é impossível pegar tudo assim, a menos que você faça tudo sozinho. Eu acho que é de onde você vem - você sente que não pode ter uma boa noção de todo o projeto, a menos que esteja envolvido em cada pequeno detalhe, mas não pode se envolver em cada pequeno detalhe sem sobrecarregá-lo (o que desmoralizará totalmente o equipe e provavelmente queime você).

A resposta é não se preocupar com as coisas que dão errado - sempre o fazem - em vez de se preocupar em corrigi-las posteriormente, de maneira construtiva.

Se você mantiver o controle da comunicação, poderá não apenas delegar, mas também permitir que os funcionários seniores saiam e façam o que eles sabem ser necessário, sem sempre atrasá-los com críticas, discussões e tentativas equivocadas de controlá-los. Confie neles para fazer a coisa certa e esteja lá para 'conversar' sobre o que está acontecendo, para que você possa se manter informado (e enfie o nariz quando achar que é realmente necessário).

Você tem vários problemas. Primeiro, seu gerente ficou do lado de sua equipe e disse para você delegar mais. Isso mostra falta de confiança em sua capacidade de liderar a equipe. Na verdade, mostra que, embora você tenha o título de líder técnico, você não é o líder técnico porque não tem autoridade. Você precisa se sentar com seu gerente e ter um coração a coração sobre isso. Ninguém pode ter sucesso em uma posição de liderança técnica sem o apoio de seu gerente e sem autoridade para alterar as decisões de projeto tomadas pela equipe sem o seu consentimento. Você não tem autoridade para fazer seu trabalho. Seu chefe precisa entender que você está em uma posição sem vitória e que ele deve lhe dar seu apoio público para que melhore. Responsabilidade sem autoridade é a pior situação possível para você se encontrar.

Em seguida, sua equipe o cegou. Você precisa conversar sobre isso com eles. Você deve ter a discussão sobre design com eles antes que eles desenvolvam e muito antes que eles apresentem publicamente. Não há problema em delegar parte do design (embora você, não eles, possa decidir o que acha que deve ser delegado), mas não é certo que eles continuem sem informar você. Eles perderam a sua confiança ao cegá-lo, agora eles precisam aprender um comportamento melhor. Você precisa consultá-los com frequência para garantir que eles não os ocultem novamente e, se o fizerem, deverá fazer algum tipo de relatório formal do problema ao RH. Leads não são leads para serem populares; quando os desenvolvedores os deliberam depois de receber instruções para não fazê-lo, eles merecem consequências. Não Não importa se eles gostam de você ou não, mas claramente no momento em que não o respeitam. Eles precisam ter conseqüências por seu comportamento inadequado ou isso só vai piorar. No entanto, você não pode corrigir essa parte do problema até resolver o problema de suporte de gerenciamento.

Em seguida, você explodiu publicamente, precisa se desculpar publicamente. Isso ajudará você a recuperar sua reputação.

Então, você precisa deixar cada uma das pessoas de lado em particular e dizer-lhes as conseqüências por seu mau comportamento contínuo (depois que seu gerente concordar em permitir que você lhes dê consequências). Elogios e apoio público, críticas privadas devem ser sua regra. Você também pode precisar contatá-los com mais frequência, fora das reuniões do grupo, para que não possam ficar cegos.

Agora, francamente, já que os que estão acima e abaixo de você claramente pensam que você é alguém que pode ser ignorado e não mantido informado, você precisa fazer uma alma séria se investigando sobre o que está fazendo com que eles o desrespeitem. Você também precisa decidir se não seria mais feliz por não ser um líder técnico ou se deveria mudar para um lugar onde sua autoridade terá autoridade para assumir a responsabilidade. Se você decidir permanecer na posição, terá que pedir às pessoas que se igualem a você por que elas o tratam tão mal. Isso vai ser doloroso e você provavelmente não vai querer ouvir a resposta, mas precisa saber por que é percebido da maneira que eles claramente o percebem.