前言：
本文为 CODING 教你一步步从一个程序员变身成管理者系列文章的第三篇，文章内容来自 Unity 的一位研发总监，详细叙述了他的管理风格和处事态度，同时列举了很多扩展阅读材料来帮助读者更全面、更深入地了解不同的管理风格，解决职位转变带来的困惑。系列文章地址：
《CODING 告诉你硅谷项目经理的项目管理之道》zhuanlan.zhihu.com/p/65147030
《CODING 告诉你硅谷项目经理的项目管理之道（2）》zhuanlan.zhihu.com/p/65686020
原文地址：github.com/angryweasel…
原文作者：Alan，现任 Unity 研发主管
正文
对于在我手下工作的人来说，请把这份材料当作一份如何与我互动的说明手册。其实在差不多一个月的相处时间后，你都能或多或少地摸清楚门道，但是考虑到你刚刚加入到 Unity 这个大家庭，会有超多的事情需要学习和关注（遥想当年我刚刚加入的时候，一把辛酸泪），因此我整理了这份文档，希望能帮你快速入门，了解我们做事的风格。
对了，即使你已经在公司工作一段时间了，但对我还不是很了解，也欢迎仔细看看，对大家都好。
1 on 1 Meetings
我认为在组内保持信息通畅是非常重要的。每个组员应该每周与我预约一次约 30 分钟的 1 对 1 会议，建议提前选好时间（根据你的时区来），这样可以避免给其他会议或者工作带来冲突。
即使在我出差的时候，我也会按照预定的时间跟你聊聊，但如果我们之间的时区相差太远导致没办法如约进行，我们也可以找个其他时间通过 slack 或者视频的形式进行。因为作为一个管理人员，我需要了解并满足你的需求。我的工作中最重要的部分就是要助你成功，让你在 Unity 的时光有所收获，所以请善用这一点。
你，作为领导者
我做的管理人员的工作是去培养更多具有领导力的人。无论是在管理团队，还是在解决客户问题，你都应该通过自身的领导力来推动团队做出改变，选用更好的工作，采用更高效的流程等等。在推动团队改进研发效率的这个过程中，你会提高领导力并逐步改变对自身的定位。
我会尽全力帮助你成为更好的领导者，在我们每周的 1 on 1 中，我们也会经常讨论领导力相关的话题。我希望你能带着问题来，把你最近在领导力方面的挑战拿出来，我会尽我所能地帮助你克服这些挑战。
只有极少数情况下我会用我的头衔来压人，我主要还是以给你提供建议和解决你遇到的问题为主，从产品质量角度来说，我绝对信任你和你的团队。
我的管理准则
我在读质量控制方面的书的同时也看了大量的管理学和领导力方面的书籍。总的来说，一部分观点还是很不错的，另外一些观点我觉得不行，不过我现在已经有能力能取其糟糠去其糟粕，并逐步开始形成我自己的管理哲学。我也不清楚到底是这些书中的理论在指导我，还是因为我自己的观点得到了书中的肯定从而带来了自信。
长话短说，有 4 个观点能比较完整的概括我的管理准则。
1. 我们之前是同盟关系
我们之间的关系不单单只是管理和被管理这么简单，我们的关系应该是互惠互利的同盟关系，而且目标一致，为对方创造价值和帮助对方成功。在你的工作为 Unity 创造更多价值的同时，我会帮助你在职业规划上和技能提升上带来更好的发展。
如果你想更深入的了解这种同盟关系，可以看看 www.theallianceframework.com/， LinkedIn 的创始人 Reid Hoffman 创立了这种新的管理人员/员工的关系框架，我认为其中有很多值得借鉴的价值观。
2. 指导和独立性
无论你是就坐在我身边还是 1000 公里以外的办公室，你的成功都依赖于你独立解决问题的能力和主观能动性。我作为管理人员的工作仅仅是给你提供必要的框架内容（比如目标和角色之类的），然后我就会从你的眼前消失。在 Unity 工作的大家应该都能很好的跟人共事和解决问题，我只会在需要提供一点方向性指导，或者你有什么需要我帮忙解决的时候出现。当然，有些时候我也可能会插手一些具体事务，这并不代表你做错了什么，仅仅是我觉得我看到了一些新的机会，这么做可能会帮助到你。
One Minute Manager (en.wikipedia.org/wiki/The_On…) 囊括了很多相关的内容。
3. 个人提升是最重要的
我会使用两种理论模型来辅助组员的个人成长。第一个模型是是 Max Landsberg 模型（出自 Managing Humans：managinghumans.com/)。这个模型将工作的难度和员工对这份工作的接受度作为两个象限搭建一个四象限图。每一项工作都能归结到某一个象限上。我的目标是让你尽可能做一些最想做同时难度要求又比较高的工作，这样你就能在为 Unity 提供最大价值的同时获得很高的个人成长。
另外一个模型跟这个也很类似，我称之为 ACM（Ambitious, Comfortable, Mundane）模型，这个模型关注的重点在于工作的分配问题。每次你完成了一周的工作或者一次敏捷冲刺，可以停下来分析一下哪些工作是比较具有挑战性的（Ambitious）、哪些工作是做起来比较顺手的，惯例性的工作（Comfortable）、哪些工作可能比较无聊且对于你来说过于简单（Mundane）。
我们需要经常沟通，确保有足够多具有挑战性的工作来确保个人成长，如果有时候你觉得工作上失去了挑战，就应该来跟我沟通，根据具体情况调整你的工作内容。同时我们也希望能尽量减少对于你来说简单的工作，术业有专攻，有些时候对于你来说比较简单的工作可能对其他人来说还挺具有挑战性的。
一个简单的实践方式就是把一个周期内的工作都罗列一遍，然后将每项工作分级。理想状态下，这个单子上应该有适量的具有挑战性的工作，让你保持不断学习的同时也不至于被搞的焦头烂额，还应该没有或者有一点儿无聊的工作，然后剩余的工作为常规性工作来保持平衡。如果你觉得平衡被打破了，就应该找我来讨论一下，通过发现新的工作、改变现有工作内容的形式来恢复平衡。
4. 有效的反馈是关键
关于反馈，除了 Unity 自身的反馈规则外，我还会使用 Radical Candor (radicalcandor.com) 中提到的模型。
我会很频繁的给你关于工作和影响力方面的反馈。根据我的经验越及时的反馈价值越高。所以我会尽量在本周的 1 on 1 会议中及时给出反馈。我们会经常性地进行 3Q （3qcheckin.com/why-3q）方面的对… 1 on 1 的时候。
当然，我也很欢迎关于我的反馈，我也希望通过错误来学习和成长。
译后记
从技术人员到团队管理者的转型所带来的不仅仅是身份上的变化，更多的是思维方式和处事态度的转变。Alan 作为一个资深的技术总监，在他的分享中不单是自己的管理哲学和管理方式，同时也指明了一条通往管理者的道路，比如他提到的要从初期开始就进行领导力相关的培养、如何利用好身边的资源等等都在帮助希望走上管理岗位的技术人员梳理脉络。同时他还给出了大量的延伸阅读材料，可供参考，可以说是诚意十足。
另外值得注意的一点是，Alan 对工作分配的要求很高，要减少甚至消灭无意义的重复劳动，这就需要高效的工具来实现——CODING 就能很好地解决这些问题，通过自动化的研发流程，减少人力的重复劳动。 CODING 提供持续集成到自动部署的全过程工具：自动构建、自动化测试、构建物管理、部署交付。支撑项目的快速迭代，保证软件稳定、持续构建和发布。可以无缝对接第三方运维管理工具，支持多种软件交付过程，实现 DevOps 持续交付全流程应用。
CODING 助力开发者轻松成为管理者。
