Woodgate.fr

Julien Ramel

Ingénieur Recherche & Développement, passionné par le Web et ses technologies. Responsable Technique de Wax Interactive Suisse. Lyonnais expatrié à Lausanne.


CTO, Responsable ou Directeur Technique ? Soyez plutôt un héros



J'ai pris l'année dernière la responsabilité technique de Wax Interactive CH, l'agence Web du Groupe SQLI. Mon quotidien est responsabilisant : faire en sorte que les projets se déroulent convenablement (selon différents référentiels & points de vue), que les membres de mon équipe puissent travailler dans de bonnes conditions et assouvir leur passion pour la technologie. Faire en sorte que rien ne prenne feu. Les tâches quotidiennes d'un Responsable Technique sont multiples : un mélange de savoir-faire et de savoir-être, de compréhension et d'influence. C'est être responsable de chacun et de ce que produit l'équipe.

Ma prise de responsabilités s'est dans un premier temps traduite par l'éveil de mon instinct de survie (« comment répondre aux attentes minimales ? ») puis par une prise de confiance et une montée progressive en compétences. Une pyramide de Maslow griffonnée et des coups de panique plus tard, j'ai avancé et ai maintenant une vision assez précise de ce que je considère comme une feuille de route, des conseils pour réussir au poste de CTO, Responsable ou Directeur Technique.

Je vais vous présenter cette feuille de route sans ordre particulier, en utilisant le terme "responsable" (pour simplifier CTO/Responsable/Directeur) tout en précisant que personne n'est parfait (moi le premier, mais j'y travaille) et que je ne connais personne correspondant au profil idéal. Le métier évolue en permanence, les contextes diffèrent, et la route vers la réussite est longue et semée d'embûches.

« Ne vous contentez jamais de ce que vous êtes ou réalisez, sachez vous donner des objectifs réalistes et surtout ne vous croyez jamais incapable d'accomplir quelque chose, même si cela vous prendra du temps »

N'hésitez pas à me faire part de vos remarques et idées d'amélioration via Twitter ou Linkedin. Cette feuille de route est par ailleurs susceptible d'évoluer dans le temps.


La feuille de route du héros

 
1 – Ne paniquez pas
2 – Soyez un technicien et soyez légitime
3 – Voyez large, comprenez le métier
4 – Soyez un leader, un vrai
5 – Prônez la qualité, mais sachez jauger
6 – Sachez trancher, et rapidement
7 – Remettez-vous en cause
8 – Créez un climat de confiance
9 – Créez un bon environnement de travail
10 – Mettez en place des habitudes
11 – Embauchez meilleur que vous
12 – Sachez déléguer, mais pas que
13 – Sachez éviter lower & over-engineering
14 – Sachez limiter vos responsabilités
15 – Ne devenez pas « Dr. No »
16 – Pensez à l'avenir
17 – Sachez comment et jusqu'où progresser
18 – Jaugez votre techno-dépendance
19 – Partagez votre passion
20 – Soyez fantastique... et éthique


1 – Ne paniquez pas

 
Je commence par ce point car il vous permettra de vous préparer psychologiquement à la suite de l'article : prenez les étapes une par une et ne paniquez pas si certaines semblent difficilement franchissables, voir impossibles à atteindre dans votre contexte.

C'est un réflexe tout à fait humain : la surcharge, le stress, l'impression que tout est en train de s'écrouler, les problèmes qui s'accumulent au quotidien... déclenchent un sentiment de panique. Et pourtant, seul le fait d'être lucide vous permettra de réfléchir correctement à une sortie de crise. Faites une pause, prenez l'air, soyez relativiste et pas fataliste. Prenez des vacances si besoin, demandez de l'aide, listez les urgences, pondérez-les, et traitez-les dans l'ordre avec le plus de pragmatisme possible. Ce type d'épreuve vous permettra par ailleurs de grandir et vous pourrez les appréhender de plus en plus facilement.

On ne travaille jamais correctement lorsqu'on perd ses nerfs, et on attend d'un responsable qu'il garde le cap dans la tempête lorsque le bateau tangue.


2 – Soyez un technicien et soyez légitime

 
La première chose que je souhaite à n'importe quel responsable est d'être orienté technique avant tout.

Vous devez être en mesure d'identifier et de connaître précisément :

  • Les technologies utilisées par votre équipe
  • Les forces et faiblesses des technologies et des projets
  • Ce qui posera problème techniquement aux membres de votre équipe
  • Ce qu'il existe sur le marché pour répondre aux besoins potentiels
  • Ce qui permettra à votre projet de rester pérenne et limitera la dette technique

Quelqu'un qui vient d'un autre pôle (marketing, commercial, design, gestion de projet) ne peut être efficace dans ce nouveau rôle que s'il a fait ses armes techniquement et s'il "baigne" dans le métier depuis des années. Comment comprendre les problèmes d'un développeur ? En étant ou ayant été un développeur.

Par ailleurs, votre légitimité se joue à plusieurs niveaux :

  • Auprès de votre équipe
  • Auprès des autres pôles de votre société
  • Auprès de votre hiérarchie
  • Auprès de vos clients, partenaires, prestataires, et autres externes

Vous devez être légitime à votre poste : sorti de l'école ou fort de vos 2 années d'expérience en agence, vous arborez avec fierté votre titre "CTO" au sein de votre nouvelle start-up révolutionnaire sur Linkedin. Si vous n'avez pas de projet technique ou d'équipe, vous n'êtes pas CTO.


3 – Voyez large, comprenez le métier

 
Ce qui fait un bon responsable, c'est avant tout sa compréhension de l'environnement, et cela se traduit par une compréhension technique mais aussi par une compréhension de la globalité des enjeux des projets.

Les enjeux peuvent être de différentes natures :

  • Techniques
  • Artistiques
  • Commerciaux
  • Marketing
  • Besoins métier
  • Politiques (inévitables)
  • Personnels (à éviter)

Vous vous devez d'être ouvert d'esprit : vos collègues non-techniciens ont un rôle très spécifique, leurs propres besoins et critères de réussite, et n'ont probablement pas la même vision que vous de votre projet. N'oubliez pas que vous travaillez avant tout pour une cause commune et que des choix qui peuvent vous paraître farfelus sont parfois dictés par des stratégies qui vous dépassent car ils sortent de votre contexte et de votre domaine de compétences. Vous devez être en mesure de comprendre les grandes lignes des autres pôles de votre société et de prendre du recul sur les stratégies non-techniques.


4 – Soyez un leader, un vrai

 
Ah, la fameuse comparaison entre un manager et un leader. Le mot leader vient du verbe anglais « to lead » qui signifie mener, indiquer le chemin. Quel que soit votre niveau hiérarchique, du moment que vous managez des personnes, vous vous devez d'être un leader, plus qu'un manager.

Un leader (qui est souvent un manager) a un rôle extrêmement important :

  • Fédérer et mobiliser les énergies autour d'une action commune
  • Proposer le climat le plus favorable et respectueux possible
  • Mettre en confiance les membres de son équipe
  • Les faire évoluer et leur permettre d'atteindre leurs objectifs personnels
  • Tirer le meilleur de chacun pour atteindre les objectifs
  • Gérer les conflits, prendre des décisions, communiquer

Le leader est un influenceur positif, un inspirateur, un communiquant. Son objectif est d'obtenir le meilleur de chacun, et non pas de museler.


5 – Prônez la qualité, mais sachez jauger

 
Vous serez très souvent confronté à un choix : « devons-nous travailler plus longuement sur notre projet afin qu'il soit plus stable et mieux pensé, ou à l'inverse produire un maximum de choses "visibles" en un minimum de temps pour contenter notre employeur ou le métier, mais sans assurer la qualité ? »

Par expérience, je prônerai toujours la qualité pour plusieurs raisons :

  • La dette technique sera moindre
  • Les développeurs seront plus heureux
  • Les projets seront plus beaux et plus performants
  • La maintenance sera facilitée
  • Les évolutions seront moins contraignantes

Ceci-dit, chaque projet à ses contraintes et son contexte et dans la plupart des cas, un employeur ou un client ne sera pas prêt à payer double ou triple pour un projet extrêmement qualitatif si le fonctionnel correspond à ses attentes quelle que soit la qualité technique. Certains projets éphémères ou urgents peuvent être exécutés en fonction de leurs contraintes.

C'est un enjeu important en agence : le client voudra toujours payer le moins possible, et les membres des équipes techniques voudront travailler le plus qualitativement possible et seront frustrés à chaque projet « sous-vendu pour être gagné ». Et la frustration génère le mécontentement, puis les départs, et ainsi de suite.

Chez l'annonceur, c'est aussi un enjeu : il faut être en mesure de placer subtilement un curseur de qualité permettant d'arriver rapidement à un MVP (Minimum Viable Product) tout en prévoyant les futures évolutions du produit. La méthode Lean est bonne, reconnue et répandue, mais « Lean » ne veut pas dire « faire à moitié ».

Il est important de se fixer des règles, des limites de qualité que l'employeur, le client ou le métier devront (en principe) accepter. Ces limites ne doivent être ni trop hautes, ni trop basses. Ne laissez pas la qualité être dégradée, ou pas trop régulièrement, sans quoi les membres de votre équipe se verront comme des vendeurs de kebab face à vos concurrents gastronomiques, et déserteront, frustrés.


6 – Sachez trancher, et rapidement

 
La responsabilité technique se traduit avant tout par des prises de décisions. Vous ne serez souvent pas entièrement convaincu, et c'est plutôt bon signe : ça signifie que vous avez l'esprit ouvert, que vous ne vous enfermez pas dans un choix par défaut et que vous laissez place à des alternatives.

Ceci dit, vous devez être suffisamment sûr de vous pour pousser et assumer votre décision. Devant votre hiérarchie, vous devrez rassurer et ne pas laisser penser que vous ne contrôlez pas la situation.

À titre personnel, j'ai une règle : la règle des 80/20. Partant du principe que je ne serai pratiquement jamais convaincu à 100%, je ne prends une décision que si celle-ci me convainc à au moins 80%. En général, les 20% qui créent l'indécision correspondent à des risques : précisez-les et idéalement, prévoyez des solutions pour les prévenir ou minimiser leur impact.

Enfin, ne laissez pas trainer des questions en suspend sans que cela ai un intérêt dans votre décision. Sachez trancher, assumer votre décision, et expliquer les raisons qui vous ont poussé à faire ce choix.


7 – Remettez-vous en cause

 
Vous êtes le responsable. Vous êtes arrivé à ce stade de votre carrière car vous avez passé avec succès de nombreuses étapes, avez atteint vos objectifs, vous êtes sorti de votre fameuse zone de confort et avez travaillé dur au quotidien.

Pour autant, vous n'avez pas la science infuse. Vous, moi, nous ferons toujours des erreurs et des mauvais choix et serons responsables de problèmes. Le respect et la sympathie des membres de votre équipe se gagnent, il ne vous sont pas dûs : montrez-leur que vous les écoutez et que vous respectez leur avis. Montrez leurs que vous assumez vos erreurs.

Sachez faire confiance et prendre une décision qui n'était pas initialement votre choix ou votre idée. Il est tout à fait normal de ne pas avoir raison et de changer d'avis pour le bien d'une équipe ou d'un projet.

Ne faites pas non plus une confiance aveugle à votre stack technique. Remettez-la en question régulièrement et ne foncez pas tête baissée dans chaque projet sans réflexion technique. Ne rejetez pas non plus une proposition ou contrainte technologique sans étudier sa valeur de façon objective et sans être capable d'expliquer de façon extrêmement pragmatique pourquoi elle ne convient pas au projet (et pas uniquement parce qu'elle vous force à sortir de votre zone de confort).


8 – Créez un climat de confiance

 
La confiance est probablement le sentiment le plus important dans une équipe technique. Il permet aux membres de l'équipe de se sentir naturellement protégés, de savoir qu'ils pourront compter sur leurs collègues ou leur responsable en cas de besoin. C'est ce qui leur permettra de s'affirmer et d'évoluer, et à l'inverse un employé qui n'a pas la confiance de sa hiérarchie (qui le sait, ou qui le sent) deviendra presque immédiatement inefficace.

Un responsable doit savoir accorder sa confiance aux membres de son équipe, et le prouver régulièrement. Cette confiance doit être bi-directionnelle : les membres de l'équipe doivent aussi faire confiance à leur responsable et employeur, et lui rendre (par des efforts, de la compréhension, etc).

Le principe est le même dans le monde sportif : les meilleurs joueurs de football au monde ne gagneront aucun match s'ils ne jouent que pour eux, et à l'inverse une petite équipe de division inférieure sera capable de miracles lorsqu'ils sont unis dans leurs efforts.

N'hésitez pas à prendre la température régulièrement et à être à l'écoute des sentiments des membres de votre équipe. Et n'oubliez pas que la confiance ne se donne jamais qu'à moitié.


9 – Créez un bon environnement de travail

 
L'environnement de travail est un élément essentiel au bon déroulement de vos tâches quotidiennes et au bien-être des membres de votre équipe. N'oubliez pas qu'un employé travaillera toujours dans des conditions idéales.

D'un point de vue matériel, équipez vos employés d'une machine performante et adaptée, et installez-lui 2 voir 3 écrans s'il le demande. Les gains en matière de production dépasseront vos attentes et de très loin vos investissements.

  • Un employé sur une machine plus puissante peut être 2 fois plus performant, ce qui rend l'investissement financier quasiment nul comparé aux bénéfices dégagés (vous trouverez quelques calculs ici)
  • Un employé qui se rend compte que son employeur lui donne les moyens de réussir est un employé heureux, qui prend confiance, et saura le rendre

Par ailleurs, et même si cela sort de vos fonctions, notez qu'un environnement non-technique adapté et agréable aura aussi une influence très importante sur le bonheur (et donc la performance) de vos employés : mobilier, goodies, avantages, etc.

D'un point de vue des outils, ne soyez pas aussi mal chaussé qu'un cordonnier. Vous pourriez augmenter très largement le rendement de votre équipe avec de faibles coûts en outils (services externes ou installation interne).

Une équipe de développement d'applications Web devrait par exemple être équipée d'outils modernes et performants :

  • De bonnes machines de développement
  • D'outils de communication interne robustes (Exchange, Google Apps, Office365)
  • De serveurs Web internes (développements) et externes (démonstrations, hébergement)
  • D'outils de gestion des repositories Git (Gitlab, Github, Bitbucket)
  • D'espaces d'échange de fichiers (Dropbox, serveur Samba interne)
  • D'outils de discussion instantanée (Slack, Skype, Jabber)
  • D'outils d'intégration continue (Jenkins, Gitlab CI, Travis)
  • D'espaces de documentation (Wiki, Confluence)

Sortez-vous de la tête qu'être économe matériellement et au niveau de votre organisation technique quotidienne vous fera économiser, car c'est tout l'inverse. Vous ne gagnerez pas une course automobile équipé d'un vélo et ne générerez que la frustration de vos coureurs.


10 – Mettez en place des habitudes

 
Votre rôle de responsable consiste aussi à générer des réflexes dans le quotidien des membres de votre équipe, que ce soient des réflexes techniques ou non. Mettre en place des habitudes par palier et avec des objectifs raisonnables, c'est diminuer avec le temps le sentiment de contrainte. Je vous présente un exemple que nous avons mis en place dans notre équipe.

Nous avions un problème : nous ne faisions pas assez de veille, nous la partagions relativement peu (sur Slack) et surtout nous avions tendance à oublier trop vite nos ressources. J'ai donc mis en place un classeur en ligne (Excel Online) dans lequel les membres de l'équipe technique entrent ce qu'ils trouvent utile ou notable dans leur veille. Une fois par semaine, nous parcourons ce document pendant 15 minutes autours d'un café, et chaque personne présente ses ressources. C'est un moment d'échange, le déclenchement d'une mémoire collective qui nous permet plus facilement de nous dire « Nous avions discuté d'une solution permettant de répondre à ce problème il y a quelques semaines », et de retrouver les ressources. Puis nous partageons ce document aux autres pôles et à notre hiérarchie dans une newsletter interne hebdomadaire, grâce à un processus automatisé.

Les objectifs de cette action sont multiples :

  • Partage de notre veille
  • Partage de nos learnings
  • Mémorisation collective de nos ressources
  • Suscitation d'un réflexe de veille quotidienne

Le réflexe n'est logiquement pas arrivé tout seul les premières semaines, et il n'était pas rare qu'un ou plusieurs membres de l'équipe n'aient pas rempli le document. Je n'ai pas mis de pression et ai été très clair : personne n'est forcé de participer. Pourtant, après plusieurs mois, l'habitude s'est installé : nous intégrons toujours plus de ressources dans le document semaine après semaine, et tout le monde participe.

Voici quelques pistes d'habitudes que vous seriez bien inspiré de mettre en place dans une équipe technique :

  • Partage de veille et learnings
  • Revue de code
  • Écriture de documentation
  • Écriture de tests unitaires / fonctionnels
  • Maintenance
  • Open-source
  • Communication

Mettez en place des habitudes qui ne soient pas trop contraignantes, et rendez-les ludiques si besoin. Sachez identifier les actions à mener, ordonnez-les par importance et par urgence, et tachez de ne pas tout pousser en même temps.


11 – Embauchez meilleur que vous

 
Une des règles primordiales lorsqu'on est le responsable et que l'on a à sa charge le recrutement des profils techniques, c'est de toujours chercher meilleur que soi. Par essence, votre position multi-casquette vous empêchera d'être un spécialiste de tous les domaines, surtout à une époque d'évolution ultra-rapide des technologies.

Mettez votre égo de côté et n'ayez pas peur de recruter quelqu'un de bien meilleur que vous dans son domaine (ou même dans le votre), c'est comme ça que votre équipe grandira et se professionnalisera. Ce ne peut être que positif, et cela prouve que vous faites passer l'intérêt de votre projet ou de votre société avant le votre.

La meilleure façon d'apprendre, c'est de voir faire et d'avoir des mentors spécialistes des secteurs vers lesquels vous voulez aller. Votre équipe a besoin de piliers techniques capables de tirer tout le monde vers le haut.


12 – Sachez déléguer, mais pas que

 
Suite à votre prise de responsabilités, vous avez de moins en moins de temps pour participer techniquement aux projets. Avoir de la visibilité sur votre planning et sur vos charges vous permettra dans l'idéal de vous réserver des sessions de développement, mais vous le voyez bien, vous mettez indéniablement moins la main à la pâte.

Vous devez accepter de ne pas pouvoir tout faire, au risque de ne tout faire qu'à moitié. Faire faire, c'est aussi donner sa confiance. Néanmoins, un risque important est de perdre peu à peu ses compétences techniques en ne pratiquant plus du tout.

Tâchez de garder un grand minimum 20% de votre temps de travail pour de la technique (hors veille, revue de code, choix techniques, etc). Idéalement 50%, et en fait tout le temps disponible que votre rôle vous permettra car vous devez avant tout rester un technicien, ne serait-ce que pour connaître comment sont construits vos projets et voir ce qui a été fait par votre équipe.

Bien entendu, vous pouvez aussi déléguer des tâches non-techniques à des membres de l'équipe qui aspirent à pratiquer et en qui vous avez confiance pour la mission.


13 – Sachez éviter lower & over-engineering

 
Un enjeu assez délicat de la responsabilité technique est de savoir positionner un curseur afin de rendre les projets ni trop pauvres techniquement, ni trop complexes. Vos projets doivent trouver chaussure à leur pied, ou plutôt, technologie à leur mesure.

Le lower-engineering consiste a sous-estimer la complexité technique d'un projet et à lui assigner une technologie pas assez puissante ou pas adaptée. Par exemple : choisir un CMS comme WordPress pour un projet nécessitant beaucoup de types de contenus ou de développements spécifiques, une sécurité inviolable, un environnement scalable ou encore des performances accrues. Le risque est alors d'être bloqué par sa technologie dans ses tentatives d'évolution.

L'over-engineering consiste au contraire à déployer une armada de solutions techniques pour un projet qui ne les mérite pas. Par exemple : plusieurs serveurs en cluster avec des conteneurs Docker, ElasticSearch pour les données, un service de queues RabbitMQ avec indexation asynchrone, des logs agrégés avec Logstash, et enfin du cache via Redis pour un blog de 15 articles et 50 visiteurs journaliers. Le risque est d'augmenter très fortement la dette technique de votre projet et d'imposer des coûts de maintenance beaucoup plus importants.

Jugez la complexité technique de vos projets, prévoyez les évolutions probables, et préférez une technologie logique à une technologie qui deviendra une contrainte sur le long terme.


14 – Sachez limiter vos responsabilités

 
Vous êtes le responsable technique, mais pas le responsable de tous les maux de votre société, aussi technique soit-elle. Chaque société façonne "son" responsable et il est important de communiquer régulièrement sur votre rôle, et de savoir rejeter certaines responsabilités qui ne sont pas de votre ressort ou pour lesquelles vous ne considérez pas être le meilleur.

Établissez une liste de vos rôles quotidiens, sachez les estimer, les cadrer et les préciser, et surtout prévoyez du temps pour les surprises et vos sessions de développement. N'acceptez pas tous les rôles si vos estimations dépassent votre volonté ou vos capacités hebdomadaires. En améliorant vos process et en prenant des habitudes, vous pourrez réaliser votre travail plus rapidement et reprendre des sujets par la suite.

Il vaut mieux en faire moins, mais le faire bien.


15 – Ne devenez pas « Dr. No »

 
La meilleure explication que j'ai pu lire sur ce problème courant (que je vais vous préciser plus bas) est la suivante, par Phin Barnes :

« If your engineering lead has become Dr. No, you may have a culture that treats engineering as a resource to be consumed, as executors who can never work fast enough or hard enough to deliver for everyone else. »

Le problème est en fait un cercle vicieux :

  • Le métier demande des fonctionnalités
  • L'équipe technique n'est pas capable de répondre à la demande, pour des raisons diverses qu'elle ne maîtrise d'ailleurs pas forcément
  • Une tension s'installe puisqu'aucun des deux pôles ne comprend correctement les contraintes et les objectifs du "camp" opposé, et un sentiment de frustration se développe des deux côtés
  • Le "non" devient une solution de facilité pour sécuriser l'environnement technique, ou les charges sont volontairement grossies
  • Le métier voit en l'équipe technique des « Dr. No » et insiste de plus en plus, puis court-circuite les procédures (externalisation, etc)

Il est essentiel de communiquer régulièrement avec le métier pour éviter toute incompréhension, et d'établir là aussi une relation de confiance. Non, une landing-page avec A/B Testing propulsée par un emailing responsive ne peut pas être mise en place en une journée. Non, on ne vous demande pas non plus de faire atterrir une fusée sur une plateforme dans l'océan.

Les responsables sont multiples :

  • Le responsable Technique
  • Le responsable Métier/Produit
  • La hiérarchie : Manager, Directeur de Produit, CEO, Président, Directeur Général, ...

Par ailleurs, faites en sorte que le "non" ne soit pas pris comme quelque chose de personnel. Ne partez pas non plus du principe que dire "non" soit une mauvaise chose, et transformez-le plutôt en "pourquoi ?". Cette étape permettra de préciser le besoin, de juger de son rapport efforts/intérêt, et parfois votre "non" bien préparé se transformera en "oui, je comprends", en une conciliation, ou en l'annulation de la demande trop complexe à mettre en oeuvre.

Il n'y a aucun problème à dire "non" du moment qu'il est précédé par un raisonnement et suivi par des explications.


16 – Pensez à l'avenir

 
Votre mission consiste en priorité à faire en sorte que les tâches du présent se déroulent correctement. Lorsque vous aurez suffisamment stabilisé votre environnement, pris confiance techniquement, et que les projets avanceront comme souhaité, le moment sera venu de ne pas vous reposer sur vos lauriers.

Suite à la construction et à la stabilisation, viendra alors le temps de l'amélioration. Le développement informatique est un secteur qui évolue extrêmement vite, et en particulier tout ce qui touche à votre métier et à votre équipe :

  • Les besoins métier évoluent
  • Les technologies back-end deviennent front-end
  • Les technologies front-end deviennent back-end
  • Les besoins en performance sont toujours plus importants
  • Les métiers du développement évoluent et se complexifient
  • Les formations – et donc les futures générations – évoluent

Autrement dit : l'organisation que vous avez difficilement mis en place à la sueur de votre front sera complètement obsolète dans 3 ans. Les candidats ne vous prendront pas au sérieux en voyant vos process, et les membres de votre équipe iront s'épanouir personnellement chez plus novateur.

Il est donc nécessaire d'avoir en permanence à l'esprit les "next steps". Prévoyez ce que vous voudrez faire dans 1 mois, 6 mois, ou même 1 an (ce qui paraît bien loin dans notre domaine). Documentez-vous, regardez ce que font vos concurrents, et n'hésitez pas à être l'inventeur des prochaines technologies et façons de travailler à la mode.


17 – Sachez comment et jusqu'où progresser

 
Votre organisation n'est pas parfaite : il y a des petits grincements, parfois des petits couacs. C'est normal, la perfection n'existe pas vraiment.

Il est important que vous sachiez identifier vos axes d'amélioration. Notez les, encadrez-les, gardez-les sous les yeux tous les jours. On ne vous demande pas de rendre une copie parfaite immédiatement, on vous demande de construire quelque chose. D'ailleurs avec l'évolution constante de nos métiers et des technologies, votre organisation ne sera jamais parfaite. Ou jamais pour tout le monde.

L'identification de vos axes d'amélioration représente la partie la plus complexe du travail. Une fois vos problèmes détectés, définissez des objectifs réalistes, des priorités et une feuille de route. Établissez un planning, donnez-vous du temps pour vous améliorer et n'oubliez pas que vous n'êtes pas tout seul dans votre mission.

Les membres de votre équipe veulent aussi s'améliorer dans leurs domaines de compétences, ça fait partie de leur développement personnel. Vous êtes responsable de leur développement, de leur séniorisation, et devez donc faire tout votre possible pour qu'ils évoluent professionnellement et même personnellement. Pour vous c'est très bénéfique car dans de nombreux cas, former un employé sur une technologie précise coûte moins cher que de recruter un expert.

La formation n'est d'ailleurs pas forcément coûteuse :

  • Accès à des formations en ligne
  • Accès à des formations professionnelles et diplomantes
  • Accès à des conférences techniques
  • Temps libre pour auto-formation

On apprend énormément par des retours d'expérience : une journée de conférences vous coûtera quelques dizaines de CHF/€ par employé, augmentera l'esprit d'équipe (team-building à moindre coût) et formera les membres de votre équipe sur ce qui se fait de mieux dans votre domaine, que ce soit techniquement ou au niveau des méthodes de travail. Bénéfice inestimable.


18 – Jaugez votre techno-dépendance

 
La techno-dépendance peut être définie par deux aspects :

  • La dépendance à une technologie de travail : la technologie utilisée par votre équipe pour produire les projets
  • La dépendance à son environnement technologique : outils, qui peuvent être internalisés ou externalisés

Concernant la technologie de travail, je vais préciser la techno-dépendance avec deux exemples types :

  • Une agence décide de n'investir que dans le recrutement de développeurs ActionScript pour faire du Flash et d'orienter toute sa communication et sa force de vente sur la grandeur de cette technologie
  • Un annonceur décide de construire son environnement technique complet avec le framework personnel d'un des employés de l'équipe

Soyez orienté, mais ne devenez pas dépendant de vos technologies. Je vois passer très régulièrement des sociétés avec des problématiques de ce type : elles ne sont plus capables de faire évoluer leur produit, ne sont pas ou plus en mesure de trouver des développeurs libres sur le marché et capables de les aider, et une refonte complète est hors de leurs moyens.

Concernant l'environnement technologique, on a pour habitude de dire qu'il faut externalise tout ce qui ne fait pas partie de notre métier.

Je ne suis qu'à moitié d'accord avec ce point de vue : tout ce qui est réellement extérieur à votre métier (comptabilité, feuilles de paie, protection juridique, etc) devrait en effet être externalisé, mais d'autres sujets courants sont plus difficiles à jauger dans un environnement technique car il dépend de votre culture, de votre environnement, de vos contraintes, et enfin de vos moyens.

  • Vous pouvez ne pas souhaiter que vos données critiques soient hébergées sur un service tiers (dont vous devenez à 100% dépendant)
  • Parfois, la protection des données ou le respect des lois peut vous contraindre à un choix géograhique d'hébergement des données. Exemple : utilisation de Piwik et pas de Google Analytics
  • Pourquoi développer un système de discussion instantanée chiffré en interne basé sur Jabber alors qu'un Slack sera toujours meilleur, et gratuit ?
  • Que se passera-t-il si la brique technique principe de votre application est un service externe qui change sa tarification précipitamment ou ferme ses portes ?

L'important est de savoir estimer le besoin dans votre contexte :

  • Qu'est-ce que ça nous coûterait de le faire en interne ?
    Exemple : maintenir un Gitlab avec backups sur notre infrastructure
  • Qu'est-ce que ça nous coûterait de l'externaliser ?
    Exemple : utiliser Github avec un plan payant pour des repositories privés
  • Quelles sont nos forces ?
    Exemple : ressources en interne disponibles pour gérer les serveurs, infrastructure déjà en place
  • Quelles sont nos contraintes juridiques, de sécurité, politiques ?
    Exemple : confidentialité ou sécurité des données
  • Quelle sera ma marge de manoeuvre si je change d'avis ?
    Exemple : sera-t-il possible de migrer mes données facilement ?

Faites le choix qui vous semble le plus raisonnable à l'instant T en pensant à l'avenir et aux possibles évolutions de votre projet et société, ainsi qu'en remettant régulièrement en question la confiance que vous accordez à vos services externes. Le plus important est de rester concentré sur votre métier.


19 – Partagez votre passion

 
Vous êtes un passionné. Depuis des années, parfois depuis votre enfance ou adolescence, vous baignez quotidiennement dans l'informatique, voir même (à une toute autre mesure) dans le métier que vous exercez aujourd'hui.

Mon conseil ne vaut pas que pour les responsables techniques, il vaut pour tout le monde : si vous avez une passion, partagez-la. Montrez au monde ce que vous aimez et êtes capable de faire, et ne doutez pas du fait que vous pourrez inspirer, voir passionner quelqu'un via votre démarche.

En tant qu'expert dans votre domaine, c'est pratiquement un devoir civique de partager votre passion et votre savoir faire, que ce soit auprès des membres de votre équipe ou extérieurement via des participations (actives) à des conférences, via la rédaction d'articles de blogs, l'écriture de livres, etc. Vous êtes le porte-drapeau technique de votre société, et vous devez en être fier. Il y aura toujours quelqu'un de plus fort que vous, et ce n'est un problème : vous serez aussi toujours l'exemple de quelqu'un, et ça a une valeur inestimable.

Comme dirait Holstee dans son manifesto (encadré sur mon bureau) : « Life is short. Live your dream and share your passion ».


20 – Soyez fantastique... et éthique

 
Comme vous l'avez lu plus haut, soyez un leader, un vrai. Quelqu'un de passionné, quelqu'un qui montre l'exemple, quelqu'un de fantastique.

Vous avez dans les mains un pouvoir de décision ou d'influence que vous devez mettre au profit de ce dont vous faites partie : votre équipe, votre projet, votre société, et même le monde en général. Soyez éthique : demandez-vous chaque jour si ce que vous faites est juste et apporte quelque chose à quelqu'un qui le mérite, ou à la société. Préférez travailler pour des causes qui vous importent et qui vous touchent, cela vous rendra plus résistant aux problèmes, plus performant et fier de vous.

N'oubliez pas qu'en faisant partie d'une organisation, vous partagez et acceptez tacitement les valeurs et les méthodes de celle-ci, vous les représentez. Si vous ne partagez pas les valeurs de votre employeur ou avez la sensation que votre quotidien professionnel ne vous apporte rien, quittez votre travail.


comments powered by Disqus