Donner des repères. Pas des leçons.

Article basé sur le livre “Être ou ne pas être CTO”, chapitre “Le rôle de CTO démystifié”. Situation réelle “Je veux devenir CTO.” Cette ambition est légitime, mais elle masque souvent une confusion sur ce que représente réellement ce rôle. Dans la pratique, j’observe que beaucoup confondent CTO, Lead Developer et VP Engineering, trois rôles aux responsabilités et aux enjeux distincts. Cette confusion crée des attentes décalées : des développeurs qui visent le titre CTO sans comprendre qu’ils devront coder moins, des organisations qui nomment CTO quelqu’un qui devrait être VP Engineering, des carrières qui s’orientent vers un rôle qui ne correspond pas à leurs aspirations réelles. ...

Inspiré du livre “En quête d’expérience”, chapitre “Pivoter intelligent”. Dédramatisation “J’ai 8 ans en Java, je veux passer à Rust. Je recommence junior ?” Non. Vous ne repartez pas de zéro. Vos années d’expérience en développement vous donnent des compétences transférables : logique de programmation, architecture, debugging, collaboration en équipe. Ces compétences sont précieuses, même si la technologie change. Ce que j’ai observé : les transitions de carrière sont possibles à tout âge. Beaucoup de développeurs ont changé de domaine ou de technologie sans repartir de zéro. La clé n’est pas de tout réapprendre, mais d’identifier ce qui est transférable et ce qui doit être appris. ...

Situation réelle Premier jour de stage ou premier job. Terminal noir, code incompréhensible, acronymes partout, impression que tout le monde sait sauf toi. Cette sensation est universelle et trompeuse. Ce que j’ai observé : tous les développeurs seniors ont traversé cette phase. La différence n’est pas le talent, c’est le temps et l’exposition répétée. Le faux problème Le faux problème serait de croire que tu dois tout comprendre immédiatement. En réalité, personne ne comprend tout. Les seniors ont juste appris à naviguer l’inconnu avec moins de panique. ...

Situation réelle “On veut une culture d’excellence technique.” Cette ambition est louable, mais vague. Qu’est-ce que ça signifie concrètement ? Comment on la construit ? Et surtout, comment on la maintient quand l’équipe grandit ? Ce que j’ai observé : la culture technique ne se décrète pas dans un manifeste. Elle se construit jour après jour, par des choix concrets qui s’accumulent. Une culture forte survit au changement d’équipe et au turnover. ...

Situation réelle “Qui décide si on migre vers Kubernetes ?” “Qui valide le choix de cette librairie ?” “Est-ce que je peux changer cette architecture sans demander ?” Ces questions révèlent un flou sur qui décide quoi. Ce que j’ai observé : sans cadre clair de décision, soit tout remonte au CTO (bottleneck), soit tout le monde décide en silo (incohérence). Le bon équilibre est un cadre explicite qui donne de l’autonomie sans créer le chaos. ...

Situation réelle “En tant que CTO, tu décides de la stack, non ?” Cette question revient régulièrement. Elle traduit une vision simplifiée du rôle : le CTO comme celui qui tranche, qui impose, qui décide de la direction technique. Ce que j’ai observé après 17 ans dans ce métier : le poids du rôle de CTO ne réside pas principalement dans les décisions qu’on prend, mais dans ce qu’on porte pour l’équipe et l’organisation. Une responsabilité invisible qui se manifeste dans les non-dits, les arbitrages silencieux, les angles morts qu’on surveille. ...