Situation réelle

“Tu es senior maintenant, tu veux manager ou rester IC ?” Cette question arrive souvent. Et beaucoup choisissent sans comprendre vraiment ce que chaque voie implique.

Ce que j’ai observé : beaucoup deviennent managers par défaut (“seule évolution visible”) et regrettent. D’autres restent IC sans savoir que c’est une voie légitime avec ses propres niveaux (staff, principal, distinguished).

Le faux problème

Le faux problème serait de croire que management = évolution et IC = stagnation. En réalité, les deux sont des voies d’évolution légitimes avec des trajectoires parallèles.

Un autre faux problème : penser que c’est irréversible. En réalité, tu peux essayer le management et revenir IC (ou l’inverse), même si ce n’est pas sans coût.

Le vrai enjeu

Le vrai enjeu est de comprendre ce que chaque voie implique vraiment :

Les 2 voies d’évolution :

Voie IC (Individual Contributor) : Niveaux : Junior → Mid → Senior → Staff → Principal → Distinguished/Fellow. Focus : impact technique croissant, influence par expertise, ownership systèmes critiques. Responsabilités : architecture, mentoring technique, technical leadership sans autorité formelle. Quotidien : 70-80% technique (code, design, review), 20-30% communication/influence. Évolution salaire : compétitive avec management (staff ~ manager, principal ~ director).

Voie Management : Niveaux : Tech Lead → Engineering Manager → Senior EM → Director → VP → CTO. Focus : impact via l’équipe, performance collective, développement personnes. Responsabilités : hiring, évaluations, one-on-ones, résolution conflits, alignement stratégique. Quotidien : 20-30% technique (review, architecture), 70-80% humain (réunions, coaching, politique). Évolution salaire : compétitive avec IC mais progression différente.

Les 5 différences critiques :

Différence 1 - Source d’impact : IC : impact via code/architecture/expertise directe. “Je résous ce problème technique complexe.” Manager : impact via équipe. “Mon équipe résout ces problèmes parce que je les ai aidés à grandir/débloquer.” Question test : Qu’est-ce qui te satisfait plus ?

Différence 2 - Quotidien : IC : deep work technique majoritaire, meetings ciblés, autonomie sur comment travailler. Manager : meetings 50-70% du temps, interruptions constantes, peu de deep work, disponibilité pour équipe. Question test : Préfères-tu 4h de code sans interruption ou 4h de conversations/coaching ?

Différence 3 - Feedback loop : IC : feedback rapide (code marche ou pas, PR mergée ou pas, système fonctionne). Manager : feedback lent (voir équipe progresser prend mois/années, impact diffus). Question test : As-tu besoin de feedback immédiat ou satisfait par impact long terme ?

Différence 4 - Compétences requises : IC : expertise technique profonde, capacité résoudre problèmes complexes, influence sans autorité. Manager : empathie, communication, gestion conflit, coaching, politique organisationnelle. Question test : Quelle catégorie de compétences t’attire/tu développes naturellement ?

Différence 5 - Stress et responsabilités : IC : stress technique (système down, architecture mauvaise, dette technique). Manager : stress humain (équipe malheureuse, performances, licenciements, politique). Question test : Quel type de stress géres-tu mieux ?

Les 3 mauvaises raisons de devenir manager :

Mauvaise raison 1 - “C’est la seule évolution” : Mythe : IC = plafond après senior. Réalité : track IC existe (staff, principal) avec impact et salaire comparables. Conséquence : devenir manager par défaut → malheur + mauvais manager.

Mauvaise raison 2 - “Plus de salaire” : Mythe : managers gagnent plus. Réalité : à niveaux équivalents (staff ~ manager), salaires comparables. Conséquence : choisir pour argent → job que tu détestes.

Mauvaise raison 3 - “Prestige/pouvoir” : Mythe : manager = pouvoir, respect. Réalité : bon IC staff/principal a autant d’influence, parfois plus (expertise > autorité). Conséquence : management pour mauvaises raisons = toxicité.

Les 3 bonnes raisons de devenir manager :

Bonne raison 1 - “J’aime développer les gens” : Signal : tu mentores déjà, ça t’énergise, tu vois juniors progresser comme satisfaction. Validation : mentoring te donne énergie, pas te vide.

Bonne raison 2 - “Impact via équipe m’attire” : Signal : tu penses “Comment aider équipe mieux performer ?” plus que “Comment optimiser ce code ?” Validation : satisfaction vient de succès collectif, pas juste individuel.

Bonne raison 3 - “Je veux façonner culture/organisation” : Signal : frustré par processus/culture, envie de les améliorer à échelle équipe/org. Validation : énergie pour naviguer politique et améliorer système humain.

Cadre de décision

Voici comment choisir :

1. Auto-évaluation honnête Questions : Qu’est-ce qui m’énergise ? Code ou développement personnes ? Deep work ou interactions ? Feedback immédiat ou long terme ? Ces réponses révèlent fit naturel.

2. Essayer sans engagement total Actions : mentorer intensément 3-6 mois, ou prendre interim tech lead 3 mois. Observer si ça donne énergie ou la draine. Cet essai évite erreur coûteuse.

3. Parler à ICs et managers avancés Pratique : interviewer staff engineer ET engineering manager. Questions : quotidien réel, satisfactions, frustrations. Ces témoignages révèlent réalité.

4. Accepter que choix n’est pas irréversible Réalité : tu peux essayer management et revenir IC (ou inverse). Coût existe (time, learning curve) mais pas prison. Cette flexibilité réduit peur.

5. Évaluer context organisationnel Questions : Track IC existe dans ma boîte ? Staff/Principal possibles ? Progression IC claire ? Si non, choix est biaisé (management seule option visible).

Retour terrain

Ce que j’ai observé chez différents profils :

Le manager malheureux : Senior dev excellent, devient manager car “évolution logique”. 2 ans : malheureux (déteste meetings, politique, évaluations), code lui manque. Retour IC avec soulagement. Message : manager par défaut = recette malheur.

L’IC épanoui : Senior dev refuse management, devient staff engineer. Impact technique massif, mentoring, architecture. Épanoui, salaire équivalent manager. Message : IC track est voie légitime.

Le manager naturel : Senior dev qui mentorait déjà intensément. Devient manager : s’épanouit, aime coaching, naviguer politique pour aider équipe. Message : si mentoring énergise, management peut être bon fit.

L’essai qui éclaire : Mid-level prend interim tech lead 4 mois. Découvre : déteste meetings constantes, miss deep work. Décision : rester IC. Résultat : clarté sans engagement long terme. Message : essayer révèle réalité vs fantasme.

Erreurs fréquentes (et comment les éviter)

Erreur 1 - Choisir par défaut Piège : “Je suis senior, je deviens manager.” Réalité : IC track existe. Correction : évaluer vraiment les deux options.

Erreur 2 - Sous-estimer différence Piège : “Manager c’est juste organiser l’équipe + coder un peu.” Réalité : 70-80% humain, peu de code. Correction : interviewer managers sur quotidien réel.

Erreur 3 - Penser que c’est irréversible Piège : “Si je choisis IC, plus jamais manager.” Réalité : changements possibles, même si coûteux. Correction : essayer sans terreur.

Erreur 4 - Ignorer context organisationnel Piège : choisir IC dans boîte sans track IC. Résultat : plafond de verre. Correction : évaluer si track IC existe et est valorisé.

Message de responsabilité

Ce choix dépend de toi :

  • Tu es responsable d’évaluer honnêtement ce qui t’énergise
  • Tu es responsable d’essayer avant de t’engager totalement
  • Tu es responsable de ne pas choisir par défaut ou prestige
  • Tu es responsable d’accepter que tu peux changer d’avis

Ni IC ni management n’est “mieux”. C’est une question de fit avec qui tu es.

Pour aller plus loin

Le livre "Être ou ne pas être CTO" explore les différentes trajectoires et comment naviguer ces choix.

Tu peux aussi consulter l’article "Devenir senior" ou les autres contenus du pilier "Trouver sa place".