À la tête d'une équipe, suis-je autoritaire?

Je suis dans une position qui me semble très étrange. Je suis "chef d'équipe" dans le rôle d'un projet particulier, ingénieur logiciel principal dans le titre du poste. Dans mon équipe, j'ai 4 développeurs, dont l'un joue un rôle similaire sur un autre projet, mais maintenant le mien a la priorité, il travaille donc sur le mien. J'ai également 2 testeurs, dont l'un est Manager. Un autre membre de l'équipe est le «représentant du client» qui fait partie d'un service totalement indépendant. J'ai également un Manager qui est directement au-dessus de moi et je crois aussi au-dessus du Manager of Test qui fait partie de mon équipe ... pas si sûr à ce sujet.

J'ai essayé de clarifier pourquoi mon rôle est exactement plusieurs fois. J'ai eu du mal à comprendre où commence et se termine mon autorité, même si j'en ai. La réponse avec laquelle je travaille actuellement est que je suis "responsable technique" de l'équipe. Cela semble signifier que mon autorité est sur les décisions techniques concernant l'architecture, la conception et les normes de processus / codage en ce qui concerne le code produit lui-même.

Aujourd'hui, quelque chose est arrivé et les résultats du code que j'ai délégués à l'un des membres de mon équipe ont été présentés au reste de l'entreprise lors de notre réunion de démonstration Scrum. Le représentant du client fait la démonstration. Quelque chose a été montré aujourd'hui que je n'étais vraiment pas d'accord et personne ne m'avait même demandé si je voulais avoir mon mot à dire sur ce qui s'était passé. En bref, afin de permettre à un utilisateur d'afficher une valeur dans un rapport de la manière suivante (unités "doc", unités de conception, arrondies, non arrondies), elles ont fourni des champs d'accès pour chaque permutation. Ainsi, nous avons la valeur en unités doc arrondies, unités de conception arrondies, unités doc non arrondies, unités de conception non arrondies. Chaque enregistrement avec lequel l'utilisateur souhaite travailler possède de nombreuses valeurs de ce type et chacune est permutée de cette manière.

Je déteste vraiment ça.

Les personnes à qui nous avons montré ceci souhaitaient s'assurer que l'API que nous utilisons pour les rapports est la même que la façon dont nous faisons des choses comme exporter des données vers Excel. Malheureusement, nous prenons maintenant cet élan dans une direction qui, à mon avis, est vraiment, vraiment mauvaise.

Je me suis un peu énervé lors de la prochaine réunion et j'ai demandé aux deux personnes qui avaient fait cela: "Pourquoi n'ai-je pas été impliqué dans cette décision ??" C'est un problème qui revient sans cesse et j'ai du mal à avoir des gens qui semblent simplement faire partie de l'équipe que je suis censé diriger pour me demander si je veux participer. Parfois, je ne le fais pas et je pense que tout ce qu'ils trouveront ira bien. D'autres fois, je le fais. À moins que les gens ne me le demandent, il est même difficile de savoir qu'il se passe quelque chose qui nécessite mon avis et ils ne me donnent pas cette possibilité.

Malheureusement, mon autorité ne s'étend pas à dire aux gens: "La prochaine fois que vous partez et faites quelque chose comme ça sans même me parler, vous allez être discipliné." C'est une question de «relations publiques» qui est un domaine qui ne fait manifestement pas partie de mes compétences. En fait, ça me va bien puisque je ne veux pas avoir à faire face à ce genre de merde si quelqu'un d'autre le veut.

Aujourd'hui cependant, mon manager, devant tout le monde (ce qui est en partie ma faute aussi pour l'avoir soulevé comme ça) m'a dit que je ne pouvais pas être impliqué dans chaque décision et que je devais déléguer.

Je pense bien sûr que j'ai raison ... Je le fais toujours. Je ne dis pas que les choses que je pense sont BS. Je pense que j'aurais dû être approché sur cette question et demandé si j'avais une meilleure idée. Ma direction pour cela aurait en fait été de décider d'une seule valeur à fournir pour l'instant, car il s'agissait en fait des toutes premières étapes d'une nouvelle fonctionnalité, et de discuter des options pour fournir un accès supplémentaire à l'avenir si vous le souhaitez. Je n'aurais jamais approuvé ou recommandé la mise en œuvre actuelle et je ne pense vraiment pas qu'elle aurait dû voir le jour.

La question est, suis-je celui qui est déraisonnable?

Eh bien, nous en avons parlé tous les deux et avons convenu que nous avons tous les deux "laissé tomber la balle" et nous semblons être sur la même longueur d'onde. Les lundis matins ... Nous allons essayer de nous assurer que mon rôle est clair dans l'équipe et que oui, je dois décider quand un changement de conception ou de tâche doit se produire; Je suis proposé et je suis d'accord ou décide que je dois approfondir. Ensuite, je peux essayer de travailler sur d'autres éléments pour m'assurer qu'ils savent qu'ils peuvent venir me voir.

Il semble que vous ayez besoin de surveiller les validations de la source. Perforce a cette capacité nativement, Git l'a via des hooks, d'autres, je suis sûr, ont leurs propres méthodes. Vous n'avez pas à taire chaque commit, mais au moins avoir une notification et les différencier vous donnera un bref aperçu de tout ce qui va dans votre projet.

Quant à votre gestionnaire qui dit que vous devez déléguer, je ne suis pas sûr d'être d'accord - avec une équipe de quatre développeurs, vous devriez être en mesure de le gérer. Plus, je pourrais être du côté de lui (ou d'elle). Bien sûr, même dans les tâches déléguées, vous devriez demander des mises à jour de statut ou des procédures pas à pas sur les modifications de conception, etc.

Rien de négatif ne devrait jamais être évoqué lors des réunions - on dirait que vous et votre manager avez laissé tomber le ballon sur celui-ci. La pire chose que vous pourriez jamais faire à un pair est embarrass eux. En tant que lead (comme avec votre manager), vous devez être accessible et digne de confiance. Le fait de déprécier quelqu'un entraînera du ressentiment, ce qui nuira à votre capacité de diriger votre équipe (ainsi qu'à des employés mécontents).

Je déteste entendre le mot «discipline» de quiconque dans un rôle principal. La discipline (au moins dans ce contexte) est négative et non productive. Travailler avec quelqu'un (personnellement et non dans un cadre de réunion), découvrir pourquoi ils ont fait quelque chose et proposer des alternatives si vous n'êtes pas d'accord avec leurs solutions proposées, c'est ce qui devrait être fait. Parfois, vous constaterez que la personne avec laquelle vous travaillez a raison et que votre instinct est faux. Pourquoi? Ils ont passé plus de temps sur ce problème spécifique que vous.

Quelque chose d'autre qui m'inquiète est "Je pense toujours que j'ai raison". OMI, c'est la pire attitude possible de toute piste. Vous devez évidemment avoir confiance dans vos capacités, mais se rendre compte que si vous n'êtes pas profond du cou dans un problème spécifique, plus souvent qu'autrement, vos suggestions sortent de votre arrière (peu importe l' expérience que vous avez) et ne peuvent pas sois le meilleur. Si quelqu'un qui se concentre sur un problème spécifique offre une alternative, alors c'est votre travail (enfin, ainsi que le leur, en fonction de leur propre niveau d'expérience) de prouver pourquoi le vôtre est meilleur, pas simplement de dire: «Je suis le chef de file et Je pense toujours que j'ai raison ", c'est ce que votre phrase me fait croire.

Pour conclure

Oui, vous êtes déraisonnable sur certains points, mais d'autres non. En tant que chef de file, je m'attends à ce que s'il y a des changements de fonctionnalités ou d'architecture qu'ils soient au moins passés par vous.

Cependant, il est également de votre devoir d'assurer la qualité globale du système et du code, ce que vous devez faire vous-même. Votre entreprise utilise-t-elle des revues de code? Demandez à vos programmeurs de concevoir ce sur quoi ils travaillent avant d'entrer dans le code? Sinon, vous voudrez peut-être commencer à envisager l'utilisation de ce type de mécanismes de contrôle de la qualité.

Vous pourriez être examiné pour la gestion, et si c'est le cas, vous échouez (ce qui n'est peut-être pas une mauvaise chose; beaucoup d'entre nous sont de bons développeurs et seraient de mauvais gestionnaires, et je préfère de loin programmer que gérer des programmeurs).

Les gestionnaires n'ont souvent pas l'autorité pour tout ce qu'ils doivent faire. Faire avancer les choses de toute façon est un signe d'un bon gestionnaire. Vous devez trouver des moyens d'amener les gens à faire des choses sans faire aucune sorte de sanction disciplinaire. (Remarque: dénigrer les gens en public n'est-ce pas. Louez en public, critiquez en privé et montrez un certain intérêt pour vos subordonnés en tant que personnes.)

Les gestionnaires doivent également déléguer, même lorsque cela fait mal. Vous passerez probablement plus de temps à traiter ce problème que vous n'auriez passé à l'écrire vous-même, et c'est très bien. Une fois que vous avez réglé le problème, les personnes qui l'ont fait auraient dû apprendre quelque chose et sont moins susceptibles de faire les choses de la mauvaise façon à l'avenir.

La bonne façon de traiter quelque chose comme ça est en privé, en demandant d'abord aux développeurs pourquoi ils ont fait l'affichage de cette façon. Pas dans une réunion, et pas en supposant d'emblée que vous avez raison et qu'ils ont tort (même si vous avez raison et qu'ils ont tort). Donnez-leur une chance de s'expliquer. Cela ne signifie pas que vous devez suivre leur décision; après tout, vous êtes le responsable technique. Cela signifie que vous devez leur donner des raisons de le faire à votre façon, et vous devez résoudre tous les problèmes fondamentaux qui se manifestent lors de cette réunion privée.

De plus, les gestionnaires ont la responsabilité de ce qui sort de leur personnel. Vous devriez essayer de ne pas être aveuglé par tout ce qu'ils font, en particulier devant un client. Cela peut impliquer de garder une trace des enregistrements de code ou d'avoir des mini-conférences rapides avec vos développeurs (bien que vous deviez faire attention à cela, vous ne voulez pas les interrompre lorsqu'ils sont dans la zone). Vous devriez peut-être parler à tous les développeurs l'après-midi avant la réunion avec le représentant du client.

Ne le prenez pas personnellement

C'est un effort d'équipe. Vous êtes le responsable technique, pas le seul sur le projet. Vous devez vous concentrer sur le fait que l'équipe doit apprendre des erreurs ou changer le processus.

Diriger et apprendre

Une partie de tout poste de direction, y compris un responsable technique, consiste à comprendre que vous faites de votre mieux avec les personnes que vous avez. Plus l'équipe travaille ensemble, plus elle saura quand aborder les choses et quand ne pas le faire. Assurez-vous simplement de ne pas tomber dans le piège de dicter à votre équipe. Revoyez chaque semaine ce qui a mal tourné et ce qui s'est bien passé. Communiquez avec votre équipe si vous voulez qu'elle fasse les choses différemment. Les mesures punitives devraient toujours être un dernier recours et elles signifient généralement que vous devez soit renvoyer quelqu'un, soit que vous avez échoué dans votre rôle.

Examen avant la présentation client

Si vous êtes à la tête d'un projet, pourquoi n'avez-vous pas examiné la fonctionnalité et la mise en œuvre avant sa présentation?

Si c'est mal, corrigez-le

Expliquez clairement pourquoi quelque chose ne va pas et changez-le. C'est plus cher, mais si c'est vraiment faux, corrigez-le. Si ce n'est pas mal, juste différent de la façon dont vous vouliez que les choses se fassent, encore une fois; comprenez que vous n'êtes pas le seul à travailler sur le projet.

Y avait-il des spécifications documentant ce qui est censé être mis en œuvre? Étant donné une exigence trop ouverte, les développeurs remplissent souvent les blancs (ou nécessitent une microgestion) avec tout ce qu'ils pensent être approprié.

Donc vous finissez par vous adresser à votre manager avec "Donc, au lieu de travailler sur ce qui est dans la spécification, ils ont décidé de faire [fonctionnalité] à la place. Maintenant, nous sommes en retard, à cause d'une fonctionnalité qui n'a pas été approuvée en premier lieu."

Ensuite, vous pouvez commencer à nettoyer la fonctionnalité une fois que les développeurs ont été réaffectés.

modifier> Et non, je ne pense pas que vous soyez autoritaire. Leur travail finit par être ton cul.

Je me retrouve souvent dans la même position et le soulever lors de réunions et de discussions ne semble aller nulle part. Parfois, en dernier recours, avant de me résigner à suivre la décision prise (albiet pas la mienne), j'envoie un e-mail aux parties concernées en indiquant cela en noir et blanc avec mes raisons.

Ensuite, j'archiverais cet e-mail afin de m'assurer de l'avoir pour référence future au cas où un gestionnaire ou un client demanderait pourquoi quelque chose a été fait de cette façon, ou pourquoi un changement coûte tellement cher à réparer.

Je pense que vous avez eu tort de le dire comme vous l'avez fait. Vous n'avez pas tort de dire que vous devriez avoir une contribution sur la conception à ce niveau, mais je ne sais pas comment vous vous attendez à ce que cela soit raisonnable. Les gens ne vont pas exécuter un design par vous s'ils le considèrent comme simple; puisqu'ils peuvent tout aussi bien se tromper sur le fait que cela soit simple que sur le design lui-même, vous ne trouverez pas de gens volontaires pour vous montrer tous leurs mauvais designs. À ce stade, je suis surtout curieux de connaître vos habitudes de travail et vos modes de communication, mais peu importe comment tout cela se fait parfois, vous serez simplement aveuglé par ces choses. À moins d'examiner attentivement chaque commit, je ne sais pas comment vous le prouver.

Je ressens trop souvent émotionnellement ceci:

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

mais j'ai le sens intellectuel de savoir que j'ai parfois tort. Je sais aussi quand choisir un combat - vous ne pouvez pas discuter de tout, et parfois un accord inattendu de votre part peut faire des merveilles.

Qu'est-ce qu'un vrai leader?

Est quelqu'un qui peut renvoyer un subordonné, n'importe quel subordonné. (mais pas besoin d'en embaucher un nouveau)

Parfois, la plupart des gens sont "étiquetés" en tant que chef de file d'un projet mais, sans le pouvoir de tirer sur quelqu'un, c'est plus un "guide" / "enseignant" qu'un vrai chef.

Mais encore une fois, il peut arriver que vous puissiez être un chef d'équipe mais ne pas diriger votre projet actuel. Le pire des cas est lorsque le client dirige le projet. À ce stade, si le projet échoue (et il échouera), ce n'est pas votre responsabilité.

Et le pire des cas, c'est quand existent deux chefs de projet.

En tant qu'armée, les chaînes de commandement sont tout (pas aussi radicales que «mourir pour un projet» mais assez proches). Pour cette question, votre manager a brisé votre statut, abaissé la morale de "vos" gens et n'a pas aidé du tout.

Oui, votre patron a raison - vous ne pouvez pas être impliqué dans chaque décision. En fait, il est impossible de tout attraper comme ça à moins de tout faire vous-même. Je pense que c'est de là que vous venez - vous sentez que vous ne pouvez pas avoir une bonne maîtrise de l'ensemble du projet à moins d'être impliqué dans chaque petit détail, mais vous ne pouvez pas être impliqué dans chaque petit détail sans vous submerger (ce qui démoralisera totalement le équipe et probablement vous épuiser).

La réponse n'est pas de s'inquiéter des choses qui tournent mal - c'est toujours le cas - mais de s'inquiéter de les réparer par la suite, de manière constructive.

Si vous restez sur la voie de la communication, vous pouvez non seulement déléguer, mais vous pouvez laisser vos cadres supérieurs partir et faire ce qu'ils savent nécessaire sans toujours les retenir avec des critiques, des discussions et des tentatives malencontreuses de les contrôler. Faites-leur confiance pour faire la bonne chose et soyez là pour «discuter» de ce qui se passe afin que vous puissiez être tenu au courant (et vous mettre le nez lorsque vous en ressentez le besoin).

Vous avez plusieurs problèmes. Votre manager a d'abord pris le parti de votre équipe et vous a dit de déléguer davantage. Cela montre un manque de confiance dans votre capacité à diriger l'équipe. Cela montre en fait que si vous avez le titre de responsable technique, vous n'êtes en fait pas le responsable technique car vous n'avez aucune autorité. Vous devez vous asseoir avec votre manager et avoir un cœur à cœur à ce sujet. Personne ne peut réussir dans un poste de responsable technique sans le soutien de son manager et sans autorisation de modifier les décisions de conception prises par l'équipe sans son accord. Vous n'avez pas le pouvoir de faire votre travail. Votre patron doit comprendre que vous êtes dans une position de non-gain et qu'il doit vous apporter son soutien public pour que cela s'améliore. La responsabilité sans autorité est la pire situation possible pour se retrouver.

Ensuite, votre équipe vous a aveuglé. Vous devez en parler avec eux. Vous devriez avoir la discussion de conception avec eux avant de faire tout développement et bien avant de faire une présentation publique. Il est acceptable de déléguer une partie de la conception (bien que ce soit vous, pas eux, qui décidez de ce qui devrait être délégué), mais pas OK pour eux de continuer sans vous en informer. Ils ont perdu votre confiance en vous aveuglant, maintenant ils doivent apprendre un meilleur comportement. Vous devez vérifier avec eux fréquemment pour vous assurer qu'ils ne vous cachent pas à nouveau et s'ils le font, vous devriez faire une sorte de rapport formel du problème aux RH. Les prospects ne sont pas populaires, lorsque les développeurs les contournent délibérément après qu'on leur a dit de ne pas le faire, ils méritent des conséquences. C'est pas ca' Peu importe qu'ils vous aiment ou non, mais clairement au moment où ils ne vous respectent pas. Ils ont besoin d'avoir des conséquences pour leur comportement inapproprié ou cela ne fera qu'empirer. Cependant, vous ne pouvez pas résoudre cette partie du problème tant que vous n'avez pas résolu le problème de prise en charge de la gestion.

Ensuite, vous avez explosé publiquement, vous devez vous excuser publiquement. Cela vous aidera à reconstruire votre réputation.

Ensuite, vous devez prendre chacune des personnes de côté en privé et leur dire les conséquences de leur mauvais comportement continu (une fois que vous avez obtenu de votre responsable qu'il accepte de vous permettre de leur donner des conséquences). Éloge et soutien du public, la critique privée devrait être votre règle. Vous devrez peut-être également les consulter plus fréquemment en dehors des réunions de groupe afin qu'ils ne puissent pas vous aveugler.

Maintenant, franchement, car ceux qui sont au-dessus et en dessous, vous pensez clairement que vous êtes quelqu'un qui peut être ignoré et non tenu informé, vous devez vous interroger sérieusement sur ce qui les pousse à vous manquer de respect. Vous devez également décider si vous ne seriez pas plus heureux de ne pas être un responsable technique ou si vous devez vous rendre dans un endroit où vous aurez le pouvoir d'assumer la responsabilité. Si vous décidez de rester dans cette position, vous devrez demander aux gens de vous expliquer pourquoi ils vous traitent si mal. Ce sera douloureux et vous ne voudrez probablement pas entendre la réponse, mais vous devez savoir pourquoi vous êtes perçu comme ils vous perçoivent clairement.