Leadership, influence et prise de décision

Diriger sans autorité

La plupart des architectes n’encadrent pas les personnes qui construisent ce qu’ils conçoivent. Les équipes rendent compte à des engineering managers, les priorités appartiennent aux product managers, les budgets aux directeurs. Pourtant, on attend de l’architecte qu’il veille à ce que les décisions importantes soient bien prises et respectées dans de nombreuses équipes, ce qui est la responsabilité centrale décrite à la section 1.4. L’écart entre la responsabilité et l’autorité formelle est la condition qui définit le métier, et le combler est une affaire d’influence.

L’étude classique de John French et Bertram Raven sur le pouvoir social (1959) distinguait les bases du pouvoir qui viennent avec une position (l’autorité légitime, la capacité de récompenser et la capacité de punir) de celles qui appartiennent à une personne (l’expertise et le pouvoir de référence, c’est-à-dire le respect et l’identification que ressentent les autres) ; Raven a ensuite ajouté le pouvoir informationnel, la capacité d’apporter des faits qui font changer d’avis. Les architectes détiennent rarement beaucoup de pouvoir lié à leur position, et quand c’est le cas, l’utiliser coûte cher : une décision imposée par le rang est appliquée, pas appropriée, et ceux qui n’étaient pas d’accord cessent de vous signaler les problèmes. Une influence architecturale durable repose presque entièrement sur l’expertise, l’information et les relations.

Ce n’est pas une compétence relationnelle plaquée sur le travail technique. Une conception solide que personne n’adopte a le même effet que pas de conception du tout, et une conception médiocre que les équipes comprennent et soutiennent fait souvent mieux qu’une conception brillante qu’elles contournent. La suite de cette section traite l’influence comme un ensemble de pratiques qui s’apprennent : instaurer la confiance, animer les décisions, gérer les conflits, communiquer avec la hiérarchie, faire grandir les autres et éviter les pièges dans lesquels tombent les groupes.

Instaurer la confiance et la crédibilité

The Trusted Advisor (2000) de David Maister, Charles Green et Robert Galford propose un modèle utile. La confiance croît avec la crédibilité (vous savez de quoi vous parlez), la fiabilité (vous faites ce que vous dites) et l’intimité (les gens se sentent en sécurité pour aborder avec vous des sujets difficiles), et elle diminue avec l’orientation vers soi (le sentiment que vous servez vos propres intérêts, comme avoir raison, paraître brillant ou protéger votre conception). L’enseignement du modèle pour les architectes est que l’orientation vers soi se trouve sous la barre de fraction : elle divise tout le reste. Un architecte brillant et fiable, mais qui a visiblement besoin de gagner chaque discussion, n’inspire pas confiance.

En pratique, la crédibilité se construit par de petits gestes visibles. Ayez raison sur les petites choses avant de demander qu’on vous fasse confiance sur les grandes. Restez assez proche du code pour en comprendre le coût réel : écrivez le spike, relisez la pull request, assistez à une revue d’incident. Dites ce que vous ne savez pas et comment vous le découvririez. Tenez chacun de vos engagements, surtout les plus ennuyeux. Reconnaissez publiquement le mérite des autres et assumez vos propres erreurs, publiquement aussi. Expliquez le raisonnement derrière chaque principe pour que chacun puisse l’appliquer dans des situations que vous n’aviez pas prévues.

La confiance dépend aussi du climat qui vous entoure. Les recherches d’Amy Edmondson sur la sécurité psychologique, à commencer par une étude d’équipes de travail en 1999, ont montré que les équipes dont les membres estiment pouvoir sans risque admettre leurs erreurs et contester les autres apprennent davantage et obtiennent de meilleurs résultats. Les architectes façonnent ce climat plus qu’ils ne le pensent. Réagir aux mauvaises nouvelles avec curiosité plutôt qu’en cherchant un coupable, solliciter explicitement les objections (qu’est-ce qui ferait échouer ceci ?) et remercier ceux qui en soulèvent, voilà ce qui permet d’entendre parler d’une conception défaillante tant qu’elle est encore peu coûteuse à corriger.

Animer les décisions

Beaucoup de débats d’architecture portent en réalité sur le processus : qui décide, qui doit être consulté et comment les désaccords seront tranchés. Régler les droits de décision avant de discuter du fond retire une bonne part de la tension. La section 11.4 a décrit le processus de consultation (advice process), dans lequel chacun peut prendre une décision à condition de demander l’avis des personnes concernées et des personnes compétentes ; d’autres organisations utilisent un forum de revue d’architecture, un responsable des décisions désigné par domaine, ou des matrices de rôles comme RACI. Le mécanisme précis compte moins que le fait qu’il soit connu à l’avance.

Quels que soient les droits de décision en vigueur, l’architecte est souvent le facilitateur : la personne qui formule la question, s’assure que les bonnes personnes et les bons éléments probants sont présents et guide le groupe vers une décision qui tienne. Différentes méthodes de décision conviennent à différentes situations, et choisir la méthode délibérément fait partie du métier.

Deux méthodes sont souvent confondues. Le consensus recherche une proposition que tout le monde soutient activement ; il crée un engagement fort, mais il est lent et donne à chacun un droit de veto de fait. La prise de décision par consentement, développée dans la sociocratie de Gerard Endenburg aux Pays-Bas à partir des années 1970, adopte une proposition sauf si quelqu’un soulève une objection argumentée selon laquelle elle causerait un préjudice ou ferait reculer le groupe. La question passe de êtes-vous tous d’accord ? à quelqu’un ne peut-il pas vivre avec cela, et pourquoi ? Une formule issue de la pratique sociocratique résume bien le seuil : assez bon pour maintenant, assez sûr pour essayer. Le consentement fonctionne particulièrement bien pour les décisions de type porte à double sens, que l’on peut réexaminer à mesure que les éléments probants arrivent. Le consensus approximatif (rough consensus) de l’IETF, décrit à la section 4.8, en est un proche parent.

Quand l’accord ne peut pas être trouvé, quelqu’un doit décider, et l’on doit déjà savoir qui. Le disagree and commit (exprimer son désaccord, puis s’engager), également abordé à la section 4.8, demande à chacun de défendre pleinement sa position avant la décision et de la soutenir pleinement ensuite. Cela ne fonctionne que si le désaccord a réellement été entendu, si la dissidence est consignée (dans l’enregistrement de décision d’architecture, avec ses raisons) et s’il existe un signal convenu qui rouvrirait la question.

Conflits et politique organisationnelle

La politique organisationnelle, c’est simplement la manière dont des groupes aux intérêts différents, aux ressources limitées et avec leur propre carrière parviennent à des décisions. Ce n’est pas une corruption du travail d’architecture, mais son environnement. L’ignorer ne rend pas un architecte plus intègre, seulement moins efficace. Les outils des chapitres précédents s’appliquent directement : la cartographie des parties prenantes et la matrice pouvoir/intérêt de la section 1.5 montrent qui est concerné et qui peut bloquer, et les traces écrites des compromis de la section 1.6 rendent les positions visibles.

Getting to Yes (1981) de Roger Fisher et William Ury reste le guide le plus utile de la négociation raisonnée, et ses quatre idées se transposent directement. Séparez les personnes du problème : la responsable des paiements n’est pas obstructive, elle s’inquiète pour les données de carte. Concentrez-vous sur les intérêts, pas sur les positions : nous ne devons pas utiliser Kafka est une position ; nous ne pouvons pas assumer davantage d’astreinte est un intérêt que plusieurs conceptions pourraient satisfaire. Imaginez des options à bénéfice mutuel avant de décider. Insistez sur des critères objectifs, convenus avant de comparer les options. Leur idée de la meilleure solution de rechange à un accord négocié (BATNA) est utile aussi : savoir ce qui se passe si aucun accord n’est trouvé indique à chacun ce que vaut l’accord.

Le modèle des modes de gestion des conflits de Kenneth Thomas et Ralph Kilmann (1974) décrit cinq façons de réagir à un conflit, selon le poids que vous accordez à vos propres préoccupations et à celles de l’autre partie. Aucune n’est toujours la bonne ; tout l’art est de choisir délibérément plutôt que de retomber dans ses habitudes.

Quelques habitudes pratiques aident dans tous les cas. Ne prenez jamais une partie prenante par surprise en réunion publique avec une proposition qui la concerne ; parlez-lui d’abord, en tête-à-tête (les organisations japonaises appellent cette consultation préparatoire nemawashi). Quand il faut faire remonter un désaccord, faites-le ensemble : les deux parties présentent le désaccord et les options à la personne qui peut décider, plutôt que de faire pression chacune de leur côté. Et séparez les désaccords sur les conceptions des jugements sur les personnes, dans ce que vous dites comme dans ce que vous écrivez.

Communiquer avec les dirigeants

La section 4.8 a traité de l’adaptation d’un message à son public et de l’importance de commencer par la réponse. Les dirigeants méritent un peu plus d’attention, parce qu’ils détiennent les budgets et l’autorité dont dépend le travail d’architecture, et parce que c’est le plus souvent en expliquant trop et en demandant trop peu que les architectes les perdent.

Formulez chaque sujet dans les termes que les dirigeants gèrent déjà : chiffre d’affaires, coût, risque, délai de mise sur le marché, expérience client, réglementation et personnes. Apportez des options plutôt qu’un plan unique, chacune avec son coût, son risque et ce à quoi elle renonce, et dites laquelle vous recommandez et pourquoi. Quantifiez là où vous le pouvez honnêtement, et dites quel degré de confiance accorder aux chiffres ; une fourchette avec une base explicite est plus crédible qu’une fausse précision. Dites explicitement de quelle décision ou de quel soutien vous avez besoin de leur part, et pour quand. Préparez-vous à la question que feriez-vous si c’était votre argent ? Et ne laissez jamais un dirigeant apprendre l’existence d’un risque grave par quelqu’un d’autre.

Les cadres supérieurs s’intéressent souvent moins au fonctionnement d’un système qu’au fait de savoir si ses responsables le maîtrisent. Montrer que les risques sont connus, attribués, mesurés et en voie de réduction (par exemple au moyen d’un registre des risques d’architecture ou des fonctions d’aptitude de la section 11.3) inspire plus confiance que n’importe quel diagramme. La section 11.8 montre comment présenter le travail d’architecture sous la forme que les dirigeants utilisent pour comparer les investissements : l’analyse de rentabilité.

L’ascenseur de l’architecte

The Software Architect Elevator (O’Reilly, 2020) de Gregor Hohpe donne l’image la plus mémorable de ce travail. Les grandes organisations ressemblent à de hauts immeubles. Au penthouse, les dirigeants fixent la stratégie et les budgets ; dans la salle des machines, les ingénieurs construisent et exploitent les systèmes ; entre les deux s’étagent de nombreux niveaux d’encadrement, et l’information qui les traverse est filtrée et déformée en chemin. L’ascenseur de l’architecte (architect elevator) de Hohpe circule entre le penthouse et la salle des machines et transporte l’information dans les deux sens : il descend la stratégie et ses raisons jusqu’aux personnes qui construisent les systèmes, et il monte les réalités techniques (contraintes, risques, coûts et options dont l’entreprise ignorait disposer) jusqu’aux personnes qui prennent les décisions stratégiques.

Pour Hohpe, la valeur de l’architecte réside dans le lien entre les étages. Un architecte qui reste au penthouse devient un stratège dans sa tour d’ivoire, dont les plans ignorent ce qui est techniquement possible ; celui qui reste dans la salle des machines devient un expert respecté dont les avertissements n’atteignent jamais les personnes qui pourraient agir. Bien prendre l’ascenseur, c’est changer de langage et de niveau de détail à chaque étage sans changer le fond, ce qui est exactement la compétence d’adaptation au public de la section 4.8, appliquée à toute une organisation.

Faire grandir d’autres architectes

Un architecte qui prend personnellement toutes les décisions importantes devient un goulet d’étranglement, et la capacité architecturale de l’organisation s’en va avec lui. Faire grandir les autres fait donc partie du rôle ; ce n’est pas un supplément facultatif. Il est utile de distinguer trois activités. Le mentorat partage votre expérience et vos conseils. Le coaching pose des questions qui aident la personne à trouver sa propre réponse, ce qui forge le jugement plus vite. Le parrainage met votre crédibilité au service de quelqu’un pour lui ouvrir des opportunités : le recommander pour piloter une conception, mettre son nom sur la proposition, l’inviter à la réunion de direction.

Parmi les techniques pratiques : travailler en binôme sur les conceptions et les revues, laisser des ingénieurs moins expérimentés rédiger l’ADR d’une décision et le relire avec eux, organiser des katas d’architecture (section 11.2) pour s’exercer, déléguer des décisions dans des garde-fous énoncés, et expliciter votre raisonnement à voix haute pendant les discussions de conception pour que les autres voient comment les compromis sont pesés, et pas seulement la conclusion.

De nombreuses organisations proposent désormais une filière de carrière technique parallèle au management. Staff Engineer: Leadership beyond the management track (2021) de Will Larson a popularisé le terme staff-plus pour désigner les contributeurs individuels de niveau staff, principal et au-delà, et a décrit quatre archétypes courants à partir d’entretiens avec des personnes occupant ces rôles. The Staff Engineer’s Path (O’Reilly, 2022) de Tanya Reilly organise ce travail autour de la vision d’ensemble, de l’exécution de grands projets et de la montée en compétence des ingénieurs qui vous entourent. Dans sa conférence de 2019 « Being Glue », Reilly a aussi attiré l’attention sur le travail de coordination (débloquer les gens, écrire le document manquant, repérer le vide entre les équipes) qui maintient les projets en vie mais qui est souvent peu valorisé lors des promotions ; les architectes devraient remarquer qui le fait et veiller à ce qu’il compte.

Retour sur les pièges décisionnels

La section 1.6 a recensé les biais individuels qui faussent les décisions architecturales : l’ancrage, les coûts irrécupérables, la pensée de groupe, l’architecture pilotée par le CV, l’effet de mode et le biais de confirmation. Diriger des décisions de groupe ajoute ses propres pièges, qui viennent du statut, de la fatigue et de l’inertie organisationnelle plutôt que du raisonnement individuel.