我会使用两种理论模型来辅助组员的个人成长。第一个模型是是 Max Landsberg 模型（出自 Managing Humans：)。这个模型将工作的难度和员工对这份工作的接受度作为两个象限搭建一个四象限图。每一项工作都能归结到某一个象限上。我的目标是让你尽可能做一些最想做同时难度要求又比较高的工作，这样你就能在为 Unity 提供最大价值的同时获得很高的个人成长。
另外一个模型跟这个也很类似，我称之为 ACM（Ambitious, Comfortable, Mundane）模型，这个模型关注的重点在于工作的分配问题。每次你完成了一周的工作或者一次敏捷冲刺，可以停下来分析一下哪些工作是比较具有挑战性的（Ambitious）、哪些工作是做起来比较顺手的，惯例性的工作（Comfortable）、哪些工作可能比较无聊且对于你来说过于简单（Mundane）。
我们需要经常沟通，确保有足够多具有挑战性的工作来确保个人成长，如果有时候你觉得工作上失去了挑战，就应该来跟我沟通，根据具体情况调整你的工作内容。同时我们也希望能尽量减少对于你来说简单的工作，术业有专攻，有些时候对于你来说比较简单的工作可能对其他人来说还挺具有挑战性的。
一个简单的实践方式就是把一个周期内的工作都罗列一遍，然后将每项工作分级。理想状态下，这个单子上应该有适量的具有挑战性的工作，让你保持不断学习的同时也不至于被搞的焦头烂额，还应该没有或者有一点儿无聊的工作，然后剩余的工作为常规性工作来保持平衡。如果你觉得平衡被打破了，就应该找我来讨论一下，通过发现新的工作、改变现有工作内容的形式来恢复平衡。
4. 有效的反馈是关键
关于反馈，除了 Unity 自身的反馈规则外，我还会使用 Radical Candor (https://radicalcandor.com) 中提到的模型。
我会很频繁的给你关于工作和影响力方面的反馈。根据我的经验越及时的反馈价值越高。所以我会尽量在本周的 1 on 1 会议中及时给出反馈。我们会经常性地进行 3Q （https://3qcheckin.com/why-3q）方面的对话来确保及时的反馈。当然如果事情特别紧急我会直接跟你说，而不是等到 1 on 1 的时候。
当然，我也很欢迎关于我的反馈，我也希望通过错误来学习和成长。
译后记从技术人员到团队管理者的转型所带来的不仅仅是身份上的变化，更多的是思维方式和处事态度的转变。Alan 作为一个资深的技术总监，在他的分享中不单是自己的管理哲学和管理方式，同时也指明了一条通往管理者的道路，比如他提到的要从初期开始就进行领导力相关的培养、如何利用好身边的资源等等都在帮助希望走上管理岗位的技术人员梳理脉络。同时他还给出了大量的延伸阅读材料，可供参考，可以说是诚意十足。
另外值得注意的一点是，Alan 对工作分配的要求很高，要减少甚至消灭无意义的重复劳动，这就需要高效的工具来实现——CODING 就能很好地解决这些问题，通过 自动化的研发流程，减少人力的重复劳动。CODING 提供持续集成到自动部署的全过程工具：自动构建、自动化测试、构建物管理、部署交付。支撑项目的快速迭代，保证软件稳定、持续构建和发布。可以无缝对接第三方运维管理工具，支持多种软件交付过程，实现 DevOps 持续交付全流程应用。
CODING 助力开发者轻松成为管理者。