主管与技术团队的分工

我自己是从RD出身的主管，我自己也想了很久，我到底做对了什麽，与可能做错了什麽，让我自己培养出这样的一个团队。不断思考这个问题，除了深怕自己犯错毁了一个团队外，也在寻找蛛丝马迹，试图找到还不错的成功因子，把经验复制到别的地方，扩张影响力。

其中我觉得有一块很有趣的互动，是来自於我与现在技术主力团队的工作界线与分工。

我刚开始的团队夥伴中，有一个不务正业的阿宅，资讯不是他的本行，可是在新东西的学习与运用上，有他很独到的能力，让他能快速驾驭这些东西进行尝试。刚开始跟他一起合作，是改版内部websocket服务，他负责核心的技术开发，我跟他设定使用情境，管理方式，等到专案到一阶段後，我负责对外取得资源测试，他负责数据蒐集。

我们最常混战的地方，就是争论某些业务逻辑到底该放在服务内，或者应该是由呼叫端额外自己开发业务逻辑，服务应该维持乾净。我的思考点是某些逻辑核心完成，使用起来就会比较便利；他的逻辑这些业务逻辑并非每个专案都不变，则这个工具就变成此专案的专属工具，无法通用。但即便对於业务逻辑的置入有冲突的激辩，但我们却能把问题进一步的抽象化转换成工具层面的方式，仍可对对应的业务逻辑做出便利的使用方式。

後来我自己已经在思考转型为专职的管理人，除了自己发现coding的天花板已经到了以外，我觉得整个团队人才济济，不缺coding的肝，但缺少组织规划的脑。刚好我们後续又一起合作带领团队进行一个在GCP上的产品开发。

这个时候我仍负责专案面的进度规划，切细功能，成为前後端沟通的桥梁，但是会学着"退一步"，引导同仁在专案过程中，多一点思考商业目标，与演练如何透过验收Demo缩减双方的认知落差。

这个时候面对後端的工程师团队，我一直给团队一个观念：反正到时候出问题的时候是你们要上来收尾，我不会强制你们要用我的方法，但是团队必须要最小满足我提出的管理议题。而我在意的管理议题就不外乎：log写清楚、维护人力便利度、压力测试、内部白帽骇客执行等等而在面对前端工程师团队的时候，大概只比较在意商业目标上如何追踪，以及是否有过多的特例处理等。

不同於有一些技术背景转往管理职後，死命监管每一个技术细节，我自己选择成为工程师的保护伞，由工程师团队负责"现在"的专案功能，我帮团队思考"未来"上线营运该注意的事情。当他们把当下的进度完成後，我对商业需求的状况想像，帮他们减少重复修改或者新增功能的工作。两个不同角色的团队，各司其职，发挥所长，或许也因为是这样让我们团队仍快乐的工作中吧。

「弟兄姊妹和睦相处是多麽幸福，多麽快乐！」 (圣经诗篇133:1)