Eu sou gerente. Como posso melhorar as relações de trabalho e a comunicação com os programadores? [fechadas]

Um pouco de fundo primeiro. Sou gerente de projetos em empresas de médio porte. Comecei como especialista em CS e tive uma pequena exposição à programação, mas depois de alguns meses eu sabia que não era o meu caminho, então mudei para o gerenciamento. Essa provou ser uma boa decisão e, depois de me formar, trabalhei em gerenciamento de software em várias empresas (há 5 anos).

Recentemente, tivemos um projeto muito doloroso. Foi o pior dos piores, com muitos erros do nosso lado e do lado dos clientes e mal terminando sem perdas. Isso levou a muitas situações frustrantes, uma das quais escalou até o ponto em que um de nossos desenvolvedores seniores deixou a empresa após uma discussão vocal conosco (a gerência). Isso foi uma bandeira vermelha para mim: fiz algo terrivelmente errado. (para o registro, o argumento era sobre várias estimativas de tempo equivocadas)

Procurei em muitos lugares por respostas e um amigo me indicou este site. Aqui há muitas perguntas sobre frustrações com a gerência. Eu posso entender que as más experiências gerais levam a uma relutância geral contra "aqueles caras de terno".

Eu sou aquele cara de terno. Pode não parecer, mas tudo o que quero é um projeto bem-sucedido e, com recursos limitados, toma decisões dolorosas. Esse é o meu trabalho. Uma das coisas das quais o desenvolvedor sênior mencionado reclamou foi de equipamentos de trabalho. Francamente, eu não tinha ideia de que os computadores que tínhamos não eram adequados para trabalhar. Depois disso, perguntei a muitos programadores e o consenso geral era que precisamos de máquinas melhores. Corrigi isso desde então, mas obviamente havia uma enorme lacuna de comunicação entre mim e os programadores. Alguns dos desenvolvedores mais brilhantes são as pessoas mais tímidas e silenciosas. Eu sei disso e nunca foi um problema durante uma entrevista. As pessoas são diferentes e têm pontos fortes em diferentes áreas.

O caso dos PCs com pouca potência é apenas um dos muitos que me levaram a pensar que há um problema de comunicação. Como posso melhorar a comunicação com os programadores sem ser intimidador e repetitivo?

O que espero é que as pessoas não se queixem de coisas boas. Se você ama seu local de trabalho e ama (ou pelo menos gosta :)) de seu gerente, conte-me sobre eles. O que eles estão fazendo certo? Da mesma forma, se você odeia, descreva em detalhes o motivo. Estou procurando respostas sobre como melhorar a comunicação porque acho que esse é o meu problema, mas posso estar errado.

Uau! Obrigado por perguntar. Tecnicamente, como você, acho que sou gerente, pois passo muito mais tempo comunicando e liderando equipes do que escrevendo código ... mas aqui está minha opinião dos dois lados do horizonte de gerenciamento. Seja um desenvolvedor ou gerente trabalhando para outro gerente, eis algumas coisas que ajudam na minha comunicação com meu gerente:

• Por quê? é uma pergunta muito importante - quase todas as respostas factuais têm um "porquê" e esse "porquê" pode muito bem ser mais importante do que a pergunta real. Há algumas tangentes nisso:
  • O desenvolvedor Por que - os desenvolvedores terão muitas respostas que não fazem absolutamente nenhum sentido para o gerenciamento. Certamente sim, e uma das maneiras pelas quais eu entrei na gerência estava sendo muito boa em explicar os "porquês" das equipes em termos que a gerência podia entender. Se você não tem um "orador para os geeks" em mãos, pode aprender a falar nerd, reafirmando suas respostas à pergunta por que em metáforas mais comumente entendidas. Continue assim até você entender e concordar com o que está acontecendo.
  • A Gestão Porquê- o seu "porquê" é tão importante. Por que você precisa das estimativas de tempo? Para que você os está usando? Como seremos ferrado como empresa se eles forem muito altos ou muito baixos? Isso é algo sobre o qual você, como gerente, provavelmente tem uma grande percepção, mas tudo isso é vodu para o desenvolvedor. O truque é que o desenvolvedor não pode perguntar. A gerência pediu algo e ele fará o melhor possível para ser preciso, oportuno e atencioso - mas se ele não souber o "porquê", poderá otimizar da maneira que você preferir que não. Ofereça o seu porquê e peça para ele fazer a mesma coisa - reafirme a resposta nos seus próprios termos.

Sobre as estimativas de tempo especificamente - eu tive que fazer uma tonelada e eu absolutamente lucrei ao dizer à minha equipe de desenvolvimento "Eu preciso disso porque vou pedir mais dinheiro para pagar nossos salários, vou confiar no que você me diz e Usarei seus números ... isso significa que, se você me rebaixar, estamos todos ferrados porque não poderei pedir dinheiro pela segunda vez - temos que viver com o que propomos ". Nesse contexto, os desenvolvedores mudaram de estimativas baixas, que tentavam me mostrar o quão confiantes e brilhantes eram, para estimativas altas, muito mais próximas do cenário de expectativas reais.

• Ninguém está errado - a pergunta "por que" fica longa com um corolário - perguntando "por que" em vez de dizer "isso é ultrajante! De jeito nenhum!" mantém a conversa fluindo. Às vezes, há uma desconexão severa entre o que alguém está pedindo e o que o solicitante está perguntando. Minha melhor administração ficou terrivelmente surpresa com minhas respostas e, quando surpresas, elas piscam de espanto e depois perguntam "por que você diz isso?". Eles não dizem (imediatamente) - "você precisa mudar isso". Reduzi o número de propostas para atingir uma meta competitiva, mas somente depois de falar intensamente sobre como poderíamos mudar o cenário e criar um contexto diferente para a pergunta.

• ouça o ruído ambiente, a escolha das palavras e o espaço entre as palavras . Aqui estão algumas coisas que eu gostei e roubei para usar:

  • fique na área de trabalho, faça algo produtivo (não tente entrar no trabalho de desenvolvedor, eles sabem que você não é um desenvolvedor) e apenas ouça. Como a equipe resolve problemas? Quais são os grandes problemas deles? Você nunca ouvirá o verdadeiro magrelo ao avaliar diretamente você ou a gerência em geral, mas poderá ter uma boa noção de onde estão as áreas problemáticas. Verifique se você está fazendo algo próprio que é produtivo. Ninguém gosta de espionagem, mas, a menos que o moral seja tão baixo que você não possa estar perto deles sem que todos evacuem, a produtividade nas proximidades deve ser tolerável.
  • procure por opções de palavras - elas geralmente são tão importantes quanto as próprias palavras. Quando utilizo palavras particularmente positivas ou negativas, minha gerência frequentemente me pergunta por que escolhi essas palavras quando é uma situação em que não estão familiarizadas.
  • procure pausas, lacunas e linguagem corporal. Se houver uma distância de poder entre você e os desenvolvedores (e parece que existe), eles podem não querer contradizê-lo ou confrontá-lo. Mas o instinto básico de dizer "ei, você está errado" geralmente se manifesta em algum lugar.

• abra o maior número possível de meios de comunicação - esteja pronto para conversar pessoalmente, por telefone, por email, por IM - tudo e qualquer coisa para estabelecer o fluxo da comunicação. As pessoas são tão diversas que apenas um truque não funciona. E vejo como trabalho do gerente ser o comunicador multiformato, não o desenvolvedor.

• faça com que valha a pena conversar com você Se alguém lhe falar sobre um problema e talvez uma possível solução, ele deve e provavelmente aceita que você é o gerente e, portanto, pode decidir em favor de uma solução diferente ou nenhuma solução porque você não acho que vale a pena. Mas depois da terceira vez, isso acontece, especialmente se acontecer sem uma explicação, cerca de 99% das pessoas vão parar de lhe dizer qualquer coisa.

E aqui está uma que é incrivelmente difícil para mim, mas funcionou muito bem quando eu posso fazer isso - esteja ciente da diferença entre introvertidos e extrovertidos . As chances são de que você é extrovertido - é por isso que seu trabalho parecia bom e uma posição de desenvolvimento não. Os desenvolvedores são, na maioria das vezes, introvertidos. "Introvertido" não significa "não pode se comunicar", mas significa que seu padrão, processo e velocidade são significativamente diferentes e o desejo de se comunicar incessantemente é praticamente inexistente. Planeje o tempo e o espaço silencioso (mas colocado) para permitir que pensamentos introvertidos sejam divulgados. Muitos dos meus amigos introvertidos me dizem que estão apenas esperando que eu "cale a boca por 5 minutos" para que eles possam pensar e responder. Aqui'5 coisas que os extrovertidos devem saber sobre introvertidos e Rands em Repose on the Nerd Cave - um exemplo particularmente desenvolvedor do que é ótimo para introvertidos . A propósito, Rands é bastante fantástico. Ele próprio é um nerd, então trata disso do foco do desenvolvedor, o que pode ser desconcertante se esse não for o seu estilo, mas ele é engraçado e tem algumas idéias realmente boas sobre o desenvolvimento da equipe.

Eu acho que as coisas # 1 que eu mais amei nos meus gerentes favoritos foram:

• eles estavam tão profundamente comprometidos e empolgados com o projeto quanto eu (se não mais)

• Eu nunca tive uma dúvida de que eles estavam nas minhas costas - eu sabia com certeza que, quando estavam na frente do próximo nível de autoridade, eu (ou meus colegas) nunca seria a bode expiatória. Seria sempre uma falha de grupo, se houvesse falha.

• Recebi a propriedade de algo significativo e apropriado para minhas habilidades na época, mas com recursos suficientes para expandir minhas habilidades e realizar o trabalho.

• eles me viam como indivíduo e como parte da equipe - estavam envolvidos ativamente em conhecer meus pontos fortes e fracos e trabalhando para me ajudar a aproveitar meus pontos fortes e aumentar meus pontos fracos.

• eles estavam cientes dos meus objetivos pessoais e interessados ​​em incorporá-los o máximo possível

• eles foram francos ao me fazer feliz não poderiam e não seriam uma prioridade. Há um valor real em ouvir "Eu sei que você odeia esse tipo de trabalho, mas eu preciso que você faça isso - eis como não será para sempre ...".

• sempre havia tempo em uma semana (talvez não no momento) para explicar o quadro geral

• havia feedback e status quase constantes, sem apontar o dedo, mas com bastante reconhecimento pelo trabalho individual.

• sempre havia a verdade. Se alguma coisa era sensível e não podia ser discutida, eles diziam que não. Se algo estava incerto, eles davam um nível de confiança.

A parte mais fácil primeiro: há uma bandeira vermelha técnica em seu post: Tremo com a sua menção de "estimativas equivocadas" - é uma estimativa, NÃO PODE SER ERRADA , é por isso que é chamada de estimativa. Pode sair um pouco, pode sair muito, é por isso que é chamado de estimativa. Se você está considerando estimativas como evangelho, esse será um dos principais problemas que "seus" desenvolvedores estão tendo com seu estilo.

No entanto, concordo 100% com você sobre a dificuldade de se comunicar com os desenvolvedores. Eu tive uma revelação há vários anos, como desenvolvedor de um treinamento em gerenciamento de projetos. Eu vi vários de meus colegas desenvolvedores absolutamente protestando contra o gerenciamento depois que uma atmosfera aberta de discussão foi criada (o gerenciamento estava presente aqui). Tudo o que estava errado era culpa dos gerentes aos olhos dos desenvolvedores. O ponto principal foi que a gerência não tinha idéia de quase todos os grandes problemas levantados naquele dia. Os desenvolvedores estavam assumindo que tudo era tão óbvio que o gerenciamento não poderia ter esquecido, e o gerenciamento estava assumindo que os desenvolvedores lhes diriam o que precisam.

Portanto, IMHO, a primeira parte da resposta deve ser informar seus desenvolvedores que você não é psíquico e, na verdade, provavelmente completamente estúpido quando se trata do lado técnico. Você está confiando, contando e confiando neles para chegar até você em tempo hábil. Você está lá para facilitar a vida deles, não mais difícil.

E faça o que fizer, NÃO faça perguntas para as quais você realmente não quer saber a resposta - referindo-se às "estimativas equivocadas" acima ;-). É a criptonita de um desenvolvedor.

Há muitas coisas boas aqui, mas eu sinto que o seguinte precisa ser dito .. ..Desculpe ser severo .. Mas isso precisa ser dito:

• Cinco anos como PM, e não saber de que tipo de PC um desenvolvedor precisa, é escandaloso.
• Ter um desenvolvedor demitido por causa das más condições de trabalho como sua primeira bandeira vermelha real é uma loucura.

O que acho que você tem é um problema de confiança , mais do que um problema de comunicação. Ninguém diz o que está errado, porque não confia no que você fará com essas informações e pode até temer que elas sejam usadas contra eles. O desenvolvedor que falou sobre todos esses problemas o fez porque, como não havia consequências, ele estava desistindo.

Pessoalmente, nunca contrataria um primeiro-ministro que não tivesse experiência em desenvolvimento. Penso que no seu próximo projeto, você deve dedicar uma pequena parte do seu tempo como parte do desenvolvedor. equipe . Diga 8 horas por semana, trabalhando como desenvolvedor Jr sob o líder da equipe.

Isso realmente abrirá seus olhos para a dinâmica de uma equipe de desenvolvimento, porque agora, você nem faz parte dessa equipe, é um outsider. O fato de você ter desistido do seu emprego foi um choque para você, prova isso. Todos na equipe sabiam que ele estava infeliz. E nenhum deles lhe disse:

"Nós vamos perder nosso padrinho se você não fizer algo"

Essa deve ser a bandeira vermelha # 2.

Como gerente, tenho certeza de que você já ouviu falar sobre kaizen , um dos princípios do Sistema Toyota de Produção, que significa melhoria contínua .

Você admitiu que tem um problema, então é um ótimo começo.

O Kaizen possui cinco elementos principais:

• Círculos de qualidade : Grupos que se reúnem para discutir níveis de qualidade relativos a todos os aspectos do funcionamento de uma empresa.

• Moral melhorada : a moral forte entre a força de trabalho é uma etapa crucial para alcançar a eficiência e a produtividade a longo prazo, e o kaizen a define como uma tarefa fundamental para manter contato constante com a moral dos funcionários.

• Trabalho em equipe : Uma empresa forte é uma empresa que reúne todos os passos do caminho. O Kaizen visa ajudar os funcionários e a gerência a se verem como membros de uma equipe, e não como concorrentes.

• Disciplina pessoal : Uma equipe não pode ter sucesso sem que cada membro da equipe seja forte em si. O comprometimento com a disciplina pessoal de cada funcionário garante que a equipe permaneça forte.

• Sugestões para melhoria : Ao solicitar feedback de cada membro da equipe, a gerência garante que todos os problemas sejam analisados ​​e resolvidos antes que se tornem significativos.

( Fonte )

Se você der uma olhada longa nisso, uma constante sobre esses elementos é a ênfase no trabalho em equipe e no feedback.

Um exemplo, você diz que teve uma discussão ao longo do tempo. Você é o responsável por essas estimativas de tempo? Você fala com a equipe sobre isso? Sinto muito, mas vi os gerentes apenas tirar um número do seu as-. Uma coisa crucial: nunca pechinche com o tempo as estimativas que sua equipe fornece a você. Muitos gerentes imaginam que, se puderem cumprir prazos mais curtos, se a equipe trabalhar mais. Isso é uma mentira. Nove mulheres não podem ter um bebê em um mês, lembre-se disso.

Então, meu primeiro conselho:

Ouça : comece com um e-mail simples para a equipe: "Qual é a melhor maneira para a equipe de desenvolvimento dar feedback à gerência sobre o desempenho da gerência?". Itere com a equipe e implemente o consenso. Sua tarefa é permitir que a equipe desenvolva um ótimo software, não agrupá-lo. Mantenha isso em mente.

Honestidade e lealdade : se ninguém responde quando você pergunta alguma coisa, é porque eles não acreditam que você ouvirá ou, pior ainda, acreditam que você os punirá por isso. Então seja honesto. Se alguém disser que você é péssimo, tome isso como um feedback e não se vingue. Entenda suas razões, melhore-as.

E, finalmente, embora eu tenha visto algumas críticas sobre isso aqui, eu gostaria de recomendar que você leia um livro chamado The Mythical Man-Month: Essays on Engineering Software . O livro é sobre a experiência de Fred Brooks na IBM enquanto gerencia o desenvolvimento do OS / 360. Embora algumas coisas aqui e ali possam ser datadas, é o passo inicial para entender como funciona o processo de desenvolvimento de software complexo. S.Lott cita o Manifesto Ágil , que não gosto muito dele, mas também vale a pena ler.

Leia isso:

http://agilemanifesto.org/

• Indivíduos e interações sobre processos e ferramentas

• Software que trabalha sobre uma documentação completa

• Colaboração do cliente sobre negociação de contrato

• Respondendo a mudanças após seguir um plano

Em muitos casos, a organização (seu chefe) exige que você

• siga um processo claramente quebrado até sua conclusão lógica, levando a uma "marcha da morte". Por sua vez, isso leva a argumentos e renúncias.

• crie documentação excessiva, de baixo valor e não utilizada.

• envolver-se em um complexo controle de mudanças a / k / a negociação de contrato. Toda mudança de usuário requer um ritual elaborado para "qualidade" e "priorizar" a mudança. Realmente, é tudo sobre o "congelamento" - impedindo mudanças.

• siga o plano independentemente das consequências. Algumas organizações valorizam a entrega pontual de software quebrado (ou mesmo inútil). É o plano que é valorizado, não a solução de um problema de negócios.

Pode ser que o problema não seja suas habilidades de comunicação pessoal.

Pode ser que todo o "ambiente" ou "metodologia" de desenvolvimento esteja fatalmente quebrado, e os maus sentimentos sejam apenas um sintoma de más práticas gerais.

Para mim, parece que você nunca conversou com os desenvolvedores em um ambiente fácil. Suas conversas com eles eram meramente de natureza oficial? Isso é ruim.

Por que você não os conhece pessoalmente e, assim, conhece o que é bom e o que há de ruim na empresa, no local de trabalho e nos projetos? Respeite-os e conquiste seu respeito, demonstrando sincero interesse e apreço pelo seu trabalho.

Se eles confiam em você e não precisam temer ser ofertas de peões, provavelmente dirão até verdades pouco atraentes.

Sou líder de equipe e minha equipe confia em mim. Eu os protejo. Eu assumo toda a culpa e compartilho a fama com eles. Nossa gerência me protege. Isso aumenta o moral. Tínhamos um projeto muito difícil e um cliente quase ruim, quase impossível de terminar, mas acabamos fazendo isso porque conversamos sobre tudo de uma maneira muito franca e aberta.

Aplaudir! Aplaudir! Aplaudir! Você certamente deve ser uma boa pessoa, pois saiu em aberto para ver o que pode ser feito para melhorar seu trabalho.

Veja abaixo o que testemunhei em um ótimo gerente e adotei pessoalmente quando lidero a equipe como membro sênior.

• M entor mais de gerenciar.
• A membros da equipe lLow de expressar seus pensamentos e preocupações. Seja todo ouvidos para isso. Tome os construtivos.
• N nunca trair os membros da equipe, jogando política divisória. Isso dispara mais cedo e silenciosamente.
• Nem um pouco. Nunca faça caretas quando estiver com sua equipe, aconteça o que acontecer. Este é realmente difícil.
• G enuinely e abertamente apreciar o vencedor para sua / seu bom trabalho. Na mesma amplitude, de maneira suave e taticamente, o trabalho não é cometido por nenhum erro, para a pessoa responsável, isoladamente e não ao ar livre.
• E propriedade ncourage e liderança em cada indivíduo. Isso aumenta o moral e o comprometimento da pessoa, porque ela se sentiria respeitada.
• R OAM ao redor com sua equipe de vez em quando. Este induz / aumenta a ligação entre os membros da equipe.

Desejo-lhe boa sorte em seu esforço sincero :)

Em geral, os caras nas trincheiras começam a se sentir amotinados quando sentem que suas queixas não estão sendo ouvidas por pessoas que podem e irão corrigir as situações. Quando eles nem sentem que podem se queixar sem arriscar sua posição na empresa, isso é ainda pior.

Eu sou um cara meio teórico-Y, e a maioria dos "trabalhadores do conhecimento" costuma ser; Se pudermos, gostamos do nosso trabalho e queremos fazê-lo bem. No entanto, a desvantagem de um local de trabalho da Teoria Y é que pode não ser imediatamente aparente que há um problema, porque as pessoas, querendo se sair bem e, portanto, não desejando causar ondas, encontrarão maneiras de contornar esse problema ou simplesmente o ignorarão. Isso leva à frustração reprimida, que eventualmente explode no rosto de toda a equipe. Uma loja administrada por um gerente da Theory-X provavelmente teria caras que reclamaram muito antes; os funcionários só estão envolvidos pelo dinheiro; portanto, se o trabalho for mais do que o normal, eles se queixam.

Quanto ao que você pode fazer, em um ambiente com idosos e lideranças na sala fazendo o trabalho, eles são seu melhor patrimônio. Fale com eles. Você pode agendar 30 minutos por semana para "bidirecional", onde os leads fornecem atualizações e preocupações sobre o dia-a-dia do projeto, além de atualizações no lado comercial e planejam com eles para resolver problemas. antes que se tornem problemas que afetam seriamente a equipe.

No Agile, no final de cada "sprint" ou "iteração" (que é uma unidade de trabalho de desenvolvimento que geralmente dura entre uma e três semanas), toda a equipe, dos membros mais jovens até o PM, tem uma "retrospectiva " Eles olham para o que fizeram, o que deu certo, o que não fez e identificam coisas para continuar fazendo e coisas para mudar. Existem vários formatos, e você pode inventar o seu, mas o resultado do retro deve ser que as pessoas sentem que sua voz foi ouvida e que as coisas mudam como resultado.

Falando sobre Agile; meu primeiro trabalho foi em uma pequena empresa e, por "pequena", quero dizer que toda a empresa não conseguiu um time de softbol. Havia quatro programadores quando eu comecei, e isso diminuiu para dois antes de eu sair. O fundador, presidente, CEO e 95% das partes interessadas na empresa decidiram com um punho de ferro, e ele era a única fonte de planejamento na organização, o que significa que não havia muito. O chefe era viciado em trabalho e esperava que todos os outros também fossem; Tudo o que você tinha para dar era mais ou menos do que a expectativa dele e, por isso, ele pagou um salário básico para as pessoas que trabalhavam para ele há uma década.

Deixei a empresa e comecei a trabalhar para outra empresa que fazia as coisas MUITO diferente; eles praticaram a metodologia básica do SCRUM Agile, com standups diários, programação de pares, equipes de sprint e retrospectivas. Durante um dia a cada duas semanas no início de cada corrida, não fizemos nada além de planejar o trabalho das próximas duas semanas. Por uma grande parte de outro dia, não fizemos nada além de relembrar o que havíamos feito e encontrar maneiras de melhorar como equipe. Havia desenvolvedores sentados ao meu lado que eram MVPs da Microsoft, concluindo o trabalho e incentivando e complementando o que eu estava fazendo.

Noite. E. Dia. A principal diferença? Primeiro, eu não achava que deveria me matar pelo projeto; Um princípio fundamental do Agile é o ritmo sustentável do desenvolvimento. Segundo, tive voz para decidir como seria de esperar que eu fizesse meu trabalho. Eu tinha que fazer o trabalho, mas se eu tivesse "azia" sobre o que seria esperado no próximo sprint, eu poderia expressar essa opinião e ela seria ouvida e receberia peso. Se eu achava que havia uma maneira melhor, eu poderia dizer isso e seria divertido.

Quanto a encontrar soluções e resolver problemas, você deve tomar cuidado para não parecer que está trabalhando de cima para baixo. Para computadores; digamos que seu RMR (receita mensal recorrente) permite apenas que a empresa atualize quatro computadores a cada duas semanas. Os quatro primeiros computadores nem todos devem ir para os leads e idosos; eles devem ir para as pessoas com os computadores mais lentos. Se você der bônus à equipe, não os dê apenas a "nossos valiosos idosos e líderes, sem os quais isso não seria possível"; TODOS na sua equipe de desenvolvimento fizeram isso acontecer. Se um júnior tiver uma reclamação, ouça-o; só porque ele é um júnior não significa que ele não sabe de nada.

Melhorar as relações:
Acabou de ter um projeto difícil? Dê-lhes uma pausa depois. Tempo de férias para relaxar, recuperar o fôlego.
Declaração de direitos dos codificadores Essas coisas são um dado. Coisas básicas que devem ser evitadas. Se você violar isso, estará abusando das suas chaves de código.
O teste de Joel eu concordo com a maioria deles. Mas alguns realmente dependem. Se você está sentindo falta de algum, provavelmente está dificultando a vida de seus programadores, então precisa ser.
Dívida técnica . Portanto, você pode pressionar pela conclusão, mas precisa entender que, ao cortar custos, incorre em dívidas técnicas que levarão mais tempo em uma data posterior para serem corrigidas. Se essa data chegar antes do final do projeto, você realmente estragou tudo.
Animação RSA: MotivaçãoEssa é uma parte fantástica que realmente mostra como motivar os profissionais do conhecimento.
Dia livre para codificar o que eles querem. Do vídeo da RSA. Não se lembra do nome, mas a empresa mencionada tem uma breve explicação sobre ele no site. Parece uma boa ideia para mim. Na maioria das lojas, há coisas que todo mundo sabe que estão presas, mas ninguém tem tempo para consertar, e isso não é uma alta prioridade. Isso permite que eles enfrentem dívidas técnicas. Também lhes permite mostrar suas idéias brilhantes.

E pelo amor de Deus, tente manter uma semana de trabalho de 40 horas. Além disso, horário flexível. O Flextime pode compensar um mundo inteiro de besteiras. Para mim pelo menos.

Melhorar a comunicação entre programadores e chefes
Isso é mais difícil para mim. Essa coisa toda shmoozing é mais um conjunto de habilidades de chefe, em seguida, o foco de um programador. Eu poderia dizer que algumas coisas básicas, como estimativas de tempo, são apenas estimativas. Andar na água e cumprir os requisitos são fáceis se estiverem congelados. Talvez pedindo aos programadores tímidos que apresentem seu projeto em uma revisão de código ou algo assim. A prática leva à perfeição, não é? Mas eu me curvaria ao conselho dos outros sobre este.

"Da mesma forma, se você odeia, descreva em detalhes o porquê."
Bem, isso vai abrir as comportas aqui. E se eu não estivesse usando um openID que obviamente poderia estar vinculado a mim, provavelmente também desabafaria. Se você realmente deseja uma lista gigante do que não fazer, pergunte em um fórum mais amigável para postagens anônimas.

Eu sempre achei que as pessoas em geral não o tratam melhor do que você as trata (embora elas possam te tratar pior). Pessoalmente (sou desenvolvedor), respondo à honestidade com honestidade, ao respeito com respeito, à confiança com confiança e assim por diante. Você deve ter uma conversa informal com sua equipe em um ambiente neutro e contar o que acabou de nos contar. O ponto que é esquecido nos ambientes tóxicos "nós versus eles" é que todos deveriam ser "nós". Tanto a gerência quanto os funcionários precisam saber disso, e a empresa deve apoiar isso.

Boa sorte.

Agora você tem um histórico comprovado de não apenas aceitar feedback, mas agir de acordo com ele. Você demonstrou ter influência com tomadores de decisão mais elevados e pode fazer as coisas para sua equipe. Isso faz uma grande diferença. Os programadores podem ser mais introvertidos, mas gostamos de falar sobre programação. Um ambiente informal é agradável, mas todos ainda precisam ser profissionais. Permita que as pessoas desabafem um pouco, mas certifique-se de que as discussões sejam produtivas e não apenas uma sessão de putaria.

Pela minha experiência, o fator mais significativo para eu gostar ou não do meu gerente é se ele / ela entende o desenvolvimento em geral e entende o trabalho que estou fazendo. Alguns resultados positivos estão listados aqui:

• Não preciso perder muito tempo para justificar por que uma mudança levaria tanto tempo ou não pode ser implementada. Bem, tecnicamente, qualquer mudança pode ser implementada e a alta gerência geralmente exige a implementação de qualquer maneira. Mas, pelo menos nessa situação, seu gerente direto está do seu lado, pedindo mais tempo (em vez de empurrá-lo ou esgotá-lo).
• Sei que tenho mais chances de receber suporte em caso de uma situação ruim (um hack do WTF, um problema de produção etc.). Geralmente, uma pessoa não técnica tende a culpar o desenvolvedor por essa situação, enquanto um bom gerente entende o que realmente está acontecendo e apóia seu desenvolvedor (não apenas sabe ou está disposto a agir dessa maneira por ser legal).
• Eu sei que meu trabalho e desempenho devem ser avaliados por uma pessoa adequada.

Na minha opinião, se você não faz mais a programação e geralmente em um cronograma ou orçamento apertado, a chance de os desenvolvedores gostarem é muito baixa. Nesse caso, é melhor você avançar rapidamente e ter mais alguém para ser o gerente direto. Desculpe por parecer ruim neste parágrafo, mas é assim que eu vejo. Você parece ser uma boa pessoa e merece alguma verdade.

Eu também sou um dos rapazes de terno, e há mais de 15 anos. Eu era desenvolvedor de software quando comecei e ainda escrevo código quando tenho uma chance. Acho que posso falar pelos dois lados e tenho um pouco de experiência nessas situações. Também tenho credenciais, como "Empregado do ano", eleito pela equipe, que me deixam confiante em lidar com essas situações.

O que eu testemunho com frequência é que existem diferenças substanciais nos sistemas de valores e nos métodos / abordagens operacionais adotados entre gerenciamento e desenvolvedores.

Para muitos desenvolvedores, sinceridade, honestidade e um ambiente de trabalho flexível estão no topo da lista. Infelizmente, os mesmos valores não estão muito altos na lista da alta gerência. E isso leva inevitavelmente a enormes conflitos, principalmente se a gerência intermediária (você e eu) decidirmos assumir completamente o lado da alta administração. A única maneira de escapar disso (do meu ponto de vista) é adotando uma posição firme na frente de sua equipe, apoiando-a por todo o caminho e construindo um relacionamento de confiança por meio de comunicação aberta e, o mais importante, fazendo o que você está dizendo (que geralmente é o oposto do que você obtém da alta gerência, onde a política supera completamente a sinceridade).

Ao mesmo tempo, você precisa permanecer operacional, portanto, precisa encontrar uma maneira de se comunicar com a alta gerência em um idioma que eles entendam e joguem. Esse é o verdadeiro desafio da gerência intermediária.

Acredito que, com a felicidade dos desenvolvedores, a produtividade se resume a pequenas coisas. A matemática funciona muito bem para o gerenciamento. Dê-me um donut (-25 centavos) de manhã e trabalharei duas vezes mais o dia todo (+ muitos dólares). Não é que sabatemos ativamente as coisas trabalhando devagar quando estamos insatisfeitos, é que estamos trabalhando em sistemas extremamente complicados e é extremamente difícil focar quando estamos frustrados com alguma coisa. Provavelmente é realmente melhor não codificarmos tanto quando estamos com raiva.

As estimativas, no entanto, devem ser tratadas por elas mesmas. Todos os problemas que tenho podem ser resolvidos entregando-me uma rosquinha, com exceção das estimativas irrealistas . Verdadeiro ou falso, é assim que um desenvolvedor vê: o gerenciamento tem tudo a ganhar (como um barco novo) por uma estimativa mais curta, enquanto os desenvolvedores têm tudo a perder (como um mês de sono). A gerência está no comando, então eles vencem a guerra de estimativas sempre. Eu acho que o sistema de estimativa funciona melhor quando os desenvolvedores decidem o prazo (já é difícil o suficiente fornecer uma estimativa precisa, como seria um gerente?), Mas a gerência os motiva positivamente a serem ambiciosos, com o entendimento de que nenhum desenvolvedor é prejudicado estar um pouco fora.

Considere que tipo de reação você dá a um programador que possa ter uma pergunta, comentário ou preocupação. Existe um "O que você quer agora ?" ou "Por que você está me incomodando com isso ?" tipo de resposta? Você está incentivando os desenvolvedores a expressar preocupações e comentários? Esse é apenas um ponto de partida.

Em segundo lugar, tenha cuidado com o local onde você está tentando ter essas discussões. Duvido que eu fosse muito aberto discutindo minha máquina de trabalho com alguém no próximo cubo se soubesse que meu gerente estava ao alcance de ouvir a coisa toda. Se você deseja que as pessoas dêem feedback aberto e honesto, deve haver alguma privacidade para saber que suas respostas não serão divulgadas publicamente ou usadas contra elas.

Terceiro, considere que tipo de habilidades de Inteligência Emocional você possui. Inteligência emocional para gerentes de projeto: as habilidades necessárias para alcançar resultados extraordinários de Anthony Mersino seriam uma recomendação de livro que recebi ontem de um almoço e aprenda sobre EQ. Se você realmente quer se aprofundar na psicologia aqui, existem várias ferramentas de perfil de personalidade que podem ser usadas, por exemplo, Eneagrama, estilos sociais e MBTI.

Por fim, considere qual é a cultura em sua empresa. Erros são algo varrido para debaixo do tapete? As reclamações são um grande não-não, que poderia facilmente causar problemas a alguém? Quais comportamentos são recompensados ​​ou incentivados e quais são tolerados e aceitos? Embora parte disso seja observação, algumas delas também podem exigir algumas conversas que devem ser mantidas fora do escritório ou em uma sala onde provavelmente não haja escutas. Você provavelmente será repetitivo ao tentar usar isso no começo. Isso não é algo ruim se você estiver tentando estabelecer uma nova prática e convencer as pessoas a falarem se a cultura era principalmente uma onde todos sabiam "chupar". Isso pode ser mais sensível do que outras respostas, mas é isso que eu '

Os desenvolvedores acham que você é o advogado deles? Com isso, quero dizer que eles sabem que são livres para compartilhar com você suas preocupações / frustrações sem serem espancados? Eles sentem que você luta por eles? Eles acham que você aprecia o trabalho deles? Eles acham que você realmente deseja que eles tenham sucesso em sua carreira?

Se eles se sentirem apreciados, provavelmente terá uma melhor comunicação.

Como desenvolvedor, sou um grande nerd e carece de habilidades sociais e não peço desculpas por isso. Afinal, eu sou o talento, e você me contratou para o meu talento. Se você precisasse de redes sociais para fazer o trabalho, teria uma sala cheia de gerentes de projeto em vez de desenvolvedores.

Eu sei que alguns desenvolvedores são muito astutos socialmente, mas acho que a mediana se inclina para um nerd introvertido.

Quando alguém me pede para fazer algo, não faço inferências e faço exatamente o que é solicitado. Parece que, para alguns gerentes de projetos, eu sempre acabo com problemas, porque eles esperam que eu faça inferências sobre o projeto deles, o que eu absolutamente não farei, então, às vezes, as coisas não saem da maneira que esperam, embora sejam exatamente o que eles solicitaram. Acho que o motivo disso acontecer com alguns gerentes de projeto é que eles não fornecem HLDs, BRDs de alta qualidade e valorizam muito o aspecto social do gerenciamento de projetos, e não o preto e branco.

Eu acho que é aqui que os mundos colidem. Eu acho que no mundo do gerenciamento de projetos as habilidades sociais e a qualidade da sinceridade pessoal são fatores importantes, mas para desenvolvedores como eu, isso não significa absolutamente nada. Não me impressiona falar sobre o quão importante é essa ou aquela tarefa. Eu nem quero sair para almoçar ou beber cerveja, como algumas pessoas sugeriram aqui.

O que eu realmente quero são HLDs e BRDs de boa qualidade. Quero cronogramas e prazos que sejam alcançáveis ​​e, se novos designs ou planos forem introduzidos, desejo que o cronograma e os prazos sejam reajustados. Trabalhei em projetos em que os requisitos parecem mudar rapidamente - para mim, essa é a minha bandeira vermelha de que estou lidando com uma liderança de projeto de baixa qualidade. Como desenvolvedor, a pior coisa que você pode fazer é me trazer novos requisitos de projeto diariamente, especialmente depois que já temos um cronograma ou assumimos compromissos de cronograma. É intolerável quando novos requisitos são trazidos, sem compensação de prazos. Trabalhando mais horas, trabalhando até tarde, não tenho nenhum problema com isso, mas não é algo sempre quantitativo com o desenvolvimento. Algumas alterações podem levar algumas horas extras, algumas alterações podem levar semanas para pesquisa e desenvolvimento, testes, controle de qualidade, etc. adequados ... nem sempre é como assar um bolo; às vezes, uma única alteração nos requisitos pode ser como alterar toda a receita. Testemunhei os gerentes de projeto derreterem e terem acessos de raiva em teleconferências, porque seus prazos não permitirão um desenvolvimento extra, mas eles estão pedindo um desenvolvimento que não estivesse nos requisitos iniciais do projeto.

Só posso dar meu próprio viés pessoal e experiência como exemplo; portanto, não deduza que estou falando em nome de todos os desenvolvedores. Eu só vejo essas coisas através do microcosmo de minha própria carreira, mas este post descreve as condições exatas que me levaram a jogar a toalha proverbial.

Com que frequência você está conversando com seus desenvolvedores? Não me refiro a reuniões de status do projeto, perguntas sobre entregas ou outros tópicos que você traz para eles - com que frequência você se senta com um de seus programadores, pergunta como está as coisas e apenas ouve .

Muitas das outras respostas são realmente boas - você deve analisar o desenvolvimento ágil. Você precisa que seus desenvolvedores aprendam e cresçam em suas funções. Mas se você não está realmente ouvindo o que seus desenvolvedores estão dizendo (ou não estão!), Precisará cuidar disso primeiro.

Boa referência para particulares - http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

Curto e grosso. Excel no que você faz - isso gera comunicação.

O que excelência significa para seus desenvolvedores? .. Leia, releia, sim, estude o PeopleWare

Todas as ótimas idéias e comentários nos posts acima!

Aqui está uma idéia: envie sua equipe de TI para oficinas de comunicação em sua faculdade comunitária local - paga pela empresa, é claro.

Certifique-se de que a) as oficinas tenham boa reputação eb) não envie seus funcionários juntos. Eles tenderão a permanecer juntos e não se misturar com os outros alunos, não apenas reduzindo o valor das oficinas, mas causando perturbações nos demais.

A comunicação produtiva orientada para a equipe é uma habilidade que qualquer um pode aprender, mas é um assunto que sinto que falta na maioria dos caminhos escolásticos.

Essa idéia não é de forma alguma uma bala mágica, mas é uma boa peça fundamental do quebra-cabeça. Seus associados não apenas aprenderão a se comunicar melhor uns com os outros, mas o bônus será que eles começarão a entender e respeitar melhor SEU trabalho também (a comunicação está no centro do PM).

Apenas meus 2 bits :)

Apenas para responder a uma recomendação que já está sendo apresentada em algumas respostas . Michael Lopp (aka rands ) escreveu sobre como gerenciar desenvolvedores e "entrar na cabeça deles" em seu blog, Rands in Repose , e em um livro, Managing Humans ( fontes de livros ). O livro contém principalmente conteúdo editado de suas postagens anteriores a 2007 e fornece uma boa maneira de acompanhar as partes relacionadas ao gerenciamento de seu blog (ele também fala sobre, por exemplo, jogos de azar e se você deseja ler isso é outra questão). Sua escrita é geralmente ótima e geralmente bem-humorada, então há pouco risco em lê-lo.

Leve a equipe para tomar cerveja (e você está comprando).

Estou atrasado para a festa, mas só vi essa pergunta.

Uma coisa que não vejo muito bem abordada é a seguinte:

Os grunhidos nunca dizem toda a verdade aos fatos. Rands diz isso no DNA, mas não o aborda de frente, ele está em um tópico diferente.

Você está vestindo um terno e assina os cheques. Você representa o interesse da empresa. Você não está representando os engenheiros. Se o fizesse, não assinaria os cheques deles, eles assinariam o seu.

Obviamente, isso não é novidade para você ou para os engenheiros. Porém, quando um engenheiro sabe que trazer à tona certos problemas - problemas - em seu local de trabalho causariam conflitos significativos - a troca de risco / recompensa não favorece o engenheiro. Os engenheiros são pagos para produzir produtos, não para iniciar brigas culturais no local de trabalho. Envolver-se nisso é um caminho rápido para fazer o trabalho errado.

Portanto, parte da tarefa de gerenciamento é fornecer uma maneira de os engenheiros serem abertos sobre problemas, sem incorrer em políticas corporativas e reação na carreira. É bom ter aumentos, depois de tudo, e não são outras empresas, se este não se sente agradável.

Estou surpreso que ninguém tenha mencionado este grande livro que trata exatamente de sua pergunta e assunto - "Peopleware: Projetos e Equipes Produtivos", de DeMarco e Lister . Do editorial: as principais questões do desenvolvimento de software são humanas, não técnicas . As três primeiras resenhas na Amazon seriam facilmente suficientes para me convencer a comprar este livro se eu estivesse na sua situação.

Muitas respostas aqui têm pontos muito bons, mas eu gostaria de acrescentar alguns recursos que podem ajudar. Eu já estive em algumas situações que se desintegraram em uma confusão gigante ou foram resolvidas com muita eficiência por causa da comunicação entre as pessoas envolvidas. Três livros me ajudaram a melhorar pessoalmente minhas habilidades de comunicação, especialmente em situações de alto estresse, onde há muita coisa em jogo:

• Conversas difíceis: como discutir o que mais importa
• Conversas cruciais: ferramentas para conversar quando as apostas são altas
• Confrontos cruciais: Ferramentas para resolver promessas quebradas, expectativas violadas e mau comportamento

Ao ler sua pergunta, acho que você vê o valor da comunicação. Pessoalmente, sinto que a comunicação é mais importante para um gerente ou líder do que habilidades técnicas ou comerciais. As pessoas que você lidera devem ter as habilidades necessárias para realizar a maior parte do projeto. Um bom líder técnico ou gerente de projeto deve ser capaz de se concentrar na comunicação, seja dentro da equipe ou entre a equipe e o cliente ou a equipe e a entidade comercial (ou mesmo uma combinação dessas três).

Leia alguns ótimos romances que fornecem informações sobre as perspectivas da força de trabalho técnica:

• Hackers, Steven Levy - http://en.wikipedia.org/wiki/Steven_Levy
• Microserfs, Douglas Coupland - http://en.wikipedia.org/wiki/Douglas_Coupland
• Catedral e Bazar, Eric Raymond - http://en.wikipedia.org/wiki/Cathedral_and_the_Bazaar

Estes são tão importantes quanto qualquer livro de memórias típico sobre administração (Drucker et al).

Desempenhei várias funções ao longo de muitos anos - desenvolvedor, desenvolvedor sênior, líder técnico etc.

Da sua pergunta - é bastante óbvio que seus desenvolvedores não lhe dizem coisas porque não acham que você pode ajudar.

Isso pode ocorrer por 2 razões.

1. Eles não acham que você tem o poder de consertar as coisas. No entanto, acho que isso é improvável, porque você provavelmente o saberia e também os desenvolvedores se queixariam disso.
2. Você é o tipo de pessoa que, quando um desenvolvedor chega a você com um problema, executa uma ou mais das seguintes ações
   • Quando eles chegam a você com problemas, você diz a eles - eu gosto de soluções, não de problemas.
   • Você os ouve bem e depois os encarrega de resolver o problema. Você lhes dá uma conversa animada sobre como é uma honra para eles ter a responsabilidade de resolver o problema. Com o tempo, seus funcionários entendem que, quando vão até você com um problema, acabam com um trabalho extra, para que não cheguem a você com problemas.
   • Você nega que é um problema. Você dá razões convincentes para isso. Mas, como isso continua acontecendo, com o tempo seus funcionários aprendem que não faz sentido abordar você com um problema.
   • Você diz "sim, eu entendo". Você diz que esse tipo de coisa acontece ocasionalmente e não há nada que se possa fazer. Se esse é um padrão, então, novamente, vocês entendem.

Se houver algum ou todos os itens acima, você precisará corrigi-lo.

O que eu mais odeio são as pessoas que ficam entre mim, o desenvolvedor e o usuário final. Os melhores gerentes me permitem fazer isso e mudar nossa solução para corresponder ao que eu acho que o usuário deseja ou pode fazer.

A pior prática para mim é muitas vezes vestir-se como "boa" - geralmente o gerente tem ele próprio, ou um BA ou alguém escreve especificações que os desenvolvedores precisam interpretar e implementar, com prazos previamente acordados.

Se é uma solução personalizada, muitas vezes até os desenvolvedores não sabem quanto tempo levará e, geralmente, o cliente não tem idéia do que é melhor para eles. É por isso que o desenvolvimento iterativo é ótimo. Não é assim que a maioria dos negócios é feita, portanto um bom gerente luta para trabalhar como acima.

Finalmente, alguns desenvolvedores não são bons em comunicação e não podem se relacionar com os clientes. Talvez eles sejam mais adequados para problemas com requisitos claros, especialmente requisitos técnicos claros. Talvez você precise de desenvolvedores que sejam melhores comunicadores e que desejam trabalhar para resolver problemas de negócios e não puramente técnicos.

É muito fácil manter a equipe feliz

Tente ouvi-los muitas vezes que a pergunta também tem respostas. eu encorajaria o membro da equipe a apresentar problemas e a solução provável.

Passeio em equipe é uma boa idéia (pode ser um plano de jogo)

se o seu projeto exige algumas noites e trabalho de fim de semana e você acha que realmente não agrega muito valor à equipe, ainda assim seria uma boa ideia dedicar algum tempo para comer e apreciar a equipe sobre seus esforços e, se possível organizar alguns para a tomada de força

faça um 1: 1 bimestral com todos os membros da equipe para garantir que estejam confortáveis.

Por último, mas não menos importante, pode ser uma boa idéia para você entender o projeto funcional e tecnicamente também.

Entre em contato se tiver mais alguma dúvida

Também sou gerente de software (francês, perdoe meu inglês), que possui formação em engenharia científica, mas não especificamente em software de TI originalmente. Portanto, não tenho nenhuma afinidade especial com a codificação no início, mas tenho sido um engenheiro de qualidade estatística da escola de Deming, que tem um ensino enorme e diferente de todas as escolas "modernas" que se seguiram, apesar de pretenderem herdar de Deming. O pior é 6 sigma, o lean foi melhor, mas infelizmente o que aconteceu foi isso http://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-say :

“Originalmente, o Six Sigma foi derivado do Toyota Quality Management (TQM) da Motorola para atingir níveis de qualidade seis sigma e, por meio da Allied Signal e da GE, transformou-se em projetos de Black Belts com base em estatísticas para se tornar um programa de redução de custos - todos os projetos precisa de um ROI claro. Em outras palavras, denegrimos o programa de uma filosofia de liderança para vários projetos pontuais para reduzir custos. Foi uma bastardização completa do original e raramente levou a mudanças duradouras e sustentáveis, porque faltavam liderança e cultura.

“Aconteceu uma coisa semelhante quando se reduziu a um kit de ferramentas (por exemplo, mapeamento do fluxo de valor, placas KPI, células, kanban).

"Lean e Six Sigma de maneira alguma refletem o pensamento original de excelentes empresas japonesas ou de seus professores como Deming."

Hoje, o movimento Agile é parecido com o lean (veja o curso de Jeff Sutherland e sua homenagem a Deming http://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will-be-the -century-of-scrum / ), é melhor que Waterfall, mas ainda está muito longe do ensino original de Deming porque, em vez de ler Deming em seu texto original, os gurus apenas o re-empacotam, quase nunca citando todos os seus 14 princípios de gerenciamento, e vende ferramentas e seminários que têm pouco valor por si mesmos.

Agora, quando se trata de software, os problemas são as pessoas que, por um lado, conhecem os princípios gerais, mas não têm ideias reais de como aplicá-los, e, por outro lado, as pessoas que estão escrevendo softwares, mas ignoram os princípios porque apenas ouvem gurus falsos que venderam as ferramentas sem lhes contar os princípios reais e, de fato, deveriam criar suas próprias ferramentas de gerenciamento.

Portanto, para mim, o gerente de projetos de software deve fazer um esforço para aprofundar a operacionalidade cotidiana da codificação de software, não apenas fazendo planejamento no Microsoft Project (ou gráfico de burdown com Agile) ou uma boa apresentação no Powerpoint para a gerência superior, mas também possui alguns valores para a equipe de desenvolvedores. Quando a equipe do desenvolvedor tem problemas, mesmo que sejam técnicos, o gerente de projetos pode ajudar a orientar o diagnóstico com um olhar externo. Ele pode analisar o código, mesmo que não entenda os mínimos detalhes, ele pode fazer algumas perguntas ingênuas que podem levar os desenvolvedores a perceber que não pensaram nessa pista (eu tenho vários exemplos pessoais, mas é muito longo, então em vez disso, escreva um artigo no meu blog).

Outra coisa é que tento ter uma consciência geral da evolução no campo, como novas estruturas, novos paradigmas de arquitetura lendo artigos técnicos. Vou participar de alguns testes de integração, escrever algumas documentações (os programadores de animais odeiam o que eu faço por eles, é claro que eles me alimentariam com o núcleo), qualquer coisa que eu possa fazer praticamente por ajudar a equipe.

Em geral, os desenvolvedores sentem que estão fazendo o trabalho duro, e é verdade, muitas vezes eu digo a eles que estou fazendo a parte mais fácil, permanecendo na abstração; no entanto, tento ajudar concretamente quando necessário - porque o microgerenciamento também não é bom, pois pode gerar sentimentos de interferência.

Como conclusão: elimine slogans com desenvolvedores (que é de fato um dos 14 princípios de Deming), mostre a eles que você se importa com o software concreto do projeto, não com documentos ou sua reunião apenas com a gerência superior.