点击上方蓝字关注灸哥聊管理

今天我们俩聊程序员走向技术管理之路的第六个阶段，那就是如何做好一名称职的技术总监。

如何做好称职的技术总监？

今天我们聊聊多团队管理的话题，这里的多团队在一般创业公司的技术团队我更喜欢称之为多角色，比如前端团队、后端团队、算法团队、测试团队、运维团队等，当然根据各家公司的情况不一样，这里面有些团队可能也就 1-2 个人，不过类似这种多团队，对于一名管理他们的管理者来说，你需要有多梯队，在这些人当中需要有明确职责的技术经理或者技术 Team Leader，那这个话题就又回到了你如果带领团队的技术经理/TL 上，你作为这时候的管理者，已经不仅需要直接管理你的技术经理/TL，还需要同步了解他们所带团队的内部情况和一线员工的工作状态。

那此时的你，几乎是完全脱离了实际的编码工作。如果你心和手都很痒的话，那该怎么办呢？下面可以给大家分享我的做法。

这样的管理者在中小型的公司一般 Title 称之为技术总监。那作为一名技术总监，工作的职责有哪些呢？

技术总监的工作职责

结合我过往两年的技术总监工作历程，我管理的技术部门 20+ 人员，涉及到前端研发、后端 Java 研发、测试、运维、大数据、Python 研发的多角色，我对自己的工作职责进行定义和总结有如下内容：

1、团队的管理与领导

技术总监需要负责管理多个跨业务部门的技术团队，确保团队成员能够高效协作，达成既定目标，这里包括对技术经理/技术 TL/技术组长和一线工程师的直接管理，以及通过他们对整个团队的引导和激励。

2、人才招聘与培养

技术总监需要通过招聘和内部培训，确保团队具备持续、高效交付业务需求的能力，同时技术总监还需要设计团队成员的成长路线和培训计划，以促进个人和团队的持续发展。在这一点上是我第一年工作中的重中之重，加入创业公司，原技术不能用，开始一个一个招聘，考虑成本，我一般考虑的是态度第一、能力第二、有技术追求愿意成长的对象。很庆幸，通过一年的时间，我在部门内构建了人才梯队，也培养了一位技术经理、两位技术 TL，这方面我是成功的，而且也有不错的可复制的经验，有兴趣的同学可以私聊，后面我也会专门文章来分享的。

3、技术战略规划

技术总监需要对业界技术发展趋势保持敏感，预研新技术，并参与技术系统的架构和设计工作，通过从产品和业务的角度出发，技术总监要确保技术解决方案能够满足当前和未来的业务需求。切忌技术总监带着技术团队把自己干成外包，做什么，怎么做，什么时候要，什么都听产品的，这就麻烦了。作为技术总监，你的技术战略规划一定要贴着业务和产品方向来的，你要明白，创业公司的首要目标是活下来然后是赚钱，任何脱离业务场景的技术总监都是不称职的，任何不懂业务不懂产品的技术人都是耍流氓。

4、系统稳定性保障

技术总监对关键核心系统的正常运行负直接最终责任，需要在出现问题时参与排错和故障排查工作，这要求技术总监对业务系统有深入的了解，并能在必要时参与代码评审和故障排查。

5、流程优化与基础设施建设

技术总监应该注重对内部开发流程与基础设施的持续评估和优化，构建高效、灵活的团队架构，并根据业务需求的发展迭代技术团队的内部流程，此处的你，千万别套用大厂流程，你没有大厂的条件，你要找到符合你团队客观情况的流程以及一切基于提升效率为目标的基础设施建设。比如运维部署的流水线、项目迭代管理、内部系统的构建、自动化测试体系等等。

6、沟通与协作

技术总监应该也必须成为公司内部跨部门和跨领域沟通、协作的带头人。通过建立短期和长期的技术路线图，技术总监首先要帮助公司保障业务需求和公司收入增长，也就是赚钱啦～同时要保持技术团队的高效交付能力和技术革新能力。

7、培养接班人

技术总监还要在技术团队中构建和培养下一代管理者，俗称接班人，帮助他们平衡技术能力、人事管理能力，确保团队的领导力得以延续、传承和增强。

8、目标设定与团队建设

技术总监应该要帮助团队完善目标设定流程，制定兼顾公司业务方向、技术能力发展以及人事组织质量的团队目标，推动团队向更高的目标前进。我使用了 OKR，但是这里提醒大家，OKR 是工具，不要变成形式和仅仅是个工具，要靠 OKR 做好过程的监督和改进，用真正的适合你团队客观情况的 OKR 来进行管理。关于团队建设，我这五年多的管理历程一直坚持三个方面：思想团建、目标团队和生活团建三者并重，同时推进。

技术总监的编码情怀

随着技术行业的快速发展，技术总监的角色变得越来越重要，作为一家公司技术战略的关键制定者和执行者，技术总监需要在保证技术团队高效运作的同时，引领技术创新和产品发展。然后有一个经常被讨论的话题就是：技术总监是否还应该参与日常的编码工作？

在日常管理工作的重压下，技术总监往往难以抽出时间去进行实际编码的任务。管理工作的复杂性和多样性要求技术总监将主要精力投入在团队协调、战略规划、资源分配、新技术预研等方面。然而，这并不意味着技术总监完全放弃编码。实际上，保持一定程度的编码时间对于技术总监来说，有着不容忽视的价值。不过对于我来说，两年的技术总监工作，我好像对我的本质 Java 放弃了太多太多，最近对 Python 反而更有兴趣了。

首先，编码能够帮助技术总监保持对技术细节的敏感性和理解能力。

通过参与团队内的代码评审，技术总监可以更深入地了解团队的工作内容和面临的挑战，从而可以做出更加客观和明智的决策。此外，对于自己亲自设计的系统和架构，持续的关注和参与是可以确保系统的稳定性和持续优化，尤其是可以可以技术债的范围和影响面（技术债是难以避免的，即使诸如阿里这样的大厂都很难避免，何况一切以赚钱为目的的创业公司呢？）

其次，技术总监参与编码工作也可以增强团队的凝聚力和信任感。

与团队成员共同解决问题，不仅可以传授经验和知识，还能够展示技术总监对技术工作的尊重和热爱。这种正面的形象对于团队的士气和文化的建设是非常有帮助的。

然而，技术总监在编码方面的参与应该是要适度的，过度的编码可能会分散技术总监对管理工作的注意力，影响在战略层面的思考和决策。因此，技术总监应该要找到合适的平衡点，将编码作为管理工作的一个补充，而不是主要任务。我这两年编码任务早期做的还不少，随着人数的逐渐增多，业务上的事情越来越多，我也做的比较少了，但是比较坚持的是参与核心流程技术方案评审、代码评审以及每周周末都会看团队的代码。

对于那些在成为技术总监之前没有充分编码经验的人来说，完全脱离技术工作可能是会带来一定的风险的，技术总监需要具备足够的技术背景和能力，以便在必要时能够深入技术细节，解决复杂问题。这里我提醒以下，千万别不懂装懂，胡乱指挥，比如我在前端就是不懂，其实也是懒得懂，但是我的技术经理是一个前端技术大牛，他对我在前端技术的空缺就是一个非常好的互补。

技术总监的这一角色，在一家公司理，我更觉得他是一个多面手，不仅需要在技术专长和管理能力之间找到平衡，还需要对客户、对业务、对产品都有更多的关注和主导驱动。虽然日常编码不再是技术总监的主要工作，但保持对技术的热爱和参与，是能够为技术总监带来更多的视角和思考，从而更好地服务于公司和团队的发展。同时，也建议每周流出一些时间进行一些创造性的工作，无论是编码、写技术博客、参与开源项目、准备培训内容、新技术的预研等，这些都是技术总监保持技术敏锐度和创新精神的有效方式。

接下来，给大家一起聊聊我在这两年技术总监岗位上比较重要的几个话题，有兴趣交流的同学可以联系我哦！

时间管理之道

对一个技术总监来说，每天的管理任务无穷无尽，自己的自由时光几乎没有多少，更甚者是自己的工作时间也完全不受自己的控制，每天都像打仗。有些人可能就会乱了阵脚，但从我的经历和一些教训上来说，我会告诉你们：这个时候千万不要乱了阵脚！！！

技术总监作为一家公司的技术一号位，每天面对着无数的任务和决策，管理工作的复杂性和多变性要求技术总监具备出色的时间管理能力，以确保有限的时间内完成最重要的任务。所以如何进行有效的时间管理，区分任务的紧急性与重要性，是一名技术总监必须掌握的关键技能。

首先，技术总监需要明确自己的人事管理职责。

这里包括你团队目标的设定、项目团队路线图的细化、跟踪任务的实际完成度等。这些任务对于团队的长期发展和短期效率都至关重要。

然后在日常工作中，技术总监往往会被各种会议占据大部分时间，比如之前说过的一对一沟通、项目计划会议、项目进度报告、团队站会等。在这些会议中，技术总监需要保持清洗的头脑，确保每一项工作都有明确的目标和预期成果，同时也提醒各位总监，请学会开会，对无效率或者不相关的会议 Say No。

时间管理的关键在于区分任务的紧急性和重要性。惯用的就是四象限矩阵。

紧急且重要的任务

比如系统的重大故障的排除，作为技术总监必须确保这些任务得到优先处理，必须立刻做。我在过去的两年技术总监的从业经历中，我聚焦的始终是关注重要且紧急的事情（不做就死、不做赚不到钱的事情）以及重要但不紧急的事情（晴天修屋顶，一般聚焦在战略性事务、员工培养和培训、部门文档库的维护等事情）。

紧急但不重要的任务

我们作为技术总监要保持警惕，比如参加一些不必要的会议，会占据大量的时间，而这些任务可能本质上并不真正紧急，我们要学会判断和识别这些事情，同时要学会在特定时间内集中处理这些任务，减少对其他事项的干扰。

技术总监还需要关注团队内部的士气和沟通流程。在会议中，技术总监应该关注与会者的参与度，确保会议的高效性。如果发现团队中存在问题，如会议变得冗长无聊，技术总监应该及时采取措施，改善团队的沟通和协作。没有一个喜欢开长时间且无聊无用的会议的。

技术总监还应该经常反思自己的工作重点。通过问自己一系列问题，如我目前正在做的这件事到底有多重要？这件事是否仅仅只是看起来紧急而比较重要，而非真正的紧急和重要等，技术总监可以更好地评估自己的工作重点，确保时间被有效利用。

技术总监还需要接受一个事实那就是管理工作往往难以量化，且成绩不易立即显现。即使在一天结束时没有编写多少代码，技术总监也要坚持相信自己已经尽力做好了管理工作。通过持续的自我提升和团队支持，技术总监可以更好地管理时间和任务，引领团队走向成功。

我分享一个我的工作习惯给大家：

• 我每周日晚上会写全部门的周报（用于每周向 CEO 以及管理层汇报的内容），写完周报后，我会对结束的一周进行复盘，同时明确接下来的一周我要做的事情，而且按照 P0、P1、P2 三个优先级标准进行排序，下周复盘也是针对这个列表来的

• 我每天到公司比较早，每天早上我会根据我周日的任务列表，明确今天一天我要做的事情，重点明确今天最紧急的一件事和最重要的一件事。然后我每天晚上下班比较晚，走之前会用五分钟对早上这两件事做个简单的回顾和总结

这里我推荐《清单革命》给大家！

决策和授权之道

作为技术总监，你的工作中可能会充满了各种会议和决策，而一天结束时，你可能会感到筋疲力尽，甚至没有精力去处理个人生活中的简单决策。这种状态在管理者上非常常见，因为管理工作的本质就像是杂技中的转盘子，需要同时关注并推进多个项目和任务。

在这个阶段，决策和授权成为了技术总监工作中至关重要的组成部分。有效的决策能够确保团队目标的明确和实现，而合理的授权则能够提升团队的自主性和效率。我平时的做法是：

首先，做好对决策的紧急性和重要性的甄别和识别

技术总监应该也务必要学会区分任务的紧急性和重要性。对于那些紧急且重要的任务，技术总监需要亲自介入和处理，而对于重要但不紧急的任务，则可以计划和安排在合适的时间内进行。

把简单且频繁的任务授权出去

比如每日站会的主持等，可以授权给技术 TL 或者团队内的资深工程师，这样不仅能提升团队成员的责任感和参与度，同时也能释放技术总监的时间和精力，让其专注于更复杂的问题。

对于简单但不频繁出现的事务技术总监要亲自处理

但前提是技术总监亲自处理比他人做更为高效，这样做是可以避免因为解释和培训指导他人而浪费的时间。

对于那些复杂但不频繁出现的事务

比如团队的季度或年度的绩效考核、部门招聘方案的制定，技术总监可以将其作为培训和提升团队潜在管理者能力的机会。通过共同完成这些任务，技术总监不仅能够传授关键技能，同时也能发现和培养团队中的潜在领导者。

对于那些既复杂又频繁的任务

比如项目计划的制订和系统故障的处理，技术总监应该确保团队中有成员能够独立承担。这要求技术总监投入时间和精力来培训团队成员，提升他们的能力和自信。

授权是一个持续的过程，技术总监需要定期评估授权的效果，并根据团队成员的表现和团队的需求进行调整。通过持续的观察和反馈，技术总监可以更好地理解每个成员的能力和潜力，从而做出更合理的决策和授权。

我是比较幸运的，通过上面的一些策略和措施，我在一年多的时间内逐步建立起了一个高效、自主的团队，同时也能为自己的职业发展腾出更多的空间。技术总监要明确一点：授权并不意味着放弃责任，而是通过培养团队成员的能力，提升整个团队的执行效率和创新能力。只有这样，技术总监才能真正地从转盘子的杂技演员转变为一位成功的团队领导者。

管理中的预警信号

作为一名技术总监，务必会及时识别团队中的一些预警信号，并能很好地应对，这对于你团队稳定的维护以及工作效率的提高是非常重要的。针对我的身边朋友以及我自己管理历程中看到的案例，有一些比较明显的预警信号这里列举给大家。

第一种，员工行为的突然变化。

比如，你团队中摸一个善谈、乐观、积极向上的员工突然变得沉默寡言，开始早退、迟到，工作日无故消失，也不再关注团队聊天信息等信号。这些现象就意味着这位员工要么遇到了个人生活中的问题，要么就是准备辞职了。一般来说，如果是个人生活问题，你是可以和员工讨论并帮助其解决的。比如，亲属得病、人际关系问题、感情问题、健康问题等。如果这是在团队内部的某个调整之后发生的，比如在某个成员升职、团队重组，或者其他重要事件之后发生的，那么这个员工可能就是感觉自己被忽视了。无论是什么原因，都应该尝试和该员工开诚布公地谈谈，争取在该员工提出辞职之前解决问题。

第二种，项目进展报告的不一致性。

比如，你的技术 TL 汇报项目进展一切顺利，但是经常推迟会议，在进度报告中含糊不清，这就意味着他可能在试图掩盖什么东西。在大部分情况下，这意味着项目进度比他的预估要慢得多，又或者他正忙于自己项目之外的另外一件事情。这时，管理者应该介入并帮助该员工提前创建一个完善的项目计划，提前明确如何变更该项目计划，这样该项目的进度就会更加透明。同时，管理者应该帮助员工明确项目的目标和范围，这对某些技术小组长来说可能是很重要的。

第三种，团队会议死气沉沉，员工沉默了。

会议中，只有产品经理和技术 TL 发言，而其他人则完全没有回应，或是只有在领导点到自己的名字时才发言。会议讨论中出现这种消极现象，一般意味着团队成员消极地对待工作，或者感觉自己并没有决策权。这时候作为管理者，要积极客观鼓励团队成员积极参与会议，提倡开放和包容的会议环境，可以适当用一些团队建设活动来增强团队的凝聚力，提高他们的参与度和积极性。但是，千万不要画饼和 PUA，员工都不傻。

第四种，团队的工作计划频繁变动。

比如，每周都有变化，这完全取决于当前客户的想法。这意味着团队缺乏长远计划，只关注如何服务于当前客户。因此，这就需要管理者介入，帮助团队设置好团队的产品方向与业务方向，确保团队工作和公司战略目标一致，提供稳定的工作计划指导，减少对即时客户需求的依赖。如果一个技术团队的绝大部分需求都是 P0 需求，那一定这个团队或者这家公司的战略出现了问题。

第五种，团队成员缺乏跨系统合作。

比如，在团队中大家似乎总是不能达成一致，工程师对自己不直接负责的系统完全忽视，也没有兴趣去学习和了解那些系统，只关注自己的日常工作，而忽视了团队的职责或者作为公司的一员的职责。作为管理者，要强化团队合作和跨系统沟通的重要性，通过培训和工作坊来提升团队成员的系统理解能力，鼓励团队成员参与其他项目，促进知识和技能的共享。

作为技术总监，其实挺累的，需要时刻保持高度的警觉性，及时发现并解决这些问题。

如何 Say No

技术总监不能是一个老好人，不能怕得罪人，他作为技术一号位，一家公司的高管，要做坏人，从学会有策略地 Say No 开始做坏人，要对团队成员 Say No，要对其他团队 Say No，要对自己的上级 Say No 等。

如何有策略地拒绝别人其实是技术总监必须具备的技能，不进可以帮助你维护团队的工作效率和资源分配，还能保证团队在一个清晰、有序的环境中成长。我平时的一些做法分享给大家。

第一种，学会使用积极负面反馈法。

一个管理者在拒绝上级领导的时候一般不直接说“不”。更多的时候，采用“好的，这样的话……”这种开头方式会更好。“好的，这个项目可以做，这样的话，我们需要将计划中的其他项目暂时推迟。”在提供积极反馈的同时，提出自己及团队实际执行的现实困难，是与高级管理层沟通的基本技巧。对很多技术人员来说，积极的负面反馈这种沟通技巧，是需要锻炼才能掌握的。技术人员常常过于关注一个项目目前存在的问题，习惯于张口就来：“这不可能。”作为一个管理者，你应该尝试多利用“好的，这样的话……”的句式与上级领导和同级同事进行沟通。

第二种，制定团队的内部标准。

在处理团队的内部事务时，管理者应该在团队内部推行一套决策机制和标准。比如团队中的一名工程师提议使用一种全新的编程语言，但是团队中的其他人都没有使用该编程语言的经验。该工程师确实提出了一些很有说服力的理由，但是管理者可能会担心这样会给团队增加额外负担。这时候，有的管理者会选择简单地说“不”，并给出自己的理由，直接结束这场讨论。然而，未来可能会有类似的问题重复性地出现。作为管理者，你可能会发现自己不停地在重述某些理由。例如，“不行，我们需要更多的人了解这种编程语言。”“不行，我们需要先学习在生产环境中使用新的编程语言都需要什么。”作为团队管理者，当你发现自己经常重复某些理由的时候，就应该意识到这些应该成为一套成文的团队内部标准。与其不停地说“不”，不如提前制定好一套标准，以及每个决策应该考虑的因素都有哪些。这样做可以让团队成员提前知道如何提出更可行的方案。

第三种，学会用提问式的拒绝方式。

团队的内部标准虽然是一个很有用的工具，但是该标准并不能覆盖所有情况。我这里说的提问式的拒绝方式：“这样做会遇到什么问题？”和事先制定决策标准差不多，但是其更适用于标准较为模糊，需要临时制定决策的情况。如果某些提议考虑得不够周全，那么可以针对某些不是特别清楚的部分询问提议者：“这样做会遇到什么问题？”大部分情况下，提议者会逐渐意识到自己的提案存在的问题，但是这没准也会帮助你意识到你自己忽视的部分。不论结果如何，保持一个开放的心态，针对提议进行探讨，不仅有助于你委婉地拒绝他人的不合理提议，更是一个帮助员工成长的好方法。

第四种，用时间和预算为理由去拒绝。

有的时候可以将拒绝的理由转化为任务的执行时间与预算上的困难，是拒绝团队内部提案和其他团队要求的绝妙好方法。可以将目前手上的待办工作列出来，以说明自己目前实在没有更改的余地。有的时候，你配合“现在不行，以后可以”这种委婉的拒绝方式来使用，效果也不错。采用“现在不行，以后可以”这种方式，你可以暗示对方，其提议本身是没有问题的，只是现在无法推行。很多时候，采用“现在‘确实’不行”，所以“以后再说”是很常见的对策。

第五种，拖人下水团队协作的模式去拒绝。

也有一些场景需要和同级人员一起去说”，尤其是与跨部门，对技术来说，常拖下水的是产品部门或业务部门。这个策略适用于各种级别的讨论。有的时候你可以利用自己的技术专业性来帮助产品部门拒绝某个设计方案。又比如，有时候，你也可以借助公司财务部门的反对意见来驳回某个超出预算的技术方案。不过，和其他部门配合唱红白脸这个策略只应该合理地偶尔使用。利用自己的资源帮助合作团队，就可以在未来需要的时候借助其他团队的力量来支持自己的观点。

第六种，直接而坦诚地拒绝避免兜圈子磨洋工。

作为管理者，如果你已经决定拒绝某个任务，那么就直截了当拒绝，一旦你有这件事情的决策权，并且确实这个方案不行，那就不要兜圈子，直接点。如果未来的某一天你发现你自己错误地拒绝了，你再道歉重来就是了。技术总监，你也是人，你不可能做到每个决定都百分之百的正确，但是一定要多练习自己在低风险、低成本事情上的快速决策能力。