Pourquoi les fonctions support sont détestées
Entre aider et rajouter du travail, il n'y a qu'un pas
En tant que fonction support, on a souvent le réflexe de se positionner sous l’angle du conseil ou de la gouvernance. “Voici comment il faut faire, ne faites pas ceci ou cela…”
C’est généralement pertinent et justifié :
Cybersécurité : “Ne partagez pas vos mots de passe…”
Architecture : “Nous mettons en place une Design Authority pour éviter de faire les mauvais choix…”
Coaching Agile : “Découpez le travail en incréments les plus petits possibles…”
Support : “Documentez vos processus et les évolutions de vos produits…”
Etc.
Sauf que :
Ça ne marche pas comme ça.
En pratique, ce qu’on fait vis-à-vis des équipes auxquelles “on apporte notre support”, c’est surtout de leur poser des contraintes supplémentaires.
Dans cette phrase, je mets bien des guillemets à “on apporte notre support” car finalement — certes sans s’en rendre compte — on a surtout tendance à leur rajouter plein de choses en plus, à penser et à faire.
On leur en rajoute plus qu’on ne les soutient.
Bref, on leur complique la vie au lieu de la leur faciliter.
😭
Parfois, on tombe dans le grand n’importe quoi, en ajoutant des contraintes qui n’ont ni queue ni tête.
C’est par exemple le fameux syndrome de l’architecte dans sa tour d’ivoire, qui fait des recommandations voire impose des décisions qui sont déconnectées de la réalité.
Souvent, on est plutôt sur des contraintes et injonctions qui sont justifiées et pertinentes.
Malgré tout, cela reste une charge cognitive supplémentaire qui est rajoutée “on top of“, qui complexifie un quotidien qui est déjà surchargé.
Pour autant, les équipes sont demandeuses
Les équipes ont le nez dans le guidon à gérer tant bien que mal leur run et leur build.
Mais ça ne veut pas dire qu’elles sont aveugles, insensibles ou incompétentes.
Ces équipes se rendent bien compte qu’il y a plein de choses qui ne marchent pas comme il faudrait. Que ce n’est pas fluide. Qu’elles passent trop de temps en mode pompier. Qu’elles pourraient faire mieux.
Les équipes sont dedans.
Qui mieux qu’elles pour s’en rendre compte ?
Donc, déjà, attention à ne pas juste pointer du doigt tout ce qui ne va pas. Et surtout pas avec une posture condescendante.
Tout d’abord parce que, cela va sans dire, ce n’est pas comme ça qu’on pose de bonnes bases pour la suite en termes de relation. 🤷
Ensuite parce que le risque est de finir en Captain Obvious, à dire des évidences sans vraiment de valeur ajoutée.
“Oui merci, ça on le savait déjà, la question c’est plutôt qu’est-ce qu’il faut faire, et surtout comment tu peux nous aider !” 🙄
Les équipes sont demandeuses d’aide. Elles sont conscientes de leurs propres limites. Potentiellement en termes d’expertise, mais surtout en termes de temps, de focus et de budget.
Justement, ce qu’elles veulent, c’est bien de l’aide.
Pas qu’on leur en rajoute plus à faire.
En plus de tout ce qu’elles ont déjà à gérer… 🤨
Responsabilité vs charge cognitive
En tant que fonction support, après quelques loupés où l’on est mal reçu quand on essaie d’apporter son aide, on peut se méprendre et voir cette demande d’aide comme une volonté de se décharger d’une part de responsabilité.
Par exemple, imaginons le lancement d’une démarche d’architecture d’entreprise, jusqu’ici absente.
Les équipes sont contentes, elles se réjouissent de cette initiative qui apporte un œil plus global et qui ose prendre des décisions.
Justement, ces décisions…
En se faisant l’avocat du diable, en prenant un angle politique (et en étant mauvaise langue), on pourrait plutôt se dire que cette initiative est bien reçue parce qu’elle décharge de la responsabilité de la prise de décision.
Quelque chose de cet acabit :
“Si le projet part en couille après à cause de cette décision, ce ne sera pas ma faute car ce n’est pas moi qui ait pris cette décision.”
Ce ne serait ainsi pas tellement une demande d’aide, qu’un moyen de s’assurer qu’en cas de soucis c’est quelqu’un d’autre qui trinque ?
C’est pas faux, mais c’est trop simpliste.
Il y a surtout que les équipes ont déjà trop à penser et qu’elles sont heureuses de se décharger.
Elles cherchent à réduire leur charge cognitive.
Une fonction support qui réduit la charge cognitive
Comment accompagner, comment apporter son support, d’une manière qui RÉDUIT la charge cognitive au lieu d’en rajouter ?
“Faites comme ceci ou comme cela”
❌ On en rajoute
“On s’en occupe à votre place”
✅ On réduit la charge cognitive…
⚠️ … ou pas : si l’on doit vérifier après que c’est fait correctement et que ça ne casse rien, on garde la charge cognitive ! ❌
“L’outil vérifie automatiquement et vous alerte directement”
❓ Cela peut réduire la charge cognitive (on n’a pas à penser à la vérification) mais au final cela peut aussi en rajouter (ça donne du travail en plus, qu’on n’a pas forcément prévu !)
Ce n’est pas simple. C’est tout en nuances.
On peut facilement se planter, et il ne suffit pas de faire l’inverse de ce qui ne marche pas pour que ça fonctionne. 😬
La confiance et la fiabilité sont souvent des éléments clés : on peut alors déléguer le sujet sans avoir à y penser ensuite.
C’est la définition même de la délégation.
Team Topologies
Les concepts que je manipule ici sont au cœur de Team Topologies, qui s’appuie sur cette notion de charge cognitive. 1
Le message clé de Team Topologies est de se structurer en équipes qui ont le bon niveau de charge cognitive.
Ainsi, le rôle des équipes type plateforme est de réduire la charge cognitive des autres équipes. Pas de leur fournir des contraintes ou des services en plus, mais de leur permettre d’accomplir plus en ayant à penser à moins de choses.
On retrouve également une forte orientation vers la gestion de produit, y compris et surtout sur les équipes au service des autres équipes : il faut s’assurer que les services aident bien ces autres équipes. Cela tire autant des ficelles du service lui-même, que de comment il est mis en œuvre et mis à disposition.
Un exemple tiré du monde DevOps :
ticket factory vs self-service
Un exemple concret et bien connu pour illustrer cette nuance, c’est la manière dont une équipe infrastructure offre ses services aux équipes applicatives.
Dans la littérature DevOps, on compare ainsi souvent plusieurs modes possibles d’interaction.
En particulier, on a d’un côté la ticket factory : par exemple lorsqu’on a besoin d’ouvrir une nouvelle route, on crée un ticket à destination de l’équipe infra. L’équipe infra s’en charge quand elle peut (délais pour le demandeur) et éventuellement demande plus d’informations si le ticket est incomplet (imprévus pour le demandeur).
Voire, le pire scénario, dans une organisation peu collaborative : on rejette purement et simplement le ticket incomplet. Charge au demandeur de se débrouiller pour faire un bon ticket. Bonne ambiance ! 💔
Continuons l’exemple avec cette fois le self-service : pour ouvrir une nouvelle route, l’équipe demandeuse remplit un formulaire, ce qui déclenche directement le travail nécessaire. La demande est résolue sans délai et avec un feedback immédiat.
En mode ticket factory :
En théorie, on soulage les équipes en leur enlevant l’expertise nécessaire.
En pratique, on crée un bottleneck externe à l’équipe et au lieu de réduire leur charge cognitive, au contraire on leur en rajoute car il faut suivre la demande déléguée jusqu’au bout, faire des relances si nécessaire, être disponible pour compléter la demande, et planifier la demande suffisamment en avance pour pouvoir gérer tous les aléas… 🤯
On part donc d’une bonne volonté, pour un résultat catastrophique. On est là pour aider les équipes, qui au final cherchent à la moindre occasion comment se passer de nous. ❌
En mode self-service :
Bien sûr, la difficulté qui saute aux yeux de cette approche, c’est qu’il faut automatiser le travail pour pouvoir être mis à disposition en mode self-service.
Il faut également travailler sur l’interface et la gestion des droits pour que les équipes puissent lancer ce travail automatisé seuls, de manière sécurisée et sans risque.
Sans oublier de bien remonter le feedback, efficacement et de manière compréhensible ! Si quand on lance le formulaire le truc plante sans que l’on comprenne ce qui ne va pas, ça casse le modèle : car on doit alors demander de l’aide et donc ce n’est plus du self-service.
Par contre, une fois mis en service avec succès, on a alors des équipes qui peuvent réellement faire abstraction d’un concept. L’équipe est autonome, elle fait la demande au moment où elle en a besoin et elle a un retour immédiat. On réduit effectivement la charge cognitive des équipes et on les aide réellement. On leur libère du temps, de l’énergie et du focus pour se concentrer sur la valeur ajoutée qu’elles doivent apporter. 🚀
Observer, créer du lien, itérer
Cet exemple tiré du monde DevOps est assez parlant mais ce n’est pas évident comment faire quelque chose de similaire dans d’autres domaines.
On peut tout de même se douter que, quoi qu’il arrive,
la bonne approche est tout sauf facile à mettre en œuvre.
Dans ce précédent exemple qui compare ticket factory à self-service, si on voit bien tous les avantages de la seconde approche sur la première, ne nous leurrons pas sur la difficulté de le faire, et de le faire bien. Il y a un gros travail de fond d’automatisation mais également de lien entre les outils. Et comme souvent, le diable se cache dans le détail.
Il est donc critique de se mettre à la place de ses clients et utilisateurs en les observant et en créant un lien continu avec ces derniers, pour concevoir la bonne solution et détecter ce qui coince actuellement, pour itérer jusqu’à trouver une solution satisfaisante.
Quelle que soit votre fonction support, mettez un point d’honneur à créer ces boucles de feedback avec vos clients et utilisateurs.
Si vous n’êtes pas familier avec Team Topologies, nous avions fait quelques vidéos Scrum Life sur le sujet. Je vous invite tout de même à lire le livre, qui se lit assez vite.