Pour cette semaine, j'ai voulu tenter un autre format. La réflexion que je me suis faite c'est qu'à force de parcourir des liens, je commençais à voir quelques sites qui me paraissaient pertinent au delà de l'article qui m'y avait attiré. Et que lorsque je tombe sur un tel site, en donnant plus de détails et publications je pourrais, peut-être, vous donner envie de vous y abonner par flux rss / mail ou tout autre moyen de publication qu'il rendrait disponible.
Le site de cette semaine est CommonCog. Il se décrit comme tel :
Commoncog is a blog about better business and career decision making.
That's a snappy way to say that the blog is about anything that might help you make better decisions in business (from the perspective of an operator, natch), or in your career.
En parcourant plusieurs de ses articles, j'ai découvert bien plus que ça comme la performance opérationnelle, l'appropriation de modèles mentaux, des postures, … L'auteur a aussi une formation de développeur ce qui l'amène parfois à illustrer ses sujets avec des exemples qui parlent à un public sensible au domaine. Je trouve que ses articles sont bien rédigés et accessibles, mais peuvent parfois être longs.
Si les articles ci-dessous vous inspirent, vous pouvez le suivre par flux RSS, twitter, newsletter, et il existe même un podcast !
I played Judo very competitively when I was younger. For about two years when I was 18, my entire life was school, training and sleep. The only problem was that I wasn’t very good at it. I had it in my head that the only Judo worth playing was a ‘Japanese’ style of Judo — an upright, dynamic, beautiful style. No other style, I thought, was worth looking at — not Georgian, not Mongolian, not even French.
[…]
I wished I’d learnt this alternative view of competition earlier in my life. As a competitor, I didn’t think very deeply about the constraints that I was facing, and I didn’t have a coherent strategy to win. I simply thought to myself: “Ahh, the Japanese play beautiful Judo. That’s the best form of Judo, and the only form of Judo worth playing. I want to be like that.” And then I refused to look at other styles.
I was, in other words, a scrub.
J’ai appris des trucs : La notion de scrub, le concept de Shepardizing qui est totalement la bonne description de ma méthode pour vous alimenter en liens (cela il y a une première étape quasi instinctive pour sélectionner le premier article source, et je tenterai de l’expliciter par la suite), et j’ai remis en perspective mon approche dans les jeux, en mission, et dans la vie en général (ce n’est que le début de la réflexion).
There’s an old English proverb about leading a horse to water — a proverb that has been in continuous use since the 12th century. Given what we know of how humans learn, we could presumably adapt this saying to more modern concerns: something like “you can lead a student to a mental model, but you can’t get it to take”.
[…]
In the past, when I trained my teammates in Vietnam to understand decorators in Python, or blocks in Ruby, I often came up across the same, uncrossable conceptual chasm. I used to say things like “give it some time”, or “wrestle with it for a little longer”, in the hopes that continuously bashing one’s head against the conceptual wall would lead to an eventual leap in understanding.
Papert suggests something better. From his point of view, because all knowledge is constructed, the best way to teach would be to give a student a series of progressive exercises designed to correct their existing mental models.
C'est une question constante que je me pose quand j'écris un article : comment amener le lecteur des modèles mentaux qu'il possèdent vers celui que je suggère. Et ça implique tellement de choses :
Quand je me relis aujourd'hui je me dis que la route est encore longue. De façon assez frustrante, je trouve que lorsque j'accompagne quelqu'un, ces étapes peuvent être à la fois faciles à évaluer au cours d'une discussion avec la personne (un public précis qui partage son modèle de façon plus ou moins explicite et un discours qu'on peut adapter à la volée), et facile à oublier en cours de route (pression du contexte, changements d'humeur, …).
At the beginning of 2019, I wrote a series on Putting Mental Models to Practice. That series was an actionable summary of the judgment and decision making literature, and existed as a constructive alternative to my criticism of mental model writing in The Mental Model Fallacy.
This post is a shortened version of the conclusions in my mental models series
[…]
I am a programmer by training. When I read a codebase, I build a mental model of the program in my mind. My brain’s chosen representation is a set of blocks that ‘interface’ with each other. A close friend tells me that his representation is a set of pipes that carry data throughout the program. Our brains may choose different analogues, but the point here is that they are physical in nature, and individually constructed.
[…]
To state this another way, you cannot learn the mental models of experts by studying the frameworks they teach. You must construct it for yourself through practice — perhaps by using their utterances as a guide — but ultimately your own competence has to be built on what you already know.
So, yes, mental models are incredibly useful. If nothing else, they tell you that the valuable bits of expertise is not what is communicable, but what is tacit and stuck inside the practitioner’s head.
[…]
In academia, the cognitive biases and heuristics tradition that was pioneered by Kahneman and Tversky seem particularly well-suited to probabilistic domains (book recommendation: Thinking: Fast and Slow). The naturalistic decision making field is better adapted to regular domains (book recommendation: The Power of Intuition). I sample both in my series, and continue to believe that both domains contain techniques that are useful to the career-minded individual.
Je suis initialement tombé sur ce blog par un article beaucoup acide / coup de gueule, qui m'a parlé et à la fin m’a emmené sur une série plus constructive qui m’ouvre encore un peu plus les yeux sur la façon de transmettre et d’apprendre. Cet article est un aperçu déjà bien pertinent de cette série qui vous dira assez vite s’il y a matière à lire des parts de cette série.
Ça touche complètement cet espace souvent indisponible que l’on rencontre en mission de conseil, le temps de répéter des gestes pour transmettre au lieu de larguer des livrables et grands discours. Et j’ai la satisfaction supplémentaire à travers cet énième témoignage de me dire que j’avais eu raison de suivre mon intuition en n’écoutant pas ce que mes profs avaient pu me répéter (et qui je le reconnais n’était pas adapté au milieu scolaire), et qui avait été bien synthétisé sur un bulletin par : « Julien se repose trop sur son intuition ».
I’m writing about Deming’s overall philosophy here because of a fundamental tension I’ve noticed the more I’ve dug into his work: the data tools and statistical methods he popularised can and have been used to produce amazing business outcomes with horrible human costs. But the man himself espouses a philosophy that is deeply humanistic in nature. You could argue that his methods are used to produce the former outcomes mostly by ignoring his latter ideas. But I’m not sure how true this is, and I’ll get to that in a bit
[…]
I have a couple of big, unanswered questions at this point. The biggest is whether any company has successfully implemented the entirety of Deming’s business philosophy — both the data driven, operationally rigorous parts, as well as the humanistic, “treat all workers with joy and respect” part, and gotten it all to work. Since Deming’s ideas have found the most acceptance and implementation in Japan, I figure I’ll have to dig into the histories of various Japanese auto companies, which I don’t know a great deal about.
[…]
But it so happens that there is a famous Western company that has adopted Deming’s business philosophy wholesale. That company is Koch Industries, and reading about Deming in Christopher Leonard’s Kochland was perhaps the first indication to me that this entire Deming thing wasn’t some odd management cult from an obscure business guru.
Le début d'un article à suivre, comme l'auteur je n'avais pas cette dimension humaine en tête, et les impacts de la "rigueur opérationnelle" me font également réfléchir à d'autres méthodes/théories/frameworks poussés pour la performance. Dernière en date à laquelle j'ai souscri : Accelerate. L'étude précise qu'elle se préoccupe du bien-être des opérationnels, et explique que le suivi des indicateurs en suivant certains des outils prescrits réduirait les chances de burn-out. Cela dit, Accelerate clame aussi un lien avec PDCA, la roue de Deming. Je me demande à quelle point les objectifs de ce framework sont en opposition, à quel point la réduction du burn-out est seulement possible en suivant le même fondement. L'étude possède-t-elle des blindspots sur le sujet ?
Je n'ai pas creusé plus loin les différents papiers que Nicole Forsgren et ses collègues ont sorti jusque là, mais dans les dernières annonces est apparu :
Ces deux pages sont plutôt courtes. Ce que je vois cependant c'est que le focus a dévié sur la qualité de travail des développeurs, un aspect moins élaboré dans Accelerate ou les State Of DevOps qui ont suivi, avec d'abord un axe propre au bien-être, puis un focus sur les effets de l'environnement de travail. Ces papiers ne résolvent pas la contradiction potentielle entre le bien être et la roue de Deming, et je ne retrouve pas un aspect qui couplait les métriques Accelerate et devaient garantir la "solidité" du modèle, c'est à dire que ces axes/métriques ne sont pas "en tension", c'est à dire couplé. En somme on pourrait suivre une partie en ignorant le bien-être. Mais de toute façon, quel modèle ne peut être détourné. Le problème est ailleurs.
Alors au final, est-ce un format intéressant ? Si oui est-ce qu'il donne envie de suivre le site proposé, et sinon est-ce réellement un problème ?
J'ai également pris pour habitude de proposer 4 liens, mais est-ce trop ? Ou cela convient-il ?
N'hésitez pas à me partager quoique ce soit, en réponse à ce mail, par messagerie instantanée, carte postale, … (oubliez le fax).
