领导团队，我太霸道了吗？

我处于一个非常奇怪的位置。我是特定项目的“团队负责人”，职位是高级软件工程师。在我的团队中，我有4个开发人员，其中一个在另一个项目中担任类似的角色，但是现在我的工作已被优先考虑，因此他正在研究我的工作。我也有2位测试员，其中一位是经理。团队的另一个成员是“客户代表”，他是一个完全无关的部门的一部分。我还有一个直接位于我上方的经理，而且我相信也是位于团队中的测试经理的上方...虽然对此不太确定。

我试图弄清为什么我的角色正好是几次。对于我来说，即使我有权力，也很难弄清楚我的权威在哪里开始和结束。我目前正在使用的答案是，我是团队的“技术主管”。这似乎意味着我的权限超过了与产品代码本身相关的，与体系结构，设计和过程/编码标准有关的技术决策。

今天，出现了一些问题，我将代码结果委托给团队中的一位成员，并在我们的Scrum全面展示会议上向公司的其他成员展示了这些结果。客户代表人进行炫耀。今天展示了一些我真的不同意的东西，甚至没人问我是否想对发生的事情发表意见。简而言之，为了提供用户以下列方式在报告中显示值的能力（“ doc”单位，设计单位（四舍五入而不是四舍五入）），他们为每个排列提供了访问字段。因此，我们具有舍入文档单位，舍入设计单位，未舍入文档单位，未舍入设计单位的价值。用户希望使用的每个记录都有许多这样的值，并且每个记录都以这种方式排列。

我真的很讨厌这个

向我们展示这些内容的人想要确保我们用于报表的API与我们执行诸如将数据导出到Excel之类的方式相同。不幸的是，现在我们正朝着我认为非常非常糟糕的方向发展。

在下一次会议上，我确实有点不高兴，我问做这件事的两个人，“我为什么不参与这个决定？” 这是一个不断出现的问题，我很难过，似乎只是让我领导的团队成员问我是否要参与其中。有时我不会，我认为他们想出的办法都会很好。有时候我会。除非人们问我，尽管很难知道正在发生的事情需要我的投入，而他们却没有给我机会。

不幸的是，我的权限并没有告诉别人：“下次您离开并且自己做这样的事情而没有与我交谈时，您将受到纪律处分。” 那是一个“公关”问题，这显然不在我的权限范围之内。实际上，这对我很好，因为如果有人愿意，我不想面对这种垃圾。

但是今天，我的经理在所有人面前（我想这也是我提出这样的错误的部分原因）告诉我，我不能参与所有决定，而需要委托。

我当然认为我是对的。我不是说我认为是BS。我认为应该就此问题与我联系，并询问我是否有更好的主意。我的方向实际上是决定现在提供一个值，因为这实际上是新功能的最开始阶段，并讨论在将来需要时提供进一步访问的选项。我永远不会批准或推荐当前的实现方式，而且我真的认为它不应该成为现实。

问题是，我是一个不合理的人吗？

好吧，我们两个人讨论了这个问题，并同意我们俩都“丢球”，而且我们似乎在同一页上。星期一早上...我们将尝试确保我在团队中的角色清楚，是的，我要决定何时需要进行设计或任务更改。我被提议同意或者决定我需要更深入地研究。然后，我可以尝试其他一些工作，以确保他们知道可以来找我。

听起来您需要监视源提交。Perforce本身具有此功能，Git通过钩子具有此功能，我相信其他人也有自己的方法。您不必每次都提要挑剔，但至少有了通知并加以区分，您可以简要了解一下项目中要进行的所有操作。

至于您的经理说您需要委派，我不确定我是否同意-对于一个由四个开发人员组成的团队，您应该能够处理。再有，我可能会和他（或她）在一起。当然，即使在委派的任务中，您也应该要求状态更新或设计更改的演练等。

没有什么负面应该永远在会议上被提出来-听起来像你和你的经理放弃了球在这一个。绝对最糟糕的事情，你可以永远做一个对是为难他们。作为主管（与您的经理一样），您需要平易近人且值得信赖。信奉某人会导致怨恨，这会削弱您领导团队的能力（以及导致心怀不满的员工）。

我讨厌听到任何扮演主角的人“纪律”。（至少在这种情况下）纪律是消极的，没有生产力。应该与某人（不是在会议场合中亲自或与他人开会）一起工作，找出他们为什么要做某事，如果您不同意他们提出的解决方案，则可以提供其他选择，这是应该做的。有时，您会发现与您一起工作的人是正确的，而您的直觉是错误的。为什么？他们在这个特定问题上花费的时间比您多。

让我担心的另一件事是“我一直认为我是对的”。海事组织，这是任何领导者最糟糕的态度。你应该很明显是在你的能力有信心，但要意识到，如果你不是脖子深的一个具体问题，比不了那么多次，你的建议是未来的你后面出来（不管你有多少经验），不得做最好的。如果有人谁是专注于一个特定的问题提供了一种替代，那么它是你的工作（当然，还有他们的，根据自己的经验等级），以证明为什么你的是更好，而不是只说“我是铅和我一直认为我是对的”，这就是你的一句话使我相信的。

总结一下

是的，您在某些方面不合理，但其他方面则没有。作为负责人，我希望如果有功能或体系结构更改，至少它们由您传递。

但是，确保整体系统和代码质量也是您的工作，您需要自己做。贵公司是否采用代码审查？在进入代码之前，您是否让程序员设计了他们正在做的工作？如果没有，您可能想开始考虑采用这种质量控制机制。

您可能正在接受管理方面的检查，如果失败了，那您就失败了（这可能不是一件坏事；我们中的很多人都是优秀的开发人员，可能会是糟糕的管理人员，我宁愿编程而不是管理程序员）。

经理通常没有执行预期工作的权限。无论如何把事情做好是好经理的标志。您需要找到让人们做事而无需采取任何纪律处分的方法。（注意：不是在公共场合贬低人们。在公共场合赞美，在私人场合批评和对下属作为人们表现出一定的兴趣。）

经理们也必须委派代表，即使这很痛苦。与自己编写该问题相比，您可能会花费更多的时间来处理此问题，这很好。一旦您处理了它，做这些的人应该已经学到了一些东西，并且他们将来不太可能以错误的方式做事。

处理此类问题的正确方法是私下处理，首先要问开发人员为什么要以这种方式进行显示。不在会议中，也不是通过事先假设您是对的而错了（即使您是对的又错了）。给他们一个解释的机会。这并不意味着您必须遵循他们的决定；毕竟，您是技术主管。这确实意味着您需要给他们理由以自己的方式去做，并且您应该解决在该次非公开会议上表现出的任何基本问题。

此外，管理人员应对员工的职责负责。您应该尽量避免被他们所做的任何事情所蒙蔽，特别是在客户面前。这可能涉及跟踪代码签入或与开发人员进行简短的小型会议（尽管您需要注意这一点，但是当他们在区域中时，您不想打扰他们）。可能您应该在与客户代表会面之前的下午与所有开发人员进行交谈。

不要个人

这是团队的努力。您是技术主管，而不是项目的唯一负责人。您应该集中精力让团队从错误中学习或改变流程。

领导与学习

任何领导职位（包括技术主管）的一部分，是要了解您与所拥有的人一起会尽力而为。团队合作的次数越多，他们就会知道何时提出和何时不提出建议。只要确保您不落入指示团队的陷阱即可。每周检查出现问题的地方和进展良好的地方。如果您希望他们以不同的方式做事，请与您的团队进行沟通。惩罚性措施应始终是不得已的手段，通常意味着您要么需要解雇某人，要么您的角色已失败。

客户介绍前进行审查

如果您是项目负责人，为什么不先介绍功能和实现，然后再进行介绍呢？

如果错了修复

清楚地解释为什么出问题了并进行更改。它更昂贵，但是如果确实有问题，请修复它。如果没错，那就与您希望完成工作的方式不同，然后再次；了解您不仅是从事该项目的人。

是否有任何规范记录应实施的内容？鉴于开放要求太高，开发人员通常会用自己认为合适的东西来填补空白（或要求进行微观管理）。

因此，您最终向经理询问“因此，他们决定改用[功能]，而不是研究规范中的内容。现在，我们落后了，因为该功能最初并未得到批准。”

然后，一旦开发人员被重新分配，您就可以开始清理该功能。

编辑>而且，不，我不认为你太霸道了。他们的工作最终成为了您的屁股。

我发现自己经常处于同一位置，并且在会议和讨论中似乎一无所获。有时候，在我辞职去做决定之前（最后不是我的决定），作为最后的手段，我向相关方发送了一封电子邮件，用黑白两色说明了原因。

然后，我将存档该电子邮件，以便确保在以后经理或客户询问为什么要以这种方式完成某件事或为什么更改要花费这么多费用时需要进一步处理时，可以将其备查。

正如您所承认的，我认为按照自己的方式提出建议是错误的。您不会错地说您应该在此级别上对设计有所投入，但是我不确定您希望如何实现这一点是合理的。如果人们认为设计简单明了，他们将不会由您来设计；因为他们很容易就像设计本身一样容易犯错，所以您不会发现有人自愿向您展示他们所有错误的设计。在这一点上，我对您的工作习惯和沟通方式非常好奇，但实际上，无论如何完成这些工作，有时您都会对这些事情视而不见。没有认真检查每个提交，我不确定您如何证明这一点。

我经常在情感上感觉像这样：

 I of course think I'm right....I always do. 

但是我确实有理智地知道我偶尔是错的。我也知道何时打架-您不能为所有事情争辩，有时您达成意料之外的协议可以创造奇迹。

什么是真正的领导者？

是可以解雇下属，任何下属的人。（但无需雇用新员工）

有时，大多数人被“标记”为某个项目的领导者，但是如果没有某人的火力，那么它比真正的领导者更像是“指导” /“老师”。

但是同样，您可能会成为团队的领导者，但不能领导您当前的项目，这可能会发生。在最坏的情况是，当客户是领先的项目。在这一点上，如果项目失败（它将失败），那么这不是您的责任。

而最坏的情况是当存在两个项目负责人时。

作为一个军队，指挥系统就是一切（不是像“为项目而死”那么激进，而是足够接近）。在这件事上，您的经理破坏了您的身份，降低了“您”人员的道德风尚，根本没有帮助。

是的，您的老板是对的-您不能参与每个决定。实际上，除非您自己做所有事情，否则不可能捕捉到这样的一切。我认为这就是您的来历-除非您不参与每个小细节，否则您将无法很好地处理整个项目，但是如果您不参与其中，就无法参与每个小细节（这会使您士气低落。团队，可能会把你累死。

答案不是不要担心出错的事情（它们总是会出错），而是担心以后以建设性的方式解决这些问题。

如果您保持沟通顺畅，则不仅可以委派代表，还可以让高级人员离开并去做他们所需要的事情，而不必总是通过审查，讨论和误导他们来控制他们。相信他们做正确的事，并在那里“聊一聊”正在发生的事情，这样您就可以始终处于循环状态（并在真正需要时保持警惕）。

你有几个问题。首先，您的经理支持您的团队，并告诉您委派更多。这表明您对领导团队的能力缺乏信心。它实际上表明，尽管您拥有技术主管的头衔，但实际上您不是技术主管，因为您没有权限。您需要与您的经理坐下，对此事要放心。没有经理的支持，也没有未经他的同意而有权更改团队做出的设计决策的人，就不可能在技术领导职位上取得成功。您无权完成工作。您的老板需要了解您处于双赢地位，并且他必须向您提供公众支持以使其变得更好。无权负责是发现自己的最糟糕情况。

接下来，您的团队蒙蔽了您。您需要与他们讨论。在他们进行任何开发之前以及他们进行任何公开演示之前，您应该与他们进行设计讨论。可以委派一些设计（虽然不是您，而是您，可以决定您认为应该委派的内容），但是在没有通知您的情况下让他们继续进行是不可行的。他们盲目地失去了您的信任，现在他们必须学习更好的行为。您需要经常与他们核对，以确保他们不会再对您不利，如果确实如此，您应该向HR进行某种形式的问题正式报告。潜在客户并不是受欢迎的潜在客户，当开发人员在被告知不愿意时故意绕着它们走时，他们就应该承担后果。它没有 不管他们是否喜欢你，但很明显在目前他们不尊重你。他们需要针对自己的不当行为征服他们，否则情况只会变得更糟。但是，只有解决了管理支持问题，您才能解决问题的这一部分。

接下来您要公开炸毁，您需要公开道歉。这将帮助您重新建立声誉。

然后，您需要将每个人私下放置，并告诉他们持续的不良行为所带来的后果（一旦您征得了经理的同意，您就可以允许他们给他们造成后果）。公众赞扬和支持，私人批评应该成为您的准则。您可能还需要在小组聚会之外经常与他们联系，以免他们蒙蔽您。

现在坦率地说，由于您上方和下方的人都清楚地认为您是一个可以被忽略且不了解情况的人，因此您需要认真思考一下自己是什么导致他们不尊重您。您还需要确定，如果不成为技术负责人会更高兴，还是应该继续前进到有权承担责任的地方。如果您决定要留在这个位置，您将不得不要求人们与您保持一致，以了解他们为什么如此恶劣地对待您。那会很痛苦，您可能不想听到答案，但是您需要知道为什么他们被他们清楚地感知到您。