… 新上任的经理以前都是工程师，他们关心工作，总是告诉我「我觉得自己什么也没做，我应该去帮忙什么的。」我会告诉他们，你的工作就是观察。观察你的团队，谁在深夜工作，谁没有。谁完成了他们的承诺，谁没有。让他们的行为引导你去为他们提供他们需要的东西，让他们能够做到最好，而这些事情只有你，作为经理，才能为他们提供。这通常意味着要阻止 incoming 的更多「东西」请求（比如功能之类的），为你的「执行者」腾出时间，帮助新员工尽快上手。在一次 IBM 的经理培训视频中，有一段讨论提到，美国海军训练潜艇上的每个人做每份工作，因为你永远不知道原本负责这份工作的人是否无法工作。这让我深受启发，之后我尝试在团队中重叠技能，进行交叉培训，让每个人都能理解他们的同事在做什么，同时在需要时能互相帮助，如果某部分工作需要暂时更多的努力。
源讨论把它们装上车然后扔到车下原帖 168 条评论 · 导入时统计把你的经验，加入这段讨论。
> 你的工作是观察 学习这一点的一种非常戏剧化的方式是成为一名志愿消防员。在几年的经验之后，你了解了所有角色，他们会让你在一个演练中尝试担任事故指挥官。现在你的工作是保持冷静，睁大眼睛，不要碰设备，管理你的团队。你会一次又一次地失败，直到你终于理解战术指挥官（线经理）的角色。
完整原文我在科技之外也学到了类似的教训...关于低薪员工。人们经常抱怨我们的员工，但如果我们深入挖掘，很多时候问题出在培训、手册、高流动率或管理者没有很好地设定期望上。
完整原文跨培训这一点至关重要。我曾管理或参与过多个运维团队，其中一个人是“网络专家”或“Kubernetes专家”等等。如果这个人因为任何原因离开公司，甚至只是去度假，都会是一场灾难。团队中的成员可以而且应该有他们的专业领域，但你必须绝对地进行文档记录和跨培训，这样当专家无法工作时，有人可以顶上。否则就是管理层的严重失败。
完整原文> 谁在深夜工作，谁没有。 再加上谁早起工作谁没有——仅跟踪某人何时结束工作并不能提供任何信息，除非你知道他们离开时实际工作了多长时间。
完整原文> 我告诉他们，你的工作就是观察。观察你的团队，谁在深夜工作，谁没有。 听起来像一个有毒的环境...
完整原文当然，也有一些人为该经理工作，他们认为自己什么也没做，认为中层管理者是浪费氧气的——尽管事实上，他们正在保护团队免受很多麻烦，正如你所指出的，他们正在做很多协调工作，否则会导致很多无谓的运动。
完整原文> 新上任的经理，以前是工程师，关心工作的人总是告诉我“我觉得自己什么也没做，我应该帮忙或者做点什么。” 你关于管理（与公司沟通，将公司的要求转化为合理、稳定的任务流）的观点非常正确，但我也想指出，目前对工程经理的期望各不相同。 在我第一份工程管理工作中，我因为写了太多代码而受到严厉批评，尽管我有时间，并且自己选择了非关键的任务。公司坚持认为经理应该管理/委派任务，而开发者应该开发，几乎没有重叠。我将此内化为管理的正确方式。 后来在我的职业生涯中，我担任了另一个管理职位，并采用了纯粹的委派策略。后来我因为写的代码不够而受到批评。…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。