Kickstarter八年制(2之2)

大城市的增长(2011年10月-2014年6月)

在最初的几年中,我们以团队的身份致力于建立健康,自我维持的长期文化。

建筑文化

不断发展的文化的一些特征是请求请求,白天部署,支持开发人员轮换,全员事件响应。 所有这些优点的优点已在其他地方进行了更深入的探讨,因此我将在Kickstarter上重点介绍它们为何以及如何为我们工作。

拉取请求

当团队规模较小时,拉动请求很少见,并且总是引起人们的关注和关注。 我们提早接受了请求请求,因为它们使工程师能够及时了解发生的更改,相互学习,应用样式指南和测试标准,并且可以捕获偶尔的疏忽或错误。

拉取请求使我们的团队能够对我们认为好的代码保持一致。 对话的开放式论坛性质意味着我们可以考虑想法,达成共识并假定大多数人一直在关注。 如果拉取请求在开发周期中发生得太迟而无法合并所有反馈,则对于团队在未来工作中的配合仍然值得进行讨论。

直到大约10到15个活跃的贡献者,拉动请求的数量才产生了足够的数量,人们开始从火水管退订,我们不能依赖于将讨论扩展到普通受众。 我们最终采用了类似于Swift和Rust的内部RFC方法,但是意识到这种必要性已经晚了几年。

总结:团队保持一致的方法将随着时间而改变。 非正式沟通需要形式化,并且在某个时候需要积极地教授和社交成果。 大约十二名活跃的参与者可能是一个很好的第一拐点。

白天部署

我们最初是每两周发布一次,在没有项目结束的情况下将它们安排在一段时间内,并决定足够了。 部署将在一天内开始以较小的部分进行,而我们只需要弄清楚如何进行。 这是我们对自动化测试的承诺开始真正体现出来的地方,因为在繁忙的交通时间内进行部署需要频繁的置信度检查,而这对于重量级的质量检查流程来说是不现实的。

这不是一朝一夕的成功。 我们需要弥补测试套件中的空白。 我们缺少对重要流程的可见性,因此必须建立业务和系统指标的层次结构。 我们通过反复试验学习了如何自信地进行数据库架构更改。 我们进行了投资,以缩短执行提交,进行绿色构建以及从开始一直部署到生产的时间。 我们积累了专业知识和工具,使我们能够应对AWS云计算的所有可变性。 我们还学习了如何在其余所有功能都不够用时使用功能标记进行逐步推出和置信度测试。

值得付出一切努力。 较小的更改风险较小,并且通过允许我们的小型团队在工作时间内保持动力并在晚上真正回家,我们在工具和专业知识方面投入的每一分钟都可提高生产力。

外卖:在工作时间上班。 弄清楚如何做到这一点。

全员事故

当我们在白天开始部署时,个人责任感增强了。 要求每个人在整个生产过程中一直部署他们自己的代码意味着我们避免了将代码扔到生产或部署团队的陷阱。

这也意味着,当事情没有按计划进行时,同事们将更有空余地互相帮助,这可能是怪罪和规避风险的良方,但却有助于将团队联系在一起。 我们已经有了“融合在一起”的心态,但是真正使这项工作成功的是采纳了我们Etsy的朋友们的无可厚非的验尸。 这种事后调查的方式使任何陷入困境的人都有机会变得整洁,感受到同龄人的支持和接受,并分享他们从经验中学到的知识。

要点:比从自己的错误中吸取教训更具宣泄性的另一件事是,首先要教别人如何避免这些错误。

支持开发

像其他任何有流量和客户支持的网站一样,我们也有错误和问题以及无法预期的紧急请求。 我们发现,我们的支持团队已了解到谁最有帮助,并会直接与他们联系以寻求帮助。 我们喜欢支持我们的支持团队的想法,但是需要某种方式来确保适当分担责任。 我们的解决方案是每周一次的支持开发轮换。 该人员将保护工程团队的其他人员免受干扰,同时也将资源投入到支持部门所反映的真正需求上。

随着时间的流逝,这个角色越来越大。 撰写本文时,最新的迭代要求两名具有不同专业知识水平的人员一起为支持请求和错误报告工作,作为一个星期的全职工作。

总结:寻找一些方法来在工程和支持之间建立健康和可持续的关系。 这是可能的。

成长的烦恼

Kickstarter的工程团队在相当长的一段时间内一直规模很小,而今天这一规模还小于人们的预期。 这意味着我们可以避免快速的文化冲击,并以口头传承的方式欢迎每位新员工加入我们的团队。

但这也意味着我们不必投资于更多可重复的过程和文档。 新员工之间的距离足够远,因此入职是不可重复的,并且可能会一劳永逸,从每位员工那里汲取的经验教训在下一次招聘之前都会逐渐消失。

这也意味着我们在组织过渡区停留了更长的时间。 在这个特定的成长阶段,我们面临着对管理的渴望(或明显缺乏)的挑战。 我们都同意,一定规模的管理将变得必要,但我们对将不可避免的事情推迟多长时间持不同意见。 该决定比典型的快速增长的创业公司更困难,因为拐点被延长了。

我们最初是为了获得自主的中高级经验而聘用的。 此人口统计信息可能会歪曲反独裁者,并将非贡献者角色视为组织的间接费用。 扁平化层次结构中的各个贡献者也可以受益于更多地参与对他们影响最大的对话。 无论如何,由于多种原因,我们最终朝着管理迈出了一小步:

  • 我们扁平化的管理层次结构不可扩展。
  • 我们的环境对初级工程师并不友好:我们聘用的相当自治的团队已经将现有的管理资源扩展了很多。
  • 我们有真正对尝试管理感兴趣的人,但是他们没有学习和成长的机会。
  • 当角色变得越来越重要时,我们有可能缺乏内部人才来晋升。

我们的解决方案是针对高级工程师的横向晋升,使他们担任混合管理/贡献者角色。 这为团队提供了管理兴趣的出路,创建了一些基本的可伸缩性,并允许我们开始为工程师提供更高级别的支持。 我们还特意建立了管理关系,以避开事实上的职能部门,因此贡献者会将管理者视为同行而不是权威。 对于我们当前的规模来说,这似乎是一个稳定的解决方案,随着团队的扩大,它自然会成长为专业角色。

要点:组织变革很困难,尤其是当您感觉自己已步履蹒跚时。 交流原因,真诚地倾听问题,并设计一些可以回滚或扩大规模的实验或折衷方案。

插曲

2014年初,当有机会探索专门的领导角色时,我准备回到太平洋西北地区。 我们的工程副总裁正在继续前进,我们需要寻找新的候选人,而不会失去所有进展或使团队破裂。 几年前,我已经拒绝了这个机会,但是从那时起,我便能够与出色的VPE合作,后者为我提供了参与团队和文化讨论的机会,甚至使我有机会承担管理责任。

时间到了。 Kickstarter需要临时领导,我发现自己出乎意料地感兴趣,特别是考虑到搬回西部的逃生之门。 因此,我从个人贡献中脱颖而出,加入了执行团队,并将我的时间花在了团队和公司上半年。

经验是宝贵的。 重新加入产品和战略对话,重新激发了我的热情和抱负,并且完全专注于团队不断变化的需求和挑战,这使我得以探索新的优势和劣势。 我做出了一些坚实的贡献,同时又没有把事情糟透了,然后能够退后一步,观察下一个VPE詹姆斯是如何解决我所面临的挑战的。

要点:几年后,您对职业的想法可能会改变。 不要一直将自己(或其他人)锁定在一个角色上。