Décentraliser la prise de décision avec Shawna Martell et Dan Fike
- Aisha Washington
- il y a 2 heures
- 8 min de lecture
Les organisations d’ingénierie disent souvent vouloir que les équipes avancent de manière autonome. En pratique, les décisions remontent encore dans la hiérarchie, s’enlisent en réunion ou dépendent de l’architecte senior disponible à ce moment-là. Shawna Martell et Dan Fike décrivent un modèle différent, développé chez Cartek : établir une stratégie d’ingénierie explicite, puis donner les moyens à des leaders techniques de confiance — appelés Navigators — d’aider les équipes à l’appliquer.
Leur approche considère la décentralisation comme plus qu’une simple délégation d’autorité. Les personnes ont besoin de principes communs, d’un contexte local suffisant, d’un accès à des conseillers expérimentés et d’un moyen de remettre en question ou d’améliorer la stratégie. Lorsque ces éléments fonctionnent ensemble, les contributeurs individuels peuvent prendre des décisions importantes sans faire passer chaque question par le management ou une fonction d’architecture centralisée.
Pourquoi l’autonomie exige une stratégie d’ingénierie
Martell et Fike font remonter le programme Navigator à un problème récurrent : les ingénieurs souhaitaient des orientations plus claires. Sans cadre convenu, les équipes ne pouvaient pas évaluer de manière fiable des options techniques concurrentes ni savoir quelles priorités organisationnelles devaient prévaloir.
Le résultat n’était pas nécessairement une mauvaise ingénierie. C’était une ingénierie incohérente. Deux équipes confrontées à des compromis similaires pouvaient arriver à des conclusions incompatibles, car chacune utilisait un standard différent, en grande partie implicite. Les mêmes débats refaisaient sans cesse surface, consommant du temps sans produire de connaissances organisationnelles durables.
Approuver chaque choix de manière centralisée aurait résolu l’incohérence en créant un goulot d’étranglement. Cartek a plutôt cherché à rendre les fondements des bonnes décisions largement accessibles. Sa stratégie d’ingénierie est devenue un point de référence commun : une description documentée de la façon dont l’organisation évalue les compromis et de ce qu’elle tend à privilégier dans certaines circonstances.
Point essentiel, cette stratégie a émergé en réponse aux ingénieurs qui demandaient davantage de contexte. Martell et Fike ne la présentent pas comme une directive conçue isolément par des dirigeants. Son objectif était de donner aux contributeurs la confiance nécessaire pour agir tout en maintenant leurs choix reliés à une direction plus large.
Partir de la réalité, pas d’une affiche aspirationnelle
Une partie notable du processus de Cartek était l’importance accordée à la documentation de la manière dont les décisions étaient déjà prises. L’équipe n’a pas commencé par décrire une organisation future idéale. Elle a d’abord examiné l’état actuel, y compris des pratiques qui semblaient incohérentes ou difficiles à défendre.
Cette forme d’archéologie organisationnelle compte, car chaque groupe d’ingénierie possède déjà une stratégie, même lorsque personne ne l’a mise par écrit. Elle se manifeste dans des choix répétés : déterminer si les équipes optimisent les performances immédiates ou la capacité à évoluer à l’avenir, accepter une complexité opérationnelle pour accroître la flexibilité, ou étendre un système existant plutôt que de créer un nouveau service.
Les anciens documents de conception et les registres de décisions d’architecture peuvent révéler ces schémas. Un document utile consigne les alternatives envisagées, les bénéfices et les coûts de chacune, ainsi que la raison pour laquelle une option l’a emporté. Plusieurs documents examinés ensemble révèlent les valeurs qui sous-tendent ces choix.
Martell et Fike distinguent ces valeurs des décisions elles-mêmes. Une décision indique ce qui s’est produit dans un cas. Un principe offre une orientation conditionnelle pouvant s’appliquer à un autre cas — autrement dit : « Lorsque ces conditions s’appliquent, privilégiez cette réponse. » Extraire de tels principes peut nécessiter de revenir vers les personnes et les circonstances à l’origine de décisions plus anciennes, en particulier lorsque les documents consignent un résultat sans expliquer son raisonnement.
Commencer avec honnêteté rend également le changement mesurable. Une stratégie idéalisée peut sembler inspirante tout en dissimulant l’écart entre la politique et la pratique. Une description du système réel crée une base à partir de laquelle l’organisation peut délibérément s’améliorer.
Les Navigators aident les équipes à lire la carte
Le nom du programme reflète une importante répartition des responsabilités. La stratégie d’ingénierie fonctionne comme une carte ; les Navigators aident les personnes à l’interpréter sur un terrain inconnu. Ils contribuent à la stratégie, mais leur rôle principal n’est pas d’émettre un plan directeur ni de décider personnellement de chaque question technique.
À l’époque évoquée, environ une douzaine de Navigators soutenaient une organisation d’ingénierie d’environ 400 personnes. Ils provenaient de plusieurs disciplines techniques, notamment l’ingénierie front-end et back-end, la fiabilité et la sécurité. Leurs positions dans la hiérarchie formelle variaient : certains travaillaient au cœur des équipes, tandis que d’autres opéraient plus près de la direction générale.
La sélection dépendait moins du titre que du jugement démontré, de la profondeur technique et de l’influence. Martell et Fike décrivent un réseau informel qui existe parallèlement à l’organigramme managérial. Certains ingénieurs deviennent naturellement les personnes que leurs collègues consultent lorsqu’un problème est ambigu. Le modèle Navigator reconnaît et relie ces figures de confiance au lieu de supposer que l’autorité ne circule qu’à travers les lignes hiérarchiques.
Les Navigators ont besoin d’un contexte substantiel sur les produits et les systèmes qui les entourent. Ils doivent savoir quelles décisions sont en cours, reconnaître lorsqu’un travail entre en conflit avec la stratégie et intervenir lorsqu’une équipe a besoin d’aide. Cela ne signifie pas prendre le contrôle. Un Navigator peut accompagner l’équipe dans l’évaluation du compromis, identifier les principes pertinents ou soumettre une question non résolue au groupe plus large des Navigators.
Ils font également circuler l’information dans les deux sens. La stratégie aide les équipes à faire des choix locaux, tandis que les difficultés rencontrées par les équipes révèlent les endroits où la stratégie est incomplète. Les Navigators sont donc à la fois des interprètes et d’importants contributeurs à sa révision continue.
Des conseils sans goulot d’étranglement architectural
Cartek évite délibérément de faire d’un architecte formel la porte d’entrée obligatoire pour les décisions techniques. Des Staff Engineers peuvent réaliser un travail d’architecture lorsque cela est nécessaire, mais l’organisation ne souhaite pas un rôle permanent qui concentre l’autorité décisionnelle en un seul endroit.
Son modèle ressemble plutôt à un processus de conseil en architecture. Un ingénieur peut prendre une décision après avoir consulté les personnes concernées, des collègues disposant d’une expérience pertinente, la stratégie écrite et un Navigator si nécessaire. L’autorité reste distribuée, mais la consultation est attendue.
La stratégie sert de source collective de conseils. Elle donne même aux ingénieurs moins expérimentés un standard auquel ils peuvent confronter une proposition. Par exemple, elle peut clarifier la manière dont l’organisation évalue les performances par rapport à la capacité à évoluer, ou le coût de maintenance par rapport à la rapidité de livraison.
Toutes les questions ne peuvent pas être ramenées à une orientation universelle. Martell et Fike évoquent des choix tels que déterminer si une capacité doit appartenir à un monolithe existant ou justifie un nouveau service. Une organisation peut avoir une orientation générale sans disposer d’une règle suffisamment précise pour chaque situation. Dans ces cas, la stratégie doit reconnaître l’ambiguïté et orienter les ingénieurs vers une consultation éclairée.
Cela préserve le jugement au lieu de le remplacer par la bureaucratie. L’objectif n’est pas d’encoder toutes les réponses futures. Il est de faciliter les choix courants, de faire ressortir ceux qui sont réellement difficiles et de donner aux personnes une manière cohérente de raisonner face aux exceptions.
La stratégie doit progressivement devenir moins erronée
Martell et Fike présentent la stratégie comme un instrument évolutif plutôt que comme une doctrine achevée. Les principes initiaux comporteront des lacunes. Certains seront trop larges, tandis que d’autres pourront échouer dans des conditions que leurs auteurs n’avaient pas anticipées.
Les décisions réelles fournissent le retour nécessaire pour les améliorer. Les équipes comparent une option à la stratégie, découvrent où l’orientation aide ou échoue, puis font remonter ces éléments par l’intermédiaire de leurs Navigators. Au fil du temps, les décisions individuelles comme le cadre partagé peuvent devenir moins erronés.
Autoriser une ambiguïté limitée fait partie de la conception. Les équipes doivent encore disposer de la marge nécessaire pour élaborer des « micro-stratégies » locales adaptées à leurs systèmes et à leurs contraintes. Les Navigators contribuent à garantir que ces approches locales restent compatibles avec la direction plus large de l’organisation, sans imposer à chaque équipe une mise en œuvre identique.
Les relations entre les Navigators renforcent cette boucle de rétroaction. Ils ne sont pas collectivement propriétaires de chaque décision, mais ils peuvent consulter leurs pairs lorsqu’un problème traverse plusieurs domaines. Leur combinaison d’une large conscience organisationnelle et de connaissances spécialisées approfondies est particulièrement utile pour les enjeux qui couvrent la sécurité, la fiabilité, l’architecture de plateforme et le développement produit.
La décentralisation est aussi un système de mentorat
La distribution de l’autorité ne fonctionne que si davantage de personnes apprennent à l’exercer. Le rôle de Navigator inclut donc une responsabilité implicite de transmission : apprendre à identifier les compromis, à solliciter les conseils appropriés, à documenter le raisonnement et à décider avec des informations incomplètes.
C’est particulièrement important pour les ingénieurs à qui l’on n’a pas encore confié de choix à fort impact. Leur dire de « prendre les choses en main » ne suffit pas si chaque proposition conséquente est ensuite annulée par un groupe de hauts responsables inaccessible. Les Navigators peuvent rendre le processus de raisonnement visible et soutenir les contributeurs tout en laissant la décision au plus près du travail.
Martell et Fike distinguent également la perspective du Navigator de celle du management. Les managers doivent concilier les personnes, la livraison et l’exécution de l’équipe. Les Navigators apportent un jugement technique approfondi et relient les choix d’ingénierie locaux à la stratégie de l’ensemble de l’organisation. Ces deux perspectives devraient se compléter plutôt que de se fondre dans un rôle unique.
Les candidats sont reconnus pour leur contribution existante et nommés par des dirigeants seniors, plutôt que de postuler via un processus conventionnel. La crédibilité technique seule ne suffit pas. Une personne peu disposée à faire progresser les autres ou à partager son jugement aurait du mal à remplir l’objectif du programme.
Mesurer le succès par de meilleures décisions
La valeur de la décentralisation se manifeste dans les résultats concrets des décisions. Martell et Fike décrivent une équipe envisageant un nouveau service de plateforme partagée pour un problème observé dans plusieurs domaines. Une réponse apparemment raisonnable aurait pu consister à construire une solution universelle et à entamer un long effort pour obtenir l’accord de chaque partie prenante.
Un Navigator a comparé la proposition à la stratégie de l’organisation et a conclu qu’une plateforme universelle n’était pas la direction privilégiée. Comme la stratégie représentait déjà une orientation par défaut convenue, le Navigator a pu résoudre la question sans reconstruire tout l’argumentaire depuis le début.
Cela illustre un changement significatif dans la charge de la preuve. Au lieu que les défenseurs d’une approche doivent sans cesse persuader les autres qu’une direction est correcte, la stratégie documentée fournit le point de départ. Les écarts restent possibles, mais ils nécessitent une explication convaincante.
Parmi les indicateurs utiles de progrès figurent des décisions plus rapides, moins d’escalades inutiles, un raisonnement plus clair dans les documents de conception et une plus grande confiance chez les contributeurs. Les signaux qualitatifs comptent aussi : les ingénieurs devraient se sentir moins désorientés, et les débats récurrents devraient produire de plus en plus des principes réutilisables plutôt qu’un nouveau compromis temporaire.
Comment les responsables de l’ingénierie peuvent commencer
Martell et Fike précisent clairement que nommer des Navigators avant d’avoir formulé une stratégie a peu de chances de fonctionner. Sans carte commune, des personnes de confiance risquent simplement de diffuser plus efficacement leurs préférences personnelles.
Les responsables peuvent commencer par examiner les décisions d’architecture passées et les documents de conception actuels. Ils devraient identifier les compromis récurrents, consigner d’abord les principes les moins controversés et examiner l’écart entre les valeurs déclarées et les comportements observés. Le malaise suscité par cet état des lieux constitue une preuve utile : il met en évidence les pratiques que l’organisation pourrait vouloir modifier.
Une séquence pratique consiste à :
documenter des décisions représentatives et leur raisonnement ;
extraire des principes conditionnels à partir de schémas récurrents ;
identifier les domaines où la pratique actuelle entre en conflit avec la direction souhaitée ;
trouver des contributeurs techniques respectés qui conseillent déjà les autres ;
placer ces personnes là où elles peuvent relier le travail local à la stratégie de l’organisation ;
réviser le cadre à mesure que les décisions réelles révèlent des omissions ou des contradictions.
La leçon plus profonde est que la décentralisation dépend d’une infrastructure de jugement. Les principes écrits apportent de la cohérence, les Navigators fournissent du contexte et du mentorat, et les équipes apportent les éléments probants qui maintiennent le système ancré dans le réel. Ensemble, ces mécanismes permettent à l’autorité de se rapprocher du travail sans laisser l’organisation se fragmenter en orientations techniques incompatibles.
