Comment éviter que votre quête d’autonomie pour les équipes ne se transforme en chaos…
VP of Engineering dans une scale-up européenne pour laquelle le concept d’autonomie (des gens et des équipes) est de plus en plus une question de survie, Thomas continue de partager expérimentations et leçons apprises collectivement sur ce thème chez Agicap.
Après un podcast et un talk à Devoxx France qui retranscrivent les enjeux globaux et les premiers pas de leur démarche, Thomas aborde aujourd’hui un point crucial et déterminant dans la réussite de cette prise d’autonomie par les équipes de la scale-up lyonnaise.
Ce matin dans le métro, je suis debout au milieu d’une rame bondée. Au moment où les gens se décident à sortir massivement de la rame pour une station qui n’est pas la mienne, je suis coincé par un flux sortant de gens à ma droite, un autre flux de gens sortant sur ma gauche, et un poteau central dans le dos. Je ne peux en aucun cas me déplacer, seulement me décaler légèrement pour laisser soit le flux de droite, soit le flux de gauche passer plus vite. Dans ce contexte, une personne du flux de droite qui aimerait sortir encore plus vite, commence à râler à la française (le fameux “Rrrrr !”) et à me regarder comme si j’étais incapable de comprendre qu’il fallait que je me décale encore plus pour laisser sortir plus vite les gens de sa file 😆
Jusqu’à ce que je lui fasse remarquer ouvertement, cette personne qui râlait avait juste oublié que je devais également composer avec une autre file (et un poteau central).
De l’importance d’avoir une vision globale
Cette mécommunication dans le métro me fait un peu penser à certains problèmes qui peuvent se produire lorsqu’on tente de promouvoir l’autonomie dans une structure qui grossit vite. C’est le cas chez nous, qui avons quitté le rang de startup pour devenir une scale up (c.ad. une startup qui a validé son MVP, son business model et qui croît intensivement).
Dans un tel contexte, l’autonomie des gens et des équipes est un vecteur d’efficacité et d’engagement indispensable. Mais rudement complexe à mettre en place.
Quand on aborde le sujet de l’autonomie des équipes, tout le monde pense très naturellement à l’importance de la communication top-down en provenance du top management. Il est vrai que sans information à jour sur le contexte global et sur la stratégie de l’entreprise, il est impossible pour quiconque de prendre des décisions locales pertinentes. Et sans prises de décisions locales pertinentes, l’organisation ne pourra pas aller très loin ni très vite (je vous laisse imaginer l’efficacité d’une organisation conséquente qui, au contraire, ferait valider chacune des décisions locales par le top management…). Ceci, tout le monde arrive à le comprendre.
En revanche, rares sont les personnes qui prennent vraiment conscience que les autres équipes aux alentours sont tout aussi tributaires de leurs communications à elles.
L’autonomie, un concept plus complexe qu’il n’y paraît
L’autonomie est un des concepts les plus difficiles à appréhender finalement. Très souvent, on ne voit que le petit bout de notre lorgnette.
On confond facilement Autonomie avec Indépendance (voire Isolement).
Genre : on prend des infos, et on part bosser tout seul dans notre coin. Il n’en est rien. L’autonomie est finalement un enjeu de transparence et de synchronisation pour toutes et tous.
En effet, dans un monde en perpétuelle évolution, il est indispensable de rester connectés les uns avec les autres et d’être capables de nous ajuster en permanence.
Mais sans savoir ce que font les autres, comment s’ajuster au mieux ?
J’utilise souvent la métaphore de barques sur un lac avec mes équipes.
Imaginons que chaque équipe soit une des nombreuses barques sur un lac. Nous connaissons toutes et tous l’objectif qui a été partagé au préalable : « il faut qu’on se rende sur cette île à l’autre bout du lac ». Maintenant il faut juste y aller, ensemble.
Et bien si je décide soudainement sur ma barque de tourner violemment à tribord sans prévenir mes collègues aux alentours, je risque très certainement de faire chavirer la barque qui se trouve collée à la mienne dans cette direction. Si en plus ils sont en train de se prendre en selfie sur le bord de leur barque, je risque même d’en faire tomber plus d’un à l’eau au passage. Oups.
Un nouveau shazam: le « j’ai l’intention de… »
Dans l’ouvrage Turn the ship around qui me sert de trame de fond depuis mon arrivée chez Agicap afin d’accompagner ce mouvement vers encore plus d’autonomie et d’efficacité collective, David Marquet explique que la systématisation du « J’ai l’intention de… » a été un pré-requis indispensable pour l’autonomisation du sous-marin nucléaire USS Santa Fé.
Le « J’ai l’intention de… » est ce qui permet aux équipes concernées d’intervenir au bon moment pour éviter des drames ou des gâchis.
L’absence de réponse ou d’opposition suite à une telle intention exprimée largement, correspond du coup à un accord. Celà évite ainsi à tout le monde de faire valider chaque décision avant d’agir (encore une fois par souci d’efficacité et d’autonomie).
Reprenons maintenant notre histoire de barques. Si avant de tourner violemment à tribord, mon équipe indiquait : « Nous avons l’intention de tourner violemment à tribord d’ici 5 mètres », nous permettrions du coup à l’équipe de la barque qui nous colle à tribord de rebondir en nous disant : « ok. On va ralentir pour vous laisser tourner et passer devant nous », ou bien alors un « euh… non surtout pas ! Nous avons des rochers sur notre droite et une barque qui nous colle juste derrière… Nous sommes bloqués et vous demandons d’attendre un peu ou de prendre une autre direction svp ».
Tout ce petit jeu de transparence nous permet de nous synchroniser et de nous aligner sur un plan d’eau où il va pouvoir se passer plein de choses.
Eviter le chaos
Appliqué à un cas plus concret pour nous, si une équipe de dev n’exprime pas dès que possible et clairement : « nous avons l’intention de préparer un hot-fix complexe sur cette zone clé du logiciel », ils privent les autres équipes aux alentours de réagir soit pour éviter un gâchis (« pas la peine, nous sommes déjà dessus depuis longtemps et avons presque fini » de la part d’une autre équipe de dev par exemple), voire un drame que pourrait éviter l’équipe support en réagissant (« ok, mais surtout pas de hot-fix ce jeudi après midi par contre, car nous avons une énorme démo investisseur que nous voudrions sécuriser sur ce créneau »).
Sans ces nombreux « nous avons l’intention de… » ce n’est pas l’autonomie, c’est le chaos.
Des barques qui se percutent, annihilent leurs efforts en se bloquant la route sans le savoir, des relations de type « Nous vs. Eux » qui émergent et qui mènent à beaucoup trop de gâchis et de frictions inutiles dans une organisation qui doit croître rapidement et efficacement.
Un problème à 3 corps
Cette problématique de l’autonomisation à plusieurs volets:
Un volet pédagogique tout d’abord, pour faire vraiment prendre conscience à tout le monde que l’autonomie n’est pas le « après moi le déluge » ou l’isolation des uns par rapport aux autres. Nous ne sommes pas des libertariens !
La plupart des gens ayant du mal à ne pas prendre l’obligation de transparence vis-à-vis des autres comme une contrainte insupportable (et qui leur paraît antinomique avec le concept d’autonomie), il vous faudra mettre en place la conduite du changement nécessaire.
Notamment de mettre en place très tôt les conditions de sécurité psychologique indispensables à cette transparence (pour ne pas que les gens se sentent en danger quand ils s’expriment) et pour permettre également les prises d’initiatives (autoriser les gens à se tromper et à apprendre de leurs erreurs).
Un volet pratique et logistique également, pour pouvoir organiser les modalités de tous ces échanges et ces canaux de communication pour que les personnes concernées puissent toutes entendre aisément les « j’ai l’intention de… » des autres, et avoir suffisamment de temps pour réagir ensuite. Pour ça, nous avons décidé chez Agicap d’être en cohérence vis à vis de la démarche d’autonomie, et de réfléchir toutes et tous ensemble sur les meilleurs moyens pour y arriver (ex: conventions de nommage pour des canaux particuliers dans slack, SLA d’équipes, gather.town, etc.). C’est notre sujet du moment, et nous aurons surement pleins d’autres choses à partager sur le sujet prochainement.
Enfin, le troisième et sans doute le plus important : le volet culturel, l’impact de la culture actuelle de l’organisation vis-à-vis de cette problématique. Lorsqu’on passe de startup à scale-up, il y a des changements qui peuvent paraître difficilement envisageables pour certaines personnes toujours très attachées au mode de fonctionnement initial. Celui du mode héroïque où tout le monde se connaît, travaille côte à côte, où on a l’impression que tout va plus vite et où on peut mesurer très directement son impact individuel.
Il faut en effet arriver à comprendre que c’est moins l’impact individuel que l’impact collectif qu’il est nécessaire de viser désormais. Car si on ne change pas de paradigme entre la phase startup et la phase scale-up, on risque d’avoir de sérieux problèmes de delivery et d’efficacité.
Heureusement pour nous, Lucas Bertola le CTO et un des 3 cofondateurs d’Agicap, était lui déjà convaincu de l’intérêt du changement de braquet et de la démarche vers plus d’autonomie (un thème d’ailleurs longuement abordé lors de mon 1er entretien d’embauche). Mais ce n’est pas un gage suffisant pour la réussite d’une telle entreprise.
Et pour y arriver, il faut que toutes les personnes soient en capacité de se remettre en question. D’être capable d’entendre que les autres peuvent influer sur nous et nos actions. Qu’une autre barque peut parfois nous faire dévier de notre trajectoire. Et que ce n’est pas une anomalie, c’est normal vu qu’on est beaucoup plus nombreux sur le plan d’eau.
Pour moi c’est aussi lié à une question de maturité : les gens un peu junior sur cette route vers l’autonomie seront essentiellement concentrés sur eux-même et leurs propres problématiques, leur propre efficacité individuelle. Le côté systémique va tout d’abord leur échapper ou moins les intéresser (attention d’ailleurs au passage à ne pas les incentiver dans cette direction égocentrée avec des bonus & objectifs individuels).
Comme très souvent d’ailleurs, on en revient à une question de culture (celle qui « mange la stratégie au petit déjeuner » comme disait brillamment P. Drucker). Si vous voulez éviter de caler collectivement parce que certaines personnes ne jouent pas le jeu, il va vous falloir accompagner ces personnes-là qui sont restées très attachées au précédent mode de fonctionnement : le mode startup où “on n’avait pas toutes ces problématiques et où tout semblait plus simple”.
La chance d’avoir des startups dans la start-up chez nous (que l’on appelle des Product lines) nous permet même de repositionner les plus réticents aux changements sur des postes et des rythmes qui leur conviennent mieux (retour au mode MVP & startup). Tout le monde est gagnant, mais encore faut-il prendre conscience que c’est ça qui bloque certaines personnes…
En ce qui me concerne, c’est très exactement pour résoudre ce type de challenges de mise à l’échelle et d’efficacité collective, que j’ai décidé de rejoindre une scale up aussi ambitieuse et talentueuse qu’Agicap.
Pour en savoir plus sur Agicap :
En lien, la qualité de code est-elle compatible avec le mode startup ? (debrief battle Artisan Developpeur) où je parle longuement du modèle 3X que Kent Beck à découvert lors de sa période chez Facebook.
