GitLab团队成员
- 在GitLab上，每个人都要求领导，无论是个人贡献者还是领导团队的成员。
- 作为领导者，GitLab团队成员将遵循您的行为，因此请始终做正确的事。
- 加入GitLab的每个人都应自视为我们价值观的大使和我们文化的保护者。
- 公司内部和外部的行为应该保持一致，在公司内部做正确的事情，而不是在公司外部伪造行为。
- 由于您最了解自己，因此GitLab会尊重您对最适合自己的判断。如果您在其他地方有更好的机会，不要出于对公司的忠诚感而留在GitLab。
- 在困难时期，人们会为彼此所做的努力。
- 我们异步工作。以身作则，并确保人们理解事情发生时需要将事情写下来。
- 我们不是民主或共识驱动的公司。鼓励人们发表评论和意见，但最终只有一个人在听完所有反馈后才能决定问题。
- 鼓励不同意并进行建设性辩论，但请明智地辩论。
- 我们重视寻求真理而不是凝聚力。
- 我们尽可能避免开会，因为它们不支持异步工作流程，并且由于时区不同而难以进行。
- 准时开始开会，自己准时参加会议，不要问每个人是否在那里，不要通过等待别人或为迟到的人重复做事来惩罚按时出现的人。当会议取消阻碍某个流程或决定的权限时，请不要庆祝该问题，而是要解决以下问题：我们如何在将来不需要会议的情况下取消限制？
- 我们提供了很多反馈。不要拒绝改进建议。
- 如果您遇到外部人，请始终询问他们认为我们应该改善什么。
- 遵循Paul Graham的建议：努力简化组织。
对“您可能已经听到”，“除非您一直生活在笼子里知道”，“每个人都知道”或“您可能知道”这样的说法说是有毒的。知道的人不需要这样说。不认识的人觉得自己错过了一些东西，可能会害怕询问背景信息。
团体
小组是没有直接反映在我们组织结构中的任何人员安排。
管理组
希望管理组的成员以所有GitLab团队成员的方式展现领导才能，此外：
确保团队成员感到包容和被重视是经理最重要的任务之一。与您的团队成员一起积极地建立心理安全性，以便可以听到不同的观点，并且每个人都可以进行交流，并进行真实和创造性的贡献。
- 管理绩效不佳是经理的另一项重要任务。
- 时机成熟时，请保持谦虚。在困难时期，要表达希望。
- 为了维持有效的组织，经理的控制范围应该是7个人左右，范围从4到10。在这个范围以下，额外的组织层的效率低下要比专业团队的收益大。超出此范围，经理不再有时间做适当的1：1。
- 在组织的各个级别，控制范围是相同的。这样可以防止组织增加成本并降低决策速度。要增加报告的数量，您可以增加对直接负责的个人（可能是经理）的委派。调整您希望从现在开始的6个月内组织的位置的报告数量。
- 如果您称赞某人，请尝试在观众面前公开进行。如果您有改进的建议，请一对一地私下进行。
- 了解实现同一目标的方法有多种。有不同的观点，需要进行讨论。
- 当有人说他们正在考虑戒烟时，丢下所有东西听他们讲。提出问题以找出他们的关注点。如果您耽搁，这个人将不会感到被重视，并且这个决定将是不可逆的。
- 除了宣布新的团队成员的到来之外，还会在＃team-member-updates聊天频道中宣布离职（但仅在Google / Slack帐户被撤销后，请查看离职页面和离职清单以了解详细信息）。我们必须尊重有关个人的隐私。如果您被问到为什么有人离开或要离开，请将该人介绍给手册的“ 一般准则”部分，我们在其中描述了可以共享和不能共享的内容。
- 不应因为要求或威胁辞职而给人们加薪或头衔。我们应该积极加薪，提倡无人问津的人。如果您在有人问的时候这样做，那对不问的人是不公平的，最终您会问更多的人。
- 不要把GitLab 当作一个家庭。我们的团队感觉自己像一个紧密联系的团队，这很棒，我们应该鼓励这样做，因为这样可以建立一支更强大的团队。但是家庭和团队是不同的。家人聚在一起为这种关系做些对维持关系至关重要的事情。团队为完成任务而组装，并完成任务。不要把关系放在任务之上。此外，家庭没有下岗过程。家庭应该有无条件的爱，而团队要有条件的爱。最好的公司是家庭的支持者。。您的团队就是您的家人的想法可能会导致不必要的压力：“这个办公室就像一家人一样，因为假期来这里压力不大”
- 赞扬并将报告的工作归功于公司的其他部门，请不要将其作为您自己的报告来展示。可以在Ask MetaFilter线程中找到该课程以及许多其他精彩的课程，值得一读。
- 尝试意识到您的认知偏见。
- 结合一致性和敏捷性。
- 考虑为团队维护一个README文件，该文件记录了您的期望和工作风格。鼓励MR。
- 尽管我们的时间范围较短，但是有一篇很棒的文章介绍了如何考虑PIP。
- 竭尽全力疏导人们。如果某人有一个使他们无法提高工作效率的问题，请尝试自己回答该问题或找一个可以的人。
- 以专业的方式进行交流，好像您的话会被广泛分享（例如，在报纸上发表）。
- 采用多模式通信来广播重要决策。
- 您应该在社交媒体上做出回应。
- 确保您的报告在工作中有进步感。
- 萨姆·奥特曼（Sam Altman）的推文加上保罗·格雷厄姆（Paul Graham）的回复说得最好：“人们要么做事，要么做不到。这很容易被欺骗，因为他们很聪明，但实际上什么也做不了。” 注意结果，而不要清楚地回答问题，否则，您将花费太多时间来确定效果不佳的人。
- GitLab Contribute（以前称为GitLab峰会）旨在在公司范围内进行非正式沟通和建立联系。GitLab Contribute期间的商务活动时间有限，因此我们所有的例行会议都应该在会议之外进行。我们需要非正式的，跨团队的和不限成员名额的会议，其中包括个人贡献者。例如，邀请所有人在GitLab中建议当前缺少的功能。
- 在GitLab Contribute之前，不要拖延决定。取而代之的是，将它们作为完成工作的截止日期。
- 我们在GitLab上没有20％的明确时间。我们衡量结果而不是小时。如果人们在分配给他们的工作中取得良好的成果，他们可以自由地为公司的其他部门做出贡献或从事宠物项目。不要说：“您在那个宠物项目上的工作正在损害您的表现。” 而是说：“我们同意完成X，但是它被延迟了，发生了什么事，我该如何帮助？”
- 在启动新功能之前选择一个指标。10个发射中有9个失败。如果项目无法解决，请完全将其关闭。饿死一支人数众多的团队以使其缓慢死亡既不节俭，也不激励人。为获奖者提供资金，这仍然需要数年的时间才能达到收支平衡。
- 不要提前讨论加薪，因为薪金计算器可能会在决定加薪金额之前发生变化。
- 在整个促销过程都经过促销之前，请勿讨论促销或增加促销金额。人员操作分析师可以在通知团队成员升级和增加时通知经理。
- 与其为报告指明方向，不如按照苏格拉底式的方法提问，直到您对指示感到满意为止。您的报告将在更狭窄的领域中有更深的知识，因此很容易得出不同的结论，因为它们基于不同的数据。这就是为什么问题如此重要的原因。
- 遵循伯克希尔的共同禁令：“总是及时告诉我们坏消息。只有好消息可以等待。” 确保尽快将坏消息通知您的经理。及时报告坏消息对于维护从中恢复所需的信任至关重要。
- 尽量避免军事类比。我们不是军队，没有战争，没有战斗，没有杀害任何人，也没有武器。军事语言不具有包容性，可以导致零和思考。我们非常重视比赛和获胜，但是没有必要使用肢体暴力的词汇来描述事物。同样，非合作性和侵略性术语（例如“ rockstar”和“ badass”）在人与人之间筑起了墙。如果该术语是行业中的标准术语，例如杀死Unix进程，则可以使用它，因为这样效率更高。对于复制机制，请使用“ primary-secondary”而不是“ master-slave”。
- 抱怨并解释。向您的经理提出疑虑。当同龄人或举报人抱怨时，请说明做出决定的原因。如果您不明白为什么，请咨询您的经理。
解释其他领导者做出的决定对他们的团队产生负面影响的决定，从而产生同理心。与您的团队和其他领导者一起组织录制的AMA会议，并鼓励您的团队（以及您自己）提出任何未回答的问题。以身作则，确保讨论揭示出对整个组织最有利的方面。切勿以保护团队免受组织其他成员的伤害为荣。这造成了包围的心态，阻碍了合作。
导演组
期望董事组成员以管理组所有成员的方式展现领导才能，此外：
他们有能力使日常执行与公司的首要目标保持一致。
- 他们进行点对点工作，并在团队中发起健康的冲突，以迅速解决问题，仅在所有选项都用尽时才升级。
- 他们雄心勃勃地为未来3-4年的业务需求定义角色，发展和雇用他们的团队。
他们指导团队在沟通准则内工作并以身作则。
S组
他们负有重大的战略和职能责任。
- 他们负有重要的运营预算责任（诸如薪酬计划，预算分配，谈判，投资权衡决策之类的事情）。
- 他们对大型团队的绩效和成功（直接和间接报告）具有影响力和影响力，他们的成功将导致大量人员的成功率提高。
- 他们决定的影响是广泛而重大的。
- 他们中的一些人具有至关重要的外部责任，以代表公司并做出对公司负责的决策和声明。
这是一个不常见的标题，是一个小组。在未与首席执行官开始讨论之前，请勿对内部/外部候选人设定期望。CEO批准增加所有这些头衔。
电子集团
这些是高管。预计E组成员将以S组所有成员的方式展现领导才能，此外：
- 他们提出了相关，雄心勃勃且可量化的OKR，并实现了其中的70％。
- 他们是可靠的，并确保其团队完成他们同意做的事情。
- 他们积极主动地发现和沟通其职能中的问题，而其他部门甚至没有注意到它们。
- 他们雇用并留住在其职能领域表现更好的领导者。
- 他们创建角色并为3-4年后的需求设定要求，并雇用该个人资料。
- 通过快速迭代并在迭代中培训部门，他们可以完成大量工作。
- 他们定义并传达业务战略和愿景，而不是在业务中过于战术化。
- 他们分享有关其他功能领域的见解，这些领域可以使其他人的工作做得更好。
- 他们建议并实施对我们跨职能流程的改进。
- 他们经常帮助实现超出其功能的结果。
-
做出决定
我们录制了有关此主题的培训视频：
- 我们结合了等级组织和共识组织的优点。分层组织的速度不错，但收集数据的能力很差，导致人们说是，但不这样做。共识组织擅长收集数据，但缺乏速度，导致项目在雷达下进行。我们将决策分为两个阶段。数据收集阶段具有最好的共识组织，每个人都可以参与其中。决策阶段最好采用分层组织，由负责工作的人或经理决定要做什么。
- 如果您在数据收集阶段和决策阶段都应用共识，那么您就会失去速度，并且您做出的决策会一直处于雷达之下，因此可以说服的人更少。
- 如果在数据收集阶段和决策阶段都应用层次结构，则会丢失宝贵的输入。
- 提供输入但不参与决策阶段是违反直觉的，您会被忽略。我们必须接受人们在听我们的意见，但不必欠我们任何解释，而是要根据每个人的意见做出快速决策。
- 在GitLab，决策是基于知识渊博的知识层次，而不是基于共识或民主。对重大决定进行投票表明缺乏知情的领导。
- 做出数据驱动的决策，但要考虑不允许可靠数据收集的环境。根据《哈佛商业评论》的研究，“主题领导者的经验和知识仍然胜过纯粹的数据驱动方法。”
- 分析趋势时，切勿显示累积图，因为即使业务不好，它们也总是向上并向右移动。
- 请注意您的潜意识偏见和情绪触发。
- 我们没有项目经理。个人贡献者需要自我管理。并非每个人都能有效地做到这一点并适合我们的组织。让某人负责管理他人会对可管理自己的人的结果造成负面影响。如果您管理自己，那么您将拥有更大的决策自由，这些决策是基于对情况的深刻了解。我们希望保留能够承担这一责任的人员，因此我们不能保留那些奋斗的人。分配项目经理/协调员/案例经理/等。某事表明某事是错误的，我们正在选择错误的解决方案。
- 做事的人做出决定，他们是直接负责人（DRI）。他们应该听取数据并听取他人的见解以做出决定。做出良好决策的一部分是要知道谁拥有可以为该决策提供依据的良好信息和/或经验。
- 简短地说一句：我们可以允许其他人进入我们的厨房，因为我们总是可以将他们送出厨房（如果您保留自己做出决定的能力，邀请他人提供意见会容易得多）。
沟通应该是直接的，而不是分层的
伊隆·马斯克（Elon Musk）发送了此电子邮件，主题为“特斯拉内部的通信”：关于如何在公司内部流通信息，存在两种思想流派。到目前为止，最常见的方式是命令链，这意味着您始终可以通过经理进行交流。这种方法的问题在于，尽管这种方法可以增强经理的能力，但却无法为公司服务。 与其迅速解决问题（一个部门中的一个人与另一部门中的一个人交谈并做出正确的事情），人们被迫与他们的经理交谈，后者又与他们的经理交谈，而后者又与另一部门的经理交谈。与团队中某人交谈的人。然后，信息必须再次以其他方式回流。这真是愚蠢。任何允许这种情况发生的经理，更不用说鼓励它了，很快就会发现自己在另一家公司工作。别开玩笑了 特斯拉的任何人都可以并且应该根据他们认为是解决问题的最快方法来与他人进行电子邮件/交谈，以使整个公司受益。您可以在未经经理允许的情况下与您经理的经理交谈，也可以直接与另一部门的副总裁交谈，可以与我交谈，也可以未经他人许可而与任何人交谈。此外，您应该认为自己有义务这样做，直到发生正确的事情为止。这里的要点不是随机选择，而是要确保我们执行得非常快和良好。
这些原则也适用于GitLab。管理人员不应成为沟通的瓶颈或孤岛。任何人都应该以可以解决问题的最佳信息与其他人联系。这是一种更高效，透明和协作的工作方式。
提供反馈
我们录制了有关此主题的培训视频：
定期反馈对于经理和团队成员都非常重要。反馈可以采取辅导会议的形式（我们创建了有关辅导的培训视频），与1-1会议分开。提供反馈也与准备工作有关，根据情况，您应该创建单独的议程并按如下方式组织它们：
- 提供背景
- 使用框架获取反馈。示例：1）两个区域：赞美（行之有效的方法）和技巧（可以做不同的事情）或2），三个区域：开始，停止，继续
- 问问自己，这是：
- 可行的
- 具体
- 善良（反馈对人有帮助吗？注意：善良与善良并不相同。）
- 目标（类似于公平）
- 与工作角色和公司比例有关
-
确定根本原因
有时，当性能下降时，解决该问题的最佳方法是尝试确定根本原因。说起来容易做起来难。CEB（现为Gartner）创建了一个出色的工具来帮助解决这种称为性能问题的根本原因。确定问题的根本原因可能并不总是可能或适当的，因此应遵循绩效不佳的过程。
回应负面反馈
作为领导者，您对负面反馈的回应方式会对您的团队产生重大影响。请记住，人们可能很难与有权威的人打交道，并以敏锐和赞赏的态度回应。特别是，我们建议您牢记以下几点：
不要争论或防御。接受反馈是什么-尝试帮助您改善工作或专业关系。如果您确实需要解释自己，请尝试保持同理心。
- 推迟动作很好（甚至更好）。当收到负面反馈时，我们常常感觉我们要么必须证明自己的行动是合理的，要么承诺要做出改变，并且由于当您负责一个大型团队时，改变并不总是那么容易，所以合理性成为默认值。可以说您需要时间评估反馈并决定如何进行。
- 回应负面反馈的正确方法
没有矩阵组织
- 我们相信每个人都应该向一个完全了解并了解您日常工作的人报告。拥有技术上称职的经理的好处很容易对典型工人的工作满意度产生最大的积极影响。我们具有简单的功能层次结构，每个人都有一个在其主题方面经验丰富的经理。Matrix组织很难正确。
- 我们不希望有一个矩阵式组织来与您牵头，但要正式向其他人报告。
- 职能结构的优点是，由于经理比总经理更了解您的工作，因此您可以获得更好的反馈和培训。
- 对于组织而言，放弃单独的管理人员类别可确保结构简单，职责明确。
- 职能组织结构模仿了我们组织的高层结构（财务，销售，工程等）。
- 它减少了补偿成本，协调成本和办公室政治。
- 缺点是您的经理为您提供的时间有限，并且可能缺乏管理人员的经验。
- 为了减轻这些不利因素，我们应该提供足够的培训，指导，支持结构和流程，以确保我们的经理可以在有限的时间内正确处理这些任务。
- 每个人都应该有一位出色的经理，可以为您的事业提供帮助。他们应该让您知道何时需要改进，雇用一支优秀的团队，激励并指导您从中获得最大的收益。
- “对所有矩阵进行核对。对所有双重报告结构进行核对。并且对尽可能多的共享服务功能进行核对。” 从马克·安德森（Marc Andreessen）的优秀指南到大公司（其他指南也很棒）。
- 我们建议阅读“ 高产出管理”，其作者创造了格罗夫定律：所有具有共同商业目的的大型组织最终都采用混合组织形式。我们认为双重报告结构是不可避免的，我们只是想尽可能地延迟它。
- 我们确实通过DevOps阶段组来制作功能，该阶段组由团队和稳定的对应人员组成。
- 每当需要处理特定的，高层的，跨职能的业务问题时，我们都可以组建一个工作组。
- 当您专注于一种产品时，职能公司会更容易。苹果公司专注于iPhone，可以具有单一/功能/集成的组织形式。好处是您可以制作一个强大的集成产品。只要我们继续提供新功能作为GitLab的功能（而不是其他产品），我们还可以维持职能部门的组织。因为我们使用自己的产品而与市场保持联系，这一事实也有所帮助。
- 拥有职能经理意味着他们很少将100％的时间用于管理。他们总是弄脏自己的手。除了为他们提供相关经验外，它还将他们更多地关注于输出功能而不是过程。希望既集中精力又没有很多时间可以减少政治工作量。
稳定的同行
我们希望通过为人们提供他们需要使用的其他功能的稳定人员来促进有机的跨职能协作。例如，每个战略客户主管（SAL）与一个销售开发代表（SDR）合作。对于我们的类别，每个后端开发人员团队都映射到产品经理（PM）和前端团队。为人们提供稳定的对等方可以增加社会信任度和熟悉度，从而加快决策制定速度，防止沟通问题并减少发生冲突的风险。这样，我们可以有效地跨职能开展工作，而无需矩阵组织的不利影响。工厂与工作室
我们想要工厂和工作室的最佳组合。工作室元素意味着任何人都可以加入，从用户到首席执行官。您可以走出工作区域并做出贡献。工厂元素意味着每个人都有明确分配的任务和权限。流程表现不佳
流程信誉不好。它因在GitLab上避免做的事情而享有盛誉。当您拥有不需要的流程时，它将变成官僚机构。批准流程就是一个很好的例子。我们应该通过使人们有权自行做出决定以及在需要时进行快速的轻量级批准过程，来将批准过程减至最少。
但是过程也有好的方面。拥有文件化的公司内部沟通流程，可以大大减少新员工的入职时间，提高速度并防止出错。与直觉相反的效果是，它也使更改过程变得更加容易。确实很难更改一个没有名称或位置并且生活在人们头脑中的不同版本中的过程。更改书面流程和分发差异比较容易。招聘和保留
经理在招募和保留团队成员方面负有巨大责任。
若有收获，就点个赞吧
0 人点赞
