Comprendre comment fonctionne son organisation - Historique des versions

Justine le 22 juin 2022 à 12:12

2022-06-22T12:12:37Z

← Version précédente		Version du 22 juin 2022 à 12:12
Ligne 1 :		Ligne 1 :
			[[Category:misc]]
	= Comment ça ? =		= Comment ça ? =
	[https://copyconstruct.medium.com/know-how-your-org-works-or-how-to-become-a-more-effective-engineer-1a3287d1f58d Un article intéressant que je vais en bonne partie traduire ici]		[https://copyconstruct.medium.com/know-how-your-org-works-or-how-to-become-a-more-effective-engineer-1a3287d1f58d Un article intéressant que je vais en bonne partie traduire ici]

Justine le 10 janvier 2022 à 17:56

2022-01-10T17:56:45Z

← Version précédente		Version du 10 janvier 2022 à 17:56
Ligne 52 :		Ligne 52 :

	Ce sont des choses à considérer avant de proposer des changements (importants) au système. Savoir comment et pourquoi notre orga prend des décisions techniques est un pré-requis non négociable.		Ce sont des choses à considérer avant de proposer des changements (importants) au système. Savoir comment et pourquoi notre orga prend des décisions techniques est un pré-requis non négociable.

			== Cultures : de haut en bas, de bas en haut, et les deux à la fois ==
			Quoi qu'il en soit, la plupart des organisation ont une culture du type top-down, ou bottom-up, ou les deux à la fois; aucun n'est meilleur que l'autre.

			Une culture top-down signifie que les décisions les plus importantes sont prises en haut de la hiérarchie; la personne qui prend la décision finale peut être un dir tech, un manager, etc. Ici, notre succès repose sur le fait de savoir manager avec les gens du dessus. Cela implique plusieurs choses avec eux :
			* Sont-ils sur la même longueur d'ondes que nous ? Et sinon, saurons-nous leur faire comprendre l'importance et l'urgence de nos problèmes ?
			* Leur réflexion est-elle influencée par des informations que nous ne possédons pas ? Comment obtenir cette information ?
			* Partageons-nous la même vision sur le coût des opportunités ?
			* Quels sont leurs biais implicites ou explicites, leurs angles morts, et pouvons-nous nous en servir ?
			* Quelles sont les choses qui sont favorables à leurs yeux ? Quel genre de travail ou d'attitude les impressionne ?
			* Sont-ils attachés à certaines méthodologies que nous pouvons valoriser ?
			* Avec quels genre de temporalités sont-ils à l'aise (un jour, un mois, un an) ?
			* Leur fait-on confiance ?
			* Qu’est-ce que le succès selon eux et comment le mesurent-ils ? En particulier pour les travaux en cours ?
			* Comment gèrent-ils les retards ? Ont-il un plan dans ce cas ?
			* Comment gèrent-ils l'échec ? En prennent-ils la responsabilité ou prennent-ils des boucs émissaires ?
			* Ont-ils une culture du post mortem blameless pour les projets à grande échelle ? Les leçons sont-elles discutées et partagées ?
			* Quelle est leur expérience précedente quand il s'agit de travailler avec des partenaires ?
			* Quel est leur passif ?
			* Sont-ils appréciés, respectés dans l'organisation ?
			* Ont-ils une aversion au conflit, ou un attrait pour celui-ci ?

			Connaître la réponse à ces questions peut nous aider à comment identifier les problèmes, proposer des solutions, et avoir un impact significatif.

			Dans une culture bottom-up, il faut manager vers le haut et latéralement (soit avec les gens de notre niveau hiérarchique). Cela inclue les faits suivants :
			* Comment construire un consensus parmi nos pairs sans autorité ?
			* Comment briser les barrière entre les personnes ?
			* Comment remédier aux conflits sans autorité médiatrice ? Se base-t'on sur des détails factuels (chiffres) ou nébuleux (lui je l'aime bien, lui je l'aime pas) ?
			* Si les idées viennent d'en bas, quelles sont celles qui arrivent en haut ?
			* Peut-on prototyper des idées pour les pitcher (solutions techniques) ? Peut-on le faire pendant le travail ou faut-il le faire en dehors ?
			* Le problème sur lequel je bosse a-t'il déjà été abordé avant ? Comment ça s'est passé, quels ont été les problèmes ? As-t'on une idée de leur cause ? Comment les éviter ?
			* Coût d'opportunité ? Comment convaincre nos pairs que qq chose mérite d'être résolu si cela n'as jamais été priorisé avant ?
			* Quelle influence as-t'on ? Sur notre équipe, d'autres équipes, l'organisation entière ? Des gens hors de notre équipe sont-ils prêts à tester notre solution ?
			* Comment faire adopter nos idées dans toute l'orga ?
			* Peut-on enrôler d'autres personnes dans nos efforts, ou dans la promotion de celle-ci ?
			* As-t'on des relations avec les actionnaires ? Nous font-ils confiance ?
			* Comment convaincre des gens qui ont eu une mauvaise expérience avec nous ou notre équipe par le passé ?
			* Comment augmenter sa crédibilité ?
			* Quel est le coût d'un échec ? Qui serait impacté ?
			* Quels sont les problèmes culturels que l'on perçoit ? Comment les régler sans autorité ?

			Beaucoup d'organisations mélangent ces deux modèles. Il faut alors mélanger les stratégies.

			== Être à l'aise avec le bordel ==
			La plupart des orgas récompensent les gens qui font des trucs (get things done).

			Il y'a plus de chances de rencontrer un système qui a évolué dans le temps, avec une mauvaise documentation, peu de tests, etc... Que de rencontrer un système bien documenté, bien testé. Nous serons alors bien plus productifs si nous apprenons à naviguer dans ces eaux troubles (et c'est plus facile à dire qu'à faire...). Cela inclue les points suivants :
			* Savoir amasser juste les informations dont on a besoin pour accomplir notre tâche
			* Comment ne pas (trop) s'empêtrer dans le système (sauf quand c'est nécessaire)
			* Comment lire beaucoup de code rapidement et avoir une idée de ce qu'il fait (NB : c'est trop vague, trop orienté dev)
			* Comment formuler des hypothèses et les tester avec des outils généralistes pour les valider ou les rejeter
			* Savoir reproduire rapidement des bugs sans avoir à élaborer des configurations locales (NDT : vraiment ? Ça me paraît peu réaliste)

			Ce ne sont pas des choses que l'on apprend dans les études, et on ne parles pas souvent du fait de savoir naviguer dans des systèmes bordéliques; tout le monde préfère rabâcher l'importance de la documentation et des tests (ce qui est vrai, par ailleurs). Mais savoir l’ambiguïté et le bazar permet d'améliorer notre productivité. Note personnelle : certains de mes collègues sont très forts là-dedans, et leur principale méthode semble être de découper les problèmes de façon nette et un peu arbitraire. On a pas le temps de tout remonter dans l'immédiat, alors on patche le problème en question et sinon, on verra plus tard.

			Cette idée de savoir naviguer dans le brouillard s'applique aussi en terme d'environnement social. On a des chances de rencontrer :
			* Des niveaux techniques variés, et des capacité de livrer ce qui est promis tout aussi variées
			* Des structures récompense / motivation variées et parfois opposées
			* De la variabilité dans le goût du risque et du changement
			* Des philosophies différentes
			* Des capacités à supporter l'échec différentes
			* Des volontés d'investir différentes

			Il faut alors rapidement apprendre le modèle de l'organisation pour savoir y naviguer. Notre idée personnelle des choses pourrait ne pas coller, et il faut savoir trouver notre propre intérêt.

			Bref, soyons à l'aise avec le bordel, et respectueux des autres.

			== Rechercher les petites victoires ==
			C'est vraiment long de comprendre la structure sociale et politique d'une organisation, plus que de connaître une base de code ou une infra. Pour être crédible, il faut démontrer un certain degré d'impact rapidement. Il est important de chercher les victoires faciles.

			== Comprendre les contraintes de notre organisation, gérer nos attentes ==
			Il faut comprendre que les managers ne peuvent parfois pas aller très loin pour ce qui est de résoudre les problèmes profonds d'une organisation. Si l'on prend les problèmes d'inclusivité par exemple, il est très rare de trouver une solution en mode "bottom-up". Une entreprise sérieuse sur le sujet aura des compensations pour ses exécutifs sur le sujet.

			Il n'est pas utile de demander aux travailleurs ou même aux managers de résoudre ce problème par eux-même, sans approbation de toute la chaîne au-dessus (idéalement, ils faut en tenir compte dans leur performances). Il faut savoir être réalistes quant à nos attentes sur un sujet comme ça, même si l'on est passionné(e).

			Cela s'applique à beaucoup de problèmes du type de ceux qui nécessitent un changement à grande échelle. Si l'on a pas été embauché pour ça (à un niveau exécutif), il faut se méfier des projets qui promettent ce genre d'améliorations.

			Cela ne veut pas dire que l'on ne peut pas agir sur les problèmes profonds; mais l'approche doit alors être incrémentale. C'est plus facile d'ailleurs d'identifier les victoires incrémentales quand on connaît les ficelles de la culture de notre orga.

			Cela s'applique aussi sur le sujet des promotions, souvent par les travailleurs comme opaques. Ce process est ce qu'il est car il va dans le sens de l'organisation, et pas dans le nôtre. C'est pour ça qu'il faut comprendre ses attentes et son fonctionnement.

Justine le 7 janvier 2022 à 10:03

2022-01-07T10:03:28Z

← Version précédente		Version du 7 janvier 2022 à 10:03
Ligne 26 :		Ligne 26 :

	Ce n'est pas une bonne idée de protéger les juniors de cela; cela diminue leurs visibilité sur ces talents (je traduirais ici skills par talents) pour lesquels il n'y a rien de tout prêt. Ils auront par la suite à les apprendre à la dure; certains managers et autres n'en parlent pas aux juniors pour qu'ils "puissent se concentrer sur leur travail" - c'est une erreur.		Ce n'est pas une bonne idée de protéger les juniors de cela; cela diminue leurs visibilité sur ces talents (je traduirais ici skills par talents) pour lesquels il n'y a rien de tout prêt. Ils auront par la suite à les apprendre à la dure; certains managers et autres n'en parlent pas aux juniors pour qu'ils "puissent se concentrer sur leur travail" - c'est une erreur.

			= Développer nos "soft skills" (au secours) =
			Ces talents sont assez vastes, et dépendent de chacun; en l'occurence, je n'ai que le point de vue de Cindy Sridharan, l'autrice du post cité en source. Il est facile d'apprendre tant que l'on sait quoi apprendre, comment l'apprendre, et que la réponse ne change pas dans le temps (comme avec des connaissances techniques).

			Savoir comment fonctionne une organisation est un constant voyage dans l'inconnu, en particulier pour ce que l'on croyait savoir et qui n'est plus d'actualité.

			Il est également important de savoir prendre une décision alors que l'on a pas toutes les pièces du puzzle, ce qui nous aide aussi à savoir comment récupérer les informations manquantes, et à savoir comment s'en sortir sans le faire.

			On peut développer nos talents en parlant à des gens, en inférant par l'observation, et parfois le seul moyen est de faire des erreurs. Une organisation qui aurait la culture de l'apprentissage constant ne découragerait pas la visibilité dans les erreurs - mais il faut savoir si notre organisation fonctionne ainsi, en l'occurence.

			== Comprendre les hiérarchies implicites et les opinions influentes ==
			La majorité des organisations ont une structure formelle - un président en haut, et cela redescend; nous ne sommes qu'une feuille de cet arbre.

			Mais la plupart des organisations tendent aussi à avoir une structure informelle, surtout chez les non-managers. Il peut être facile de deviner quels sont les membres les plus influents en regardant les noms des postes et les niveaux; mais parfois, c'est implicite et beaucoup plus dur à deviner. Cela peut être une question d'ancienneté. Sinon, c'est plus arbitraire (expertise d'un sujet, expérience avec l'open source, emplois précédents). Il est important d'avoir cette hiérarchie à l'esprit car elle peut influencer notre travail, peu importe notre titre, notre niveau, etc.

			Un ingé qui manie cette influence tend en général à être senior, et aussi à avoir une forte opinion, voir une philosophie sous-jacente. Ces opinions, cette philosophie qu'il manie peut avoir influencé jusqu'à la façon dont il code, les outils qu'il utilise, les choix technologiques, les choix de sujets, etc.

			Ces philosophies et opinions peuvent finir par influencer nos efforts sur le système existant. Et à moins de comprendre pourquoi les choses sont comme elles sont (et tout bordel a sa méthode), toute proposition de "comment" que nous pourrions avoir serait vouée à percuter tout le reste, la rendent difficile à accepter. De plus, cela dirait de nous que nous ne prenons pas le temps de comprendre l'histoire du système - ce qui baisserait notre indice de confiance.

			Nous devons donc nous concentrer sur:
			* Comprendre la hiérarchie implicite
			* Identifier les gens qui ont une influence implicite et comprendre leur façon de penser, leur philosophie globale (en leur parlant, en regardant ce qu'ils ont fait, en lisant des choses qu'ils auraient écrites, etc)
			* Identifier comment les philosophies sus-nommées ont eu du succès par le passé sur les projets et les équipes. Pourquoi ces efforts ont étés considérés comme un succès ? Quels problèmes ont-elles solutionnés, lesquels n'ont-elles pas solutionnés ?
			* Comment augmenter sa crédibilité auprès d'eux ? Peut-on se reposer sur nos travaux du passé ? Notre expertise ? Notre historique ? Est-ce que qu'une personne en qui ils ont confiance peut se porter garant pour nous, afin qu'ils acceptent de faire des choses à notre manière ?

			Ce sont des choses à considérer avant de proposer des changements (importants) au système. Savoir comment et pourquoi notre orga prend des décisions techniques est un pré-requis non négociable.

Justine : Page créée avec « = Comment ça ? = [https://copyconstruct.medium.com/know-how-your-org-works-or-how-to-become-a-more-effective-engineer-1a3287d1f58d Un article intéressant que je vais en… »

2022-01-07T09:34:20Z

Page créée avec « = Comment ça ? = [https://copyconstruct.medium.com/know-how-your-org-works-or-how-to-become-a-more-effective-engineer-1a3287d1f58d Un article intéressant que je vais en… »

Nouvelle page

= Comment ça ? =
[https://copyconstruct.medium.com/know-how-your-org-works-or-how-to-become-a-more-effective-engineer-1a3287d1f58d Un article intéressant que je vais en bonne partie traduire ici]

Cindy Sridharan, l'autrice de l'article ci-dessus, dit dans un tweet : "Vous pouvez vous plaindre ou [exprimer de manière dogmatique] vos opinions sur comment l'industrie de la tech devrait marcher, ou vous pouvez apprendre comment votre organisation fonctionne vraiment et savoir ce qui est récompensé (ou trouver un autre travail)."

Pour le coup, cette phrase m'intéresse : c'est un problème qui m'as beaucoup concernée et me concerne encore dans mon emploi actuel. Tout ceci se passe du point de vue d'un "Contributeur Individuel" - donc, pas d'un manager ou d'un dirigeant.

== Le mirage de l'inspiration ==
Pour faire simple, il est facile de tomber dans le piège des phrases inspirantes "votre organisation devrait fonctionner de telle façon"; "l'industrie de la tech devrait mener les gens à ceci", etc. Ce genre de phrases font qu'il est démotivant de se rendre compte que ce n'est pas le cas dans notre cas. Les réseaux sociaux, billets de blogs et autres amplifient l'effet des phrases inspirantes. L'autrice prend comme exemple la dette technique : idéalement, la culture organisationnelle devrait la minimiser et favoriser la durabilité, pas simplement vendre des features. Cela dit, il est très rare de trouver la moindre équipe qui aura la dette technique comme *principal* sujet de travail au delà d'une semaine ou deux. L'organisation récompense ce qui lui bénéficie directement (et la dette technique n'est pas toujours perçue comme un sujet important); et ce qui lui bénéficie est parfois bien loin de ce qui devrait être être de rigueur d'après les réseaux sociaux.

== Savoir comment fonctionne notre organisation ==
L'une des choses les plus utiles dans notre travail est de savoir comment fonctionne l'organisation dans laquelle on travaille. Cela permet d'améliorer notre vision de bien des choses :
* Quelles compétences techniques apprendre pour savoir lesquelles seront récompensées
* Comment construire des relations durables avec le reste de l'équipe pour que les projets arrivent à terme
* Comment expliquer efficacement des projets / améliorations et les voir menés à terme
* Naviguer dans l’ambiguïté (c'est selon moi un point très important, qui m'as menée à noter cet article)
* Gérer les priorités et attentes conflictuelles
* Gérer les contretemps
* Améliorer les choix techniques
* Identifier les victoires rapides
* Discerner ce qui est possible et en combien de temps
* Savoir choisir ses chevaux de bataille
* Et dans le pire des cas, savoir quand partir

Les managers doivent savoir gérer cela, c'est dans leur job. En tant qu'admins, nous ne devons normalement le faire qu'à un niveau senior (mais il n'est jamais trop tôt) - et je me rends compte en l'écrivant que cela n'as pas été mon cas; dès les premiers jours, on a attendu de moi que je comprenne des enjeux de mon organisation - mais on peut dire que cela devrait même être une part importante de la formation des ingénieurs. Cela leur permettrait de commencer rapidement à réussir des choses (*getting things done*).

Ce n'est pas une bonne idée de protéger les juniors de cela; cela diminue leurs visibilité sur ces talents (je traduirais ici *skills* par talents) pour lesquels il n'y a rien de tout prêt. Ils auront par la suite à les apprendre à la dure; certains managers et autres n'en parlent pas aux juniors pour qu'ils "puissent se concentrer sur leur travail" - c'est une erreur.

Comprendre comment fonctionne son organisation - Historique des versions

Justine le 22 juin 2022 à 12:12

Justine le 10 janvier 2022 à 17:56

Justine le 7 janvier 2022 à 10:03

Justine : Page créée avec « = Comment ça ? = [https://copyconstruct.medium.com/know-how-your-org-works-or-how-to-become-a-more-effective-engineer-1a3287d1f58d Un article intéressant que je vais en… »

Justine : Page créée avec « = Comment ça ? = [https://copyconstruct.medium.com/know-how-your-org-works-or-how-to-become-a-more-effective-engineer-1a3287d1f58d Un article intéressant que je vais en… »