Devenir CTO (Directeur technique)

Il y a quelques semaines, j’ai lu ce billet sur lequel je suis tombé, depuis touiteur. Et vu que je le trouve très pertinent, et que le texte n’est disponible qu’en anglais, je me suis dis que ça pouvait être cool de proposer une traduction.

Voici donc.


Si vous vous êtes déjà retrouvé à écrire un billet de blog qui explique pourquoi PHP c’est naze, alors vous n’êtes pas prêt.

Devenir Directeur Technique (CTO) ne ne veut pas dire que vous êtes le meilleur hacker de l’équipe. Aujourd’hui, écrire du code est probablement la dernière chose que vous seriez en train de faire. Vous êtes plutôt une personne qui est capable de communiquer la technologie aux autres, les guide dans l’exécution du projet. C’est en quelque sorte quelqu’un qui protège les autres des interférences extérieures, et quand c’est nécessaire, prend la responsabilité des erreurs.

C’est facile de devenir Directeur Technique accidentellement, en étant recruté par une petite société qui n’a aucun autre développeur, comme vous pouvez le voir dans beaucoup de startup. Mais bien que le titre dise Directeur Technique, c’est probablement un acronyme un peu chic pour dire : Développeur Surchargé de Travail.

Je déteste les environnements dans lesquels l’équipe technique ne fait qu’implémenter ce qui a été envisagé par les autres. Ca pourrait aussi bien être une équipe en outsourcing puisqu’ils sont complètement séparés du processus de décision. Comme l’écrit Camille Fournier dans ‘On the role of CTO’, “Le directeur technique doit protéger l’équipe IT de devenir un outil d’execution des idées, sans tendre à ses propres besoins et ses propres idées”.

Si une société a besoin d’un directeur technique, alors cette personne définie la vision de l’impact à long terme sur la technologie. De plus en plus d’entreprises aujourd’hui n’utilisent pas la technologie, mais sont définit par elle. Tout est construit avec la technologie, du commerce de détails, à l’application mobile, et tous y tirent un grand bénéfice quand quelqu’un ce qu’il faut pour que la technologie fasse encore mieux. C’est le combat qu’un Directeur Technique ne peut ignorer. L’équipe technique doit pouvoir se positionner en maître d’oeuvre.

Je suis déjà allé dans quelques réunions avec d’autre Directeurs Techniques, et la majorité des discussions portent sur les manières de faire en sorte le reste de l’entreprise respecte les processus de développement. Par exemple, vendre et faire accepter le test unitaire. Non, non non ! Pour ma part, je ne vais pas essayer de vous vendre quoique ce soit. Je vais dire : Voici la direction dans laquelle nous allons, et voilà comment on va faire. En bref, le quand le CTO donne une direction, ça doit se passer comme ça. Si un directeur technique n’a pas ce petit pouvoir pour les décisions techniques, alors il n’est pas CTO, mais plus ingénieur en chef dans un costume.  Le costume étant optionnel.

Le CTO est un emploi stratégique dans l’entreprise , qui définit l’orientation technique à l’intérieure de l’entreprise. Ce n’est pas le bon job si vous détestez les meetings, si vous détestez traiter avec ceux qui ne sont pas techniques, et pensez que les manager sont assis toute la journée, et ne font rien. Chaque meeting est une discussion sur l’orientation que l’entreprise va prendre, et comment la technologie peut aider, ou parfois, comment la technologie peut créer de nouvelles opportunités pour grossir.  Tout ceci doit être expliqué simplement, pour être compréhensible par tout le monde.

Donc, il est essentiel de comprendre les besoins de l’entreprise et des clients. D’après mon expérience, beaucoup de gens techniques aiment se mettre à l’écart de tout ce qui touche au business. Pourtant, c’est la première chose à savoir en tant que CTO. Aucune décision technique ne devrait se prendre dans une préoccupation  purement logicielle ou matérielles. La plupart du temps, le CTO devrait être en phase avec les gestionnaires de produits de sorte que la stratégie du produit soit compatible avec les opérations de développement.

En fin de compte, le CTO créé un environnement qui permet à l’équipe de réaliser de grandes choses. Aujourd’hui, une grande partie du problème est l’embauche. Tout le monde est à la recherche de développeurs, mais ils sont peu nombreux, donc l’environnement doit être aussi accueillant que possible. C’est quelque chose que le CTO devrait savoir faire, car il a été une fois l’un d’eux. Si l’équipe veut faire du TDD, ou coder en binôme, ou s’occuper des serveurs – ça doit être accepter par le CTO. C’est aux CTO de considérer le plus grand impact de ces changements.

Réfléchir sur l’impact financier des opérations technologiques est important. Une startup peut se permettre de se jeter sur toutes les dernières technos, mais une plus grande entreprise ne peut pas se le permettre. Tout doit être pesé sur une base de retour sur investissement, en demandant combien de valeur il faut livrer au client. Donc, dans la plupart des cas, il faut équilibrer l’évolution et les mises à jour des infrastructures existantes, tout en ne tombant pas dans une réécriture trop lourde du code. Trouver ce qui donne 80% de rendement avec seulement 20% du d’investissement, selon la règle des 80-20, y contribue en grande partie.

J’ai fait des entretiens avec des futurs CTO qui disaient, «Pourquoi êtes-vous coincé avec cette vielle version, pourquoi ne pas passez à React.js? » Désolé de vous faire redescendre, mais ce n’est pas une bonne idée. Parfois, des applications deviennent coûteuses à gérer, mais les réécrire offrent presque toujours une valeur nulle au client. Il faut équilibrer les efforts de développement. Construire une équipe de personnes qui veulent seulement utiliser les technologies qui viennent de sortir n’est pas durable.

Il construit un écosystème  pour mettre en œuvre les choses que vous trouvez les plus importantes. Par exemple, je pense que la fiabilité et la sécurité sont les deux des caractéristiques les plus importantes de toute application. Ainsi, tout changement dans les objectifs de l’entreprise sont pesés en tenant compte de ces 2 aspects. La confidentialité aussi importante, mais c’est un sujet qui est encore difficile à appréhender pour les personnes non-techniques. Pourtant, elle limite parfois ce qu’une entreprise peut faire, tout simplement parce que les choses pourraient tomber en dehors du respect de la vie privée. Une partie de mon travail consiste à appréhender ces aspects et à s’assurer que l’équipe l’execute correctement.

Alors que je ne fais que la technologie. Je pense que la technologie devrait être invisible pour l’utilisateur. Alors, quand on débat sur le fait que oui ou non PHP est naze, je pense que c’est une question qui n’est pas pertinente. C’est une question stimulante pour certains, mais pour une entreprise, ça ne devrait pas compter. J’aime à croire que c’est une rampe de lancement pour devenir CTO – ne pas se soucier de ce genre de choses, ne pas se focaliser sur les détails techniques, mais plutôt sur la recherche de l’équipe, etc.

Devenir un CTO c’est avoir une vision d’ensemble de l’impact technologique, qui définit l’entreprise et la façon dont d’aider le client. Ca aide à être génial, et à comprendre la technologie, mais c’est beaucoup plus que ça.

Recherches utilisées pour trouver cet article :devenir cto, cto devenir
metrogeek

Laisser un commentaire