最好的激励因素是信任，*团队的团结是完成目标的关键。规则文化是由不信任而生的，用棍棒和棍棒来执行规则只会进一步侵蚀你的团队的信任。

与其关注确切的时间和非正式的文化，不如试着弄清楚内在的价值观是什么。还是是你的团队需要确保自己的缺席不会妨碍其他团队的工作？

–5分钟的时间是否有区别？*还是最重要的是所有成员都要加入到每天的坚持中来？

–非正式性是个问题吗？还是*是灵活性是个好处？

–我会挖掘问题的核心，那就是你的团队还没有买账。看出脱节在哪里，但避免创造规则文化。以迟到为由把他们送回家（这是你在小学里就能找到的一种惩戒策略），会让你的团队相信你把他们看成是不可信任的孩子。

创建一种守时文化可能需要时间，可能是你不得不在某种程度上做出妥协的事情。因为你面对的是聪明的知识型员工，如果你能让他们买通计划，你会更成功。与其把注意力放在时间上，不如把注意力放在排程问题所产生的问题上。

把这个问题作为一个挑战，向团队提出来，看看他们能想出什么办法。答案可能是设定好的时间表，也可能是解决这个问题的不同方案。可能是周一、周三、周五是上午9点上班的日子，而周二、周四是灵活的日子。虽然这个计划可能并不完美，也不会是你所设想的那样，但找到一个既能让开发团队满意，又能解决实际问题的中间地带，可以防止你的员工变得苦不堪言，视你为敌人。

请记住，你面对的不是一个制造过程，在这个过程中，每个人都必须在上午9点半准时出现，当哨声一响，他们就可以开始重复组装同样的小塑料小部件，直到哨声再次响起，然后心神不宁的员工们就会去当地的酒吧享受快乐时光。我试过强迫他们，但没有用

强迫聪明人永远不会有效果。你需要记住，你面对的是受过高等教育、聪明、有创造力、善于解决复杂、抽象、独特问题的人。这些人，至少是真正优秀的人，绝不会盲目听从命令。这又回到了把问题放在他们的手中，至少在一开始的时候是这样。如果他们什么都不做，那么你就会想插手，拿出自己的解决方案。

你提到你是一个新的团队领导。踏入这样一个新的岗位是很有挑战和压力的，因为你不知道如何获得团队的尊重，同时也不知道如何做一个好的领导者。这与经验有关，没有经验的新团队领导通常会试图 “强迫 "或强迫人们按自己的方式做事。这不是领导力。

开发人员和其他知识工作者不需要管理者，相反，他们需要一个领导者。

研究表明，当人们参与决定解决方案时，他们更有可能做出承诺，而不是把解决方案告诉他们，这对于知识工作者来说尤其如此。我强烈推荐任何人和每一个有领导能力的人观看这段简短的访谈。

根据我的经验，知识型员工不喜欢被人指手画脚的政策，他们不喜欢被人指手画脚，因为他们看不到任何目的。你确实说了一个目的，但你所管理的员工似乎认为这不是一个好的目的。此外，你可能还没有考虑过其他的替代方案，而且考虑到这听起来像是 “上面的命令"，你的员工可能没有考虑过这些方案，不愿意提出这些方案，或者觉得这些方案会被拒绝。但我认为这并不是唯一的原因。例如，如果需要开发人员去修复一个紧急的生产问题，而这个问题发生在8点或9点或其他什么时间，怎么办？然而，你不可能需要所有的开发人员都到场来解决这个问题。如果你有一个轮流（除非有人自愿）"提前 "的时间表，那么每个开发人员轮流在8:00（或9:00等）到场呢？这样的解决方案似乎更有可能同时满足业务需求和员工的愿望。每个人都会 "同甘共苦"（或者把痛苦施加在不介意的人身上）。人们可以在他们觉得自己最有生产力的时候，大部分时间都可以进来工作。这只是一种可能，但它可能会引起你的员工讨论如何解决真正的问题，并在这里满足大家的利益。

如果你选择走更有纪律性的路线，而 "开工时间 "的问题对你的开发人员来说真的很重要，那么你会把你的好员工流失到其他岗位上。你的员工很可能会对自己的工作没有安全感（如果有一天真的发生了什么紧急情况，让别人迟到了怎么办？更进一步说，这可以看作是管理方向的转变（从你的员工的角度来看），因为他们之前确实有在别人手下工作的经验。

当然，这取决于你，但我劝你退一步，努力从员工的角度看问题。当然，你有工作要做，但我认为有比你提出的方案更能满足大家的利益。

对你的问题的准确答案是解雇和替换不懂的人，然后解雇其他不懂的人。

我不指望这对你的事业和公司的发展目标有什么帮助，但你已经决定了这个问题，似乎没有办法说服你。所以就是这样，

更有建设性的是，我建议你考虑以下几点：

–你的开发人员有弹性时间。现在你想把它拿走

这并不重要，在一些书面政策中是否是官方的福利。这是一个事实上的政策，也是既定文化的一部分。人们的生活和日程安排都是围绕着这些时间来制定的。而对于像我这样的开发人员来说，他们更喜欢躲避上班高峰期，而且在冬天的时候会患上可怕的SAD，但却想不出有什么对开发人员有利的地方，我宁愿住在赤道附近，这就像拉健康福利一样重要。是a）主要是嫉妒，还是b）合法的部门间沟通问题，比如难以安排会议/一般的沟通。

a）开发人员不需要与客户或其他业务互动。根据我的经验，公司结构越僵化的公司，开发人员越是平庸。虽然开发的很多工作都是坚果式的，但这也是一个创造性地解决问题的过程，需要人们在解决问题的过程中发挥出自己的聪明才智。这也是一个不可预测的最后期限驱动的过程，有时会导致非常非常晚的时间。这样做的一个副作用是，开发人员往往会得到 “创造性 "的待遇。在一个30人的公司里，坚持做一个成年人的员工应该不难，因为他们需要在工作的时候保持最佳的状态，而且在一年的时间里，他们很可能会比通常每天下午4:55收拾东西的9-5人的员工多花很多时间。这还不算冲刺会议或其他双月计划会议，每天把你的开发人员捆绑在会议上超过30分钟，是一种荒谬的、无能的浪费。同样的，一般的沟通也是如此。30人意味着你走过去和对方谈一谈。在弹性时间的情况下，设定一个时间跨度，让每个人同时在办公室里开会是合理的。我想不出有什么好的理由让这个时间跨度超过3-4个小时的工作时间，也想不出为什么不应该尽可能的接近于一天中的时间段。

–为什么要早上的跷跷板？

为什么从scrum、敏捷等的第一条想法管理的废品总是建议你不要第一时间跷跷板？在编程过程中，你需要一段时间的时间来夯实你对某个问题的所有细节和问题的全面认知。当你在第一时间做Standups的时候，你的开发人员不会完全拧成一股绳。standups是沟通和提高效率的关键，而不是你只是为了 "摆脱困境 "而做的第一件事。”

–你的开发人员是失败了吗？

如果不是，为什么要把一件好事搞砸了？在公司里，与其他关心的事情沟通，不是他们的工作。这是你的工作。在一个理智的管理结构中，你的责任是对你的直属经理和你管理的人负责，而不是其他部门的酸葡萄，因为实际的原因，他们必须在更典型的时间到场。

首先要做的事情是去看《人品》

现在再想改变这一点是错误的。我曾在一家公司担任经理，我们的工作时间安排相当灵活。我们的一个最有生产力的开发人员早上11点就来了。他向我汇报了一段时间。我被告知要让他改变工作时间。我拒绝了这个要求。我很努力地抗争。结果是：

结果是：

一个生产力低下，对团队贡献巨大的开发人员的兴趣降低了。

都是因为一些愚蠢的 “准时 "的概念。

更多的关注于生产力。

作为管理者，你的工作是消除生产力的障碍–而不是让每个人看起来、感觉和行为都一样。尤其是在你似乎想要的方向上。你是否做了什么来改善团队的角色/工作？

首先要努力与他们建立信任。很多第一次做经理/领导的人都会犯这样的错误。

找出其他团队真正需要的是什么。而不是 "他们必须在9:30到这里"。真正找出问题是什么。然后找到解决问题的方法。

**不要告诉你的团队该怎么做–解释问题，然后问他们的建议/反馈。真正的潜在问题是什么？

我试过蛊惑他们，但没有效果。

这是有原因的。而你似乎并没有听进去。追求更激烈的措施和更大的锤子，并不能真正改善情况。试着用 "胡萝卜 "的方法，而不是 "大棒 "的方法。

再来看看 "人品 "吧。

你的想法是不会走远的，比如每天开会或送人回家，或者是认为他们是你的奴才，需要按照你说的 "否则就得听你的 "的想法。是其他群体？你的老板们？你呢？找出真正的问题并解决这个问题。他们什么时候出现不应该是问题。

不管你为什么要这样做，对你的团队成员来说，感觉就像你在拿走了一份福利。对他们中的一些人来说，这甚至可能是他们为你的公司工作而不是为另一家公司工作的主要原因之一。

从本质上来说，你要求他们在总的薪酬方案中减免。

从你的描述来看，主要原因似乎是其他部门的嫉妒。你有没有考虑过给其他部门同样的福利？

简而言之：除非你认为值得因此而失去一些人，否则就不要这样做。

私の経験では、「他部署との調整」というのは、役職が高く、プロジェクトや人の管理をしている人の領域である傾向があります。コードにしか興味のない日雇いの開発者は、このようなことから守られている傾向があります。より構造化されたショップでは、彼らはそれを全くしないかもしれませんし、小規模なショップでは、彼らはより非公式にそれをするかもしれません。

好むと好まざるとに関わらず、あなたはフレックスアワーの文化を継承してきましたが、それはほとんどの開発者にとって大きな特典です。リーダーとしての最初の行動の一つでそれを奪うことは、彼らにとっては暴君的に見えるだけでなく（9:30 はそれほど早くないと彼らに説明するとき、あなたは彼らの意見に合わせて自分のスケジュールを彼らに押し付けていることになります）、現実的にはかなりの特典を奪うことになるでしょう。あなたは特定のスケジュールで働くのが好きで、これを意味のある特典とは考えていないかもしれませんが、彼らはおそらくそれを非常に貴重なものと考えているでしょう。これは、あなたが彼らの休暇の1週間を奪うか、数パーセントで彼らの給与をカットしていると彼らに言っているのと同じように考えてみてください。棒を使うか、もしかしたらもっと大きな棒を使うか、という話ですね。もしあなたがそのルートを行くなら、あなたのチームの何人かは他の会社の面接に行き始めると思うので、私は新しい開発者を何人か雇うつもりです。私は個人的には、将来の昇進や昇格は「他の部署との調整」を行う人たちによって決定されることを明確にすることで、この特典の廃止に賛成してもらうためにニンジンルートに行きたいと思っています。つまり、リーダーや重要人物が早くから出社し、他のチームと協力し、責任を負うなどです。"新人にはフレックス特典がありますが、真面目に昇進を考えている人は時間通りに出社します。進歩への関心と、"重要な人は早く出社する “という認識の両方によるものです。

我并不羡慕你这个人–作为一个同道中人的经理人，我会很难受。而且很坦率地说，我相信你会因此而失去很多人。我认为你有一个单一的症状，那就是来自于 “初创期"（Start Up）>"中等规模"（Medium Sized）的文化转变，并不是每个开发人员都能成功地进行这种转变。我认为你需要准备好职位描述和知识，我认为你需要准备好如何打开工作请求，我认为你需要强调雇佣新人的能力和改善文档的能力…..

很抱歉，这很严峻。但我觉得你不存在信任问题的情况，也不存在轻易把人解释成同意的情况。而且真的没有什么补偿可以完美平衡工作中的大量灵活性。

我同意你是在剥夺了一个福利。开始时间的灵活性对一些人来说是个大问题，这说明非正式的文化对一些人来说可能是一种强烈的偏好。大概是随着公司的发展，工作量变得更可靠，工作的安全性得到了改善，对产品的尊重度也提高了，而且你可能已经能够提供一些不错的股票计划、加薪或其他的改善。如果这些都不是真的，那么你要问自己，你是拥有一个成长中的公司，还是一个陷入绝望的公司。

技巧是，人们往往无法把这些新的价值增值和取消最喜欢的福利之间的联系起来。你可以试着解释一下，但对一些人来说，这并不是一个很好的权衡，这种情况下，你可以提供选择。这是一种 "我行我素或高速公路"，因为它对组织的影响，不一定能在团队内部感受到，但在公司的更高层次的人都有经验和支持。

听起来你做了正确的事情：

—你已经把事情说得很清楚了

–你已经谈到了变革的原因和需要

–你已经一对一地（我想是继续这样做），当个别案例出现时，你已经给出了反馈

我认为你已经到了 "他真的是认真的吗？ "这一点，主要是向别人证明你是认真的，这一点真的需要改变。在我个人看来，在我所在的地区，在办公室迟到5分钟并不是什么大事，而那些时间跨度较短的会议（比如敏捷冲刺中的站立会议）也不应该如此砸锅卖铁，以至于错过了公交车接驳或交通不畅都会成为常态。但这是有一定的地域性的–不同地区的交通状况有很大的差异。所以，这和了解自己所在的地区和从个人投诉中知道什么是合理的一样。

剩下的就是想出一个足够让人崩溃的机制来证明你是认真的。扣发一天的工资是一个选择，这在你的法律权利范围内–尽管我想出的任何机制都会通过律师来解决。所以，正式的警告制度也是一种正式的警告制度，会导致惩罚性的行动。我想你的人力资源部门可能会有建议…..

这在很大程度上取决于工作的容忍度–当你把人送回家时，你也会失去当天的工作，这影响了你的成本和进度。

我认为问题是，当你处理惩罚时，你必须准备好一个足以让人认真对待的惩罚，并将 "如果你不这样做，你就不是在做你的工作 "这一点带回家。

简单的答案是，你不应该这样做。你的技术团队成员（或者至少，应该是）足够聪明，知道让每个人都在办公室里的某个任意时间出现在办公室里并没有什么实际的好处；唯一重要的衡量标准是他们的工作是否完成。但是，如果他们正在完成工作，那么你为什么要骚扰他们，就因为其他部门一直在骚扰你呢？

作为一个领导者，你的角色之一就是让你的团队不被外部的琐碎的分心和批评所困扰。如果你对其他人对你的团队成员的抱怨的反应是把这些抱怨转嫁到你的团队成员身上和/或仅仅根据这些抱怨来发号施令，那么你的工作就是失败的。我建议，假设你的团队实际上是在完成工作（听起来他们是在完成工作，因为你没有对他们的工作效率提出任何抱怨），更好的回应方式是告诉抱怨者："是的，我的人很努力工作，并始终如一地提供可靠的结果，这是唯一重要的事情；所以你为什么不停止担心我的团队如何处理他们的任务，回到你自己的工作中去？ “。”

当然，如果你真的实行了 “你必须在X时间前必须在办公室 "的硬性规定，那就应该辅以 "你必须在Y时间前离开办公室 "的规定，以及 "你不能在正常工作时间以外在家工作 "的规定，这才是公平的。这样做是为了保护员工的工作/生活平衡，这才是公平的，因为我敢打赌，你的团队中很多直到11点才出现的员工，可能都是在家里待到很晚，或者是在家里加班。

看来，你们的开发人员如何看待这个问题，和其他部门（或你们的上级，或实际上要求这个改变的人）如何看待这个问题之间似乎存在着脱节。我建议，如果有必要的话，可以分多个阶段来弥补这个差距。

首先，开发人员是否同意有充分的理由进行这种改变？如果不同意，他们有什么好的反驳理由，或者是其他的建议吗？如果他们有，你应该把这些带到管理层那里，看看他们是否会放宽时间要求–或者他们是否能解释为什么替代方案行不通，反驳的理由也不能解决这个问题，这样你就可以回去找你的开发人员，给他们一个更完整的解释。只要有必要/有效果，就继续进行回访。

如果你到了这样的地步，开发人员同意有很好的理由，但就是不愿意适应，或者他们认为理由不好，反感整个想法，那么就向管理层沟通。解释一下，你可以_逼迫开发人员去做他们想要的事情，但是这样做会引起他们的反感，降低他们的积极性，很可能会降低生产力，甚至是员工离开。确保管理层明白这一点，并且仍然同意强制执行开始时间的重要性（再一次向你的开发人员传达这一点），否则你可能会因为这样的改变而导致公司的损失大于收获。

_（个人注：我曾经遇到过这样的情况：在员工看来，我曾被告知在规定的时间内进场，没有任何好的理由，这真的是非常不积极的。真的很重要的一点是，要让员工明白其中的原因，不要觉得你只是一时兴起，或者因为不信任他们而改变政策。

我以前在一个非营利组织工作时就有这个问题。会议总是开得很晚，迟到10分钟就成了 “标准"。

然后我们为一个大的关键项目找了一个新的项目经理（而且是在固定的时间内）。她召集了第一次会议。大家像往常一样，迟到了几分钟，随意地闲聊着。她坐在椅子上，一言不发–什么也没说–好几分钟。最后，聊天声 "渐渐地 "消散了，直到一片寂静。我们都在等着听她说话。她让这种沉默再持续一段时间。她环视了一下四周，说："我需要说清楚。会议要准时开始。如果你们要迟到5分钟，就不要来了，事后再来找我就可以了。好了，现在说说我们这周要做的项目[随便]……….."。这给人留下了一个很大的印象，大家都很努力地准时参加她的会议。

_注：下面增加了额外的答案。这一点既要考虑到，也要与其他部门沟通。这种沟通应该是微妙的—-不要召开会议，只需开始寻找方法来表明 "是的，乔昨晚很晚才睡，在x上工作 "和 "是的，玛丽周日修好了，她一直睡到半夜"。如果有人10点半来，他们的通勤时间可能是15分钟。如果他们需要在9点或9点半来，他们的通勤时间可能是一个小时。再加上如果他们工作8或9小时，回家的时间也是一样的。很多人觉得这是对自己生活的极大浪费。他们宁愿远程工作一段时间，然后再进来。在设定时间时，要将这一事实与你的需求进行整数化，并确保其他部门也知道这一点，再一次通过经常提及。比如说，我100%的时间都是虚拟工作。所以开着Skype，显示我的在线状态，视频摄像头等也会有帮助。

在经历过类似的情况后，虽然承认时间比OP的时间短，但我只能对他的情况说：

最实际、最简单的解决办法…..

…将是尝试在11点开始开会。别担心，你不是 “让步"。相反，你在调整方向，就像合气道背后的原则。我们的想法是把重点放在使你的团队能够完成重要的事情上，因为这是最重要的一点，因为有一个严重的问题需要解决：

**团队真的不知道其他部门在做什么，也不知道他们真正需要做什么。你已经尝试过了，也失败了，所以不要再坚持这样做了。不要再把你的头撞到砖墙上了。我在这里唯一的提示是，要永远重视沟通而不是任意设定的会议。

既然其他部门8点开始开会，你可以利用这个迟到的团队会议来为自己争取。在8点到11点之间，你有3个小时的时间来帮助你的团队进行项目管理活动，比如（不分先后顺序或优先级）。 更新任何与团队相关的计划，如果有任何计划的话 –弄清楚今天需要注意的代码和软件架构问题 –对没有提供任何商业价值的请求说 "NO” –接受其他公寓的批评，并保证问题会得到解决 –等等。(总有一些问题需要解决)(总有一些问题需要解决)

最后在开会前为团队总结一个简报，让他们有一定的情境意识。当会议在11点开始，大家都刚刚开始工作的时候，你就为他们准备好了资料和会议纪要。你可以把会议的简报和会议记录像通讯一样写好，在会议结束后的某个时候以邮件的形式发过去，作为一种温和的提醒。

在与团队开会的过程中，你需要从他们那里得到两点：

—要求对需要完成的任务进行***，尤其是那些优先级较高的任务。它不一定要精确，比如以分钟为单位。有了这个，你可以和其他部门更清楚地决定承诺和期限。如果他们对某项任务不能给出任何估计，请他们在当天或第二天再去想办法。 –询问障碍，或者如果他们需要帮助的事情，写下来，看看这些问题是否可以解决，并得到解决。但最初的时候，逆来顺受是不行的，只会导致更有感染力的文化（其中唯一的修复方法就是更换整个团队）。*如果他们像你说的那样，是 “骁将"，那么你真正的工作就是把他们翻新成令人敬畏的骁将，高质量地交付。

当你通过沟通而不是胁迫，建立了一个可靠的团队，你可以比团队中的其他人早三个小时离开，因为你知道他们在做他们的工作（但如果有什么事情发生，你仍然可以随时待命）。这就是你可以信赖的信任*。

关于如何处理这种情况，其他人提出了很多好的观点；然而，在一天的最后，如果你的小组的日程安排扰乱了公司中的其他人，那么你必须纠正这个问题，确保事情的顺利进行。考虑到这一点，你需要弄清楚其他组在什么时候需要可靠地访问开发人员，以及在这个日程安排中是否有弹性空间。如果其他小组需要在不可预知的情况下，需要接触到开发人员，那么就需要确保核心部分开发人员的需求得到满足。如果这意味着一些开发人员必须在固定的时间段在办公室，那么这就是事实。

关于将开发人员转移到某种固定的可用时间安排，你最好的办法是确保尽可能地软化任何 “硬时间"。例如，如果 "核心时间 "是11点到15点，那么你也可以确保周五的核心时间不出现，周五是真正的弹性时间。由于周二、周三和周四传统上被认为是一周中最有生产力的日子，所以你可能会让核心时间适用于这几天，并允许周一和周五也是完整的弹性时间。你应该尽你所能确保它是分阶段实施的，如果有些开发商将弹性工作时间写进了他们的雇佣协议中，那么就应该解决这个问题（例如，通过改变他们的报酬和福利，将他们纳入其中，等等）；但是，在某些时候，你必须确保政策必须得到遵守，这可能也需要对员工进行正式的纪律处分。同样，如果有些人选择离开，可能值得尝试看看他们是否愿意留下来与补偿和福利的变化，但是你可能也必须接受失去一些开发人员。你可以也应该尽一切努力来软化这种变化，并尽可能地与其他团体达成妥协，但最终你需要强制执行这种变化，并接受任何可能随之而来的人事变动。

我在看评论和回答，我不得不承认，我有点懵了。从什么时候开始，让人准时出现是 “失去了一种福利"？什么时候起，弹性时间不必在意自己的行为对团队其他成员和公司的影响了？

从我读到的问题和评论来看，他的团队成员的行为证明是对公司不利的，也是对公司有损失的。

向你的团队解释一下，你对弹性工作时间没有问题，但这意味着你要承担一定的个人责任，确保你的弹性工作不影响其他人（你的团队或其他团队）的工作。由于你的团队显然在责任部分没有尽到责任，我想说的是，立即生效，直到另行通知，所有的弹性时间必须事先得到你的批准。在没有批准或合理的借口（不，闹钟没响是不能接受的）早上没有准时出现，将导致纪律处分，比如扣工资或休假时间。

要非常清楚为什么会发生这种情况，是什么迫使你采取这些措施。指出这并不是你*想做的事情，而是你被逼着做的事情。同时要明确，一旦情况好转，这些限制性政策可以取消。

你仍有多种途径来处理这个问题，其中之一就是改变部门的角色，比如说，你可以改变部门的角色。如果你是和软件开发人员一起工作，你可以在一周内改变某一个或几个人的角色，让他们为其他部门提供支持，这需要1个或更多的人在9点或更早的时候来，如果这样做不行，你可以随时援引不服从的条款，通常在美国的任何雇佣手册中都有***。就我个人而言，我一直反对使用这个条款，因为它给了经理一个渠道来训斥甚至开除某人原因，但在你的情况下，这可能是合适的。所以，如果你会这样做的话，请查看员工手册*，并与你的上级讨论一下。

基本思路如下：

1.你设定了至少1-2个员工的规则，并将其作为一个员工的基本守则。你设定的规则是，至少有1-2个或全部人在X小时前到岗 2. 如果你的团队成员没有合理的借口不出现或坚持这种做法，你作为经理应该训斥他们，并可能解雇他们。有很多关于员工不服从的文章，你可以在网上找到，这些只是一些例子：

• BlogSpot
• Duhaime

当然，不幸的后果可能是你的团队中的高翻身率，这将会对你这个经理人产生不好的影响，但它将执行纪律，并可能在这个过程中杀死士气。你真的需要你的团队在他们来的时候就早些到场吗？

基本上，你必须决定什么更重要，是把工作做好，还是在规定的时间里在办公桌前坐8个小时？