Sangsues. Classification des programmeurs

Qui sont les dirigeants et pourquoi sont-ils nécessaires? Quelle est leur utilisation dans la vie? Que font-ils du tout? Que devraient-ils faire?

D'une part, le leader est traditionnellement compris comme celui qui gère - fait des plans, donne des instructions, contrôle le timing, crie le plus fort, prend des décisions et en est responsable.

D'un autre côté, il existe un avis selon lequel le chef ne devrait s'occuper que du développement de l'unité confiée, sans participer à la gestion opérationnelle.

D'un autre côté, il y a l'autonomie gouvernementale et les organisations turquoise, qui dans la pratique ont prouvé qu'une telle entité en tant que leader n'est pas du tout nécessaire - c'est juste un ensemble de responsabilités, de rôles et de points de contrôle qui sont facilement répartis entre différentes personnes.

Alors, qui est-il, ce leader, et pourquoi at-il besoin de lui? Un manager a-t-il besoin d'une entreprise ou une entreprise a-t-elle besoin d'un leader comme source de revenus? Peut-être justifie-t-il son existence, car le résultat en vaut la peine - les revenus des managers sont souvent incomparablement plus élevés que les revenus des employés ordinaires.

J'utilise un modèle spécial pour évaluer les gestionnaires, que je vous suggère de vous familiariser avec.

Modèle

Le modèle est simple à déshonorer, mais généralement compréhensible uniquement pour les programmeurs. Mais vous êtes programmeurs, et tout sera clair pour vous.

Imaginez donc une entreprise qui a automatisé sa comptabilité dans un certain système d'information. Et à côté de ce système est un programmeur, juste un. Lui et le chef du service informatique, le codeur et l'architecte - tout en un. La situation est assez courante pour les petites, et parfois pour les grandes entreprises - moi-même, pendant un certain temps, j'ai été le seul programmeur de l'entreprise.

Imaginons maintenant qu'un programmeur soit à la tête d'un département, et qu'un système d'information soit, en fait, son département, y compris le personnel, l'équipement, les processus, etc. Et le département, et le service, et le département, et toute l'entreprise - c'est un système. Et l'information - c'est aussi un système.

Le programmeur est libre de traiter son système de différentes manières - pour développer, maintenir, supprimer, casser, réduire ou augmenter la productivité, le remplacer par un autre, écrire ou supprimer des documents, contrôler les soldes, etc.

Le chef est libre de faire à peu près la même chose avec son système (département) - développer, accompagner, travailler comme exécuteur testamentaire, interférer, aider, disperser, remplacer le personnel, etc.

Le modèle est clair: la relation gestionnaire / service est la même que celle du programmeur / système d'information.

Regardons maintenant les leaders à travers le prisme de ce modèle.

Slicker

Le type de programmeur le plus primitif est celui qui ne fait rien du tout, mais parvient d'une manière ou d'une autre à ne pas sortir du travail. Personnellement, je l'ai vu - il a été amené à passer du démarreur progressif intégré 1C 7.7 au 1C 8, et il n'a pas utilisé son pied, ni dans le premier, ni dans le second, mais il s'est étiré un an - uniquement parce qu'il courait sur Internet pour configurer Internet à temps, ICQ et télécharger de la musique à partir de torrents.

Un autre exemple est une fille qui ne savait rien faire elle-même, mais qui avait un vaste réseau de contacts parmi les programmeurs et qui était, comme on dit, jolie et charmante, alors les gars ont volontiers aidé, résolvant complètement ses tâches. De plus, les gars travaillaient dans d'autres entreprises.

Vous comprenez que le système avec un tel programmeur vit sa propre vie, ne dépend pratiquement pas du tout et il n'y a aucun changement visible avant de partir.

Parmi les dirigeants de ces gars-là est également plein - qu'ils sont, qu'ils ne le sont pas. Parfois, ils sont appelés généraux de mariage, mais c'est dans ces cas où la tête peut remplir au moins des fonctions représentatives, par exemple, pour s'asseoir agréablement lors d'une réunion avec des clients.

Ces dirigeants aiment toutes sortes d'événements, de réunions - en particulier ceux où il y a beaucoup de monde et où il n'est pas nécessaire d'ouvrir la bouche. Parfois, ils sont si misérables que s'ils obtiennent toujours la tâche de la direction, ils ne peuvent même pas la déléguer normalement, car le système les ignore complètement, à moins que quelqu'un n'ait pitié et aide.

Cela n'a aucun sens de parler du rôle d'un tel programmeur et d'un tel leader dans le système et son développement, car il n'y a ni rôle ni développement. C'est le cas le plus misérable.

Un parent

Il s'agit d'un type distinct de furtivité, à la différence près que les proches n'ont pas à faire grand-chose pour rester en place. Ils y ont été amenés avec une patte hirsute et ils sont assis. Qui est toute la journée, qui est avant le dîner, qui est après le dîner, qui est à la maison.

Les proches ont déjà un impact sur le système, comme ils ont peur - vous ne savez jamais quel type de rênes tombera sous la queue, vous pouvez perdre votre travail.

Mais en fait, ils n'utilisent généralement pas cette influence. Être un élément du système, c'est-à-dire ils ne veulent y exécuter aucune fonction, car la responsabilité et les obligations apparaîtront, au moins vous devez venir travailler. Ils ne peuvent pas développer le système, car cela nécessite au moins quelques compétences et une compréhension de ce qui se passe.

Bien sûr, il existe des exceptions lorsqu'un parent ne se comporte pas comme un parent, mais nous l'excluons solennellement de cette catégorie. Parfois, les liens familiaux aident même, rendant une personne plus responsable et efficace, par exemple, dans une entreprise familiale. L'efficacité augmente parce qu'un parent n'a pas peur du licenciement.

Mais en général, pour la plupart, un tel programmeur ne joue aucun rôle dans la vie du système, et le chef dans la vie du département.

Vis

Il arrive qu'un programmeur se transforme en opérateur. Pas souvent, mais ça arrive.

Il effectue uniquement des échanges, télécharge et télécharge des fichiers, effectue des sauvegardes, saisit des documents, génère des rapports, effectue une sorte d'analyse des données, etc. En fait, il fait juste le travail de l'utilisateur. Dans ma vie, j'ai vu cela quand, lentement, peu à peu, et le programmeur s'est transformé en comptable.

Si tourné, c.-à-d. déménagé dans un autre département et à un autre poste - et l'enfer avec lui, une telle transformation normale. Mais il arrive qu'il fonctionne en tant qu'opérateur et s'appelle un programmeur. Qui est-il alors, dans notre modèle? Juste un élément du système qu'il était censé gérer. Qui gère et développe ensuite le système? Personne, jusqu'à ce qu'un autre arrive et remarque que quelque chose ne va pas ici.

Cela se produit tout le temps avec les dirigeants, en particulier avec le niveau le plus bas, tels que les chefs d'équipe, les gestionnaires de site, les administrateurs système en chef, etc. Leur position est une formalité, ils ne gèrent rien et ne développent rien, ils travaillent comme tout le monde, ils ont juste un peu plus de responsabilités, comme aller à la RAM et fournir des feuilles de temps.

Ni l'un ni l'autre des dirigeants n'a d'influence sur leur système. Ne gérez pas, ne développez pas, ne répondez pas. Le système ne dépend pas d'eux.

Poulpe

Mais c'est un cas complètement différent. Un tel programmeur, bien qu'il ne soit pas impliqué dans la programmation, est un élément système d'importance unique. Par exemple, lui seul sait calculer le coût et l'ajuster en fonction de la stratégie fiscale.

En fait, c'est le même opérateur, mais plus avancé, réalisant sa valeur et le vendant avec succès. Un tel programmeur prétend que lui seul sait comment faire des ajustements pour enregistrer les entrées afin que "rien ne vole". Lui seul peut corriger le moins dans le dos pour que le subconto ne se disperse pas. Vous pouvez continuer la liste vous-même.

Un tel programmeur fait partie intégrante du système, son goulot d'étranglement, un appendice qui ne peut être coupé. Sans cela, il y aura une crise, et tout le monde, y compris lui-même, comprend cela - tout repose sur elle. Il prend des décisions sur l'exécution d'opérations complexes, sur la résolution de problèmes complexes, tels que des erreurs lors du téléchargement de rapports, etc.

Il y a plus de gestionnaires de ce type que de programmeurs. Ils créent artificiellement et intentionnellement des conditions dans lesquelles le système ne peut exister sans eux, même pour une journée (cela peut être clairement vu lorsqu'ils partent en vacances). Ils coordonnent tout, vérifient tout, en particulier ce qui est fourni "à l'étage", prennent des décisions sur chaque instance du processus (par exemple, la commande d'un client), vont à toutes les réunions.

Lorsqu'on leur dit qu'ils doivent être délégués, ils se réfèrent à l'emploi - il n'y a tout simplement pas de temps pour s'asseoir et réfléchir, écrire des instructions et remettre les choses. En général, c'est leur excuse préférée - l'emploi qu'ils ont créé artificiellement. Et plus de multitâche.

La situation semble parfois ridicule, surtout quand un supérieur hiérarchique change et commence à demander notre élément clé - que faites-vous? Et surtout - pourquoi? La réponse est généralement - «ainsi accepté», ou, s'il parvient à fixer son caractère indispensable dans les normes de l'entreprise, «il devrait en être ainsi». Qui a accepté, quand accepté, pourquoi accepté - il n'y a pas de réponse, ou elle ne peut pas être prononcée, car «J'ai pensé à cette merde insignifiante» sonne comme ça.

Le programmeur et le manager commencent progressivement à croire en leur exclusivité. Parfois, ils commencent même à se sentir désolés pour eux-mêmes et à demander de la pitié aux autres, ou même à induire cette pitié des plus élevés pour augmenter leurs revenus.

Il arrive qu'un tel programmeur ou gestionnaire clé apporte des modifications au système, c'est-à-dire agit favorablement sur elle. Mais il manque presque toujours de concentration sur l'élimination du système. Par exemple, un programmeur peut écrire un traitement sympa pour la formation de liasses de documents, ce qui évite aux gens de faire un travail de routine, mais seul le programmeur utilisera ce traitement. S'ils lui demandent d'enseigner à quelqu'un d'autre, alors il trouvera un tas d'excuses, telles que "oui là pour expliquer plus longtemps, laissez-moi faire mieux".

Les dirigeants font de même, aiguisant le système pour eux-mêmes. Par exemple, il y avait un tel directeur des ventes qui a éliminé une condition: donnez-moi un pourcentage des ventes de tout le département, et je distribuerai la prime à ma guise. Vous comprenez que pour les vendeurs, cela devient le principal motif de travailler pour un tel leader - non pas «vendre plus», mais «aimer plus». Le gestionnaire ne pourra pas expliquer l'algorithme de distribution, car cet algorithme n'existe pas.

Du coup, pour le programmeur, pour le manager, le résultat est un: le système ne peut ni exister ni se développer sans lui.

Gant

Il y a des programmeurs qui changent des systèmes comme des gants. Ils ne savent pas vraiment comment programmer, penser à l'implémentation, résoudre les petits et grands problèmes des utilisateurs et bénéficier à l'entreprise.

Dans toute situation de crise, quand il y a plus de mal que de bien du système, ils prononcent: il est temps de passer à un autre système.

Heureusement, il n'y a maintenant aucun problème avec cela, surtout compte tenu du mélange de niches dans la gamme de produits, le même 1C. Vous pouvez passer d'UT 10.3 au démarreur progressif, puis à KA 1, puis à KP 3.0, puis à KA 2, puis à ERP, puis cracher sur tout et implémenter UNF, puis une sorte de perversion comme USHP (si l'industrie le permet), alors, étonnamment, revenez à SCP. Chaque transition est d'un minimum d'un an. Comptez-vous combien vous pouvez tenir sur une telle stratégie. Avez-vous rencontré de tels programmeurs? J'ai rencontré.

À quoi ressemble un leader similaire? Il change sans cesse la méthodologie, l'approche de base de la gestion. Aujourd'hui, il établit un plan pour un mois, demain il établit un plan pour un an, puis passe à Agile, puis à TOS, puis à Lean, puis à 4-4-5, puis à budgétisation, puis à un modèle sans budget. Ce n'est pas mal si la tête connaît toutes ces techniques, au moins vous pouvez pratiquer leur application.

Mais généralement, tout est plus prosaïque - un tel leader résout tous les problèmes en se restructurant. Il en crée deux à partir d'un département, puis dix, puis à nouveau un, puis il recrute un nouveau département à partir de nouvelles personnes, puis les annule et les place dans les anciens départements, invente de nouveaux postes et écrit des instructions, des processus et des normes, ou de manière très enfantine - change les divisions en divisions, divisions pour départements, départements pour équipes, équipes pour districts, etc.

L'essence de l'approche pour le programmeur et le gestionnaire est la même: bien qu'il y ait des changements à grande échelle, personne n'ira au fond des résultats. Et si vous arrivez au fond, vous pouvez toujours otmazatsya: nous sommes en plein changement, maintenant il est tout simplement impossible de répondre à votre question, de revenir dans un mois ou de chercher la réponse vous-même.

L'impact sur le système est terrifiant à l'échelle, mais dénué de sens dans son résultat et son efficacité. Ce ne sont que des changements pour le changement, uniquement à une échelle colossale.

Ce qui est particulièrement mauvais, c'est que les autres s'habituent à un tel comportement et oublient progressivement que ces changements ont eu un début et qu'il doit y avoir une fin. Ils oublient la chaîne des changements, quel système ou méthodologie a changé et pourquoi. En conséquence, après un certain temps, vous pouvez simplement répéter toute la gamme des changements, et personne ne le remarquera. Dans la pratique, j'ai observé une telle image et calculé la fréquence du cycle - 4 ans.

Bien sûr, il n'est pas nécessaire de parler de tout avantage pour l'entreprise d'un tel programmeur et gestionnaire.

Plyushkin

Plyushkin est le personnage de "Dead Souls" de Gogol, un petit mercenaire avide qui a traîné et gardé tout ce qu'il trouve, jusque dans les moindres détails.

Ces programmeurs Plyushkin aiment toutes sortes de référentiels de solutions et de code, tels que git, mais ils sont utilisés à d'autres fins. Au lieu de chercher une solution à leur problème, ils téléchargent stupidement tout ce qui a suffisamment de capacité de disque ou d'argent (pour les solutions payantes). Ils sont stockés dans des dossiers soignés, triés, parfois ils essaient de les intégrer dans leur système pour les montrer aux utilisateurs ou au réalisateur, se faisant passer pour les leurs et justifier ainsi leur existence.

Ils ne savent pas vraiment quoi faire, alors utiliser les petites choses de quelqu'un d'autre pour eux est le seul moyen de survivre dans la profession. Pour des changements sérieux, ils manquent de force, de compétences et de courage.

Vous pouvez reconnaître de tels Plyushkins en regardant l'interface de leur système - il sera plein d'icônes de divers add-ons, dont la signification ne sera claire pour personne. Toutes sortes de panneaux de fonctions, duplication de l'arborescence des métadonnées, tri universel des tableaux, gestion des échanges dans une base de données qui n'utilise pas les échanges, un tas de rapports, même pour d'autres systèmes, etc.

Les dirigeants de Plyushkina se comportent de la même manière. Ils lisent des blogs, des articles, toutes sortes de groupes sur les réseaux sociaux sur la façon d'apporter des changements utiles avec peu d'effort. En raison de la nature peu systématique du choix des méthodes, de la compréhension des problèmes de leur service et de la mise en œuvre elle-même, ils ont généralement un non-sens.

Par exemple, Plyushkin regardera à la télévision que le nouveau jeune gouverneur tient des réunions en se levant, disant que cela augmente l'efficacité - et c'est tout, profitez-en, subordonnés. Auparavant, assis dans un stupa, ils poussaient l'eau, maintenant vous serez debout. Ou il lira une autre meilleure pratique selon laquelle tous les employés devraient rédiger un rapport quotidien à la main, ils disent que ce n'est pas un copier-coller informatique, mais de vrais mots sincères - et ici, des essais quotidiens, moins une heure du temps de travail.

Ces programmeurs et gestionnaires ont un impact mineur et surtout nuisible sur le système. remplissez-le de déchets et de bruit.

Amant d'escorte

Il y a des programmeurs qui, presque toujours, pour la solution de tâches plus ou moins complexes, sont appelés des sous-traitants. Le projet d'introduction du système, de lancement d'un nouveau sous-système, d'intégration avec le site, de développement d'un nouveau document, d'ajout d'accessoires - un programmeur externe est appelé pour tout.

Il y a les mêmes dirigeants, j'ai personnellement vu. Besoin d'un système de motivation? Optimisation des processus d'affaires? Développement de stratégie? Analyse du système de gestion? Il n'y a qu'une seule réponse - nous recherchons des spécialistes externes.

L'impact sur le système, semble-t-il, est, mais presque toujours tordu et nuisible, car le consultant travaille avec une seule partie de la mosaïque.

Par exemple, il crée un système de motivation pour les processus tordus. Ou écrit une stratégie, sans tenir compte de la motivation de sa mise en œuvre. Ou, notre natif - fait l'automatisation de l'instantané du processus, qui perd de sa pertinence un an avant la fin du projet, bien que ce ne soit pas important, car les objectifs et la motivation ne sont pas non plus pris en compte.

En conséquence, il est toujours tordu, avec un biais dans une certaine direction. Le chef et le programmeur. Mais l'essentiel est que leur propre rôle dans ce processus de développement soit nul.

Toléré

C'est le type de programmeur le plus courant - ceux qui font tout ce qu'on leur dit. En conséquence, ils apportent des changements insignifiants au système, le donnant, morceau par morceau, pour la réalisation des ambitions malsaines de quelqu'un d'autre. C'est la majorité d'entre nous, que puis-je dire.

Et ces dirigeants - en vrac. Ce sont tous ceux qui ont laissé entrer des spécialistes externes de l'automatisation, des implémenteurs de la norme ISO 9001, des bureaucrates internes de toutes sortes qui ont dû fournir un tas de rapports, des morceaux de papier, passer par des millions d'approbations, apprendre des chansons et préparer des scènes pour des événements d'entreprise, etc. En général, qui a ouvert une partie de son système à une agression extérieure, comme un porche pour les sans-abri, et ne sait plus comment les chasser de là, pour ne pas tout sentir.

En conséquence, le système d'information et le système de gestion des départements ou des entreprises deviennent comme Frankenstein inhibé, incapable de faire un pas.

Ces gens sont des parasites, car sous le couvert de "et je Che, ils m'ont dit de" détruire leurs systèmes.

Normal

Il y a des programmeurs normaux dans le monde qui décident eux-mêmes quoi faire avec le système, connaissant les objectifs auxquels il est confronté. Si les objectifs sont des courbes définies, ils ne sont pas timides et les ajustent, et tout le monde parvient à s'entendre.

Il y a des gestionnaires normaux qui sont constamment engagés dans l'amélioration de l'efficacité de leur système, et ils le font de manière réfléchie, cohérente et professionnelle.

Ni l'un ni l'autre ne pénètrent dans le système, sauf dans les cas très urgents.

Aucun d'eux n'a lié le système à lui-même, et à tout moment, il peut partir, et le système continuera de fonctionner, même s'il cessera de se développer.

Le seul problème est que ni l'un ni l'autre n'existe.

Problème clé

Il y a des connaissances, de l'expérience, des compétences dispersées entre différentes personnes qui ne peuvent jamais être d'accord. Certains sont capables de créer des systèmes de motivation, d'autres sont la stratégie, les troisièmes objectifs et indicateurs, la quatrième automatisation, le cinquième système de gestion. Mais ils ne travaillent jamais ensemble en même temps.

Le développement est toujours cohérent, vous pouvez le voir à partir de projets parfois conçus en entreprise.

Par exemple, un système de motivation basé sur les processus actuels est en cours d'introduction. S'il est visible que les processus sont tordus, cela est ignoré afin de ne pas dépasser l'échelle et le budget du projet.

Ou l'optimisation des processus est lancée, mais l'automatisation ne suit pas, ce qui se traduit par un terrible hybride des nouvelles et anciennes versions des deux.

J'ai déjà parlé à plusieurs reprises de l'automatisation, notamment externe, grâce aux efforts des sous-traitants. Ils font simplement une distribution automatisée de processus dénués de sens, de motivation non motivée, d'objectifs incommensurables et sans système de gestion en général.

Des courses sans fin sont obtenues - chaque partie du système se succède, ce qui ne fait qu'exacerber l'état de l'ensemble de la population.

Solution

La solution est simple à ignorer - pour intégrer le développement. Changez toutes les parties du système en même temps afin qu'il n'y ait pas de déséquilibre entre elles.

Parce que le principal problème est le déséquilibre, l'inadéquation des parties du système les unes aux autres. Bien qu'il semble que le problème soit dans une partie spécifique.

Par exemple, très souvent, ils réduisent l'automatisation - c'est la faute de tout.

Nous, les programmeurs, blâmons généralement les processus, ils disent qu'il y a un gâchis et nous sommes obligés de l'automatiser.

Les développeurs de systèmes de motivation se plaignent des processus, des indicateurs non automatisés et du manque d'objectifs. Etc.

Mais le vrai problème est le déséquilibre qui crée la course au développement, et l'entreprise n'obtient jamais les avantages de chaque partie du système d'entreprise.

Implémente l'ERP, et profite de 10% des possibilités, car il n'y a pas de processus pour le reste. Il implémente un système de notation et ne l'utilise pas, car le calcul des indicateurs n'est pas automatisé. Il écrit des objectifs stratégiques, mais il ne les atteindra jamais, car les processus ne sont pas réorganisés en conséquence.

Il n'y a qu'un seul point: chaque partie, en soi, n'est pas mauvaise, mais toutes ensemble elles ne fonctionnent pas, car elles sont en déséquilibre.

Retour aux cadres et programmeurs

Le modèle que je vous ai dit n'est pas seulement de rire. Elle est pour comprendre la situation dans un endroit particulier, dans une entreprise particulière, avec un leader spécifique.

J'ai choisi l'analogie avec un programmeur pour une raison simple - je suis moi-même programmeur et vous êtes programmeurs. Certes, si vous expliquez le rôle et l'influence des leaders aux filles des RH, vous devrez trouver un modèle différent. Parce que la pensée que je veux transmettre en est une, mais il peut y avoir de nombreux modèles - ils ne sont que pour faciliter la compréhension.

Mais, comme il me semble, les dirigeants sont de l'atavisme. Les entreprises n'en ont pas besoin. Ils sont comme une mauvaise habitude que vous détestez, mais ont peur d'arrêter. Les leaders créent l'illusion du support, de la stabilité et de la gestion de l'entreprise. Ils, comme, «portent la responsabilité», «prennent des décisions», «coordonnent» et ainsi de suite, des mots sans signification.

Tous ces mots ont été inventés par les dirigeants eux-mêmes. Essayez, pour le plaisir, de convaincre le leader qu'il n'est pas nécessaire. Il vous dit tellement de choses à quel point ce serait mal sans lui que ses oreilles soient tirées. Mais écouter le chef lui-même sur les raisons pour lesquelles l'entreprise a besoin de lui, c'est comme demander à la personne condamnée de se faire tirer dessus, pourquoi devrait-il vivre.

Le modèle de comparaison d'un gestionnaire avec un programmeur, je l'espère, vous aidera, lors de conversations telles et similaires, à ne pas oublier pourquoi un gestionnaire est nécessaire.

Où le mettre?

Il n’est pas nécessaire de nommer une personne, mais le modèle généralement accepté de leader - «un grand patron avec un gros salaire». En fait, ceux qui veulent devenir un leader aspirent vraiment à cela?

Le modèle Belbin donne une bonne réponse. Un leader ordinaire est un ensemble indéfini de responsabilités peu claires, dont vous avez juste besoin pour trier les rôles et sélectionner un emploi approprié pour une personne en particulier.

Pouvez-vous coordonner les actions des personnes en ligne? Ok, sois le coordinateur.

Pouvez-vous inspirer, soutenir, faire avancer les choses? Ok, soyez un motivateur.

Pouvez-vous terminer des projets en peu de temps? Ok, sois un finisseur.

Avez-vous une vision, savez-vous où aller, pouvez-vous proposer les bonnes idées? Ok, sois un générateur.

Pouvez-vous analyser, garder à l'esprit un grand nombre de paramètres système et comprendre ses vulnérabilités? Ok, soyez analyste.

Tous ces rôles ne sont pas du leadership. Ce ne sont que des rôles, un tel travail.

Si vous dites aux gens quoi faire, cela ne signifie pas que vous êtes en charge. Le répartiteur indique également aux chauffeurs de taxi où aller. Il ne parle pas, il l'a fait. Il a été remplacé par le système.

Si vous savez inspirer les gens, cela ne signifie pas que vous êtes en charge. Quelqu'un a juste besoin de regarder le bon film pour s’inspirer, et tu l’as baisé n’a pas abandonné ta motivation. Et quelqu'un à la maison sera tellement inspiré à la maison qu’elle ne semblera pas assez.

Si nous étendons le «leadership» traditionnel sur les étagères des rôles et des compétences, alors il n'en restera rien. Alors pourquoi avons-nous besoin d'un tel leader? De plus, avec la mise en page, il s'avère qu'il ne peut vraiment jouer aucun des rôles.

Et le roi est nu, comme l'a dit l'histoire.