Construire son équipe technique : les 5 pièges à éviter

Partager sur facebook
Partager sur linkedin
Partager sur whatsapp
Partager sur twitter
Partager sur reddit

1. Un mauvais recrutement

Le recrutement est bien souvent l’enjeux n°1 lorsque l’on parle de construire et développer son équipe technique. Recruter les bons candidats est primordial mais les bons profils tech sont rares : développeurs, devOps ou AdminSys ne courent pas les rues. Il faut alors arbitrer entre l’urgence du recrutement et ses exigences en matière de candidats (compétences, expériences, salaire etc.)

Les erreurs les plus fréquentes :

- Trop tarder à embaucher en recherchant absolument LA perle rare indéfiniment (mieux vaut revoir ses critères de priorité et/ou trouver des axes de flexibilité : télétravail, salaire etc.)
- A l’inverse, embaucher « à tout va » complique les onboarding, augmente le risque de déstabilisation de l’équipe et est souvent synonyme d’erreurs de casting.
- Mal définir ses recrutements à effectuer : soit parce qu’on se précipite, soit par manque de visibilité (ou de recul) sur les compétences manquantes à l’équipe actuelle.
- Un mauvais processus de recrutement :

  • Des process trop longs VS trop courts
  • Trop d’étapes (X entretiens, tests…)
  • Ne pas poser les bonnes questions
  • Mal identifier les compétences techniques en entretien.
  • Pour aller plus loin : Comment recruter un développeur : les bases.
    Pour être accompagné par un expert du recrutement tech, c'est par ici.

    2. Des incohérences de salaire

    Il n’y a pas de meilleur moyen pour planter son équipe que d’avoir des disparités de salaire injustifiées. Le salaire est fréquemment LA source de tension au sein d’une équipe car il n’est pas rare qu’un développeur soit mieux payé qu’un autre pourtant plus expérimenté et compétent.

    Il y a plusieurs raisons à cela, notamment :

  • La pénurie de candidats à l’embauche, qui fait grimper les salaires et le pouvoir de négociation des plus audacieux (VS les moins gourmands).
  • Les augmentations pour certains, mais pas pour tous.
  • Les disparités de salaires selon les régions et les plus-values (ou les diminutions) de salaire à l’embauche post déménagement.
  • Des développeurs passionnés moins expérimentés que d’autres mais parfois meilleurs et plus productifs.
  • C’est une illusion de penser que les membres d’une même équipe ne parlent pas de salaire entre eux. Les rumeurs vont bon train, les discussions à la machine à café sont quotidiennes et les infos circulent sur slack à la vitesse de la lumière.

    Sans pour autant adopter une grille salariale inflexible, il est nécessaire de garder une cohérence de salaire au sein des équipes, une logique avec pour objectif l’EQUITÉ.
    Si le mal est fait, privilégiez (tant que possible) une harmonisation des salaires pour apaiser toute source potentielle de conflit.

    3. Une mauvaise communication

    Équipe technique ou non, la communication est la clé du bien-être général et donc de la stabilité. Voici les erreurs les plus fréquentes, qui impliquent au mieux une perte de productivité, au pire des tensions et des démissions :

  • Manque de transparence
  • Rejet catégorique des doléances
  • Mauvaise remontée des informations
  • Absence ou mauvaise définition des objectifs
  • Échanges rares ou de mauvaise qualité
  • Ce qu’il faut faire, à l’inverse :

    Faciliter les échanges, à la fois au sein de l’équipe et avec la direction.

    Prévoyez des points réguliers, à la fois avec toute l’équipe mais aussi des points individuels. Prendre un moment avec chacun est essentiel pour comprendre l’état d’esprit du moment, les doléances potentielles, remarques, suggestions, projections, atteintes d’objectifs, etc.
    Organiser des RDV mensuels ou trimestriels fait partie des bonnes pratiques.

    Assurez-vous également que la hiérarchie ne soit pas hermétique, que les informations remontent correctement et qu’un véritable échange ait lieu (et non pas que dans un sens). Valorisez tant que possible les membres de l’équipe qui sont force de proposition, si tenté que leurs idées ne soient pas farfelues.

    Définir des objectifs atteignables et des perspectives d’évolution accessibles

    Définissez clairement les objectifs courts et moyens terme : qu’il s’agisse d’objectif individuels, collectifs, techniques, business, stratégique etc. Établissez les règles du jeu de façon transparente, impliquez et motivez.

    Plus que de simples objectifs à valeur d’évaluation, communiquez sur des objectifs globaux, ceux du pôle, de la DSI, de la société. L’équipe technique n’est pas une simple machine à exécuter les ordres dictés par des attentes business. Donnez aux développeurs et aux membres de l’IT une vision globale, stratégique. Il n’y a rien de pire que de ne pas connaître la finalité de son travail.

    4. Des rôles mal définis ou une mauvaise organisation

    Facile de s’y perdre lorsque l’équipe grandit. Entre un développeur qui a été embauché pour une tache précise et qui a finalement agrandit son champ d’action (ex : un développeur backend qui a un rôle de plus en plus fullstack) et un autre qui a mis un pied dans la gestion de projet, l’organisation d’une équipe devient vite compliquée.

    Il faut savoir répondre (et bien) à la question suivante : « Qui fait quoi, quand et comment ». Et ce n’est pas si évident.

    D’autres questions "de base" sont également primordiales à traiter (et reviennent souvent) :

  • Quelles sont les responsabilités techniques et/ou managériales de chacun.
  • Quels sont les périmètres d’action de chaque membre de l’équipe.
  • Le Lead développer a t’il une responsabilité de « manager » Humain ou seulement de Lead Tech ?
  • Le chef de projet a-t-il un rôle de pilote uniquement ou est-il un supérieur hiérarchique de l’équipe de dev (plus rare) ?
  • En méthodologie Agile, le Scrum master est-il – ou doit-il être - changeant selon les projets ? Quel est son périmètre d’action ?
  • 5. La banalisation du travail effectué / le manque de considération

    Le manque de reconnaissance est l’une des raisons principales du mal-être des développeurs salariés.
    Ce n’est pas parce que le travail doit être fait qu’il ne faut pas souligner ou récompenser le travail bien fait. Beaucoup d’entreprises de grandes tailles délaissent les équipes techniques, souvent parce qu’elles n’ont pas conscience de leur importance. Les compétences techniques pointues sont rares et les bons éléments d’une équipe doivent être récompensés à leur juste valeur.

    Primes, variable sur objectifs, avantages en nature, télétravail, autant d’éléments qui permettent de récompenser l’investissement des meilleurs employés. Et un simple « merci » est déjà un bon début 😉 !

    Vous recherchez un développeur en CDI ?
    Afin d'optimiser votre expérience, ce site utilise des cookies 🍪, que vous acceptez en poursuivant votre navigation.