À quel point restez-vous opérationnel en tant que manager ?

Restez assez technique pour prendre de bonnes décisions et relire des conceptions de façon crédible, sans vous placer sur le chemin critique. En pratique, ça veut dire lire des pull requests, participer aux revues de conception, prendre parfois du petit travail non urgent, et rejoindre les incidents comme coordinateur plutôt qu'en héros. La taille de l'équipe fixe le niveau : avec cinq personnes vous pouvez coder un peu, avec quinze vous ne devriez pas.

Ma règle, c'est de rester assez technique pour avoir un avis et de ne jamais prendre de travail qui bloque quelqu'un. Donc je lis des pull requests presque tous les jours, je suis actif dans les revues de conception, et je prends des sujets qui ne sont vraiment pas urgents : de l'outillage, un test instable, de la documentation, du travail qui peut attendre une semaine quand mon agenda explose. Ce que je ne fais pas, c'est prendre une fonctionnalité sur le chemin critique, parce que la semaine qui part de travers est toujours celle où j'ai trois entretiens et une conversation de réorganisation, et là je deviens le goulot d'étranglement en plus d'avoir appris à mon équipe à ne pas faire confiance à mes engagements. Avec six personnes, j'écris probablement du code quelques heures par semaine. Quand je dirigeais un groupe de seize sur deux équipes, je n'en écrivais presque pas et je restais affûté par les documents de conception et les rétrospectives d'incident. Pendant les incidents, je rejoins comme coordinateur et comme bouclier, pas comme la personne qui tape, parce que c'est le moyen le plus rapide de faire attendre les vrais experts.