- Les demandes floues des managers et des dirigeants peuvent sembler anodines, mais perturber fortement le temps de l’équipe, ses priorités et sa direction d’exécution
- Des formulations comme « peux-tu vérifier ? » ou « il faut que ce soit moderne » peuvent facilement dériver vers des réponses excessives : rapports, slides, travail le week-end ou mises à niveau de grande ampleur
- La personne qui formule la demande doit aussi préciser le temps attendu, l’impact sur les priorités, s’il faut vérifier des documents existants ou produire un nouveau travail, ainsi que l’usage prévu du livrable
- La personne qui reçoit la demande doit également redemander le niveau d’effort attendu et clarifier les zones d’ombre, sans supposer que le dirigeant est trop occupé pour répondre
- Être un peu trop explicite au départ peut sembler maladroit, mais cela réduit fortement la confusion, le travail mal orienté et le gaspillage de coûts en aval
Comment une petite demande se transforme en gros travail
- Dans les organisations, il arrive sans cesse qu’une demande courte et légère en apparence se transforme en une tâche bien plus importante que prévu
- Il existe des cas où un manager demande « peux-tu t’occuper de X ? », puis son report direct y consacre 10 fois plus de temps qu’attendu, avant que le manager ne réagisse en disant qu’il ne voulait pas qu’on y passe autant de temps
- Une remarque rapide d’un dirigeant en réunion, du type « tu peux vérifier ça ? », peut conduire 24 personnes à préparer 4 versions d’un deck de slides et à travailler jusqu’au week-end
- Alors qu’en réunion, le dirigeant peut se contenter de lire le résumé de la première phrase de la première slide et dire qu’il n’y a pas besoin de présentation complète
- La formule « il faut que ce soit moderne, sans excuses » peut aussi être interprétée comme une mise à niveau technique de grande ampleur si personne n’en clarifie le sens
- L’intention réelle peut n’être qu’une mise à jour progressive de la syntaxe d’API vers une nouvelle version sur plusieurs années
- Entre-temps, la sortie de projets importants peut être retardée
Ce que le demandeur doit définir en premier
- Un dirigeant doit indiquer explicitement la limite de temps attendue lorsqu’il fait une demande
- Exemple : « n’y passe pas plus de 20 minutes, et reviens dans 20 minutes avec ce que tu as »
- Il faut aussi préciser l’impact attendu sur les priorités
- Exemple : « je m’attends à ce que cela prenne environ 2 semaines, sans faire fortement baisser la priorité des autres tâches majeures »
- Il faut demander à être contacté immédiatement si le planning réel diffère ou s’il y a conflit avec d’autres travaux
- Il faut distinguer s’il suffit de vérifier des éléments existants ou s’il faut analyser ou produire quelque chose de nouveau
- Exemple : « dis-moi simplement si nous avons déjà quelque chose sur ce sujet. Si personne n’y a encore réfléchi, cette information me suffit pour l’instant »
- Indiquer l’usage du livrable aide l’autre personne à ajuster le niveau d’effort
- Exemple : une réponse à envoyer à un prospect commercial, une préparation au Q&A du prochain All Hands, ou un sujet clé du prochain conseil d’administration
Ce que la personne sollicitée doit vérifier
- La personne qui reçoit la demande doit poser des questions de clarification
- Il faut vérifier le niveau d’effort attendu, par exemple : « attendez-vous un résultat très approfondi qui demande plusieurs heures, ou un bref résumé ? »
- Poser la question ne fait pas paraître stupide ; le vrai risque, c’est de ne pas demander et de faire un travail complètement inadapté
- Au lieu de perdre du temps à interpréter l’email ou le message du dirigeant comme s’il s’agissait d’un artefact ancien, mieux vaut lui demander directement de clarifier
- Si un dirigeant a le temps de formuler une demande, il a aussi le temps de la clarifier
1 commentaires
Avis Hacker News
Ce que je déteste le plus, c’est quand un responsable non technique saute une ou deux étapes et s’adresse directement à du personnel technique junior au lieu de passer par des profils techniques seniors qui ont l’expérience nécessaire pour poser des questions de clarification et définir le calendrier ainsi que les livrables
C’est un schéma que j’ai souvent vu dans différentes organisations de campagne et structures de tech politique
Même les profils techniques juniors comprennent la chaîne de commandement, donc la casser, intentionnellement ou non, crée de la confusion et du chaos
La personne qui fait réellement le travail concret est souvent un ingénieur junior, et elle peut parfois mieux répondre à certaines questions que quelqu’un avec une vue plus haut niveau
On peut se demander s’il est vraiment nécessaire de jouer au téléphone arabe
Quand on réunit un coordinateur de projet d’un prestataire peu expérimenté, un technicien du prestataire habitué à ce que le coordinateur gère tout, et un client novice dans ce genre de situation, ça peut créer une sacrée confusion
À propos de l’idée que “si on ne pose pas de questions et qu’on fait quelque chose de complètement à côté, on a clairement l’air idiot” et qu’“il ne faut jamais supposer que l’autre est trop occupé pour répondre à des questions de clarification pendant le travail”, je me demande comment faire dans un contexte de travail à distance où le chat en ligne n’est même pas possible
En présentiel, il est facile de poser beaucoup de petites questions rapides et un peu brouillonnes, mais l’e-mail paraît plus formel et plus intrusif, donc il faut plus de temps pour expliquer ce qui bloque et anticiper les réponses possibles
Organiser un appel vidéo prend aussi du temps et a un coût de coordination non négligeable
Sur des projets client, j’ajoute chaque petite question dans un Google Doc, puis je demande de temps en temps au client de consulter le document, ou je lui fais suivre les notifications de modification
Le client écrit directement ses réponses dans le document, puis le travail avance et le processus se répète
Les avantages, c’est que le client n’a pas besoin de tout traiter d’un coup, qu’il y a moins de notifications, que les deux parties peuvent écrire de façon moins formelle, que cela donne une impression de collaboration, qu’il est facile d’ajouter des questions de suivi à côté de la section concernée, que les commentaires du document permettent de courtes discussions ainsi que l’assignation et le suivi de petites tâches, et qu’il est aussi facile pour d’autres personnes de lire et de contribuer
Je pense ici à des situations où surgissent beaucoup de petites questions, comme du travail sous contrat avec des clients non techniques qui ne connaissent pas bien le sujet
Les autres ne lui imposent pas ce genre de contraintes
À moins d’écrire au CEO, vous pouvez très bien noter vos questions au fil de l’eau et les envoyer immédiatement
Inutile d’avoir peur d’envoyer un deuxième e-mail juste après, du genre : “Ah, j’ai aussi oublié cette question. Merci ! $QUESTION”
Si vous regardez les e-mails de hauts dirigeants sur https://twitter.com/TechEmails, la plupart sont très informels
Certains vieux e-mails échangés entre Bill Gates et des dirigeants de Microsoft ne sont pas beaucoup plus structurés que des SMS de lycéens
Ça ne veut pas dire qu’il faut mettre des emojis dans un mail à l’N+4, mais un e-mail rapide et informel ne mettra pas fin à votre carrière
Je comprends que beaucoup de gens le ressentent plus fortement, mais je ne sais pas si c’est réellement plus pénible pour les deux parties
S’il faut un échange aller-retour pour clarifier la question, alors faites-le
L’approche du document partagé est aussi une bonne idée, avec deux avantages supplémentaires
Le simple fait d’écrire ajoute une étape qui aide à clarifier la question, et les questions comme les réponses sont documentées pour plus tard
Ce sont deux avantages majeurs par rapport à une conversation rapide qu’il faut ensuite retranscrire
Vous pouvez faire porter la charge cognitive à votre interlocuteur
Il vaut mieux interrompre quelqu’un une seule fois que plusieurs fois dans la journée
Quand je reçois un nouveau sujet, je le parcours d’abord, je planifie ce qu’il faut faire, j’explore mentalement les problèmes ou conflits potentiels, ce qui me conduit parfois à une énorme liste de questions, puis je répartis ces questions selon les personnes les plus susceptibles d’y répondre avant de lancer la discussion en ligne
En interne, il suffit généralement de demander un petit appel vidéo de cinq minutes via une messagerie d’entreprise comme Slack
Avec des collègues proches, il m’arrive aussi d’appeler directement sans prévenir
Avec des clients externes, on peut faire de manière similaire via un vrai numéro de téléphone ou un appel vidéo, si cela a été convenu à l’avance
Par exemple, lors de la réunion de lancement, on peut définir la fréquence de contact souhaitée par le client, ainsi que les questions qui nécessitent une communication immédiate et celles qui peuvent très bien attendre un échange asynchrone plus lent
Le temps est un très mauvais indicateur de substitution pour l’effort, la substance et le périmètre
Par exemple, face à une demande du type « regarde ça pendant 20 minutes, puis reviens avec ce que tu as au bout de 20 minutes », la quantité de travail accomplie en 20 minutes varie un peu d’une personne à l’autre
Même en ignorant cet écart, rien ne garantit que le manager à l’origine de la demande obtiendra ce dont il a besoin à partir de ces 20 minutes d’effort
En environnement agile, on appelle souvent le travail de découverte ou d’investigation un « spike » et on lui assigne une « timebox », mais quand on demande « que se passe-t-il si on ne découvre pas ce qu’on veut dans ce délai ? », il y a rarement une bonne réponse
En pratique, la timebox est prolongée jusqu’à ce qu’on trouve ce qu’il faut
Donc le temps est un mauvais indicateur indirect de l’effort, de la substance ou du périmètre
L’exemple cité plus loin dans l’article, « vous attendez quelque chose de très approfondi qui demande plusieurs heures, ou bien un rapide récapitulatif suffit ? », me paraît meilleur
Car on y parle du périmètre du travail, pas du temps nécessaire
Si on mesure en temps, rien ne garantit qu’on obtiendra ce qu’on veut dans ce créneau, et au final on finit par rajouter du temps
À la question « que se passe-t-il si on ne découvre pas ce qu’on veut dans ce délai ? », la réponse est qu’on apprend qu’on n’a pas pu trouver la réponse dans le temps prévu, et qu’on ajuste les attentes concernant l’effort nécessaire pour cette investigation
En tant que manager, c’est justement l’une des informations essentielles que je veux connaître
C’est pour ça qu’il faut timeboxer n’importe quoi si on veut éviter qu’un projet déraille et finisse à la poubelle
Cela vaut aussi pour le travail individuel ou en solo
On peut s’accrocher indéfiniment à n’importe quel sujet, donc il vaut bien mieux se forcer à un point d’arrêt, obtenir du feedback ou mettre en production, puis décider si cela mérite qu’on continue
Le mécanisme en jeu ici consiste à forcer les gens à hiérarchiser les priorités
Si l’on est très bon pour arbitrer les priorités, on a peut-être moins besoin de timebox, mais même dans ce cas, sans timebox il peut être difficile de résister à la tentation de continuer à travailler jusqu’à un niveau de qualité supérieur à ce qui est réellement nécessaire
Ce mode de travail est utile quand il y a beaucoup plus d’inconnu que de connu
L’objectif n’est pas de faire des suppositions au doigt mouillé, mais d’augmenter progressivement la part de ce qu’on “sait” suffisamment pour faire des hypothèses éclairées
Par exemple, s’il y a un bug dans une base de code legacy, qu’un système de remplacement est presque terminé et doit sortir dans deux mois, comment traiter ce bug ?
On pourrait l’ignorer, ou dire à quelqu’un « corrige-le coûte que coûte », mais aucune de ces options n’est bonne
On dit donc : « enquête sur ce bug, sans y passer plus d’une heure, puis dis-moi où tu en es »
Une fois terminé, on comprend mieux la forme du problème
Si la personne revient en disant « j’ai trouvé la zone du problème, mais il faudra le résoudre avec quelqu’un qui connaît bien la logique métier », on peut alors affecter les bonnes ressources et aller vers un correctif
Si elle dit « c’est dans cette partie du code, c’est plutôt propre, mais je n’ai pas encore complètement remonté la piste », on peut lui accorder plus de temps en ayant confiance que ce ne sera pas un énorme chantier
À l’inverse, si elle dit « c’est quelque part dans ce spaghetti immonde ; j’ai regardé dedans, l’abîme m’a regardé en retour, j’en ai eu des frissons dans le dos et les tableaux sur les murs pleuraient des larmes de sang, alors ne m’y renvoyez plus », il devient clair que cela ne vaut pas la peine de creuser davantage et qu’on peut laisser tomber
Je veux bien croire que vous avez vécu des situations où, faute d’obtenir ce que vous vouliez dans le temps imparti, on a simplement ajouté plus de temps, mais ce n’est pas universel
Le problème tient au fait de traiter « ce qu’on veut » comme si c’était l’objectif final
C’est pourquoi l’article dit aussi « dites pourquoi c’est nécessaire »
« Notre plus gros client doit le savoir avant de renouveler son contrat » mérite qu’on y consacre plus d’argent et plus de temps salarié que « je me demandais juste »
Au niveau du leadership, il faut comprendre qu’on ne peut pas poursuivre tous les bénéfices possibles, et se concentrer stratégiquement sur ce qui offre le meilleur rapport coût/bénéfice
Il ne s’agit pas seulement d’affecter quelqu’un à une tâche, mais aussi d’assigner le bon travail à la personne qui a les compétences appropriées
Le CEO d’une startup a demandé quelque chose, et la demande semblait n’avoir fait qu’une ou deux phrases
Résultat : un rapport de 14 pages a été produit, après plusieurs heures de travail, en grande partie sur du temps personnel
Le rapport a été envoyé au CEO, mais il n’y a ensuite eu aucune réponse et il ne s’est rien passé
La personne s’est ensuite fixé une nouvelle règle
Le coût d’une demande doit être proportionnel au coût nécessaire pour la formuler
Désormais, lorsqu’elle reçoit une demande coûteuse, elle attend, la retarde et exige une escalade
La personne à l’origine de la demande doit faire sa diligence, obtenir l’approbation d’un niveau supérieur et montrer que cela vaut le coût
Si c’est une demande absurde, on n’en entendra plus parler ; si c’est une demande valable, elle sera traitée, avec l’avantage supplémentaire que l’effort ne se fera pas en douce, sans visibilité appropriée
Premièrement, je ne fais absolument rien à la première demande
Si c’est important, la personne redemandera, et c’est à ce moment-là que j’y réfléchirai
Deuxièmement, si je dois faire des heures sup, l’autre aussi
Si l’autre ne veut pas faire d’heures sup, c’est que ce n’était pas si important que ça
Après avoir occupé plusieurs positions en ingénierie, de junior jusqu’au niveau C, j’ai appris quelques choses
Premièrement, tout le monde doit agir de bonne foi
J’ai vu des leaders demander quelque chose à un subordonné direct sur un coup de tête, sans y réfléchir ne serait-ce que 5 secondes, et à l’inverse j’ai vu des subordonnés directs qui ne bougeaient que si on leur donnait une syntaxe exacte, comme une « ligne de commande humaine »
Aucun des deux ne convient
Deuxièmement, il n’existe pas de « demande ponctuelle » pour un manager ou un leader
Toute demande reçoit implicitement une priorité au-dessus de tout le reste
Il faut agir en tenant compte de l’ensemble du système et de son contexte, sinon on force l’équipe à faire ce choix à sa place
Troisièmement, quand on est du côté de la personne qui reçoit la demande, il faut aider le demandeur à comprendre ce dont il a besoin
Il faut éliminer les hypothèses implicites, car c’est là que se cache le dragon
Il faut communiquer, informer, enseigner, préciser ce que veut le demandeur et vérifier que les deux parties sont d’accord
Ce genre de situation naît souvent d’une volonté d’efficacité, pour ne pas perdre de temps si ce n’est pas nécessaire, mais quand le demandeur et le destinataire essaient de s’entraider, la vie devient généralement bien plus supportable
Il y a un contraste saisissant entre un leader qui pousse sans cesse les limites de ce qu’il peut se permettre et un leader qui cherche à construire une relation de bonne foi avec son équipe
Un manager qui accumule les exigences irréfléchies finit inévitablement par perdre ses meilleurs éléments
D’après mon expérience, avec suffisamment de temps, il ne reste plus que des juniors sous ce type de leader, car les personnes expérimentées évitent cette équipe
Le coéquipier « ligne de commande humaine » est lui aussi un bon exemple d’attitude de mauvaise foi
J’ai travaillé avec des gens qui exigeaient que la moindre petite demande ne puisse commencer qu’après avoir rempli leur propre formulaire ou document, puis qu’on débatte, critique ou fasse circuler la demande pendant des jours avant même de réfléchir à la petite tâche en question
Ils croient s’être protégés des petites demandes en décourageant quiconque de faire l’effort de formuler correctement une question, mais avec le temps ils se construisent surtout une réputation de personnes difficiles à faire travailler avec les autres
Une autre variante, c’est la personne qui exploite l’ambiguïté de toute demande
Elle comprend globalement ce qui est demandé, mais pour « donner une leçon », elle livre un résultat qui correspond littéralement à la demande tout en sachant que ce n’est ni ce dont tout le monde a besoin ni ce que tout le monde voulait
Sans surprise, la plupart des gens que j’ai vus jouer à ce petit jeu ont été licenciés au cours de l’année écoulée
On peut tolérer un temps un mauvais collègue qui fait quand même un peu de travail, mais au moment des réductions d’effectifs, il monte tout en haut de la liste des personnes à supprimer
Il y a un mois, en tant que leader, j’ai pris conscience d’un échec que je reproduisais
En apparence, mon intention était de donner à l’équipe un sentiment d’appropriation et je déversais sur elle tout un tas de choses à faire, mais en réalité je lui transférais le stress du « que faut-il faire, ici et maintenant ? »
C’est un piège subtil qui rend très facile de se dire « j’accorde énormément d’autonomie à l’équipe ! », alors qu’en réalité on la stresse et on réduit sa capacité de concentration
askest passé d’un vieux verbe à un nom moderne, à la mode et maladroitSelon l’OED, cette substantivation viendrait de l’anglais familier australien
https://www.oed.com/search/dictionary/?q=ask
On sait tous qu’il n’existe pas vraiment de règles, puisque la langue est un produit bio-social et cognitif en évolution constante, mais cet usage reste agaçant, comme mâcher du sable, alors qu’il existe déjà de très bons synonymes
Je ne voulais pas que cette information influence la décision
Je pensais qu’il fallait faire ce qui était le mieux pour l’entreprise et pour l’utilisateur final, pas ce qui était le plus facile pour moi
Mais l’autre personne a choisi l’option la plus longue et la plus difficile, et j’ai appris plus tard qu’en réalité elle voulait l’autre, mais pensait que ce serait plus difficile pour moi
La même chose arrive dans la vraie vie
Quand je fabriquais de nouveaux placards de cuisine, j’ai proposé à ma femme deux options pour le rail supérieur des portes sans dire que l’une était plus difficile, parce que je voulais qu’elle choisisse ce qu’elle préférait
Bien sûr, elle a choisi l’option la plus difficile, pensant que ce serait la plus simple, alors qu’en réalité elle préférait l’autre
Il faut donc toujours donner à l’autre toutes les informations
Pourquoi ne pourrait-on pas dire qu’une question lancée par la direction n’a aucun sens ?
La réponse, bien sûr, c’est qu’on n’ose pas aller à l’encontre de la hiérarchie
Mais cette soumission à la hiérarchie n’aide pas réellement l’entreprise
Cela ressemble à une valeur dont on devrait pouvoir se débarrasser plus facilement
La question « vous attendez quelque chose de très approfondi, ou bien un rapide résumé suffit ? » est drôle
Si un ingénieur dit honnêtement à un non-ingénieur combien de temps quelque chose prendra, le non-ingénieur sera choqué et dira non
La demande « n’y passe pas plus de 20 minutes, et au bout de 20 minutes apporte ce que tu as » paraît délirante
Il n’existe pas de tâche qui prenne 20 minutes
Autant dire plutôt « ne regarde même pas ça, va prendre un café et reviens me faire une estimation à la louche »
Nous faisons un travail complexe et nous avons besoin de temps pour réfléchir
Si l’on ne veut pas que nous prenions du temps pour réfléchir, alors il ne faut tout simplement pas demander
Une partie du problème, c’est qu’on n’a ni envie de dire à son chef d’aller se faire voir, ni envie de lui dire qu’on a passé 6 heures sur quelque chose qu’il croyait être une tâche de 20 minutes
Alors, à la place, tout le reste prend du retard
C’est pourquoi un bon management de l’ingénierie tient les ingénieurs aussi loin que possible des personnes qui, sans le vouloir, vont siphonner l’attention des techniciens
Un signe typique de management faible consiste à exiger des rapports ou à assigner des tâches dont on ne comprend pas soi-même toutes les implications
Un signe typique d’ingénierie faible consiste à répondre « oui » à cette demande
Quand un mauvais manager demande quelque chose qui dépasse ce qui pourrait être traité comme un détail, la personne chargée du travail doit, selon le contexte technique et social, faire l’une des trois choses suivantes
A) Demander : « Comment faut-il faire ? »
Cela fonctionne quand le manager est lui-même technique et lance vaguement le travail pour compenser sa propre incompétence technique
Si on lui renvoie ses absurdités telles quelles, il se retrouve face à la réalité de l’ampleur de ce qu’il demande et des mécanismes impliqués
B) Indiquer : « Ce travail nécessite X ressources. Quelles sont les attentes ? »
Ici, X peut être n’importe quoi : un volume énorme d’heures-personnes, de l’argent, de vieux GP de RuneScape, etc.
C’est adapté à un manager non technique et, comme dans A, cela l’oblige à reconnaître qu’il ne s’agit pas de quelque chose à approuver sur le moment, mais d’une grosse demande qui doit suivre une procédure normale
C) Dire : « Non »
Ce n’est pas possible dans toutes les organisations ni dans tous les contextes sociaux, mais les organisations très performantes rendent cela possible
Dans un environnement d’ingénierie très performant, l’organisation d’ingénierie dispose d’un fort droit de veto contre les tâches absurdes et inutiles, qui ne peut être annulé qu’au niveau de la direction C-level
Savoir quand et comment exercer ce veto est aussi une compétence importante que l’ingénierie doit développer
Du coup, quoi qu’on dise à ce sujet, cela pouvait finir par vous pousser vers la sortie
Chaque fois que je vois “ask” utilisé comme nom, mon sens de la langue tique, alors j’ai cherché et je suis tombé sur ce billet
https://english.stackexchange.com/questions/4246/can-or-shou...
Cela peut aider d’autres personnes que ça agace de la même manière
L’absence de contexte dans une demande est l’une des plus grandes pertes de temps
On a l’impression qu’on essaie de gagner du temps en n’informant que les personnes nécessaires, mais le « pourquoi » et le contexte sont vraiment essentiels pour trouver une bonne solution
Sans cela, on ne peut pas savoir à quoi l’autre a déjà réfléchi
Par exemple, si on dit « il faut bloquer les requêtes venant du pays X », ce n’est pas très difficile avec la plupart des services de pare-feu
Mais pourquoi faut-il le faire ?
Si c’est pour fournir une garantie contractuelle qu’aucun trafic ne provient d’un pays donné, cette approche ne fonctionne pas, puisque n’importe qui peut contourner la détection du code pays en deux minutes avec un VPN
L’utilisateur veut faire X mais ne sait pas comment, pense que Y va marcher et demande donc de l’aide sur Y, tandis que les autres sont déconcertés parce que Y leur semble étrange
https://xyproblem.info/
Beaucoup de gens sont déjà morts sur cette colline, et malgré tout cela a été implémenté
Mieux vaut ne pas devenir une victime de plus
Au final, cela dépend beaucoup de la culture d’entreprise et du degré de liberté qu’ont les gens pour contredire un dirigeant senior
Cette responsabilité incombe aux dirigeants seniors, qui doivent faire en sorte qu’il soit facile pour les personnes en dessous d’eux de répondre et de contester
D’après mon expérience, les meilleurs dirigeants font preuve d’humilité et d’une volonté d’écouter
Cela dit, faire du travail inutile fait parfois aussi partie du métier
Si c’est trop fréquent, il faut bien sûr chercher autre chose, mais il vaut mieux éviter de devenir quelqu’un qui soupçonne systématiquement la direction et remet toujours ses demandes en question