Construire sa Première Équipe d'Ingénierie : De 3 à 15
Avec trois ingénieurs, tout est simple. Tout le monde connaît toute la base de code. Les décisions se prennent dans un fil Slack. Il n'y a pas de processus parce qu'il n'en faut pas. L'architecture est ce que l'ingénieur fondateur a décidé un mardi soir, et c'est bien parce qu'il est encore là pour l'expliquer.
À quinze, rien de tout cela ne fonctionne. La connaissance est cloisonnée. Des décisions sont prises dans des réunions que la moitié de l'équipe ne sait pas avoir eu lieu. Et si vous n'avez pas construit de structure en chemin, vous vous noyez dans la dette organisationnelle.
La différence entre les équipes qui scalent bien et celles qui implodent n'est presque jamais le talent. C'est le séquençage : recruter les bons rôles dans le bon ordre et introduire la structure aux bons moments.
L'Étape 3-5 : Des Généralistes qui Livrent
Vos premières recrues doivent être des généralistes solides — des ingénieurs capables d'écrire du code backend le matin, de déboguer du CSS après le déjeuner et de configurer un pipeline CI avant la fin de la journée. Ils n'ont pas besoin d'expertise de domaine. Ils ont besoin de compétences dans de nombreux domaines et d'une aisance avec l'ambiguïté.
Recrutez : des ingénieurs full-stack senior ou mid-level solides qui ont livré des produits, pas seulement des fonctionnalités. Des personnes qui trouvent des solutions plutôt que d'attendre qu'on leur assigne des tâches.
Ne recrutez pas : des spécialistes. Vous n'avez pas besoin d'un ingénieur DevOps dédié, d'un spécialiste mobile pour un produit web-first, ou d'un ingénieur data quand vous avez 200 utilisateurs. Chaque spécialiste précoce est de la capacité bloquée dans un domaine qui n'est peut-être pas votre goulot d'étranglement.
Erreur courante : recruter trop junior. Le CTO pense qu'il peut mentorer deux juniors pour moins d'argent. En pratique, vous passez 60% de votre temps à revoir du code et à les débloquer — du temps que vous devriez consacrer aux décisions produit et à livrer. À ce stade, chaque ingénieur doit être un contributeur net dès la deuxième semaine.
L'Étape 5-8 : Première Structure
La base de code grandit. Les fonctionnalités touchent plusieurs services. Les revues de code prennent plus de temps. Les conflits de déploiement commencent. C'est le moment d'introduire des processus légers :
- Des cycles de planification courts. Hebdomadaires ou bimensuels. Qu'est-ce qu'on construit ? Qui fait quoi ?
- La propriété du code. Pas rigide, mais quelqu'un doit être la référence pour chaque zone principale.
- Une vraie stratégie de branches. Tout le monde suit le même flux. Plus de push direct sur main.
Le recrutement à faire en 5-6 : Un ingénieur de niveau staff qui peut être propriétaire de l'architecture technique. Pas un manager — l'ingénieur qui s'assure que le système tient. Il revoit les PRs critiques, définit les patterns et repousse quand quelqu'un propose d'ajouter une nouvelle base de données « parce que ce serait plus facile ».
Ce qu'il ne faut pas recruter : un VP Engineering. Je vois ça constamment. Le CEO recrute quelqu'un dont le dernier rôle était de gérer 50 ingénieurs. Cette personne arrive, trouve 6 ingénieurs qui n'ont pas besoin de management, et introduit des processus conçus pour une équipe dix fois plus grande. Les standups deviennent des réunions de statut de 30 minutes. Les ingénieurs qui aimaient le rythme startup commencent à mettre leur LinkedIn à jour.
À 6 personnes, vous avez besoin d'un leader technique qui code 60-80% du temps, pas d'un manager de personnes.
L'Étape 8-12 : Les Communications Cassent
À 7 personnes, tout le monde reste aligné grâce à une conscience ambiante. À 9, ça se casse. L'Ingénieur A ne sait pas que l'Ingénieur B a déjà résolu le problème sur lequel il travaille. Deux personnes construisent des fonctionnalités qui se chevauchent sans s'en rendre compte.
C'est le moment de vous diviser en squads. Deux ou trois équipes, chacune propriétaire d'un domaine. Pas des microservices — la propriété de domaine. Chaque squad a besoin d'une mission claire liée à un résultat business, d'un lead technique, d'assez d'autonomie pour planifier son travail, et de standards partagés pour que la base de code ne diverge pas.
Le recrutement à faire en 8-10 : Votre premier engineering manager. Un bon premier EM a été ingénieur, comprend le travail technique et se soucie genuinement de la croissance des personnes. Il gère les 1:1s, les conversations de carrière, la coordination du recrutement et l'alignement inter-équipes.
Erreur courante : promouvoir votre meilleur ingénieur au management. Souvent vous perdez un excellent ingénieur et gagnez un manager médiocre. Les compétences sont différentes. Demandez à la personne si elle veut vraiment manager avant de supposer que la promotion est une récompense.
L'Étape 12-15 : Organisation Réelle
Les fonctionnalités nécessitent maintenant du travail de plusieurs squads. Le rôle du CTO a fondamentalement changé — moins de code, plus de revue d'architecture, de recrutement et de design organisationnel.
- Les revues d'architecture deviennent formelles. Les changements transversaux sont discutés dans des ADRs avant implémentation.
- Le recrutement devient continu. Vous interviewez toujours, sourcez toujours.
- La réponse aux incidents nécessite une structure. Propriété claire de ce qui casse et une rotation qui n'épuise pas les gens.
Le recrutement à faire en 12-15 : Un Head of Engineering qui peut être propriétaire de la structure organisationnelle et du développement des personnes pendant que le CTO se concentre sur la stratégie technique. C'est le rôle que le recrutement prématuré de VP à 6 personnes aurait gaspillé. À 15, il y a assez de complexité pour le justifier.
Les Erreurs qui Vous Coûtent des Mois
Recruter trop vite. Doubler l'équipe en un trimestre signifie que la moitié de vos ingénieurs a moins de trois mois de contexte. Les personnes senior passent tout leur temps à onboarder au lieu de construire.
Ne pas recruter assez senior. Si tout le monde est mid-level, personne ne fixe les standards et la base de code dérive. Vous avez besoin d'ancres senior dans chaque squad.
Ignorer la culture. La culture n'est pas les poufs. C'est comment vous prenez des décisions, gérez les désaccords et donnez du feedback. À 15 personnes, si vous n'avez pas été intentionnel, vous avez 15 hypothèses différentes sur comment les choses fonctionnent.
Copier les processus des grandes entreprises. Le modèle de squads de Spotify et les pratiques SRE de Google ont été conçus pour des organisations d'ordres de grandeur plus grandes. Picorez des idées, ne copiez pas les frameworks. Votre processus devrait être le minimum nécessaire pour vous coordonner efficacement.
La vérité inconfortable pour les cofondateurs techniques : le travail à 3 personnes n'est pas le travail à 15. Si vous écrivez encore le plus de code à 15 ingénieurs, vous êtes le goulot d'étranglement.
Chez Conectia, nous aidons les CTOs à naviguer cette transition. Quand vous devez scaler de 5 à 12 ingénieurs sans sacrifier la séniorité ou l'adéquation culturelle, nos ingénieurs LATAM validés par des CTOs s'intègrent dans vos squads comme membres à part entière. Ils contribuent dès le premier sprint, ce qui signifie que vous scalez la capacité, pas juste les effectifs.
Vous scalez votre équipe et avez besoin d'ingénieurs senior qui s'intègrent dès le premier jour ? Parlez à un CTO — nous vous aidons à trouver les bons ingénieurs pour exactement l'étape où vous en êtes.
