Comment puis-je encourager une culture de la ponctualité dans une entreprise de logiciels ?

*Le meilleur facteur de motivation est la confiance * L'unité de l'équipe est d'une importance capitale pour atteindre vos objectifs. Les cultures de règles sont empreintes de méfiance, et les bâtons et les aiguillons pour faire respecter les règles ne feront qu'éroder davantage la confiance de votre équipe.

Plutôt que de vous préoccuper des heures exactes et des cultures informelles, essayez de comprendre quelles sont les valeurs intrinsèques.

• Est-ce que 9h30 (ou toute heure arbitraire) compte vraiment ? Ou est-ce que votre équipe doit s'assurer qu'elle ne gêne pas le travail des autres équipes par son absence ?

• 5 minutes font-elles une différence ? Ou est-ce qu'il est très important que tous les membres se joignent à la réunion quotidienne ?

• L'informalité est-elle un problème ? **Ou bien la flexibilité est-elle un avantage ?

Je voudrais creuser le cœur du problème, à savoir que votre équipe n'a pas adhéré à l'idée. Voyez où se situe la déconnexion, mais évitez de créer une culture de règles. En les renvoyant chez eux pour leur retard (une tactique disciplinaire que vous trouveriez dans une école primaire), votre équipe croira que vous les voyez comme des enfants en qui on ne peut pas avoir confiance.

La création d'une culture de la ponctualité peut prendre du temps et peut nécessiter un certain compromis. Comme vous avez affaire à des travailleurs de la connaissance intelligents, vous aurez plus de succès si vous pouvez les faire adhérer au plan. Au lieu de vous concentrer sur le temps, concentrez-vous sur le problème créé par les problèmes d'horaires.

Présentez le problème comme un défi à l'équipe et voyez ce qu'ils en tirent. La réponse peut être des horaires fixes ou quelque chose de différent qui résout le problème. Ce peut être le lundi, le mercredi, le vendredi sont les jours de pointe à 9 heures du matin, tandis que le mardi et le jeudi sont les jours flexibles. Même si le plan n'est pas parfait et ne correspond pas exactement à ce que vous aviez envisagé, trouver un terrain d'entente quelque part qui satisfera l'équipe de développement et résoudra le problème réel empêchera votre personnel de devenir amer et de vous considérer comme l'ennemi.

Gardez à l'esprit que vous n'avez pas affaire à un processus de fabrication où tout le monde doit se présenter à exactement 9h30, lorsque le coup de sifflet retentit, afin de pouvoir commencer la tâche abrutissante d'assembler les mêmes petits gadgets en plastique à plusieurs reprises, jusqu'à ce que le coup de sifflet retentisse à nouveau, et que le personnel abruti se rende au bar local pour l'happy hour.

Mon équipe n'arrive pas à l'heure. J'ai essayé de les obliger et ça ne marche pas.

Forcer les gens intelligents ne marche jamais. Vous devez vous rappeler que vous avez affaire à des personnes très instruites, intelligentes, créatives et qui savent résoudre des problèmes complexes, abstraits et uniques. Ces personnes, du moins celles qui sont vraiment douées, ne se contenteront jamais de suivre aveuglément les ordres. Cela revient à mettre le problème entre leurs mains, du moins au début. S'ils ne font rien, alors vous voudrez intervenir avec votre propre solution.

Vous avez mentionné que vous êtes un nouveau chef d'équipe. Entrer dans un nouveau poste comme celui-ci est un défi et un stress car vous ne savez pas comment gagner le respect de l'équipe et être un bon leader. Cela vient avec l'expérience, et il est courant que les chefs d'équipe inexpérimentés tentent de “contraindre” ou d'obliger les gens à faire les choses à leur manière. Il ne s'agit pas de leadership.

Les développeurs et autres travailleurs de la connaissance n'ont pas besoin d'un manager, mais d'un leader. Les grands leaders inspirent les autres à faire de grandes choses, et c'est votre chance de mener votre équipe à la grandeur plutôt que de la pousser au désespoir.

Les recherches montrent que les gens sont plus enclins à s'engager lorsqu'ils ont participé à la détermination de la solution plutôt que de se faire dire cette solution, et c'est particulièrement vrai avec les travailleurs de la connaissance.

Pour l'inspiration, veuillez consulter l'interview de Seth Godin sur la Différence entre le leadership et la gestion . Je recommande vivement à toute personne exerçant des fonctions de direction de regarder cette courte interview.

D'après mon expérience, les travailleurs de la connaissance n'aiment pas qu'on leur dicte des politiques pour lesquelles ils ne voient pas l'utilité. Vous énoncez un objectif, mais les employés que vous dirigez semblent penser que ce n'est pas un bon objectif. De plus, il y a probablement des alternatives que vous n'avez pas envisagées, et étant donné que ce qui semble être une question “dictée d'en haut”, vos employés peuvent soit ne pas y avoir pensé, soit ne pas se sentir à l'aise pour les proposer, soit avoir le sentiment qu'ils seraient tout simplement abattus.

Si la seule raison pour laquelle vous mettez en œuvre la politique est due à des tensions avec des personnes d'autres départements, c'est votre travail de gérer ces tensions afin que vos employés puissent travailler le plus efficacement possible. Mais je ne pense pas que ce soit la seule raison. Par exemple, que faire si un développeur est nécessaire pour régler un problème de production urgent qui se produit à 8 ou 9 heures ou à n'importe quelle autre heure ? Cependant, il est peu probable que vous ayez besoin de la présence de tous vos développeurs pour résoudre ce problème. Que se passerait-il si vous aviez un planning tournant (à moins que quelqu'un ne se porte volontaire) “anticipé”, de sorte que chaque développeur prenne son tour en étant tenu d'être là à 8h00 (ou 9h00, etc.) ? Cette solution semble plus susceptible de satisfaire à la fois les besoins de l'entreprise et les souhaits de vos employés. Tout le monde “partage la douleur” (ou l'inflige à quelqu'un qui ne s'en soucie pas). Les gens peuvent venir et travailler la plupart du temps lorsqu'ils estiment qu'ils seraient les plus productifs. Ce n'est qu'une possibilité, mais elle peut susciter une discussion avec vos employés sur la manière de résoudre les vrais problèmes et de satisfaire les intérêts de chacun ici.

Si vous choisissez de suivre la voie plus disciplinaire, et que la question du “moment de départ” est vraiment importante pour vos développeurs, vous perdrez vos bons éléments au profit d'un autre emploi. Vos employés risquent de ne pas se sentir en sécurité dans leur travail (et si une véritable urgence se produisait un jour pour mettre quelqu'un en retard ?) En outre, cela peut être considéré comme un changement de direction dans la mauvaise direction (du point de vue de vos employés), puisqu'ils ont déjà eu l'occasion de travailler sous la direction de quelqu'un d'autre.

C'est à vous de décider, bien sûr, mais je vous invite à prendre du recul et à vous efforcer de voir la situation du point de vue de vos employés. Vous avez un travail à faire, bien sûr, mais je pense qu'il existe des solutions qui satisfont mieux les intérêts de chacun que celle que vous proposez.

La réponse précise à votre question est de virer et de remplacer quelqu'un qui ne comprend pas le message et de virer ensuite toute autre personne qui ne comprend pas le message.

Je ne pense pas que cela aiderait votre carrière ou les objectifs de développement de votre entreprise mais vous avez décidé que c'est le problème et il semble que vous ne soyez pas convaincu du contraire. Voilà donc comment procéder.

De manière plus constructive, je vous suggère de considérer ce qui suit :

• Vos développeurs avaient un horaire flexible. Maintenant, vous voulez le supprimer

Peu importe qu'il s'agisse d'un avantage officiel dans une politique écrite ou non. C'est une politique de facto et une partie de la culture établie. La vie et les horaires des gens ont été établis autour de ces heures. Et pour les développeurs comme moi, qui préfèrent éviter l'heure de pointe et qui sont victimes d'un terriblement mauvais cas de dépression saisonnière en hiver, mais qui ne peuvent pas imaginer d'endroit plus proche de l'équateur où je préfèrerais vivre, c'est aussi important que de retirer des avantages en matière de santé.

• Quelle est la nature de cette “angoisse” dont vous parlez ? Est-ce a) principalement de la jalousie ou b) des problèmes de communication interministérielle légitime comme la difficulté à programmer des réunions ou la communication générale.

a) Les développeurs n'ont pas besoin d'interagir avec les clients ou d'autres entreprises. D'après mon expérience, plus la structure de l'entreprise est rigide, plus les développeurs sont médiocres. Si le développement est en grande partie une affaire de boulons, il s'agit également d'un processus créatif de résolution de problèmes qui exige des personnes qu'elles soient à leur meilleur niveau. C'est aussi un processus imprévisible, axé sur les délais, qui entraîne parfois des heures très, très tardives. Un effet secondaire de cette situation est que les développeurs sont souvent traités de manière “créative”. Dans une entreprise de 30 personnes, il ne devrait pas être difficile d'insister pour que les employés soient des adultes qui doivent être au mieux de leur forme lorsqu'ils sont présents et qui sont susceptibles de consacrer beaucoup plus d'heures au cours d'une année qu'un 9-5 qui fait habituellement ses valises à 16h55 tous les jours.

b) Dans une entreprise de 30 personnes, vous ne devriez pas avoir tellement de réunions que cela devienne un problème. Sans compter les réunions de sprint ou autres sessions de planification bimensuelles, immobiliser vos développeurs pendant plus de 30 minutes chaque jour en réunion est un gaspillage d'argent absurde et grossièrement incompétent. Il en va de même pour la communication générale. 30 personnes signifie que vous allez vers l'autre gars et que vous lui parlez. Dans les scénarios d'horaires flexibles, il est raisonnable de fixer une durée pendant laquelle tout le monde est au bureau en même temps. Je ne vois pas de bonne raison pour que cet intervalle dépasse 3-4 heures de travail par jour et pour qu'il ne soit pas aussi proche du milieu de la journée que possible.

• Pourquoi une réunion debout le matin ?

• Pourquoi la première idée de gestion des déchets de la mêlée, de l'agilité, etc… est toujours le conseil de ne pas avoir de réunion debout en premier lieu ? En programmation, il faut un certain temps pour revenir à la pleine conscience de tous les détails et de toutes les questions que vous traitez sur un problème donné. Quand vous faites des stand-up en premier lieu, vos développeurs ne vont pas avoir la tête complètement vissée. Les positions debout sont essentielles à la communication et à l'amélioration de l'efficacité, et non pas quelque chose que vous faites simplement en premier lieu pour “vous mettre à l'écart”

• Vos concepteurs ne parviennent pas à faire le travail ?

Si ce n'est pas le cas, pourquoi gâcher une bonne chose ? Ce n'est pas leur travail de communiquer avec les autres préoccupations de l'entreprise. C'est le vôtre. Dans une structure de gestion saine, vous êtes responsable devant votre supérieur hiérarchique et les personnes que vous dirigez, et non devant le raisin aigre des autres services qui doivent être présents à des heures plus habituelles pour des raisons pratiques.

La première chose à faire est go read “Peopleware”

C'est une erreur d'essayer de changer cela maintenant. J'étais directeur dans une entreprise où nous avions un horaire de travail assez flexible. L'un de nos développeurs les plus productifs est arrivé à 11 heures du matin. Il m'a fait son rapport pendant un certain temps. On m'a dit de lui faire changer ses horaires. Je me suis battu contre cette demande. J'ai lutté avec acharnement. J'ai été débouté.

Le résultat :

Un développeur moins productif, moins intéressé, qui apportait une énorme contribution à l'équipe. Il est devenu beaucoup moins productif et utile pour l'équipe.

Tout cela à cause d'une notion idiote de “ponctualité”.

Concentrez-vous davantage sur la productivité.

En tant que manager, votre travail consiste à supprimer les obstacles à la productivité - et non pas à faire en sorte que tout le monde ait la même apparence, le même sentiment et le même comportement.

Les horaires flexibles sont un avantage - et un employeur qui autorise les horaires flexibles peut attirer davantage de personnes de qualité.

En tant que “nouvelle piste technique”, il n'y a aucune chance que vous puissiez changer de culture rapidement. Surtout dans la direction que vous semblez vouloir prendre. Avez-vous fait quelque chose pour améliorer les rôles/emplois de votre équipe ?

Travaillez d'abord à établir une relation de confiance avec eux. Beaucoup de nouveaux managers et responsables font des erreurs comme celle-ci.

**Découvrez ce dont les autres groupes ont VRAIMENT besoin. Pas “ils doivent être là à 9h30”. Trouvez vraiment ce dont il s'agit. Au lieu de dire à votre équipe ce qu'elle doit faire, expliquez-lui le problème et demandez-leur ensuite de faire des suggestions ou de donner leur avis. Vous faites une vague référence aux “causes de beaucoup d'angoisse entre mon service et les autres services”, mais la nature de cette angoisse n'est pas claire. Quel est le véritable problème sous-jacent ?

J'ai essayé de les contraindre et ça ne marche pas.

Il y a une raison à cela. Et vous ne semblez pas écouter. Prendre des mesures plus drastiques et utiliser de plus gros marteaux ne va pas vraiment améliorer la situation. Essayez l'approche de la “carotte” plutôt que celle du “bâton”.

Encore une fois, lisez “Peopleware”.

Vous n'irez pas loin avec des idées comme les réunions quotidiennes ou le renvoi des gens chez eux ou avec l'idée qu'ils sont vos larbins qui doivent faire ce que vous dites, “ou sinon”.

Qui vous dit qu'ils doivent être au travail à 9h30 ? D'autres groupes ? Vos patrons ? Vous ? Trouvez le VRAI problème et réglez-le. Le moment où ils se présentent ne devrait PAS être le problème.

Quelle que soit la raison pour laquelle vous le faites, les membres de votre équipe ont l'impression que vous leur enlevez un avantage. Pour certains d'entre eux, il peut même s'agir d'une des principales raisons pour lesquelles ils travaillent pour votre entreprise plutôt que pour une autre.

Essentiellement, vous leur demandez d'accepter une réduction de leur rémunération globale.

Il est possible de les convaincre de l'accepter, mais vous aurez besoin de bons arguments et il est presque certain que cela suscitera un ressentiment persistant. Vous risquez de perdre ou non de bonnes personnes à cause de cela.

D'après votre description, la principale raison semble être la jalousie des autres services. Avez-vous envisagé de donner aux autres services les mêmes avantages ?

En bref : ne le faites pas, sauf si vous pensez que cela vaut la peine d'en perdre certains.

Pour changer votre culture, vous devez comprendre pourquoi vous rencontrez une résistance et ensuite gérer la cause de cette résistance.

Selon mon expérience, la “coordination avec d'autres départements” est généralement du ressort de ceux qui occupent des postes plus élevés et qui sont à la tête d'un projet ou d'une piste de gestion du personnel. Les développeurs qui ne s'intéressent qu'au code ont tendance à être protégés de cette situation. Dans les ateliers plus structurés, ils peuvent ne pas le faire du tout et dans les petits ateliers, ils peuvent le faire de manière plus informelle.

Que cela vous plaise ou non, vous avez hérité d'une culture d'horaires flexibles, ce qui est un avantage énorme pour la plupart des développeurs. Leur enlever cela dans l'un de vos premiers actes en tant que dirigeant ne leur paraîtra pas seulement tyrannique (lorsque vous leur expliquez que 9h30 n'est pas c'est tôt, vous leur imposez votre propre horaire, arbitrairement selon eux), mais c'est aussi, de manière réaliste, la soustraction d'un avantage substantiel. Vous pouvez aimer travailler selon un horaire particulier et ne pas considérer cela comme un avantage significatif, mais ils le considèrent probablement comme inestimable. Considérez que cela équivaut à leur dire que vous leur enlevez une semaine de vacances ou que vous réduisez leur salaire de quelques pour cent.

Pour changer cela, vous pouvez utiliser la carotte ou le bâton. Vous parlez d'utiliser un bâton et, peut-être, un plus gros bâton. Si vous suivez cette voie, j'envisage d'engager quelques nouveaux développeurs, car je suppose qu'une partie de votre équipe va commencer à passer des entretiens dans d'autres entreprises. Je choisirais personnellement la voie de la carotte pour obtenir l'adhésion à la suppression de cet avantage en précisant que les promotions et les avancements futurs seront décidés par ceux qui “coordonnent avec les autres services”. C'est-à-dire que les responsables/les personnes importantes sont en avance, travaillent avec d'autres équipes, assument des responsabilités, etc. Les “nouveaux” bénéficient de l'avantage de la flexibilité, mais les personnes qui veulent sérieusement progresser arrivent à temps.

Si vous créez cette culture, je pense que certains de vos développeurs commenceront à arriver à temps de leur propre chef. Tant par intérêt pour l'avancement que par la perception que “les gens importants arrivent tôt”.

Je ne vous envie pas celui-ci - en tant que collègue manager, ce serait difficile pour moi. Et très honnêtement, je crois que vous allez perdre des gens à cause de cela. Je pense que vous avez un seul symptôme qui vient du changement de culture de Start Up -> Medium Sized, et tous les développeurs ne vont pas réussir ce changement. Je pense que vous devez vous préparer avec des descriptions de poste et savoir comment vous ouvrez les demandes d'emploi et je pense que vous devez mettre l'accent sur la capacité à embaucher de nouvelles personnes et à améliorer la documentation…

Désolé, c'est si sinistre. Mais je ne pense pas que vous ayez une situation de problèmes de confiance, ou un cas où vous pouvez facilement expliquer aux gens qu'ils sont d'accord. Et il n'y a vraiment aucune compensation qui équilibre parfaitement la flexibilité massive au travail.

Je suis d'accord que vous enlevez un avantage. La flexibilité dans les horaires de début de carrière est un problème important pour certaines personnes, et cela témoigne d'une culture informelle qui peut être une forte préférence pour certaines personnes. Il est probable qu'avec la croissance de l'entreprise, la charge de travail est devenue plus fiable, la sécurité de l'emploi s'est améliorée, le respect du produit s'est accru et vous avez peut-être pu proposer des plans d'action, des augmentations de salaire ou d'autres améliorations. Si rien de tout cela n'est vrai, alors vous vous demandez si vous avez une entreprise en pleine croissance et prospère ou une entreprise qui plonge dans le désespoir. L'astuce est que souvent les gens ne peuvent pas faire le lien entre ces nouvelles valeurs ajoutées et la suppression de l'avantage favori. Vous pouvez essayer de l'expliquer, mais pour certaines personnes, ce n'est pas un bon compromis, et ce n'est pas un cas où vous pouvez offrir le choix. C'est une “voie ou une autoroute”, car elle a un impact organisationnel qui ne se fait pas nécessairement sentir au sein de l'équipe, mais qui est expérimenté et soutenu aux niveaux supérieurs de l'entreprise. Il semble que vous ayez fait ce qu'il fallait : vous avez clairement exposé les choses, vous avez parlé de la raison et de la nécessité du changement, vous avez engagé un dialogue individuel (et vous continuez à le faire, je suppose) pour régler les cas individuels au fur et à mesure qu'ils se présentent, vous avez donné un retour d'information, je pense que vous en êtes réduit à la question “est-ce qu'il le pense vraiment ? "où il s'agit surtout de prouver aux gens que vous êtes sérieux, et que cela doit vraiment changer. Je pense personnellement qu'avoir 5 minutes de retard dans un bureau de ma région n'est pas un problème et que les réunions qui ont une courte durée (comme les stands up dans un sprint agile) ne devraient pas être si difficiles en début de journée de travail qu'une correspondance de bus manquée ou une mauvaise circulation serait un problème régulier. Mais il s'agit d'un problème régional : la situation de la circulation varie beaucoup d'une localité à l'autre. Il s'agit donc autant de connaître sa région et de savoir, à partir de plaintes individuelles, ce qui est raisonnable.

Le reste consiste simplement à trouver un mécanisme suffisamment débilitant pour prouver que vous êtes sérieux. Un jour de salaire à quai est une option et c'est dans le cadre de vos droits légaux - bien que tout mécanisme que je trouverais passerait par les avocats. Il en va de même pour un système d'avertissement formel qui conduit à une action discplinaire. Je suppose que votre département des ressources humaines pourrait avoir des suggestions…

Beaucoup dépend de ce que le travail peut tolérer - quand vous renvoyez quelqu'un chez lui, vous perdez aussi le travail de cette journée, ce qui a un impact sur vos coûts et votre emploi du temps. Lorsque vous disposez d'un système d'avertissement qui conduit à des mesures disciplinaires - y compris le licenciement - vous économisez le reste de la journée de travail, mais vous risquez de devoir licencier l'employé.

Je pense que le fait est que, lorsque vous avez affaire à des punitions, vous devez être préparé à une punition qui est suffisamment dommageable pour être prise au sérieux et pour faire comprendre que "vous ne faites pas votre travail si vous ne faites pas ceci”.

La réponse courte est que vous ne devriez PAS faire cela. Les membres de votre équipe technique sont (ou du moins, devraient être) suffisamment intelligents pour savoir qu'il n'y a aucun avantage tangible à ce que tout le monde soit présent au bureau à un moment arbitraire ; la seule mesure importante est de savoir si leur travail est fait ou non.

Si votre équipe ne fait pas son travail, alors c'est une question distincte. Mais si elle fait son travail, pourquoi la harcelez-vous simplement parce que d'autres services vous harcèlent ? Une partie de votre rôle de dirigeant consiste à protéger votre équipe des distractions et des critiques insignifiantes provenant de sources extérieures. Si votre réaction aux plaintes des autres personnes à l'encontre des membres de votre équipe consiste à transmettre ces plaintes aux membres de votre équipe et/ou à leur dicter des changements sur la seule base de ces plaintes, alors vous échouez dans votre travail. Je vous suggère, en supposant que votre équipe fait effectivement son ou ses travaux (ce qui semble être le cas, puisque vous ne vous plaignez pas de leur productivité), de dire au plaignant : “oui, mes hommes travaillent dur et obtiennent constamment de bons résultats, et c'est la seule chose qui compte ; alors pourquoi ne cessez-vous pas de vous préoccuper de la façon dont mon équipe s'acquitte de ses tâches et revenez à la vôtre ? "Et bien sûr, si vous appliquez la politique obligatoire "vous devez être au bureau à l'heure X”, il est juste de la compléter par une politique “vous devez quitter le bureau à l'heure Y” et une politique “vous ne devez pas travailler à la maison en dehors des heures normales de travail”. Ce n'est que justice pour protéger l'équilibre entre vie professionnelle et vie privée de votre employé, car je parie que nombre des membres de votre équipe qui ne se présentent pas avant 11 heures restent probablement tard ou font des heures supplémentaires à la maison.

Il semble qu'il y ait un décalage entre la façon dont vos développeurs perçoivent le problème et la façon dont les autres services (ou vos supérieurs, ou quiconque demande ce changement) le perçoivent. Je suggère d'essayer de combler ce fossé, en plusieurs étapes si nécessaire.

Premièrement, les développeurs sont-ils d'accord sur le fait qu'il y a de bonnes raisons pour ce changement ? S'ils ne sont pas d'accord, ont-ils de bons contre-arguments ou des suggestions alternatives ? Dans l'affirmative, vous devriez les soumettre à la direction et voir s'ils assouplissent l'exigence de délai - ou s'ils peuvent expliquer pourquoi les alternatives ne fonctionneront pas et les contre-arguments ne résolvent pas le problème, afin que vous puissiez retourner voir vos développeurs et leur donner une explication plus complète. Continuez le va-et-vient aussi longtemps que nécessaire/productif.

Si vous arrivez au point où les développeurs conviennent qu'il y a de bonnes raisons mais ne sont pas disposés à s'adapter, ou s'ils pensent que les raisons ne sont pas bonnes et n'apprécient pas l'idée dans son ensemble, communiquez-le à la direction. Expliquez que vous pourriez forcer les développeurs à faire ce qui est souhaité, mais que cela provoquera du ressentiment, une baisse de motivation, voire une baisse de productivité ou même le départ des employés. Assurez-vous que la direction le comprenne et qu'elle soit toujours d'accord sur l'importance de faire respecter l'heure de début (et encore une fois, communiquez-le à vos développeurs), sinon vous risquez de vous retrouver responsable d'un changement qui a fait perdre à l'entreprise plus qu'elle n'en a gagné.

_(Une note personnelle : on m'a dit de venir à une heure fixe pour, en ce qui concerne les employés, aucune bonne raison, et c'est vraiment extrêmement démotivant. Il est vraiment important de s'assurer que les gens comprennent les raisons et n'ont pas l'impression que vous changez la politique sur un coup de tête ou parce que vous n'avez pas confiance en eux).

Je travaillais dans une association à but non lucratif qui avait ce problème. Les réunions commençaient toujours en retard, 10 minutes de retard devenaient un “standard”.

Ensuite, nous avons eu un nouveau chef de projet pour un grand projet clé (et un autre avec un calendrier fixe). Elle a organisé la première réunion. Les gens se sont promenés comme d'habitude, avec quelques minutes de retard et en bavardant tranquillement. Elle s'est assise sur sa chaise et n'a rien dit - rien du tout - pendant plusieurs minutes. Finalement, la discussion s'est “éteinte” jusqu'à ce qu'il y ait un silence. Nous attendions tous de pouvoir parler. Elle a laissé le silence se prolonger un peu plus longtemps. Elle a regardé autour d'elle et a dit : “Je dois être claire. Les réunions commencent à l'heure. Si vous avez 5 minutes de retard, ne vous donnez pas la peine de venir, venez me voir après. OK, maintenant pour le projet que nous faisons cette semaine [peu importe]…”. Cela a fait une GRANDE impression et les gens ont fait un réel effort pour être à l'heure pour ses réunions.

Note : Ajout d'une réponse supplémentaire ci-dessous.

Rendre compte du travail effectué à distance.

Souvent, les plus grands producteurs font une grande partie de leur travail à distance de toute façon, donc ils passent parfois autant de temps à distance qu'au bureau. C'est un point important à considérer et à communiquer avec les autres services. Cette communication doit être subtile - ne convoquez pas de réunion, commencez juste à chercher des moyens de montrer “oui, Joe s'est couché tard hier soir pour travailler sur x” et “oui, Mary a arrangé ça dimanche, elle s'est levée "jusqu'à minuit”.

Parlez ouvertement du trajet. Si quelqu'un vient à 10h30, son trajet peut durer 15 minutes. S'il doit arriver à 9 ou 9h30, son trajet peut durer une heure. De plus, ce serait la même chose pour rentrer à la maison s'il a travaillé 8 ou 9 heures. De nombreuses personnes estiment que c'est un grand gaspillage de leur vie. Ils préfèrent travailler à distance pendant un certain temps et revenir ensuite. Essayez d'intégrer ce fait à vos besoins lorsque vous fixez les horaires et assurez-vous que les autres services le savent également, là encore en le mentionnant fréquemment.

Assurez-vous d'utiliser la technologie pour vous aider. Par exemple, je travaille virtuellement - 100% du temps. Donc, avoir Skype allumé, montrer mon statut en ligne, une caméra vidéo, etc. peut aussi aider.

Ayant été dans des situations similaires, bien qu'en moins de temps que le PO, je n'ai que ceci à dire sur l'état de sa situation :

La solution la plus pratique et la plus simple…

…serait d'essayer de commencer les réunions à 11 heures plutôt. Ne vous inquiétez pas, vous ne “cédez” pas. Au lieu de cela, vous redirigez le flux comme le font les principes qui sous-tendent Aïkido . L'idée est plutôt de se concentrer sur le fait de permettre à votre équipe de faire des choses importantes car c'est le point primordial car il y a vraiment un problème sérieux qui doit être résolu :

L'équipe n'a vraiment AUCUNE idée de ce qui se passe dans les autres départements et de ce qu'ils doivent VRAIMENT faire.

Avoir votre équipe qui se présente à 9h30 ce qui, je peux l'admettre, n'est pas tôt n'est cependant pas une solution à ce problème. Vous avez essayé et échoué, alors arrêtez d'insister pour le faire . Arrêtez de vous cogner la tête sur un mur de briques. Mon seul conseil ici est de toujours privilégier la communication par rapport aux réunions fixées arbitrairement.

Puisque les autres services commencent à 8 heures, vous pouvez utiliser cette réunion d'équipe tardive à votre avantage. Entre 8 et 11 heures, vous disposez de 3 heures pour aider votre équipe dans des activités de gestion de projet telles que (sans ordre ni priorité particuliers) : - Aller aux réunions et recueillir les objectifs et les exigences des autres départements - Déterminer ce qui a été terminé depuis hier - Gérer les attentes et les engagements avec les autres départements sur ce qui doit et peut être fait pendant la journée de travail - Communiquer les bonnes et les mauvaises nouvelles aux autres départements - Mettre à jour tout plan pertinent pour l'équipe s'il y en a - Déterminer quels problèmes de code et d'architecture logicielle doivent être pris en compte aujourd'hui - Dire “NON” aux demandes qui n'apportent aucune valeur commerciale - Accepter les critiques des autres appartements et s'excuser avec l'assurance que les problèmes seront résolus - etc. (il y a toujours quelque chose qui doit être réglé)

Et enfin, avant la réunion, résumez un briefing pour l'équipe sur ce qui se passe, afin de leur donner une certaine connaissance de la situation. Lorsque la réunion commence à 11 heures et que tout le monde est prêt à se mettre au travail, préparez des informations et un protocole de réunion pour eux. Vous pouvez faire rédiger le briefing et le compte-rendu de la réunion comme un bulletin d'information et les envoyer par e-mail après la réunion pour les rappeler.

Pendant la réunion avec l'équipe, vous avez besoin de deux choses :

• Demandez des estimations pour les tâches qui doivent être effectuées, en particulier celles qui sont prioritaires. Il n'est pas nécessaire d'être précis, comme dans un procès-verbal. Vous pouvez ainsi décider des engagements et des délais beaucoup plus clairement avec les autres services. S'ils ne peuvent pas donner d'estimation pour une tâche, demandez-leur de la calculer dans la journée ou le lendemain.
• Demandez des impédiments ou s'ils ont besoin d'aide pour quoi que ce soit, notez-les et voyez si ces problèmes peuvent être résolus et qu'ils le soient.

Après un certain temps, vous pouvez probablement passer progressivement à des réunions plus tôt. Mais au départ, aller à contre-courant n'est pas la solution et ne fait que conduire à une culture encore plus infectieuse (dans laquelle la seule façon de réparer est de remplacer toute l'équipe). Si elles sont, comme vous le dites, des “primadonnas”, alors votre véritable travail consiste à les remettre à neuf pour en faire des primadonnas géniales qui fournissent une grande qualité. Il est clair que votre équipe avait et veut de l’autonomie, alors commencez à exploiter cette culture au profit des objectifs de votre entreprise. Lorsque vous avez réussi à constituer une équipe fiable, par la communication plutôt que par la coercition, vous pouvez partir trois heures plus tôt que les autres membres de l'équipe en sachant qu'ils font leur travail (mais en restant de garde si la merde frappe le ventilateur). C'est la confiance sur laquelle vous pouvez compter.

Les autres soulèvent de nombreux points positifs sur la manière de gérer la situation ; cependant, en fin de compte, si l'emploi du temps de votre groupe perturbe les autres membres de l'entreprise, vous devez corriger le problème et veiller à ce que les choses se passent bien. Dans cette optique, vous devez déterminer quand les autres groupes ont besoin d'un accès fiable aux développeurs et s'il y a une marge de manœuvre dans ce calendrier. Si d'autres groupes ont besoin d'un accès aux développeurs lorsqu'ils sont au bureau de manière imprévisible, un noyau de développeurs doit s'assurer que ce besoin est pris en compte. Si cela signifie que certains développeurs doivent être au bureau à des périodes fixes, alors c'est ce qui se passe.

En ce qui concerne le fait de placer les développeurs dans une sorte de calendrier de disponibilité fixe, votre meilleure chance est de faire en sorte que les “heures dures” soient assouplies autant que possible. Par exemple, si les “heures de base” sont de 11h00 à 15h00, vous pouvez également vous assurer que les heures de base du vendredi ne sont pas présentes et que le vendredi est un véritable jour de flexibilité. Comme le mardi, le mercredi et le jeudi sont traditionnellement considérés comme les jours les plus productifs de la semaine, vous pouvez faire en sorte que les heures de base s'appliquent à ces jours et que le lundi et le vendredi soient également des jours de flexibilité. Vous devez faire ce que vous pouvez pour vous assurer qu'elle est mise en place progressivement et si certains développeurs ont des horaires flexibles dans leur contrat de travail, il faut y remédier (par exemple en modifiant leur rémunération et leurs avantages, en les faisant bénéficier de droits acquis, etc. De même, si certains choisissent de partir, il peut être utile d'essayer de voir s'ils sont prêts à rester avec les changements de rémunération et d'avantages ; cependant, vous devrez peut-être aussi accepter de perdre certains des développeurs.

En fin de compte, si votre travail exige que vous appliquiez un changement culturel au groupe pour répondre aux besoins de l'entreprise, vos options seront limitées dans une certaine mesure. Vous pouvez et devez faire tout ce qui est en votre pouvoir pour adoucir le changement et obtenir des compromis avec d'autres groupes, mais vous devrez finalement appliquer le changement et accepter tout changement de personnel qui pourrait en découler.

Je lis les commentaires et les réponses et je dois avouer que je suis un peu sidéré. Depuis quand le fait d'avoir des gens qui se présentent à l'heure est-il une “perte d'avantage” ? Depuis quand l'horaire flexible ne doit-il pas se soucier de l'impact de vos actions sur le reste de l'équipe et de l'entreprise ?

D'après ce que j'ai lu dans la question et les commentaires, il est prouvé que le comportement des membres de son équipe est préjudiciable et coûteux pour l'entreprise. Et après avoir essayé de raisonner et de faire des compromis, la situation ne s'est pas améliorée (et d'ailleurs, 9h30 n'est pas précoce ou en aucune façon déraisonnable).

Expliquez à votre équipe que vous n'avez aucun problème avec l'horaire flexible, mais que cela implique une certaine responsabilité personnelle pour s'assurer que votre flexibilité n'a pas d'impact sur le travail des autres (dans votre équipe ou dans d'autres équipes). Comme votre équipe manque clairement à sa responsabilité, je dirais qu'à partir de maintenant et jusqu'à nouvel ordre, tout horaire flexible doit être approuvé par vous au préalable. Le fait de ne pas se présenter à l'heure le matin sans approbation ou sans excuse raisonnable (non, le réveil n'a pas sonné n'est pas acceptable) entraînera des mesures disciplinaires telles que l'indemnité de quai ou les vacances.

Expliquez très clairement pourquoi cela se produit et ce qui vous a obligé à prendre ces mesures. Précisez que ce n'est pas quelque chose que vous voulez faire, mais quelque chose que vous avez été forcé à faire. Précisez également que ces politiques restrictives pourront être levées lorsque la situation s'améliorera.

Il existe encore de multiples possibilités pour traiter cette question, dont l'une serait de modifier le rôle que joue le ministère, comme par exemple : Si vous travaillez avec des développeurs de logiciels, vous pourriez changer le rôle d'une ou plusieurs personnes pendant la semaine pour qu'elles assurent le soutien des autres départements, ce qui nécessite qu'une ou plusieurs personnes viennent à 9 heures ou plus tôt et si cela ne fonctionne pas, vous pourriez toujours invoquer une clause d'insubordination qui est normalement présente dans tout manuel d'emploi aux États-Unis. Personnellement, j'ai toujours été contre l'utilisation de cette clause, qui donne à un responsable un moyen de réprimander et même de renvoyer quelqu'un pour cause mais dans votre cas, cela peut être approprié. Donc, passez en revue le manuel de l'employé et discutez-en avec votre supérieur si vous en avez un que vous allez utiliser.

L'idée de base est la suivante :

1. Vous fixez la règle qu'au moins 1 à 2 personnes ou toutes les personnes doivent être au travail à l'heure X.
2. Si les membres de votre équipe n'ont pas d'excuse valable pour ne pas se présenter ou persister dans cette pratique, vous devez, en tant que manager, les réprimander et éventuellement les licencier.

En tant que manager, faire ce que je décris serait le dernier recours mais, d'après ce que vous décrivez, vous avez peut-être atteint ce point. Il existe de nombreux articles sur l'insubordination des employés que vous pouvez trouver en ligne et ce ne sont que quelques exemples :

• BlogSpot
• Duhaime

Bien sûr, la conséquence malheureuse peut être un taux de rotation élevé dans votre groupe, ce qui n'aura pas une bonne image de vous en tant que manager, mais cela renforcera la discipline et tuera probablement le moral dans le processus.

Maintenant que tout cela est dit, j'ai une question : Avez-vous vraiment besoin que votre équipe soit présente plus tôt que prévu ?

Fondamentalement, vous devez décider ce qui est le plus important, faire le travail correctement ou rester assis à votre bureau pendant 8 heures à des moments prescrits ?