Question:
Comment gérer un rapport direct de chef d'équipe qui n'agit pas de manière professionnelle?
Babu
2013-03-03 18:41:01 UTC
view on stackexchange narkive permalink

Je suis un chef d'équipe. J'ai un membre de l'équipe qui relève directement de moi et qui vient d'une petite entreprise et qui avait de solides compétences en programmation et de très très faibles compétences en communication et une mauvaise étiquette d'entreprise. Il est également responsable du module.

Il veut se concentrer uniquement sur la programmation et déteste les réunions ou tout ce qui concerne l'organisation, la planification et la gestion. En tant que chef d'équipe, j'ai besoin de son implication pour planifier, organiser et gérer les livraisons. Et j'ai beaucoup de mal à obtenir sa participation à ces activités. Il n'aime même pas m'envoyer des mails de statut à moi-même et aux autres parties prenantes du projet ou de la mission dans laquelle il est impliqué. Quand je lui demande d'envoyer un mail ou quelque chose, il me demande en retour de le faire à sa place. La raison derrière cela est qu'il veut passer plus de temps sur la programmation et les activités connexes.

Il a également de faibles capacités d'écoute. Dans toutes les discussions, il saute rapidement dans les conclusions et réagit émotionnellement. Dans de telles situations, il m’est très difficile de remettre la discussion sur les rails. La plupart du temps, je lui demande exclusivement d'écouter attentivement jusqu'à ce que je termine avant qu'il ne parle. Alors que dans les discussions elles-mêmes, je lui rappelle généralement que je n'ai pas terminé et d'écouter patiemment jusqu'à ce que je termine mon discours.

Lors de l'une des réunions avec les parties prenantes du projet et la direction supérieure, il se lance rapidement dans les conversations discussion lorsque je dirige ceux-ci, et essaie de parler ou essaie d'ajouter ses points. La plupart du temps, ses points détournent la discussion ou créent des confusions au lieu d'ajouter de la valeur à la discussion. Je pense qu'il vaudrait mieux qu'il discute de ce point avec moi avant de prendre la parole à la réunion. Parfois, son intervention intempestive et indésirable conduit à des attentes non désirées de la part de l'équipe envers d'autres parties prenantes avec lesquelles j'ai encore affaire.

Tout commentaire, toute rétroaction ou opinion qui n'est pas positive à son sujet, à son travail ou à sa façon dont il se sent très ému et qui conduit parfois à des disputes émotionnelles et passionnées qui sont très difficiles à gérer pour moi.

Dans notre organisation, nous ne disposons pas des outils de base pour l'affectation et le suivi des tâches, etc. bien que nous ayons à peine suffisamment d'outils pour le développement. La plupart du temps, nous devons dépendre des feuilles Excel. J'ai essayé de simplifier le processus en créant des trackers Excel qui ont à nouveau une certaine quantité d'intervention manuelle, comme la mise à jour d'Excel avant la fin de la date et la publication dans toute l'équipe, etc.

Malheureusement, je ne peux pas prendre de décision outils, infrastructure, etc. Tout ce que je peux faire est de suggérer les outils et de demander les outils. Mais obtenir l'approbation des autres équipes comme le département du matériel et de l'infrastructure et la direction supérieure est très difficile. Il y a de fortes chances que ma demande soit rejetée. Je souffre également ici du manque d'outils. Mais c'est une décision d'organisation et de gestion; Je ne peux pas m'empêcher ici moi-même.

Il n'aime même pas envoyer de mails de suivi et de préparation. Il veut donner des mises à jour oralement et aimerait terminer la conversation dès que possible. Et j'ai généralement du mal à sonder pour plus d'informations. Je dois justifier chaque question que je pose.

Quel retour lui avez-vous donné et à quelle fréquence? Puisque vous êtes son manager, y a-t-il une raison de ne pas l'exclure des réunions avec les parties prenantes et la direction jusqu'à ce qu'il apprenne mieux / vous définissez des attentes qu'il peut suivre? Les autres responsables de module se conduisent-ils correctement?
Parfois, il y a un manque de communication sur les attentes liées à lui de la part d'une autre équipe car il y a une dépendance à son travail. J'ai donné des commentaires proactifs et clairs sur les attentes. Il réagit de manière négative et commence à blâmer les autres équipes. J'ai beaucoup de ces exemples similaires. J'essaie de donner des commentaires au fur et à mesure des besoins
_ "il réagit de manière négative" _ - envisagez de mettre en place des formations en communication pour ce type. Je me souviens d'avoir "réagi de manière négative" à des commentaires utiles avant d'avoir été informé de choses comme ça. Notez qu'il est peu probable qu'une personne sans compétences professionnelles et sans expérience dans ce genre d'éducation soit en mesure d'enseigner cela
Je me reconnais dans votre collègue, je n'aurais aucun respect pour un chef d'équipe qui me considère comme un subalterne plutôt que comme un égal, je ne vais pas à des réunions où je n'ai pas le droit de dire ce que je pense. Je ne travaillerais pas non plus pour un employeur qui ne fournit pas les outils de base nécessaires, qui sont pour la plupart gratuits et faciles à installer de toute façon. Ce sont des conneries du plus haut niveau, et je viens de quitter un tel travail. Plus jamais.
En termes simples, l'étiquette professionnelle et faire ce que l'on attend de lui fait partie de son travail. S'il «n'aime pas envoyer des e-mails de statut», c'est qu'il n'effectue pas les tâches attendues de lui / elle dans son travail. Personnellement, j'exprimerais mes préoccupations à la haute direction et leur demanderais de s'en occuper. À la fin de la journée, il / elle met une pression supplémentaire inutile sur vous (un employé plus âgé) qui pourrait affecter votre performance. Pas juste
@eskimo: D'où avez-vous obtenu «plus senior»?
@ChristofferHammarström "_Je suis chef d'équipe. J'ai un membre de l'équipe qui relève directement de moi_"
@ChristofferHammarström: Drôle, parce que je reconnais aussi une partie de moi-même dans cette histoire, mais je ne reconnais personne de moi-même dans "Je n'aurais aucun respect pour un chef d'équipe qui me considère comme un subordonné plutôt que comme un égal" - et c'est pourquoi je dis qu'il est dangereux de projeter.
@eskimo: Gotcha, je pensais que senior signifiait plus âgé ou plus expérimenté.
@pdr: La question montre clairement que OP considère que le collègue en question est en dessous de lui, alors qu'en fait le chef d'équipe existe pour l'équipe, et non l'inverse. Le fait que quelqu'un vous rende compte signifie que c'est votre travail de vous assurer qu'il peut faire son travail avec le moins de perturbations possible. Non pas que vous soyez censé les entraîner à des réunions et leur dire ensuite qu'ils ne sont pas autorisés à parler pendant ces réunions, ce qui dévalorise effectivement leurs opinions et leur participation. C'est terriblement irrespectueux.
_ "Dans notre organisation, nous n'avons pas le luxe des outils" _ Wow. Vous devriez vraiment prendre du recul et décider si vous pensez cela. Imaginez un atelier de mécanique automobile, un atelier de menuiserie, un cabinet d'architecture ... en fait TOUTE entreprise qui "ne peut pas se permettre le luxe des outils". Feriez-vous affaire avec une telle entreprise? Vous attendez-vous à ce que vos employés soient heureux et productifs? Si j'interviewais pour un poste et qu'on me le disait, je mettrais immédiatement fin à l'entrevue. Lisez [The Joel Test] (http://www.joelonsoftware.com/articles/fog0000000043.html) pour comprendre ce dont les développeurs ont besoin.
@ChristofferHammarström: Je suis d'accord avec beaucoup de ce que vous dites, lisez ma réponse. Mais vous faites toujours des hypothèses, basées sur vos propres expériences. Prenons un autre scénario qui correspond également à la description: un chef d'équipe emmène un développeur dans une réunion de planification pour ses connaissances techniques. Lors de cette réunion, les parties prenantes (comme elles le feront) demandent une date de livraison. Le chef d'équipe détourne à juste titre la question, pour donner à l'équipe le temps de discuter. Un membre de l'équipe fait une promesse. A-t-il miné son chef d'équipe? Si l'estimation s'avère irréaliste, a-t-il miné ses coéquipiers?
@pdr: Ouais, tu as raison, c'est un scénario possible.
Vous pouvez vous trouver un (ou plusieurs) membre (s) de l'équipe très heureux si vous leur permettez de remplacer votre "solution" Excel par un vrai système comme le FREE [trac] mentionné (http://trac.edgewall.org/) . Ils seront probablement impatients de vous donner une introduction très complète si vous avez le courage d'admettre que vous ne le saviez pas (en supposant que vous ne l'ayez pas fait, car si vous avez toujours insisté sur Excel, vous devriez (re) lire @JimGarrison's [commentaire] (http://workplace.stackexchange.com/questions/10047/d/#comment21339_10047)). Le suivi des problèmes n'est qu'un exemple bien sûr
@JimGarrison,, cette déclaration sur le «luxe des outils» me dit davantage de ne pas savoir quels outils les développeurs préfèrent réellement que de leur budget. Comparé à Trac, Subversion et autres, Excel est en fait le plus "luxueux" car il coûte plus cher (et pourrait tout aussi bien produire plus de frais généraux s'il étouffe la production).
On dirait que la personne ne devrait pas être un chef d'équipe si elle n'est pas disposée à effectuer les tâches exigées par son poste et que je suppose que vous avez jugé nécessaires.
Il semble que vous ne partagez pas l'état d'esprit de votre programmeur. Je vous suggère de lire http://randsinrepose.com/archives/managing-nerds/
Je connais son ancien mais dans notre organisation, nous n'avons pas les outils de base pour l'affectation et le suivi des tâches, etc. Jira est libre d'utilisation.
Pour ceux d'entre vous qui suggèrent les outils gratuits, toutes les entreprises n'autorisent pas leur installation sur leurs réseaux.
@ChristofferHammarström Il me semble que vous remplissez des blancs dans sa question avec votre propre expérience dans une situation similaire, mais différente.Les deux situations ne sont peut-être pas aussi étroitement liées qu'il y paraît au premier abord.
Treize réponses:
#1
+105
pdr
2013-03-03 20:34:47 UTC
view on stackexchange narkive permalink

En fin de compte, la seule réponse correcte à toute question sur la gestion d'un membre de l'équipe gênant est "Comprenez ses motivations, réagissez en conséquence."

Nous ne pouvons pas vraiment vous dire quelles sont ses motivations. Je peux faire une supposition, car j'ai été accusé de la plupart des choses que vous décrivez, mais cela ne veut pas dire que nous sommes des personnes similaires. Ce serait juste de projeter mes propres frustrations sur le lieu de travail sur le membre de votre équipe, ce qui pourrait être juste, mais peut-être pas non plus.

La seule façon de vraiment comprendre la motivation d'une personne est de l'écouter. Beaucoup.

Sortez-les du bureau, dans un endroit confortable et posez-leur quelques questions d'approfondissement. Et une fois qu'il commence à parler, écoutez. Rands in Repose nous a expliqué comment faire cela dans un excellent article intitulé The Update, The Vent and The Disaster.

À la même heure chaque semaine. Lorsque vous devenez un gestionnaire de personnes, une chose étrange se produit. Vous êtes automatiquement perçu comme étant plus occupé. Que vous l'êtes ou non n'a pas d'importance; les gens pensent que vous l'êtes. L'atterrissage constant de vos 1: 1 à la même heure le même jour est un rappel hebdomadaire que vous êtes là pour eux, quelle que soit leur occupation.

Faites-le toujours. Ok, donc vous êtes vraiment occupé. Vous courez de réunion en réunion. Il est facile de dé-prioriser un 1: 1 car, contrairement à la réunion à laquelle vous participez ou à partir de laquelle vous vous dirigez, un 1: 1 ne représente pas un problème urgent à résoudre. Je vais battre ce manque d'opinion de valeur perçue de votre part plus tard dans cet article, mais pour l'instant, comprenez que chaque fois que vous renoncez à un 1: 1, ils entendent: "Vous n'avez pas d'importance".

Au moins 30 minutes. Un autre geste préféré du gestionnaire occupé est de programmer un 1: 1 pendant 15 minutes ou moins. C’est le mieux que je puisse faire, Rands. J'ai 15 personnes qui travaillent pour moi. Premièrement, ces 15 personnes ne travaillent pas pour vous; vous travaillez pour eux. Pensez-y comme ceci: si ces 15 personnes partaient, quittaient juste le bâtiment demain, combien de travail serait réellement fait? Deuxièmement, si vous avez 15 personnes qui travaillent pour vous, vous n'êtes pas leur manager, vous êtes juste le gars qui sourit mal à l'aise alors que vous volez rarement près du bureau, demandez comment ça se passe, puis n'écoutez pas réellement la réponse.

La seule chose dont je suis presque sûr, c'est que la personne à qui vous parlez n'est pas malveillante. La plupart des gens ne le sont pas. (S'il est l'un des rares, alors assurez-vous de cela, puis renvoyez-le.)

Lorsque les gens réagissent émotionnellement dans des situations inappropriées, c'est généralement parce que personne ne leur donne une situation appropriée pour exprimer leurs frustrations. Alors, donnez-lui ça, je pense que vous serez surpris de la facilité avec laquelle ce problème est à résoudre.

Il vous dira ce qu'il veut, s'il croit que vous écoutez et que vous êtes sur son côté. Si vous ne pouvez pas le lui donner, dites-lui cela (et dites-lui pourquoi, pour qu'il comprenne), directement, et encouragez-le à penser à une alternative.

EDIT: Une dernière pensée, qui peut être évident, mais cela vaut la peine de le dire quand même.

Ne faites pas cela uniquement pour la personne qui vous cause des problèmes. Pour une chose, vous ne devriez pas le distinguer. D'autre part, vous ne devriez pas encourager un mauvais comportement en lui laissant penser qu'il s'est maintenant mérité un statut spécial.

Mais pire, vous pourriez aussi constater que d'autres personnes sont tranquillement en train de bouillonner sur les mêmes problèmes. Si vous les laissez bouillonnants, ils pourraient finir par exploser, d'une manière beaucoup plus destructrice que l'individu qui laisse échapper ses frustrations à toute occasion, même quand il ne le devrait pas.

+1 pour l'or pur dans chaque paragraphe. Tout cela est plus difficile à mettre en œuvre que de le préciser, mais le présenter est tout ce que l'on peut faire. J'aurais aimé lire ceci quand j'ai commencé ma carrière de gestionnaire!
Un autre +1 pour "comprenez que chaque fois que vous renoncez à un 1: 1, ils entendent, vous n'avez pas d'importance". J'y suis allé pendant que celui qui a renfloué, l'a ressenti, à la pelle.
+100 pour "... vous constaterez peut-être également que d'autres personnes se préoccupent des mêmes problèmes." L'OP est à la marelle sur la ligne d'être un PHB. N'invitez pas des personnes à des discussions auxquelles elles ne sont pas autorisées à participer, * JAMAIS *. Je parie que ce gars est le "champion" ou "porte-étendard" pour environ 1/3 de votre équipe. La gestion dominante produit des cellules dormantes de résistance. Vous avez une cellule active. Vous ne savez pas combien de gens ressentent la même chose, ils ne le vocaliseront pas parce que ce type le fait pour eux.
Alors, quand un individu ne doit pas laisser sortir ses frustrations?
#2
+60
Amy Blankenship
2013-03-03 22:59:47 UTC
view on stackexchange narkive permalink

Contrairement à pdr, je n'ai pas peur de projeter :). En lisant entre les lignes, je vois quelqu'un qui sait qu'il a été embauché pour ses solides compétences en programmation dans un environnement où vous ne disposez pas des outils de base que la plupart d'entre nous tiennent pour acquis. Par exemple, la plupart des systèmes de contrôle de version peuvent être intégrés à des systèmes de billetterie, souvent gratuits. Par exemple, nous utilisons SubVersion et nous l'avons intégré à Trac. Donc, si vous n'avez pas de système de billetterie, vous n'avez probablement pas de contrôle de version. Et si vous n'avez pas de contrôle de version, cela implique qu'il y a de nombreux problèmes avec votre code et votre environnement qu'il pourrait avoir du mal à résoudre.

Ce type peut être dans une situation où il ressent une pression pour performer en tant que programmeur, mais il est dans un environnement où c'est très difficile. Il peut donc penser que même s'il passe 110% de sa journée à faire les tâches de programmation pour lesquelles vous l'avez engagé, il ne peut pas répondre à vos attentes en raison de l'environnement dans lequel vous l'avez placé. cette situation, et cela conduit aux symptômes que vous avez décrits - couper les gens qui, selon vous, sont en train de faire valoir un point qu'ils ont déjà fait valoir afin que vous puissiez obtenir une réponse et retourner au travail, être sur la défensive pour que les gens réalisent que vous êtes dans une situation difficile et que vous dites souvent «non» pour que vous puissiez finir ce qu'il y a dans votre assiette avant de commencer à accumuler plus de tâches.

De son point de vue, il peut avoir l'impression que les tâches de programmation sont celles qu'il est le seul à pouvoir faire, alors que les tâches de communication peuvent être confiées à quelqu'un qui peut y consacrer en toute sécurité son attention sans affecter le critique (pour lui ) tâches dans lesquelles il est engagé. C'est une façon très "programmeuse" de voir les choses - les tâches sont accomplies en parallèle, chacune par la ressource la mieux équipée pour les gérer.

Vous voudrez peut-être regarder exactement la pression exercée par ce type et déterminer s'il existe un moyen pour vous, en tant que manager, de la soulager. Gardez à l'esprit qu'une partie de cette pression peut être interne à lui - il s'est peut-être fixé des objectifs dont vous n'êtes pas au courant, et sa volonté d'atteindre ces objectifs peut l'emporter sur vos attentes à son égard pour communiquer davantage. Si la pression est externe, vous devrez peut-être lui acheter un peu d'espace pour qu'il se sente à l'aise de consacrer du temps à des choses qu'il pourrait percevoir comme nuisant à sa capacité à respecter des délais (peut-être déraisonnables). Si la pression est interne, vous devrez peut-être simplement lui parler pour qu'il se donne la permission de consacrer du temps à des tâches qui vous apprécient.

+1 pour une réponse incroyable! Je pense que vous avez fait un excellent travail pour capturer l'état d'esprit d'un développeur de logiciels stressé.
Je pense que mon passage dans une startup qui m'a laissé blessé pendant un moment pourrait être utile à quelqu'un.
#3
+32
l0b0
2013-03-03 23:40:20 UTC
view on stackexchange narkive permalink

Dans notre organisation, nous n'avons pas le luxe des outils. La plupart du temps, nous devons dépendre des feuilles Excel. J'ai essayé de simplifier le processus en créant des trackers Excel qui ont à nouveau une certaine quantité d'intervention manuelle, comme la mise à jour d'Excel avant la fin de la date et la publication dans toute l'équipe, etc.

Les outils ne sont pas un «luxe». Du moins pas les outils mentionnés jusqu'à présent (bug trackers et contrôle de version). Ce sont des moyens extrêmement basiques pour les développeurs de produire plus efficacement du code de bonne qualité et de se concentrer sur la création de valeur pour le client.

Le temps passé à créer un tracker personnalisé dans Excel serait bien meilleur passé à installer et à configurer un tracker gratuit existant. Même le meilleur programmeur VBA au monde aurait besoin de milliers d'heures de travail pour implémenter les fonctionnalités de base de tout outil de suivi de bogues majeur. L'utilisation d'un bug tracker signifie que tout le monde peut mettre à jour les informations en même temps sans collision (un problème fondamental avec tout document unique partagé), ce qui signifie déjà moins de temps passé pour chaque mise à jour pour vérifier si quelqu'un d'autre est en train de modifier , verrouillez le document d'une manière ou d'une autre, puis déverrouillez-le à la fin.

Le contrôle de version est un autre outil extrêmement important pour les développeurs. Si ce n'est pas disponible, alors ne soyez tout simplement pas surpris si vous ne pouvez pas embaucher de bons développeurs.

Fournir de tels outils vous sera également bénéfique: la plupart des systèmes de contrôle de version et de suivi des bogues sont excellents à créer automatiquement des mises à jour de statut. Par exemple, dans Git et Bugzilla, obtenir une liste des changements des derniers jours est trivial, et vous pouvez souvent modifier la quantité de détails que ces rapports contiennent. Cela ne nécessite aucun travail supplémentaire de la part des développeurs, sauf une connaissance de base du fonctionnement de ces outils.


Il est important de garder à l'esprit qu'il est probablement conscient de ce qui précède. Comme vous l'avez mentionné, il a de «solides compétences en programmation» - cela signifie en particulier qu'il est capable de détecter les activités de routine et de sentir que celles-ci peuvent être rendues plus faciles. Cela signifie également qu'il est capable de rechercher et de découvrir des outils efficaces pour des emplois particuliers (sinon, on ne pourrait pas qualifier ses compétences de «fortes»).

À cause de cela, il serait soyez plus sûr pour vous de supposer qu'il connaît une grande variété d'outils de gestion de projet abordables, riches en fonctionnalités et efficaces - même une recherche rapide sur le Web révèle un exemple de liste de ces outils sur la page Wikipédia respective, ainsi que de nombreux d'autres ressources.

Compte tenu d'une prise de conscience probable décrite ci-dessus, il serait inexact de supposer qu'il perçoit le manque d'outils comme un simple inconvénient, c'est vraiment plus dangereux que cela.

Du point de vue d'un employé conscient des outils , un tel manque pourrait indiquer soit une incapacité assez profonde à résoudre un problème de gestion simple ( "hey why don" t il vous suffit de consulter la liste sur Wikipedia et de choisir l'outil approprié abordable, c'est aussi simple que cela ") ou tout aussi profond sentiment de négligence envers leur besoins ( "ne pas vouloir faire une chose aussi simple montre à quel point je suis sans importance à vos yeux, c'est aussi simple que cela" ).

Notez comment l'une ou l'autre de ces perceptions se heurte aux deux premiers des principes célèbres de Packard:

  1. Pensez d'abord à l'autre camarade. Ceci est LA base - la première condition - pour s'entendre avec les autres. Et c'est la seule réalisation vraiment difficile que vous devez accomplir. En gagnant cela, le reste sera "un jeu d'enfant".

  2. Développez le sens de l'importance de l'autre personne. Lorsque nous faisons en sorte que l'autre personne semble moins importante, nous frustrons l'un de ses pulsions les plus profondes. Permettez-lui de ressentir l'égalité ou la supériorité, et nous pouvons facilement nous entendre avec lui ...

Cela détruit essentiellement sa confiance en vos compétences managériales qui à son tour rend très difficile la collaboration sur n'importe quel sujet.


Pour ce qui est de traiter directement avec l'employé, vous pouvez essayer d'organiser des réunions régulières 1: 1 avec tous les développeurs pour comprendre les défis et les frustrations avant qu'ils ne soient évacués au plus grand groupe disponible. Cette personne peut être verbeuse et conflictuelle, mais les préoccupations qui la sous-tendent peuvent être partagées par d'autres membres du groupe (ou au contraire, peuvent être considérées comme sans importance). Comme indiqué après le saut, il est difficile d'établir des 1: 1 utiles, mais cela peut désamorcer le conflit avant qu'il ne se propage.

Merci de contribuer à The Workplace! Malheureusement, votre réponse ne répond pas à la question. Veuillez le modifier pour répondre à la question posée, sinon il sera supprimé.
OP a demandé des suggestions ("Je crois que cette communauté a plus d'expérience dans ce genre de situations dont les idées aident à gérer la situation. Des suggestions?"), Et je réponds avec les raisons possibles de la réaction du travailleur et une façon constructive de s'améliorer la situation. À quelle partie de la question posée je ne réponds pas?
La question indique que les outils ne sont pas une option dans cette entreprise en particulier. Bien que votre réponse soit pertinente par rapport au problème, elle ne fournit pas de réponse pour la situation donnée.
Cela arrive aussi souvent dans d'autres forums Stack *: OP dit «X n'est pas une option» sans fournir de justification, et plusieurs réponses tentent à juste titre de démêler la raison ou de convaincre OP qu'il * est * vraiment une option. Sur la base de la notation générale de ces réponses, je dirais que ces types de réponses sont les bienvenus.
Essayer de * démêler la justification * est vraiment quelque chose qui devrait être fait dans les commentaires, pas dans une réponse. Si le PO clarifie le raisonnement derrière (et a la capacité / l'autorité de changer) une telle politique, alors ce serait une réponse. Cependant, pour le moment, cela ne correspond pas à la question posée.
Cela n'a rien à voir avec la question. La question est de savoir comment traiter avec un collègue, pas des outils spécifiques. Votre réponse n'aborde littéralement pas le problème central de la question (ou pire, même tenter de le faire).
Salut @l0b0, Je pense que les informations que vous avez publiées sont incroyablement utiles, mais pensez-vous que vous pourriez être en mesure d'ajouter un ou deux paragraphes qui répondent à la question: "Comment gérer un rapport direct de chef d'équipe qui n'agit pas de manière professionnelle?". Je pense que ce que vous avez publié est utile, mais notre communauté doit également respecter nos directives de publication de réponses dans les [faq] et [answer]. Faites-nous savoir dans [chat] si vous avez besoin d'idées ou de suggestions car nous sommes heureux de vous aider! :)
#4
+23
Kate Gregory
2013-03-03 19:52:16 UTC
view on stackexchange narkive permalink

Je travaille avec des gens comme ça tout le temps. Ce que vous devez faire, c'est lui faire profiter de ce que vous voulez. C'est trop gros pour que le seul avantage soit de garder son travail.

Donc, cette personne n'aime pas les réunions. Vous n'aimez pas ce qu'il fait en réunion. Vous voulez qu'il envoie des e-mails et mette à jour les éléments de travail ou les éléments de suivi ou les listes de statut, etc. Cela peut totalement être résolu.

  1. Rendez le processus aussi léger que possible. Par exemple, un outil de suivi du travail qui est intégré à l'outil de programmation afin que vous sélectionniez simplement quelque chose dans une liste déroulante lors de l'enregistrement d'une modification, et le statut de l'élément est mis à jour pour vous (Visual Studio Express le fait en association avec TFS hébergé, qui est gratuit pour 5 développeurs ou moins. Les bons outils ne doivent pas coûter des dizaines de milliers de dollars)

  2. Donnez-lui ce qu'il veut en échange de ce que vous voulez. «Si vous me recevez cet e-mail de statut avant 9 heures, j'aurai le temps de l'examiner et de vous demander quoi que ce soit avant la réunion, et vous n'aurez pas à venir à la réunion. "Si vous m'envoyez un e-mail de statut sous forme de points, je le rédigerai en phrases et je l'enverrai à toutes les parties prenantes." "Si vous prévoyez 15 minutes pour un face à face, nous pouvons mettre à jour le document de statut ensemble et je vais faire la saisie"

Apportez-lui des avantages, laissez son son travail ressemble plus à ce qu'il veut, et votre valeur est claire. De nombreux développeurs voient les PM et les chefs de projet comme des boucliers pour éloigner la direction et les utilisateurs afin qu'ils puissent coder. Si vous êtes prêt à être un bouclier pour lui, il vous aidera avec ce dont vous avez besoin pour le faire.

J'ai rencontré des développeurs et des personnes d'assistance et je les ai aidés à saisir et mettre à jour des "tickets" et des éléments dans divers trackers. Une fois parcouru plusieurs fois, ils commencent à y gagner. Quand quelqu'un les interrompt pour obtenir le statut, je souligne qu'ils peuvent simplement regarder dans le tracker (et laisser le développeur seul) et que cela se produit plusieurs fois, le développeur commence à voir le point. Rien n'est plus frustrant que quelqu'un interrompant votre progression pour vous poser des questions sur votre progression! Vous pouvez patiemment enseigner à ce développeur que les rapports proactifs et la mise à jour du statut laisseront beaucoup de temps pour coder en toute tranquillité. Si le développeur n'aime pas taper des phrases, vous pouvez l'aider. Faire avancer les progrès (et voir par vous-même où est la douleur - mettre à jour des feuilles Excel partagées est vraiment horrible) fera une plus grande différence que de corriger et de harceler le développeur pour qu'il fasse ce qu'il n'est pas motivé à faire.

#5
+10
mhoran_psprep
2013-03-03 22:05:37 UTC
view on stackexchange narkive permalink

Si ces compétences que vous décrivez comme hebdomadaires ou inexistantes sont importantes pour son rôle dans l'équipe, alors la sélection de cet employé pour ce rôle était erronée ou la formation était un problème. S'ils n'ont jamais effectué ces tâches, ils n'ont pas été correctement formés sur ce qui est requis dans le rôle, ou la formation n'a pas suscité de réticence à effectuer ces tâches.

S'ils voient leur seul vrai rôle de codeur , alors c'est peut-être leur rôle. Une réticence à communiquer correctement (à leur équipe, à votre équipe, aux clients) est un signe qu'ils ne sont pas prêts pour cela ou qu'ils ne seront peut-être jamais prêts pour ce rôle.

Les e-mails livrés selon un calendrier défini sur un sujet défini ne sont pas gérés. Ces e-mails sont rapidement considérés comme une corvée, surtout s'ils semblent n'être rien de plus que de cocher une case. Se déplacer régulièrement vers toutes les parties de l'équipe, avec vous puis prendre des notes lorsque vous rentrez à votre bureau, peut soulager les communicateurs réticents.

Je peux vous produire un e-mail régulier, tous les jours vous croyez que des progrès réguliers sont accomplis; ou que nous surmontons des obstacles difficiles; ou que nous sommes a désespérément besoin de ressources supplémentaires. Si c'est votre seule fenêtre de progression, vous ne dirigez pas l'équipe.

Concernant la communication avec les clients. Il n'est peut-être même pas nécessaire de l'avoir là-bas. J'ai connu de nombreuses personnes très heureuses de ne jamais parler aux clients.

Vous devez résumer les compétences essentielles nécessaires pour la tâche, à la fois en programmation et hors programmation. Ensuite, vous devez décider ce que cette personne peut faire maintenant, peut faire avec une formation supplémentaire et ce qu'elle ne pourra jamais faire. Ensuite, vous devez trouver un moyen dans votre équipe d'atténuer ces problèmes. Cela peut être des tâches supplémentaires pour vous ou pour quelqu'un de votre équipe; ou un changement est un rôle pour eux.

#6
+6
HLGEM
2013-03-05 22:29:53 UTC
view on stackexchange narkive permalink

Personnellement, je pense que vous avez une personne qui occupe un poste qu'elle n'est pas apte à occuper. Une fois que vous prenez une position de leader, le codage est votre responsabilité secondaire et cela ne devrait pas prendre plus de 50% à 70% de votre temps (personnellement, je vais avec 50 mais il est un module plomb, alors peut-être que 70% est plus approprié). Je m'asseyais avec lui et lui demandais combien de temps il pense qu'il devrait consacrer aux tâches de gestion du codage vice, puis je lui disais ce que vous attendez de la scission entre les deux, puis je lui demanderais s'il préfère être un développeur plutôt qu'un lead si les deux estimations sont complètement déréglées et il n'est pas disposé à modifier votre estimation. Avoir un lead qui dévalorise le temps passé à gérer signifie que vous n'avez pas d'avance.

#7
+4
Ourjamie
2013-03-05 17:48:47 UTC
view on stackexchange narkive permalink

Cela pourrait être un conflit de personnalité direct. J'étais l'un des deux chefs d'équipe pour une entreprise en particulier. L'autre chef d'équipe avait un développeur qui sonne comme le vôtre. Au fur et à mesure que les problèmes augmentaient et que les difficultés augmentaient, le développeur a été transféré dans mon équipe. J'ai réussi à le renverser en voyant les problèmes qu'il avait avec l'autre chef d'équipe et en utilisant un ensemble de critères différents pour le motiver et le défier. À bien des égards, j'étais plus assertif, stimulant et plus dur (comme pour fixer des échelles de temps agressives, et vraiment démonter son travail et le faire recommencer) avec lui. Cela l'a amené à s'épanouir, d'autant plus que j'ai beaucoup écouté ce qu'il avait à dire et que je l'ai mis en avant pour diriger des spectacles et parler directement à la haute direction des projets. Au bout de trois mois, mon manager a discuté d'une promotion pour ce type avec moi et nous l'avons dûment fait. Trois ans dans l'autre équipe, il est allé nulle part, six mois sur la mienne, il s'est retourné et a brillé.

En fin de compte, j'ai fait un peu différent de mon collègue de chef d'équipe car tous les processus de gestion de base étaient les même dans les équipes. Cela se résumait vraiment au fait que ma personnalité était différente.

Je n'ai pas l'intention de critiquer ouvertement le PO, mais il y a un monde de différence entre Team-Leadership et Team-Management. J'ai lu que la situation était davantage un processus de gestion basé sur un processus de gestion, plutôt qu'un leadership réel.

#8
+4
amphibient
2013-03-06 01:03:09 UTC
view on stackexchange narkive permalink

Cela vous aidera à faire face à votre situation si vous vous réconciliez avec plusieurs vérités irréfutables:

  1. Les ingénieurs en logiciel sont des travailleurs du savoir qualifiés qui n'aiment pas faire la paperasse. Ils aiment programmer.

  2. Les ingénieurs en logiciel, du moins les bons, comme cela a été dit ci-dessus, détectent facilement les écueils opérationnels (par exemple, "Dans notre organisation, nous n'avons pas le luxe de La plupart du temps, nous devons dépendre de feuilles Excel. "et trop de réunions inutiles) et, comme ce sont des travailleurs du savoir talentueux, ils sont facilement ennuyés par cette circonstance et doivent faire plus de travail fastidieux, inutile et bureaucratique parce que leurs gestionnaires étaient bâclés ou bon marché pour investir dans une infrastructure appropriée. S'ils sont bons, ils ne toléreront pas cela et iront travailler ailleurs. Je remarque le ton de votre exclamation que vous n'avez pas d'outils comme si vous en étiez presque fier (du genre "quand j'avais 8 ans, je devais marcher à l'école 18 km dans la neige") alors que état embarrassant de votre organisation.

  3. Selon votre compte, votre associé souffre probablement du syndrome d'Asperger. Devinez quoi, c'est le terme scientifique pour le nerd ultime à qui la plupart des réalisations technologiques peuvent être attribuées. Vous n'aimez pas les Aspies, leur introversion et leur maladresse et vous préférez que votre développeur soit un vendeur de voitures d'occasion frat boy avec ... euh ... compétences relationnelles? Eh bien, le garçon de la fraternité ne sait pas programmer. Que diriez-vous de revenir à l'âge de pierre si les compétences interpersonnelles sont si importantes? Vous ne pouvez pas avoir les deux. Si vous voulez un logiciel bien construit, vous devrez vous adapter aux types de nerdy.

Ma réponse finale à vous est d'accueillir votre associé Aspie. Je me vois en lui à 100%. Pourquoi quelqu'un qui sait programmer devrait-il être obligé de participer à des réunions inutiles une demi-journée? Ou remplir des pages de garde sur leur rapport TPS? Pensez à votre processus et rendez-le léger pour le bénéfice de tous. Une fois que cela devient simple et rationalisé, votre associé ne sera peut-être pas dérangé de passer 10 minutes par jour à soumettre les artefacts nécessaires pour garder tout le monde au courant.

Ce n'est pas un programmeur, c'est un chef de file. Les responsables doivent faire ce truc bureaucratique gênant que les développeurs ne veulent pas faire.
#9
+3
user8365
2013-03-05 04:15:04 UTC
view on stackexchange narkive permalink

Pourquoi avez-vous embauché cette personne / pourquoi a-t-elle accepté ce poste? Quelque part, une déconnexion s'est produite lors de la mise en correspondance de cette personne avec ce poste. Bien sûr, un programmeur ne «veut» pas faire des choses hors programmation, mais s'il a accepté le travail, je suggérerais de le renvoyer chez lui et de lui permettre de revenir quand il est prêt à travailler.

Tirez parti des compétences dont il dispose. Si votre entreprise pense pouvoir embaucher et rémunérer des programmeurs de haut niveau en faisant d'eux une sorte de manager, c'est un exemple parfait de pourquoi c'est une erreur. Vous perdez de l'argent à chaque minute où il ne programme pas. Il veut de meilleurs outils, dites-lui de commencer à mettre en œuvre et à intégrer certains des produits open source. Laissez-le partager et apprendre aux autres développeurs comment les utiliser. Vous obtiendrez un meilleur retour sur investissement dans cette personne si vos autres programmeurs peuvent apprendre quelque chose de lui. Mettez-le sur les projets difficiles. Laissez-le créer les référentiels, les frameworks et les API qui peuvent être exploités par d'autres.

Stratégie de réunion améliorée Je déteste quand un responsable m'entraîne dans une réunion où il a une idée claire agenda de la façon de gérer le client / situation, mais je n'ai jamais pris la peine de me l'expliquer à l'avance. Il faut beaucoup d'efforts pour éviter les opinions contradictoires et sortir du sujet. Rencontrez-vous d'abord. Faites-lui savoir que c'est le moment de la dissidence et lorsque vous entrez dans la réunion, soyez un joueur d'équipe et respectez le plan, que cela vous plaise ou non.

Communications Quiconque a une aversion pour la communication apprend mieux à STFU à tenir sa langue lors de mes réunions. Vous n'obtenez pas les deux. Bien sûr, vous devriez éviter de mettre cette personne dans cette situation en premier lieu.

#10
+2
Jeanne Boyarsky
2013-03-03 21:44:23 UTC
view on stackexchange narkive permalink

Une autre approche consiste à commencer petit. Les e-mails de statut destinés à vous-même sont un bon point de départ sûr. En tant que chef d'équipe / gestionnaire, il est parfaitement raisonnable pour vous de demander un e-mail de statut hebdomadaire (ou quotidien). Je voudrais en fait commencer quotidiennement pour améliorer la communication entre vous deux. Ce n'est pas grave pour lui de vous envoyer un e-mail une fois par jour.

Et finalement, nous faisons tous des choses que nous n'aimons pas. C'est pourquoi nous sommes payés. Si quelqu'un veut coder sans interagir avec qui que ce soit, coder est un passe-temps et non un travail.

Lorsque vous lui parlez, c'est un point important. Que notre travail n'est PAS de coder. C'est pour produire de la valeur pour le client. Le codage en fait partie. Pas tout.

À moins que la distance entre l'équipe ne soit grande, la gestion en contournant mieux que les courriels de statut quotidiens.
Ce n'est pas une question de statut. C'est un truc d'entraînement. L'affiche originale pense que cette personne n'est pas disposée à envoyer des courriels et aimerait seulement donner son statut oralement. C'est un problème. Et si l'affiche originale ne peut pas amener la personne à lui envoyer des courriels, comment amener la personne à les envoyer aux clients ou à faire d'autres choses qu'elle ne veut pas.
#11
+2
Jason Baker
2013-03-04 04:02:08 UTC
view on stackexchange narkive permalink

Il me semble que votre collègue est très créatif. Devine quoi? La gestion de personnes créatives est un domaine créatif en soi. Cela me rappelle un sketch de Hee Haw:

Patient: Docteur, ça fait mal à chaque fois que je bouge mon bras comme ça! Docteur: Eh bien, arrêtez de bouger votre bras comme ça alors!

Si vous êtes fatigué d'avoir des disputes avec lui, arrêtez de vous disputer avec lui. Je ne prétends pas avoir toutes les réponses. Cependant, je tiens à souligner que vous avez deux solutions fiables: convaincre quelqu'un de le renvoyer. Ou quittez votre travail et travaillez ailleurs.

Lorsque vous traitez avec ce programmeur, vous devez garder une chose en tête: les problèmes que vous rencontrez avec lui peuvent très bien être aussi ce qui le rend utile pour vous. Ce que j'entends de vous, c'est "C'est un employé très compétent. Cependant, dans notre entreprise, nous attendons des gens qu'ils se comportent de manière x , et cet employé ne se comporte pas de cette manière."

Je comprends parfaitement la nécessité d'avoir une direction commune et des règles communes. Cependant, la recherche a montré que (en gros) c'est une bonne chose pour les organisations d'avoir leurs dissidents. En fait, vous pouvez en fait considérer cela comme un " bon problème à avoir". Certaines personnes marchent simplement au rythme d'un tambour différent, et non seulement ça va, vous devriez probablement l'encourager.

D'un autre côté, votre organisation a des contraintes pratiques. Vous ne pouvez pas laisser cet employé agir de manière à faire tomber tout le monde. Ma suggestion est de penser pratiquement. Identifiez deux choses:

  1. Les batailles majeures qui valent vraiment la peine de se battre. J'ai tendance à me demander ce que j'en dirai dans 20 ans. Dans 20 ans, direz-vous vraiment "j'aurais aimé qu'il communique mieux par e-mail"? Il est plus probable que vous vous surprendrez à dire quelque chose de plus du genre "J'aurais aimé trouver un meilleur moyen d'exploiter son talent. Garçon, il a dit des choses amusantes en réunion."
  2. Le fruit à portée de main. Des choses que vous pouvez résoudre sans trop de problèmes. Je soupçonne qu'au moment où vous êtes arrivé là où vous êtes, vous avez probablement déjà réglé la plupart de ces problèmes. Néanmoins, cela vaut la peine d'être recherché.

Voici les choses dont vous devez faire quelque chose. Ma suggestion est de lutter contre l'envie de simplement "résoudre" les problèmes de la catégorie 1, car vous ne pourrez probablement pas les résoudre. Cela dit, si vous et lui êtes capables de résoudre quelques problèmes importants et concrets sur lesquels vous concentrer, les chances de les résoudre seront beaucoup plus faciles.

#12
+1
Charles
2013-03-04 12:47:13 UTC
view on stackexchange narkive permalink

Le travailleur peut être assez créatif comme mentionné précédemment, ou peut être très concentré sur la résolution de problèmes (le problème tel qu'il le comprend) et être beaucoup moins concerné par la vue d'ensemble (créer un logiciel qui s'intègre parfaitement aux projets d'autres groupes, pour exemple).

Une idée que j'ai serait de lui démontrer certains des problèmes qu'il pourrait introduire en étant tellement concentré et peu disposé à communiquer avec les autres. Mon idée est de rédiger un exercice que tous les membres de l'équipe doivent réaliser au début d'une réunion (de faible priorité). L'exercice doit commencer par une instruction telle que «Cet exercice est destiné à des fins de discussion; des erreurs sont attendues et sont acceptables. Veuillez lire l'ensemble de l'exercice avant de commencer». (Apportez des stylos supplémentaires au cas où les gens n'auraient que des crayons et ont les stylos disponibles près de chez vous, probablement dans une petite pile devant vous, mais ne les distribuez pas.) Ayez un espace en haut intitulé Nom: (où ils remplirait leur nom) ;-)

L'idée de l'exercice est de demander des réponses qui changeront en fonction des informations (détails supplémentaires) fournies ultérieurement. C'est un exercice astucieux, qui, espérons-le, démontre qu'un travailleur en supposant qu'il comprend suffisamment bien les besoins et qu'il ne coordonne pas l'état et les mises à jour entraînera des erreurs et des réécritures. être comme ceci:

  1. Écrivez un programme simple ou un organigramme qui comprend les étapes de saisie des noms et adresses d'utilisateurs, leur attribue un numéro de client et imprime le numéro de client et les noms d'utilisateur et adresses.

    (inclure une demi-feuille de papier vierge.)

  2. Les utilisateurs doivent être en mesure de trier les données par un certain nombre d'identifiants, y compris le numéro de client, le nom du client, la ville du client, le code postal du client, le numéro de téléphone du client, le SSN du client, la date d'ouverture du compte du client ou la date de la dernière transaction du client.

    (Incluez un espace à propos de tiers de page.)

  3. Veuillez n'utiliser qu'un stylo pour votre travail et ne pas discuter de l'exercice pendant cette réunion.

  4. Important: veuillez ignorer les instructions ci-dessus. Au lieu de cela, écrivez seulement votre nom en haut et cochez les instructions numéros 1, 2, 3 et 4, et attendez tranquillement que les autres terminent.


Après environ deux minutes, dites merci, c'est tout le temps dont nous disposons pour cela. Veuillez remettre votre travail là où vous l'avez laissé. Ensuite, continuez avec la réunion normale.

Probablement beaucoup ou la plupart suivront les instructions commençant par 1, puis 2, au lieu de tout lire d'abord et de faire ce que 4 demande. Ceci est votre ouverture pour cet employé, ou si vous le souhaitez, pour tout le groupe, soit seul, soit en groupe (mais seul serait mieux pour une meilleure conversation avec l'enfant à problème) sur la valeur du partage d'informations, se tenir au courant des changements Besoins, etc. Assurez-vous de vous excuser pour l'astuce, mais vous vouliez avoir un moyen de le signaler de manière peu coûteuse, par opposition aux réécritures majeures qui pourraient survenir avec des heures supplémentaires, de mauvaises critiques, etc.

Je suis tout à fait d'accord avec votre motivation de leur faire voir comment ils rendent le travail des autres plus difficile, mais leur faire faire un exercice que vous avez conçu pour leur apprendre quelque chose ne peut que les pousser plus loin dans la mauvaise direction.
De plus, que se passe-t-il si «l'employé à problème» est le seul à réussir? Il est alors bien placé pour dire qu'il est en fait assez doué pour déterminer quand il a besoin d'entendre la fin de la phrase et quand il peut en déduire où elle va.
#13
+1
Samuel
2013-03-05 06:48:56 UTC
view on stackexchange narkive permalink

J’ai déjà été chef d’équipe du développement logiciel de mon entreprise pendant plus de 2 ans et j’ai observé que la productivité de chaque membre de l’équipe reposait à plusieurs reprises sur leur niveau de motivation et une certaine reconnaissance. Une fois, j'ai eu un gars dans mon équipe avec relativement plus d'expérience que les autres membres et j'avais vraiment besoin de sa contribution. J'ai réalisé après un certain nombre de discussions avec lui que son manque de coopération était dû au fait qu'il ne voulait pas être traité comme les autres membres de l'équipe. ce que j'ai fait, c'est lui donner des responsabilités et lui faire référence. De cette façon, il est devenu plus coopératif alors j'ai essayé de trouver ou de créer une responsabilité et de le placer en charge, plus comme le laisser diriger dans un domaine. Vous devrez donc peut-être trouver quelque chose de très créatif comme l'a dit Jason. le but est d'essayer de trouver un moyen de le mettre en charge / responsable de quelque chose afin qu'il se sente un sentiment de responsabilité et valorisé et plusieurs fois cela fonctionne. Je sais que gérer une telle personne peut être frustrant. Une manière similaire d'exprimer cette stratégie consiste à donner aux employés la possibilité de créer un "impact" dans le document "Les 9 principales choses qui motivent les employés à réussir" de forbe

Bonjour Samuel, bienvenue sur Workplace SE, un site de questions / réponses Stack Exchange pour des questions / réponses de haute qualité sur la navigation dans le milieu de travail professionnel. Sur notre site, nous exigeons que les réponses soient étayées par des faits, des références ou des expériences qui vous sont arrivées personnellement. Cela permet de valider votre réponse et donne aux futurs visiteurs l'assurance que votre réponse est correcte. Si vous avez besoin de conseils pour apporter une [modifier] à votre message, veuillez consulter la [FAQ] ou la [réponse]. Bonne chance! :)


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...