VP Engineering et CTO : qui fait quoi

La guerre entre un CTO et un VP Engineering ne naît presque jamais d'un conflit de personnes. Elle naît d'une décision que les deux croient posséder. Les fiches de poste disent « vision technique » pour l'un et « excellence de la livraison » pour l'autre, et ces formules ne tranchent rien le jour où une refonte d'architecture décale de deux mois une fonctionnalité promise à un client. Ce jour-là, il faut savoir qui décide, et l'avoir écrit avant.

Le partage qui fonctionne ne se fait pas par domaines. Il se fait par décisions.

Le système, et l'organisation qui le produit

Tant que l'équipe est petite, une seule personne fait tout : elle choisit l'architecture, recrute, organise, livre, parle aux investisseurs. Le dédoublement apparaît quand cette charge ne tient plus dans une semaine, et il coupe le rôle selon une ligne assez stable.

Le CTO répond du quoi technique et de l'horizon long. Quelle architecture dans deux ans, quels paris technologiques, ce qu'on construit et ce qu'on achète. Il porte la parole technique vers l'extérieur : clients importants, audit d'un investisseur, conseil d'administration. Son unité de temps est l'année.

Le VP Engineering répond du comment et du qui. Qui on recrute, comment les équipes sont découpées, comment le travail passe d'une idée à la production, comment les gens progressent, ce qui est livré ce trimestre. Son unité de temps est le trimestre.

L'un travaille surtout sur le système, l'autre surtout sur l'organisation qui le produit. Aucun des deux postes n'est une version junior de l'autre, et la question « lequel rapporte à l'autre » est la première sur laquelle on se trompe.

Les décisions à deux propriétaires

Le partage ci-dessus paraît net. Il cesse de l'être dès qu'une décision touche à la fois le système et l'organisation, c'est-à-dire souvent.