Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante. Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Pierre Hamelot, Pierre bonjour.
Bonjour. Est-ce que tu peux te présenter pour ceux qui ne te connaîtraient pas encore en quelques mots ?
Eh ben bonjour à tous et bienvenue. Je m'appelle Pierre Hamelot et je suis entrepreneur depuis
une quinzaine d'années et mon métier au quotidien c'est d'aider des dirigeants et des dirigeants à
structurer leur business, trouver des réponses à leurs questions avec pour faire simple une double
casquette de directeur marketing et technique à t'en partager. Le sujet de l'épisode que
on a évoqué c'est comment devenir TechLid ? Comment est-ce qu'on passe de développeurs à TechLid ?
Quel chemin de carrière ont choisi ? Parce que d'abord est-ce que est-ce que c'est une fatalité
de devenir TechLid ? C'est quoi les options qui s'offrent à nous ? Comment est-ce que tu vois
t'imagines ? Si tu repars toi, si on retrace un développeur en général les premières années
son enjeu ça va être de faire ses armes, ça va être un petit peu de manger du code a priori
si il s'est lancé là dedans c'est pour manger un peu du code, ça va durer quelques années et puis
après il va commencer à relever le nez du guidon, sortir la tête de l'écran, regarder ce qui se
passe autour de lui et là il va dire bon c'est quoi l'étape suivante ? Et là c'est quoi l'étape
Gignore, Medium, Senior et Lid. Pour moi le junior c'est globalement en général c'est 24 mois c'est
les deux premières années, le junior il n'est pas autonome surtout sur un point, c'est à quel moment
je dois demander de l'aide aux gens qui m'entourent. Est-ce que quand on donne quelque chose à faire,
est-ce que je dois dire tout de suite j'ai pas les bonnes données, je peux pas commencer, est-ce que
je dois bloquer pendant un quart d'heure, bloquer pendant deux heures ou bloquer pendant une journée ?
Ne bloquez pas plus d'une demi-journée ou d'une journée, solliciter un senior autour de vous,
c'est vraiment ça le sujet. Pour moi le Medium c'est le profil soit qui a de l'expérience sur
une techno mais qui change de boîte et qui doit se réapproprier un environnement technique des
collègues, une documentation, une un legacy et le senior c'est celui qui non seulement a de l'expérience
mais qui en plus et ont capacité de en fait de maîtriser parfaitement la stack, l'entreprise,
l'enjeu client et après il y a le lead et le lead c'est vraiment l'étape suivante, c'est le senior
qui accepte de partager avec les autres, c'est le senior qui va faire de la veille et qui va emmener
les autres vers le haut, c'est le senior qui va être la personne qu'on va suivre dans l'équipe
parce qu'il peut avoir un senior qui va travailler dans l'équipe, collaborer avec ses collègues
mais qui en gros globalement va se concentrer 95% de son temps sur la conception, sur son
dev et faire avancer l'équipe et t'as le lead qui lui va potentiellement passer une partie de son
temps conséquent 30, 40, 50% des fois plus à accompagner les autres et les faire grandir,
donc faire beaucoup moins de dev et beaucoup moins de conception. Plus sur la partie comment j'accompagne
et je fais grandir l'équipe, comment je m'assure que la documentation est propre, tiens on a dit
qu'on faisait du TDD donc du développement de la dev par les tests, qu'est ce qu'on met en place,
quel outillage, comment on passe d'un cycle en V à potentiellement une gestion de projet un peu
plus agile et voilà comment je fais évoluer tout ça et pour moi le lead, il est vraiment la différence
entre le chef et le leader, le leader il tire avec les autres et il montre le chemin.
Concrètement ça veut dire quoi dans le quotidien, comment j'accepte à ce genre de poste en tant
que dev, donc déjà ça sous-entend de passer par les étapes de seniorité ?
Pour moi c'est déjà avoir un minimum de seniorité d'être en capacité de comprendre comment
l'entreprise fonctionne, la stack de techno, l'ensemble des éléments et pour moi après c'est une
posture, c'est j'accepte de passer 30% de mon temps à aider un junior ou un stagiaire ou un
alternant à être onboardé dans l'équipe et je vais répondre à ces questions et je vais pas souffler
à chaque fois qu'ils m'avent arrêté, je vais accepter d'être un peu moins productif, je vais
accepter de peut-être faire un peu moins de code et d'analyse et plus de temps avec d'autres humains.
Moi j'ai croisé tous types de dev et j'en ai croisé beaucoup les 15 dernières années,
je travaillais plusieurs milliers de dev différents dans plein d'équipes et d'entreprises
différentes, j'ai certains développeurs qui en fait aiment bien être dans leurs coins et n'ont pas
spécialement envie d'échanger avec d'autres et j'en ai d'autres qui sont un peu plus sociables si
je me permets de ce mot là et qui vont accepter de passer énormément de temps, donc pour moi c'est
une posture, alors on peut être médium et lead, je peux arriver dans une boîte en ayant un peu
d'expérience sur une techno et par contre ne pas maîtriser tout l'enjeu de la stack techno
dans laquelle j'arrive, c'est normal, le temps de prendre en main les outils, la doc, le legacy et en
même temps par exemple accompagner un alternant ou un junior à grandir aussi dans cette équipe,
c'est possible, donc on peut être lead avec un profil médium ou senior et c'est une posture pour moi.
Et c'est quoi les compétences que tu as besoin de développer pour être crédible dedans ?
Pour moi, elles sont majoritairement, c'est de la curiosité et après c'est des compétences
interpersonnelles, c'est des compétences humaines, c'est l'envie des dessous prochains,
accepter un peu de pédagogie, de répondre aux défis parce que quand quelqu'un vient me voir en me
disant Pierre, j'arrive pas à faire ça, il va falloir que je me creuse la tête pour comment
moi je le ferai, avoir de l'empathie et la notion de lead après, elle est soit sur un tech lead,
donc un développeur qui a aussi le rôle de lead et elle peut être aussi sur un rôle de direction
technique dans les petites équipes, dans les équipes de jusqu'à 10 personnes, il y a encore la
possibilité que la direction technique, qui est une personne qui n'est pas forcément les mains dans le
code au quotidien, je sais qu'il y a beaucoup de types de directions techniques différentes,
mais il faut savoir que la majorité des directions techniques, la majorité des DSI sur le marché,
ne mettent pas les mains dans le cambouille, ne mettent pas les mains dans le code au quotidien
tout simplement parce qu'il gère de l'humain, il gère des enjeux politiques en interne,
des enjeux de roadmap produit, etc. Le choix de techno par exemple. Donc un CTO peut être aussi lead.
Tu m'avais dit, ce qui m'intéresse aussi, tu m'avais dit que pour toi il n'y avait pas de barrière,
quand on discutait pour préparer cet épisode, je me disais pour moi des roles de CTO ou des
roles de leader, c'était essentiellement des roles traditionnellement plutôt réservés à des
employés, c'est à l'impression qu'on fait appel peu à des freelance pour ça, et tu allais plus
d'eau à l'encontre de ça en disant bah non, en fait il y a de tout qui existe et du coup je trouve
ça vachement intéressant. Comment est-ce que tu exprimes ça ? Comment ça s'exprime ? C'est
quoi les différences entre le fait d'être salarié ou pas salarié ou être freelance,
que tu sois ta clé ou directeur technique ? Est-ce que tu fais des différences d'ailleurs entre
le rôle des statuts ? Pour moi il y a un statut administratif d'un côté qui n'est qu'un
statut administratif et après il y a un sujet d'implication en long terme. Forcément si je
monte une équipe technique et que je vais recruter 10-15 personnes, voire plus, et que j'ai besoin
d'un quelqu'un à temps plein pour les accompagner, les manager, les faire grandir, structurer la
techno, je vais plutôt avoir tendance à recruter quelqu'un à long terme et cette personne à long
terme ça peut être un deal associé, associé salarié, ça peut être un deal indépendant. Même
si majoritairement je suis d'accord avec toi que la personne, elle risque d'avoir un contrat
de travail en étant associé ou non et de travailler plutôt sur un projet à 4-5ème ou à
5-5ème, donc 80% ou 100% du temps. En freelance, qu'est-ce qu'on va demander ? On va demander du
renfort, on va demander un remplacement d'un CTO qui est dans le commun ou qui a la jambe cassée
parce qu'il s'est cassé la jambe pendant ses vacances ou en râtant une marche et qu'il
n'est pas opérationnel maintenant et qu'on a besoin de tenir une équipe. Moi j'ai déjà eu le cas
dans une boîte avec 70 tech et du jour au lendemain on n'a plus de CTO parce qu'il est dans le
commun. Là il y a un moment. Oui, des CTO transition. Exactement. Et après ça peut être une
expertise, ça peut être on fait du on-premise et on veut passer sur du cloud et on a besoin
de quelqu'un qui nous accompagne à faire évoluer notre stack. On travaille sur du cyclan V et on
veut faire plutôt de l'agilité et mettre en place du scrum. Alors là tu vas me dire on peut faire
appeler un scrum master. Oui mais bien souvent on fait appel à un binôme. Oui non mais là c'est
plus un job de conseil. Il y a du conseil et de l'accompagnement parce que ça peut être aussi
le rôle de CTO à t'en partager. Bien souvent on me dit mais Pierre les autres CTO te voient
comme un concurrent et moi je leur dis maintenant en fait je suis juste un binôme parce que bien
souvent le CTO il y a des choses qui ne peuvent pas en parler à ses équipes parce que il y a des fois
des sujets un peu sensibles sur une réduction d'effectifs, sur un licenciement économique
qui va arriver. Comment tu gères un licenciement économique quand t'es CTO ? Ça c'est un vrai
sujet. Moi j'ai déjà accompagné des CTO sur ces sujets là et puis j'ai autre chose c'est que mes
autres associés comprennent pas la tech donc ils comprennent pas les implications et donc ils ont
besoin d'un père avec qui discuter en toute confidentialité et en même temps de pouvoir
être accompagné sur certains sujets. Ça peut être aussi un CTO qui a vu son équipe grandir et
qu'il n'arrivent maîtrise plus. J'ai connu des CTO qui sont très bons à 8-10 tech. Par contre
la boîte a grandi on a levé des fonds où on a des nouveaux clients et là on a 40 tech et en fait
je m'en sors plus et j'ai besoin d'aide. Et à ce moment là on va peut-être pas accompagner
l'équipe mais le CTO et on n'est plus sur du conseil on est sur du mentorat et de l'accompagnement.
Et après sur le côté lead, moi il m'est déjà arrivé de voir des lead tech freelance qu'on va
payer 2, 3, 5 jours par mois et qui vont amener un cadre pour faire de la veille,
qui vont amener les bons outils, les bonnes sources, si je parle juste de la veille par exemple,
qui vont amener du TDD par exemple. Moi j'ai déjà fait appel à des lead tech pour dire comment
je fais pour passer une base de code de 350 000 lignes avec 0 tests unitaires à une couverture
de code à plus de 80%. Comment je prends ça ? Comment je monte ma factory pour faire mon
intégration et mon déploiement continue alors qu'aujourd'hui en fait j'arrête mon serveur de prod,
j'utilise mon FTP et je fais une mise en prod à la main avec mes fichiers que je copie-colle.
Comment je passe d'un état A à un état B ? Je me fais accompagner par des gens qui ont du recul sur
le sujet en interne avec un contrat classique de salariat ou en externe avec des indépendants.
Écoute Pierre, je te remercie pour tout ça, c'était hyper intéressant et qui donne en tout cas
moi qui ouvre plein de perspectives intéressantes. J'adore péter les croyances limitantes qui sont
par défaut pas visibles jusqu'à ce que tu les confrontes à la réalité. Merci pour tout ça,
je te propose que ce soit le mode de la fin, si les auditeurs veulent en savoir plus sur ce que tu
fais ils peuvent te suivre où. Vous pouvez me trouver directement sur Twitter PierreAnderscoreA
ou m'envoyer un mail PierreArabazHamelot.fr et vous trouverez tout ça sur internet.
Merci beaucoup Pierre et je te souhaite une bonne journée. Merci à bientôt.