Les 90 premiers jours avec un CTO à temps partagé

Un nouveau responsable technique peut impressionner en annonçant tout ce qui devrait changer. Ce n'est pas la même chose que comprendre les besoins de l'entreprise. Le début d'une mission doit clarifier la situation avant d'agrandir le plan.

La progression suivante aide à penser les premiers mois ; ce n'est pas un forfait de livraison. Capacité, accès et situation de l'équipe changent le rythme. Un incident peut exiger une action immédiate. Pour un produit stable, écouter d'abord peut être la contribution la plus utile.

D'abord : comprendre le travail réel

Parlez à la direction, aux développeurs et aux personnes qui utilisent ou soutiennent le produit. Suivez une modification récente de la demande à la production. Examinez un incident et un problème client réels. Les documents aident, mais la circulation du travail explique souvent davantage que le schéma d'architecture.

Établissez les accès nécessaires en sécurité et les responsabilités actuelles des systèmes et prestataires. Repérez les risques urgents et les engagements existants. Le premier résultat doit être une vue partagée et courte de ce qui exige de l'attention, peut attendre ou reste inconnu.

Ensuite : choisir un agenda de travail limité

Convenez des décisions prises en charge par le rôle et de celles qui restent les vôtres. Sélectionnez quelques priorités liées à l'entreprise : sécuriser une livraison fragile, clarifier une dépendance fournisseur ou rendre un backlog surchargé plus maîtrisable.

• Écrire le problème et l'amélioration recherchée.
• Nommer les responsables de la décision et de l'implémentation.
• Définir les éléments qui montreront l'utilité du changement.
• Convenir des disponibilités, des remontées et de la prochaine revue.

Ne lancez pas plusieurs projets structurels simplement parce que la revue les a identifiés. Une longue liste d'améliorations raisonnables peut devenir la nouvelle source d'incertitude. Montrez le compromis et terminez quelque chose d'utile avant d'élargir l'agenda.

Puis : suivre les choix dans l'exécution

Restez assez proche de l'implémentation pour découvrir les hypothèses erronées. Examinez la partie modifiée, le parcours de mise en production et les conséquences pour le support. Gardez les décisions accessibles à l'équipe et à la direction. Le journal doit expliquer pourquoi un choix a été fait, pas seulement qu'une réunion a eu lieu.

À la revue : demander ce qui est devenu plus simple

L'équipe sait-elle expliquer ses priorités ? La direction comprend-elle les risques techniques ? Un changement auparavant fragile est-il plus sûr à livrer ? Une autre personne que l'expert habituel peut-elle réaliser la tâche ? Ces questions sont plus utiles que compter recommandations ou réunions.

La revue peut conduire à poursuivre, réduire l'implication, ajouter de la capacité de développement ou préparer un poste interne. Une mission qui constate qu'elle n'est plus nécessaire n'a pas échoué. Le but était une organisation plus capable, pas une dépendance permanente.

La page CTO à temps partagé décrit comment convenir de cette implication. Consultez aussi le parcours professionnel de Levi avant de décider de prendre contact.