CREDIT

GitLab的六个价值是合作结果效率多样性和包容性,迭代,和透明度。一言以蔽之,他们的英文首字母是CREDIT。以下将阐述他们如何实行的。

关于我们的价值观

我们从其他公司那里获得灵感,我们一直在寻求简单直接的方案。如同我们其余的工作,我们不断调整我们的价值观,并不断努力改进它们。我们曾经总结出繁杂的价值观体系,发现过于复杂难记,因此我们将它们压缩成五个基本价值观,创建了首字母缩写词。欢迎大家提出改进建议。

Comment:一个组织如要建立企业文化,其核心务必简单直观。(huangyi)

合作

帮助他人是当务之急,即使与您要实现的目标没有直接关系。同样,您可以依靠其他人的帮助和建议-实际上,您应该这样做。任何人都可以涉足任何主题,包括不在GitLab工作的人。负责这项工作的人可以决定如何执行,但是他们应该始终认真对待每个建议,并尝试做出回应并解释为什么可能没有实现。

善良

我们重视关怀他人。证明我们关心人民为直接挑战和提供反馈提供了有效的框架。我们不同意说“准确评估人”而不是“善待人”的公司。我们都希望进行准确的评估,但是我们认为必须以一种友好的方式进行评估。尽可能多地提供正面反馈,并以公开方式进行。

分享

GitLab文化的某些方面(例如极高的透明度)对于局外人和新团队成员而言并不直观。愿意投资于人并参与公开对话。例如,考虑尽可能公开公开私人问题,以便我们都可以从经验中学到东西。
每个人都可以提醒公司中的任何人关于我们的价值观。如果对解释存在分歧,则可以将讨论升级为公司内更多人员,而不会造成任何影响。
分享遇到的问题,寻求帮助,提供信息并大声说出来

负数是1-1

以尽可能小的设置给出负反馈。首选一对一视频通话。如果您对任何事情(您的职责,您的同事,您的老板,您的薪水,您的位置,您的计算机)不满意,请在意识到后立即通知您的老板或首席执行官。我们希望在问题小的时候解决它们。

说谢谢

认可公开帮助您的人,例如在我们的#thanks聊天频道中

有效地提供反馈

提供反馈具有挑战性,但是有效地提供反馈很重要。提供反馈时,请始终对工作本身进行反馈。关注业务影响而不是人员。确保至少提供一个清晰的最新示例。如果一个人在自己的生活中正处于艰难时期,则应考虑到这一点。提供正面反馈的一个例子是我们的感谢聊天频道。对于经理来说,重要的是要意识到员工对经理负面事件的反应要强六倍比他们积极的一面。请记住,如果错误如此无关紧要,以至于从提供批评中获得的价值很低,那么将这些反馈留给自己可能是有意义的。在必须提供负面反馈的情况下,请专注于该反馈的目的:提高员工的绩效。在公开场合慷慨地给予认可,并通常会引起团队的更多参与

了解对方

我们使用了大量基于文本的交流,如果您知道文本背后的人,则可以更轻松地防止冲突。因此,我们鼓励人们通过我们的公司通话,虚拟咖啡聊天以及在GitLab Contribute期间在个人层面上互相了解。

不要拉等级

如果您必须提醒某人您在公司中的职位,则说明您在做错事。人们已经知道我们的决策过程。说明您做出决定的原因,并尊重每个人,无论他们的职能如何。

假设积极的意图

对于他人的行为,我们自然有双重标准。我们将自己的错误归咎于环境,而个人的错误归咎于个人。此双重标准称为基本归因错误。为了减轻这种偏见,您应该始终在与他人的互动中表现出积极的意愿,尊重他人的专业知识,并在面对可能被您视为错误的事物时给予他们宽容。当不同意时,人们有时反对最弱的论点,或者有时反对“稻草人”。假设要诚实地提出要点,而要争辩“钢人”(或“强人”)

那是当您清楚表达对手立场的绝对最强观点时,甚至可能比对手提出的观点更为强烈。良好的钢铁人论据是另一个人认为您很好地表达了他们的论据,即使他们仍然不同意您的假设或结论。

解决行为,但不给人贴标签

目前在很多的好文章关于我们的团队不想抽搐,但我们认为,jerk是行为的标签,而不是一个人的内在的分类。我们避免分类。(jerk:起源于2009年美国L.A的一群青少年,除了是新兴的街舞风格外,也是一种正面积极的生活态度—反对暴力霸凌、金钱勒索、吸毒酗酒等与次文化中给人的负面形象。)

说声抱歉

如果您输入有误,则表示歉意。表示歉意不是软弱的标志,而是力量的一种。做最多工作的人可能会犯最多错误。此外,当我们分享错误并引起他们的注意时,其他人可以向我们学习,并且其他人不太可能重复相同的错误。

没有自我

不要为赢得论点辩护或为错误加倍辩护。你不是你的工作;您不必捍卫自己的观点。您必须在其他人的帮助下寻找正确的答案。

看到别人成功

一位与GitLab内部很多人交谈过的候选人说,与其他公司相比,一件事情最引人注目:这里提到的每个人都希望看到彼此成功。

人不是他们的工作

始终对工作实例而不是人员提出建议。说,“您没有回应我对设计的反馈”,而不是“您从不听”。而且,在收到反馈时,请记住,反馈是改进的最佳方法,并且其他人希望您获得成功。

自己做

我们的协作价值是在遇到问题,需要批评或需要帮助时互相帮助。无需集思广益,等待共识或做两个自己可以做的事情

无懈可击的解决问题

以侧重于失败机制的情境方面和导致失败的决策过程的方式调查错误,而不是责怪个人或团队。我们进行无罪的根本原因分析回顾,让利益相关者大胆发言,而不必担心受到惩罚或报应。

脚趾短

加入公司的人们经常说:“我不想踩任何人的脚。” 在manbetx客户端打不开我们应该更多地接受人们主动尝试改善事物。随着公司的发展,由于涉及更多的人,因此决策速度下降。我们应该以脚趾短小并让其他人为我们的领域做出贡献而感到舒适。

不可能一无所知

我们知道,我们必须依靠别人来获得我们所没有的专业知识。承认自己一无所知并寻求帮助是可以的,即使这样做会使您感到脆弱。提出问题永远不会太晚,这样您就可以获取生成结果并增强自己的技能以及整个GitLab所需的信息。在回答您的问题后,请记录下答案,以便可以共享
当人们说自己不知道某事时,请不要感到惊讶,因为让每个人都说“我不知道”和“我不理解”感到很重要。(受Recurse启发。)

结果

我们遵守彼此,客户,用户和投资者的承诺。

狗粮
  • 我们使用自己的产品。我们的开发组织使用GitLab.com来管理GitLab的DevOps生命周期。
  • 我们整个公司都使用manbetx客户端打不开来合作本手册。我们还将在Git仓库中捕获其他内容和流程,并通过GitLab对其进行管理。
  • 当出现问题,无法正常工作或需要改进时,我们更有可能在内部发现问题并在其影响整个社区之前加以解决。
    测量结果而不是工时
    我们关心您取得的成就;您提供的代码,让您满意的用户以及您帮助的团队成员。下午休假的人应该不会觉得自己做错了什么。您不必捍卫自己的一天。我们信任团队成员做正确的事情,而不是制定严格的规则。不要通过宣布您昨天工作了几个小时来煽动竞争。如果您工作时间过多,请与您的经理讨论解决方案。
    给予代理商
    我们给人们提供代理,使他们专注于他们认为最有益的事情。如果会议看起来不那么有趣,并且某人的积极参与对会议的结果并不重要,那么他们总是可以选择不参加,或者在视频通话中,他们可以根据需要处理其他事情。即使您正在执行其他任务,仍然可以保持通话畅通无阻,因此其他同伴可以ping您并在需要时快速获得答复。这在您可能只参与几分钟的多用途会议中特别有用。
    写下诺言
    就可衡量的目标达成书面协议。在公司内部,我们为此使用公共OKR(OKR:目标和主要结果)
    成长心态
    您并非总能获得结果,这将导致您和/或其他人的批评。我们相信,我们的才能可以通过艰苦的工作,良好的策略和他人的投入得到发展。我们试图根据他们的轨迹而不是他们的血统来雇用他们
    全局优化
    这个名字来自于Stripe文化快速指南。我们对全局优化的定义是,您要做对整个组织最有利的事情。当它对其他团队,我们的用户和/或公司的目标产生负面影响时,请勿针对您团队的目标进行优化。这些目标也是您的问题和您的工作。使您的团队保持精简,并帮助其他团队实现目标。在协作的背景下,这意味着,如果有人在您的某个问题,您的批准或合并请求审核中被您阻止,则您的首要任务始终是直接取消阻止他们,或者通过帮助他们找到可以解决的其他人,即使这需要花费您自己或团队的优先重点。
    韧性
    我们称此为“目标的持久性”。正如在The Impact Blog中所谈到的那样,坚韧是表现出对自己所相信的信念的能力。您不断振作起来,除尘自己,并在学到了更多知识后迅速开始前进。
    所有权
    我们希望团队成员完成分配给他们的任务。拥有任务意味着您有责任预测和解决问题。作为所有者,您负责克服挑战,而不是供应商或其他团队成员。主动解决问题,并主动通知利益相关者。
    紧迫感
    在成倍的缩放比例下,获得或失去的启动时间会产生复合影响。尝试尽快获得结果,以便开始进行结果复合,我们可以专注于下一个改进。
    雄心勃勃
    在进行小的更改的同时,我们也在努力取得宏伟的成果。
    毅力
    在GitLab工作将使您面临各种难度和复杂性的情况。这需要重点,并需要延迟满足的能力。我们重视在艰苦的工作中保持专注和动力的能力,并在需要时寻求帮助。
    行动偏见
    重要的是,我们必须专注于行动,不要陷入分析瘫痪的陷阱,也不要陷入无风险的缓慢而安静的道路。决策应该考虑周到,但是要想迅速取得结果,就需要无所畏惧地接受偶尔犯的错误。我们对行动的偏见也使我们能够迅速纠正。
    接受不确定性
    能够接受我们对正在尝试做的工作不了解的事情的能力,消除不确定性的最佳方法不是通过分层分析和推测,而是接受并移动向前,随着我们的前进赶尽杀绝。可以解决错误的解决方案,但是根本不存在无法解决的问题。聪明的PM博客
    客户结果
    我们的重点是改善客户获得的结果,这需要了解Concur效果有关特定的UX示例,请参阅Hacker News讨论客户结果比以下内容更重要:
  1. 我们打算做什么。如果我们仅专注于自己的计划,那么我们将只有GitLab.com,而不会自行托管GitLab。
  2. 大客户。这导致了创新者的两难境地,因此我们也应该关注小客户和未来的客户(用户)。
  3. 客户要求什么。这意味着,我们不使用“以客户为中心”一词,因为它会诱使我们优先考虑客户所说的需求,而不是我们在产品开发过程中发现的实际需求。通常,对于客户而言,根据特定的解决方案进行思考比考虑需要解决的核心问题要容易得多。但是,对一个客户有效的解决方案并不总是与其他客户相关,并且可能与我们的整体产品战略不符。当客户要求某些特定的东西时,我们应该努力理解原因,努力理解更广泛的影响,然后创建可扩展的解决方案。
  4. 我们现有的范围。例如,当客户要求更好的集成并抱怨集成成本和工作量时,我们的回应是扩大了范围,为DevOps生命周期创建了一个应用程序
  5. 我们的假设。每个公司的运作方式都不尽相同,因此我们不能认为对我们有效的产品将满足客户的需求。当我们有一个想法时,我们必须直接与客户确认我们的假设,以确保我们创建可扩展的,高度相关的解决方案。
  6. 我们控制什么。我们应该对客户的经历负责,即使这并非完全由我们控制。例如,当客户管理的实例停机可能是每天100万美元的问题时,我们仅查看GitLab.com 。

    效率

    我们关心的是做正确的事情,不要做超出需要的事情,并且不要重复工作。这使我们能够取得更大的进步,从而使我们的工作更加充实。

    好记性不如烂笔头

    我们将所有内容记录下来:手册,会议记录和问题。我们这样做是因为“ 最微弱的铅笔比最清晰的记忆更好 ”。在您方便的时候阅读文档比问和解释要有效得多。在版本控制中包含一些内容,还可以使每个人都提出改进建议。

    无聊的解决方案

    使用最简单,最无聊的解决方案来解决问题,并记住“无聊”不应与“坏”或“技术债务”混为一谈。我们组织和产品的创新速度受到我们添加的总复杂性的限制,因此到目前为止,每降低一点复杂度都会有所帮助。不要仅仅选择一种有趣的技术来使您的工作更有趣。使用成熟的流行技术将确保您和其他贡献者获得更稳定和更熟悉的体验。
    做出有意识的努力,以认识团队中其他人的约束。例如,销售困难是因为您依赖于另一个组织,而开发困难是因为您必须保留在将来快速改进产品的能力。

    合适人群的效率

    在全球范围内为更广泛的GitLab社区优化解决方案。对于一个人或一小群人来说,使流程高效可能不是整个GitLab社区的有效结果。例如,最好选择一种流程,使您的工作效率稍微降低一些,同时使数千名客户的工作效率大大提高。例如:选择替换一个续签过程,该续签过程需要1,000名客户每个人花费2个小时,而这只需要60秒,即使这可能会使内部月度报表的效率降低!在决策中,问自己“这对于谁最有效?”。通常,答案可能取决于您的用户,贡献者,客户或团队成员。

    尊重别人的时间

    考虑一下您要求其他人通过会议和许可流程进行的时间投入。尽量避免开会,如果有必要,尽量让尽可能多的人参加。任何会议都应有与邀请相关的议程,并且您应记录结果。与其让别人征求许可,不如相信他们的判断并在遇到问题时提供咨询过程。

    像花钱一样花公司钱

    我们花掉的每一美元都必须赚回来。与自己一样,省钱省钱。

    节俭

    亚马逊最擅长的是:“事半功倍。约束会养育足智多谋,自给自足和发明。增加员工人数,预算规模或固定费用没有额外的要点。”

    转换率

    我们按照对话发展的原则工作。

    自由

    您应该有明确的目标,并可以自由选择合适的目标。

    简短的口头回答

    简短回答口头问题,以便对方有机会提出更多要求或继续前进。

    简短的口头回答

    并如本HBR研究中所述,保持一对多的书面简短交流:“大多数人说,他们阅读的内容常常太无效,因为它太长,组织不清,不清楚,充满术语和不精确。”

    一位经理

    我们希望每个团队成员成为不需要每天签到即可实现目标的经理

    对刚性的责任

    在可能的情况下,我们让人们有责任做出决定并让他们对此负责,而不是强加规则和批准程序。

    接受错误

    并非每个问题都应导致新的过程来防止它们发生。附加的流程会使所有动作的效率降低,一个错误只会影响一个动作。

    通过运送最小的可行变更来快速行动

    我们重视通过每月一次的快速迭代来不断改进。如果一项任务太大而无法在一个月内完成,请缩小范围。

    多元化与包容性

    多样性和包容性是GitLab成功的基础。我们的目标是在我们努力营造所有人都可以成长的环境方面产生重大影响。我们正在设计一种多维方法,以确保GitLab是一个来自各个背景和环境的人都觉得自己属于并能做出贡献的地方。我们积极选择建立一种包容性的文化并使之制度化,并在实现其职业目标的过程中平等地支持所有员工。我们在全球范围内招聘,并鼓励在多个国家/地区招聘。我们努力使每个人都受到欢迎,并增加代表性不足的少数民族和我们社区和公司的参与。例如我们的赞助多样性活动双重推荐奖金

    偏向异步通信

    主动尽可能地异步操作。这表明了对那些不在同一时区,不在正常时区旅行或正在安排在家中或社区中紧迫承诺的一天的人们的关心和考虑。
    通过传达会议记录,使用GitLab问题和合并请求(而不是文本,呼叫或Slack消息)并且对本地假期和休假状态敏感,可以证明这一点。鼓励其他人默认使用文档,而不是强迫其他人在工作时间之外上网。

    跨公司部门

    在职能部门内寻求专家建议是明智的,但我们鼓励GitLab团队成员在部门之间寻求并提供反馈。这使团队可以更快地进行迭代,并考虑了更多样化的观点。

    让家人感到宾至如归

    远程文化的独特元素之一是能够在协作时访问一个人的家。如果会议期限允许,欢迎您邀请您的家人或宠物前来欢迎您的同事。

    根据原因改变工作时间

    护理,外展计划和社区服务无法方便地等待正常的工作时间结束。如果您出于事业或社区的需要而努力,欢迎与您的经理一起工作,并在可以带来最大影响的时期内改变工作时间。对于在这些原因下支持他人的同事,请记录所有内容并努力发布录音,以使他们很容易跟上。

    成为导师

    人们得到支持后会感到更多的包容。为了鼓励这种情况并支持跨部门的多元化学习,请考虑GitLab的“学习实习”计划。

    文化契合是一个不好的借口

    我们不根据文化来招聘或选择候选人,因为我们想和他们一起喝酒。我们根据此页面上详述的共同价值观雇用和奖励员工。我们想要的是价值观,而不是文化。我们想要的是文化多样性,而不是文化整合,例如,暴徒氛围。换句话说:“文化添加”>“文化契合度”或“聘请文化贡献者”,因为我们的使命是每个人都可以贡献力量

    工作中的宗教和政治

    我们通常避免在公共论坛上讨论政治或宗教,因为很容易疏远少数派人士。这并不意味着我们从不讨论这些主题。因为我们重视多样性和包容性,并希望所有团队成员都能受到欢迎并做出同等贡献,所以我们鼓励对运营决策进行自由讨论,以使我们成为更具包容性的公司。GitLab还公开支持支持多样性的活动。
    个人在社交场合中提出政治和宗教信仰也可以接受,例如与其他同事聊天,进行现实生活中的聚会(目的是理解而不是判断),但要始终保持敏感,做出最佳判断,并确保您遵守我们的行为准则的范围

    诡诈

    意外和非常规的事物使生活变得更加有趣。庆祝和鼓励古怪的礼物,习惯,行为和观点。一个例子是我们公司的电话会议,我们花费大部分时间谈论从私人投掷到编织的私生活。开源是与有趣的人互动的好方法。我们尝试聘请认为工作是表达自我的好方法的人。

    建立一个安全的社区

    不要开有关种族,民族,肤色,性别的玩笑或发表性取向不友好的言论。每个人都有权在为GitLab工作和/或作为GitLab社区的一部分时感到安全。我们不容忍任何社区成员(包括我们的员工)的虐待,骚扰,排斥,歧视或报复。您总是可以拒绝与对您不好的人打交道,并摆脱使您感到不舒服的情况。

    无意识的偏见

    我们认识到无意识的偏见会影响每个人,并且它对我们作为人类和我们公司的影响是巨大的。我们有责任了解我们自己的内隐偏见,并帮助他人了解他们的内隐偏见。我们正在不断努力以使这个主题变得更好

    包容性利益

    我们公开列出了我们的跨性别医疗服务育儿假,这样人们在面试时就无需提出要求。

    包容性语言和代词

    使用包容性语言。例如,与“嗨大家”相比,更喜欢“大家好”或“嗨人”。尽管有一些不错的指南,例如18f卡尔加里大学Buffer等使用包容性语言的人,但我们并没有列出详尽的清单。当出现新的可能不包容性的词语时,我们宁愿积极主动并寻找替代方案。如果您的目标是包容性强,那么在某些人遇到问题时对词汇表进行少量调整会比在某些人认为这不是问题的情况下决定不更改它更有效。如果您犯了一个错误(例如,不小心使用了错误的代词或过时的短语),请予以承认,,此刻无需赘述。之后,您可以努力避免将来犯此错误。如果您对代词和其他与性别/性取向有关的主题有疑问,请访问我们的性别和性取向身份定义和常见问题页面。

    包容性面试

    这记录在我们有关面试的页面上。

    看到什么说什么

    作为一家遍布全球的公司,我们拥有来自许多不同背景和文化的员工。这意味着对我们每个人来说,在尊重和包容队友时要运用出色的判断力,这一点很重要。同时,有时我们可能无法完全意识到自己曾说过或做过得罪某人的事情。重要的是,我们的队友要互相追究责任,并让他们知道自己是否无意或有意做某事,以便他们可以学习并获得对不同于我们自己观点的更多理解。同样重要的是,我们的队友不要被我们使用的文字或我们所做的事情而感到被排斥或贬低。因此,当我们看到不尊重或包容的事物时,我们所有人都需要大声疾呼。

    神经多样性

    神经多样性是一种多样性,包括自闭症,注意力缺陷多动症和其他类型的神经多样性功能。尽管他们经常带来独特的技能和能力,可以利用这些技能和能力在包括网络安全在内的许多领域中获得竞争优势,但神经分化型个体通常会受到歧视,有时很难通过传统的招聘流程来实现。这些人应该能够作为GitLab团队成员做出贡献。手册,价值观,策略和访谈过程绝不应歧视神经。

    家人和朋友第一,工作第二

    持久的关系是人生的坚石,是上班前必不可少的部分。正如某人在我们的#thanks频道中说的那样,在飓风过后帮助了家人5天之后:“感谢GitLab提供真正意义上的“家庭至上”的文化。”

    迭代

    我们做最小的事情,并尽快推出。如果您提出的建议可以从第一次迭代中排除,则将它们变成您链接的单独问题。不要写一个大计划,只写第一步。相信您会在发布某些内容后更好地知道该如何进行。如果您对第一次迭代中提供的最小功能集感到有些尴尬,那您就做对了。加入GitLab时,这个价值是人们最被低估的。对您的工作流程和成就的影响都比预期的要大。刚开始时,做出快速的决定以及减少咨询会改变一切都是很痛苦的。但是,最简单的版本经常是最好的版本。
    加入GitLab的人们都说他们已经练习了这个迭代。但这是他们最难采用的价值。人们受过训练,如果您不提供完美或精致的东西,您会为此而感到嫉妒。如果您只做一件事情,就必须重新做。整个过程似乎更有效率,即使事实并非如此。如果不清楚整体情况,则可能无法像您希望的那样感知您的作品。制作一个全面的产品似乎更好。他们看到GitLab组织中的其他人在迭代方面确实很有效,但不知道如何进行过渡,并且很难摆脱对不断迭代可能导致交付质量较低的产品或劣质产品的担忧。
    解决此问题的方法是仅记下您目前在此项目上所能做的事情。那可能是5分钟或2个小时。想一想您可以在那时完成的事情会改善当前的状况。迭代可能令人不舒服,甚至痛苦。如果您正确地进行迭代,则应该如此。
    但是,如果我们采取较小的步骤并提供较小的简单功能,则会更快获得反馈。我们可以花费最小的产品,获得快速的反馈并正确执行路线,而不必花时间在错误的功能或错误的方向上工作。人们可能会问为什么有些东西不完美。在那种情况下,提到这是一个迭代,您只花了“ x”个时间,而下一个迭代将包含“ y”并准备好在“ z”上。

    不要等

    不要等 当您拥有有价值的内容(例如潜在的博客文章或小的修订)时,请立即实施。现在,一切都在您的脑海中焕发,您有了动力,灵感就荡然无存。不要等到有了更好的版本。不要等到录制更好的视频。不要等待事件(例如Contribute)。未发布的库存是一种负债,因为必须对其进行管理,过时,并且当您立即实施该库存时,您会错过获得的反馈。

    减少周期时间

    短迭代减少了我们的周期时间

    作为社区的一部分

    小迭代使与更广泛社区的合作变得更加容易。他们的工作看起来更像我们的工作,我们的工作也更快地收到反馈。

    最小可行变化(MVC)

    我们鼓励MVC尽可能小。始终希望尽可能快地进行更改以改善用户的结果。如果您确认更改所增加的价值超过现在的价值,那么那就去做。无需等待更强大的功能。有关更多信息,请参见产品手册,但这适用于我们在所有功能上所做的所有事情。专门针对产品MVC,还有责任与客户确认我们正在添加有用的功能而没有明显的错误或可用性问题。

    提出建议

    如果您需要以团队的方式做出决定,请提出一个具体的建议,而不要召开会议以征求大家的意见。提出建议将更有效地利用每个人的时间。每次会议都应是对提案的审查。我们应该自己动脑筋,而不是大声疾呼。说明潜在的问题,以便人们有足够的背景来提出合理的选择。如果实施了完全不同的提案,收到提案的人应该不会感到被排斥,制作提案的人也不会感到难受。不要让您希望尽早介入,也不要希望看到您的解决方案已实施,从而阻碍了您获得最佳结果。如果您没有建议,不要阻止您突出问题,请声明您无法想到一个好的解决方案,并列出您考虑的任何解决方案。

    一切都在草稿中

    在GitLab,我们很少将草稿放在任何内容或建议上。一切总是草稿,并且随时可能更改。

    正在施工🚧

    随着我们获得更多用户,他们会要求稳定性,尤其是在我们的用户体验中。我们应该始终进行长期优化。这意味着短期内会给用户带来不便,但是当前和将来的用户最终都会享受更好的产品。

    低耻度

    当我们与纳特·弗里德曼(Nat Friedman)交谈时,他说:“低耻辱是您的文化所固有的。” 这可以通过运送尚未到达我们想要的位置的东西来捕捉我们的痛苦。

    专注于改善

    我们认为,伟大的公司听起来是消极的,因为他们专注于自己可以改进的地方,而不是工作中的问题。在与公司外部人员进行的每次对话中,我们的第一个问题应该是:您认为我们可以改善什么?这并不意味着我们不承认自己的成功,例如,看到我们的“感谢声”价值。我们对公司的未来充满信心;我们是当今的悲观主义者和长期乐观主义者。

    做无法扩展的事情

    首先优化速度和结果;当成功时,找出如何扩展它。保罗·格雷厄姆(Paul Graham)的这篇文章就是很好的例子。

    做出双向门决定

    大多数决定很容易被推翻,直接负责的个人在未经批准的情况下做出决定。正如杰夫·贝佐斯(Jeff Bezos)所描述的那样,只有在您无法撤消它们时,才需要进行更彻底的讨论。

    更改提案不是迭代

    更改提案不会重复进行。只有将更改发布给用户后,您才能从反馈中学习。当您基于不同的意见更改提案时,您经常在浪费时间。最好迅速推出一个小的更改并获得现实世界的反馈。
    我们如何进行迭代遇到了一些挑战。最好的例子可能是建议将发布周期设为2个月。有观点认为更长的发布周期将为我们争取时间来进行错误修复和功能开发,但我们认为并非如此。如上所述,我们的目标是使绝对最小的事情成为可能,否则这样做只会减慢我们的速度。
    也就是说,我们很乐意以2周的发布周期进行工作,但这应该是另一回事。

    提出小的合并请求

    当您提交合并请求以进行代码更改或手册中的过程更改时,请使其尽可能小。如果要在手册中添加新页面,请创建少量初始内容的新页面,使其快速合并,然后在后续合并请求中迭代添加其他部分。同样,如果您要向软件中添加较大的功能,请针对不同方面创建较小的迭代合并请求。这些合并请求可能不会提供即时价值,只要它们不破坏任何内容并对新功能进行适当的测试即可。如果您不确定如何将某些内容拆分为多个小的合并请求,请考虑向您的团队和/或维护人员寻求建议。如果要求您审查太大的合并请求,

    当我们慢慢地迭代

    在某些情况下,快速迭代会影响结果。例如,在调整我们的营销消息(一致性是关键),产品类别(我们制定开发计划),销售方法(我们对团队进行培训的地方)和此价值页面(在其中我们使用价值来指导所有人)时, GitLab团队成员)。在这些情况下,我们会在批准过程中添加其他审核,而不是禁止审核,而是在我们的迭代过程中更加审慎。更改过程记录在页面上,并通过合并请求批准进行。

    透明度

    开放尽可能多的东西。通过公开信息,我们可以降低贡献的门槛并简化协作。尽可能使用公共问题跟踪器,项目和存储库。
    一个示例是该网站公共存储库,其中也包含该公司手册。默认情况下,我们所做的一切都是公开的,例如,GitLab CEGitLab EE问题跟踪器,以及市场营销基础架构。透明度提高了GitLab的知名度,使我们能够招募关心我们价值观的人员,它能使我们从公司外部的人员那里获得越来越多的反馈,并使与他们的协作变得更加容易。它还涉及到本着开源精神与整个社区和全世界共享出色的软件,文档,示例,课程和流程,我们认为开源所带来的价值大于所获取的价值。
    也有例外。默认情况下不公开的材料已记录在案。我们在保持事物机密性方面处于平均水平之上。在个人层面上,您应该像说的那样告诉自己,而不是摆出一张扑克脸。不要害怕承认您犯了一个错误或错了。当出现问题时,这是一个很好的机会,说“这里的改善时刻是什么?” 并找到一种更好的方式而不会有伤害的感觉。
    即使我们要成为一家上市公司或其他公司,我们也知道透明度的价值将是我们成功的关键。公司价值常常随着增长而被摊薄,这很可能是因为它们没有写下来任何东西。但是,我们将确保我们的价值观随着公司而扩展。当我们公开上市时,我们可以宣布公司中的每个人都是内部人员,这将使我们能够在内部对我们的人数保持透明,等等。所有其他可以透明的事物将继续如此。

    默认公开

    默认情况下,GitLab上的所有内容都是公开的。如果某些不公开的内容,则手册中应有引用说明,指出做出的机密决定与我们的“不公开”准则相关联,除非法律认为这样做会带来不适当的风险。公共过程有两件事:允许其他人从对话中受益并充当过滤器;由于只有有限的时间,因此我们优先考虑可让更多受众受益的对话。

    不公开

    默认情况下,大多数事情都是公开的。但是由于问题或要求的敏感性,有些事情是不公开的。

    直接

    直率意味着彼此透明。我们试图通过坦率和友善来传达我们内在的本·霍洛维茨,这是一种无聊无聊,无混蛋的罕见鸡尾酒。反馈总是关于您的工作而不是您的人。这并不意味着给予或接受它都会很容易。

    建设性的表面问题

    在正确的时间(仍可采取行动时)对正确的人(向上)保持透明。如果您犯了一个错误,请不要担心。进行纠正,并主动让受影响的一方,您的团队和首席执行官知道发生了什么事情,如何纠正它以及如何(如果需要)更改流程以防止将来出现错误。

    任何人都可以质疑

    只要您按照决定行事,直到改变为止,任何过去的决定和准则都容易受到质疑。

    不同意,承诺和不同意

    一切都可以受到质疑,但是只要有适当的决定,我们希望人们致力于执行该决定,这是一个普遍原则。每个决定都可以改变,我们最好的决定是改变一个较早的决定。当您想重新讨论某件事时,请表明您的论点是由先前的对话所引起的,并假定决策是出于最佳意图。即使决定要做出更改,您也必须在每项决定立时取得结果。您应该与可以更改决定的DRI进行沟通,而不是与不能更改的人进行沟通。

    透明度只有在困难时才能做到

    例如,加利福尼亚的许多公司没有提供拒绝他们申请的真正原因,因为这增加了提起法律诉讼的机会。我们只想出于正确的理由拒绝别人,我们想通过获得这些反馈使他们有成长的机会。因此,我们将承受越来越高的风险来坚持自己高水平的决策,并通过告诉他们我们的想法来做正确的事。其他示例对于安全事件是透明的,并参与直播并为直播做出了贡献。

    真理的单一来源

    通过使大多数公司沟通和工作成果在互联网上公开,我们为所有GitLab团队成员,用户,客户和其他社区成员提供了一个真实的来源。我们不需要对不同人员具有不同权限的单独工件。

    找到极限

    我们接受我们偶尔会在透明度方面犯错误。换句话说,如果我们有时会公开那些本来应该保密的信息,那么我们会接受。随着时间的流逝,大多数公司变得不透明,因为它们不接受任何错误。犯错并反思它们意味着我们知道透明度的极限在哪里。

    说为什么,不只是什么

    透明的更改具有导致更改以及更改本身明确列出的原因。由于人们已经有了一定的了解,因此以后产生的问题更少了。在没有公开解释的情况下进行更改会导致很多额外的询问,但效率较低。避免使用诸如“行业标准”或“最佳实践”之类的术语,因为它们含糊,不透明并且没有提供足够的上下文作为进行更改的原因。

    重现性

    使涉及的每个人都能得出与您相同的结论。这不仅涉及推理,还涉及例如提供原始数据而不仅仅是绘图。脚本来自动执行任务,而不仅仅是完成的工作;分析问题时记录步骤。即使他人可能不同意,也要尽力使思路透明。

    问责制

    在制定决策和做出艰难选择时增加问责制。

    五个功能障碍

    我们的价值观有助于我们预防这五个功能障碍

  7. 缺乏信任不愿意在团队中变得脆弱=> 通过合作,特别是 友善来阻止

  8. 对冲突的恐惧在建设性的激烈辩论中寻求人为的和谐=> 透明,特别是 直接 和协作,特别是 短脚趾阻止了这种冲突
  9. 缺乏承诺冒充团体决策的买主在整个组织内造成歧义=> 受到透明度(尤其是 直接性)的阻碍
  10. 避免问责制承担起责peer同行的反生产行为的责任,该行为设定了低标准=> 受结果,迭代和 透明度的阻碍
  11. 对结果的注意力不集中在团队成功之前关注个人成功,地位和自我=> 结果阻止

我们的价值观无法直接解决某些功能障碍,例如信任不是我们的价值观之一。与幸福类似,信任是一种结果,而不是您可以直接争取的东西。我们希望我们的工作方式和我们的价值观将灌输信任,而不是强迫人们信任它;获得信任,不给予信任。

更新我们的价值观

我们的价值观会根据需要经常更新。欢迎大家提出改善建议。更新:提出合并请求,并将其分配给CEO。如果您是团队成员核心团队,请在#values频道中发布指向MR的链接。如果您不属于这些组,请直接向@sytses发送Twitter消息。

我们如何强化我们的价值观

您奖励的任何行为都会成为您的价值观。我们通过以下方式增强我们的价值观:

  1. 领导才能做到。
  2. 我们在招聘时选择。
  3. 我们在入职强调。
  4. 我们会互相提供360度(全方位)行为的反馈
  5. 我们称赞的行为。
  6. 我们用于酌情发放奖金的标准。
  7. 我们用于年度薪酬审查的标准
  8. 我们用于促销的标准。
  9. 我们用来管理绩效不佳的标准。
  10. 当我们让人们离开时我们就会做。
  11. Contribute期间,我们给予价值奖。

在负面反馈中,我们应该具体说明问题所在。例如,说某人“ 不遵守价值观 ”是没有帮助的。

任务

我们的使命每个人都可以贡献力量。这项使命指导着我们的道路,我们沿着这条道路践行我们的价值观。