- Un article qui traite du concept de « conseils dangereux » (dangerous advice) : utiles pour les ingénieurs seniors compétents, mais potentiellement nuisibles pour les ingénieurs moins expérimentés
- Des éléments comme l’accès au SQL de production sont des « outils tranchants » (sharp tools)
- Définir soi-même les priorités du travail, enfreindre parfois délibérément les règles de l’entreprise, ou encore adopter une position ferme malgré l’incertitude sont des exemples concrets de conseils dangereux
- La plupart des conseils de carrière sont faux, car rédigés pour éviter toute responsabilité ou soigner son image ; pour réellement faire avancer les choses, il faut agir en dehors des règles officielles
- Les managers ont une limite structurelle qui les empêche de donner directement ce type de conseils, à cause du risque qu’ils encourent eux-mêmes
- Les conseils dangereux relèvent d’une logique à haut risque, haute récompense, et l’essentiel est de comprendre la zone invisible (illegible) qui existe au-delà des règles officielles d’une organisation
La métaphore des « outils tranchants » et des « conseils dangereux »
- Les « sharp tools » sont des outils comme
ssh, kubectl ou une console SQL de production en lecture-écriture, qui peuvent être d’une grande aide ou causer de gros dégâts selon le niveau de compétence
- Les « conseils dangereux » ont la même propriété : ils ne peuvent être bien utilisés qu’avec les compétences et le jugement nécessaires
- Donner des conseils dangereux à la mauvaise personne revient à donner un accès au SQL de production à la mauvaise personne
Exemples concrets de conseils dangereux
- Décider soi-même sur quoi travailler
- Parfois enfreindre délibérément les règles écrites de l’entreprise
- Prendre une position ferme même en situation d’incertitude
- Se définir un peu comme un « grifter »
- Éviter délibérément toute activité qui n’est pas liée à la mise en production
Pourquoi la plupart des conseils de carrière sont faux
- Les ingénieurs compétents recherchent les conseils dangereux pour la même raison qu’ils veulent des outils tranchants
- La plupart des conseils de carrière sont écrits dans une logique d’évitement de responsabilité (liability avoidance) ou de gestion d’image (impress people)
- Quiconque veut réellement faire avancer le travail finit par adopter ces comportements risqués, parce qu’ils sont manifestement utiles
- Savoir que les choses ne fonctionnent pas officiellement ainsi, tout en n’entendant personne le dire, provoque un profond sentiment d’aliénation
- Au début de sa carrière, un petit nombre de collègues qui parlaient franchement de manière informelle ont été d’une grande aide
Pourquoi les managers ne peuvent pas donner ce type de conseils
- Si un manager conseille d’ignorer la politique de l’entreprise et que l’ingénieur l’applique mal (par ex. en publiant publiquement sur Slack que le manager l’a autorisé), les conséquences retombent davantage sur le manager
- Le leadership des entreprises tech a tendance à voir les ingénieurs comme des « useful idiots », et attend des managers un comportement professionnel
- Beaucoup de managers aimeraient donner ce genre de conseils, et si un ingénieur agit spontanément de cette façon, ils l’apprécient beaucoup
- Pour un manager, il est très frustrant d’encadrer un ingénieur solide qui serait bien plus efficace avec une approche plus stratégique du travail, moins enfermée dans la fiche de poste
L’essence des conseils dangereux : haut risque, haute récompense
- Suivre des conseils dangereux demande du courage
- Leur nature à haut risque, haute récompense les rend particulièrement utiles aux ingénieurs solides, et nuisibles aux ingénieurs plus faibles
- Il ne faut jamais les suivre si l’on ne s’y sent pas à l’aise ; mais si vous travaillez déjà ainsi tout en vous inquiétant d’erreurs à long terme, ce n’est probablement pas votre cas
Réactions sur Hacker News et dimensions illisibles de l’organisation
- Sur Hacker News, les réactions ont été à la fois très positives et très négatives
- L’erreur centrale des commentaires négatifs consiste à voir l’organisation comme un simple ensemble de règles codifiées, et à considérer que le mode principal de fonctionnement en son sein est une collaboration formelle et structurée
- C’est l’erreur que James C. Scott décrit dans Seeing Like a State comme une survalorisation de la lisibilité (legibility)
- Toute communauté comporte des éléments illisibles mais essentiels (load-bearing illegible)
- Réfléchir avec soin à cette part illisible dans son propre travail constitue l’argument central de cet article et du blog dans son ensemble
Aucun commentaire pour le moment.