Gérer la hiérarchie dans une équipe de développement

Le débat initié récemment sur ce blog concernant la place du développeur a ouvert, au travers des commentaires, une question complémentaire à la fois plus vaste mais tout aussi importante : comment gérer l'évolution de carrière de chacun et, par extension, la hiérarchie dans une équipe ?

Il est à la mode de contester l'idée que la hiérarchie est nécessaire pour organiser une équipe. Je ne souscris pas à cette mode. Pour expliquer ma position, je veux d'abord revenir sur l'idée même de hiérarchie. Souvent, on considère que gravir les échelons de l'organisation d'une société donne droit à plus de "pouvoir" (notez les guillemets…). Cette idée, je la rejette également, tout en étant conscient que c'est effectivement comme cela que ça se passe, dans le faits, le plus souvent. 

De mon point de vue, appuyé par l'expérience (il ne s'agit pas là de pure spéculation intellectuelle, ni de posture éthique), la hiérarchie est nécessaire dans une équipe, car des décisions doivent être prises pour que les choses avancent. Et les décisions ne peuvent pas toujours être prises de manière collégiale. Aussi, je considère qu'évoluer dans une hiérarchie ne conduit pas à exercer plus de pouvoir, mais à assumer plus de responsabilités.

Certains m'ont objecté que pour être en mesure de faire face à ces responsabilités, il est indispensable d'avoir le contrôle de la situation, et donc le pouvoir, ne serait-ce que de prendre les décisions que l'on juge nécessaires pour mener à bien sa mission. Mon désaccord sur ce point est… subtil. Je pense que ce que l'on qualifie couramment de pouvoir devrait être considéré différemment : pour moi, c'est d'autorité dont on a besoin, laquelle doit être naturelle et légitime pour s'exercer pleinement. Je précise, pour éviter les quiproquos que j'entends autorité dans le sens de référence, et non pas dans son acception coercitive.

Le pouvoir confié arbitrairement à un membre de l'équipe, au prétexte qu'il serait directement lié à sa position dans l'organisation, ne sera pas, ou alors difficilement, accepté par ceux qui sont placés en-dessous (sur l'échelle des responsabilités). En effet, si l'on a pas confiance en la personne supposée assumer la responsabilité de la mission dans laquelle on est engagé, le risque est grand de contester voire même de refuser ses décisions. Avec des conséquences énormes sur le succès de l'équipe. 

Une autorité exercée sans légitimité provoque d'abord la frustration. Et la frustration dégrade considérablement la cohésion de l'équipe. Partant du principe que tous les membres de l'équipe ont une importance égale (chacun est indispensable à la réussite de tous), négliger sa cohésion est sans doute la pire erreur qu'un manager puisse commettre.

Aussi, au fur et à mesure que l'équipe s'agrandit, et que de nouvelles responsabilités sont identifiées, il faut trouver la bonne personne à qui confier cette responsabilité. Sur quelle critère ? Le plus important est sans doute la confiance. Pas seulement celle que le manager à dans le candidat qui lui semble être le mieux placé, mais aussi et surtout la confiance qu'ont ses collègues en ce candidat. C'est la confiance qui assurera la légitimité, et la légitimité qui à son tour assurera l'autorité. Et c'est enfin l'autorité qui garantira qu'une responsabilité sera prise en charge dans les meilleures conditions.

Parmi les dilemmes cornéliens auxquels le manager peut être confronté, il y a celui de l'ancienneté. Un membre de l'équipe doit-il se voir confier des responsabilités au seul titre de son ancienneté ? Théoriquement, non, bien sûr. Seules les compétences devraient guider une telle décision. Mais avec le risque là encore de frustrer ce membre de l'équipe si on lui préfère un plus jeune, ou un collègue arrivé après lui dans l'équipe. C'est ce qui explique que l'on préconise parfois de préférer solliciter quelqu'un de l'extérieur, dont on aura (un peu) moins de mal à expliquer qu'il est plus qualifié pour le job et que c'est pour ça qu'on le fait rejoindre l'équipe. 

Mais ça reste délicat bien sûr. Gare dans ce cas à ne pas démoraliser celui qu'on aura laissé "à sa place", car même si on fait souvent ce choix parce que la personne est à la place qui lui est la plus appropriée, il faut quand même trouver des motivations et un objectif personnel. Je reviendrai plus loin sur ce point.

L'ancienneté sur un poste donné, autrement dit l'expérience, ne garantit pas toujours la capacité à assumer des responsabilités autres. C'est là que je boucle la boucle avec le sujet précédent : l'expérience de développeur ne prépare en rien aux responsabilités de responsable de projet, c'est pourquoi on fait rarement évoluer les développeurs vers ce poste, ce qu'ils vivent pourtant le plus souvent comme une frustration.

L'erreur, dans cette situation, vient de ce que les responsabilités dans les équipes sont souvent mal identifiées. Il existe de nombreuses responsabilités que l'on peut dégager à l'intérieur de l'activité de développement, à commencer par l'architecture, mais aussi la qualité (via les tests), ou encore le design de bases de données. Chacune de ces responsabilités peut justifier la création d'un poste dédié, accompagné d'un package plus motivant que celui de "simple" développeur. Ce qui représente je pense le meilleur moyen de satisfaire le désir naturel de chacun de progresser professionnellement sans compromettre la cohésion de l'équipe.

Résumons-nous : la confiance mutuelle est la base de la cohésion de l'équipe. La confiance confère la légitimité nécessaire à exercer une autorité indispensable au bon fonctionnement d'une équipe. Et la confiance est toujours plus facile à accorder à quelqu'un dont on sait qu'il a une réelle maîtrise du sujet qui lui est confié. Alors je propose aux managers d'équipes IT d'être créatifs, de ne pas limiter leur hiérarchie à développeurs/chef de projet, de ne surtout pas mettre les premiers sous l'autorité du second, et de trouver à chacun la place dans la laquelle il se sentira respecté, car légitime, et qui répondra à ses aspirations en terme d'évolution de carrière. 

Pour cela, il ne faut pas hésiter à déléguer des responsabilités bien identifiées, et à créer des postes pour que chacun puisse exercer au mieux ses talents dans l'équipe. C'est ainsi que l'on pourra demander à quelqu'un de rester dans sa partie sans le frustrer. La position  de développeur ne doit pas être un fourre-tout de l'organigramme dans lequel on maintient tous les profils techniques dont on ne comprend pas toujours bien le job, et dont on pense parfois que la seule évolution de carrière consiste à migrer vers le management. 

Le développement est un métier technique, qui offre de multiples spécialisations, et c'est vers ça qu'il faut tendre : il faut former les collaborateurs sur des aspects plus précis du métier pour qu'ils puissent continuer de s'éclater dans leur job, de rendre d'inestimables services aux clients de leur société (pour le service) ou à leur employeur, et tout ça sans vivre la frustration de rester développeur pendant un temps infini, sans avancement ni de responsabilité ni de considération, et surtout, sans perspective !