在 AI 公司做技术管理的一点体验

其实光标题要怎么概括我都想了五分钟，尽力不写成一个标题党。

本来要写写过去两年的年终总结，想来似乎有不少话可以讲；而太久没认真码字的情况下，怕是很难在一两篇博文的篇幅里好好表述完整。于是决定拆成几个短篇内容聊聊，每篇有一个明确主题。去年开始写东西的心态就很复杂了，大多数时候都要劝自己是“这些更多是写给自己看的记录”，避免输入太多输出太少带来的副作用——缺少从知到行再到沉淀的系统性思考。

这篇是我读了一半《知行：技术人的管理之路》后，想结合实际经验聊聊的一些内容。尽管前文提到想整理自己的思绪，让行文更系统，但也为了避免太过抽象，还是多把一些实践所得的想法穿插进去，使其具有“人味”。本文未涉及任何具体工作内容和公司背景，下文出现人物均为虚构。

角色定位

我之前一直以为，我和不少走上技术管理岗的人一样：有一个契机出现，需要你去带领团队做些事情。即在上家公司时，团队里原先的小组长走之前把很多事情移交到我手上，我负责把做了一半的项目 deliver 上线，中间包括制定技术方案、对齐三个端各种细节（因为是个对外 SDK）、编写外部阅读的 Manual 等等。但最近回头想，其实他离开前我就已经承担了很多不同角色，带新人，做两端的 Code-review、与测试团队及 Accessibility 团队协同帮助改进他们的方案，bottom-up 的方式去提出很多区块链和 AI 落地的场景需求等等。

身边有很多朋友热爱写代码，热爱代码本身、架构的优雅性，但我可能在来新加坡一年后，就变的更 problem-solver。之前在基础架构团队工作（两家这方面的经历加起来两年半吧），同时解决的是团队成员的需求、业务长期迭代的需求以及最重要的技术上本身一些难点，我能在此找到并坚持很多技术上的探索，基本上这也是能写出《Extending Android Builds》的原因。但随着换地点换工作，自己写书过程中遇到的各种人事物，成为 GDE 等各方面历练，我找到了不一样的新个人成长路径。比如提升沟通能力，继续发展大学时锻炼出来的审美思考，寻找有价值的能帮助他人的项目和视野，这些价值无非概括为一超多强、木桶原理。但从每一个点出发，就可以发掘大量之前把自己定位为工程师时没有看到的景色，发现一些自己和身边人的问题，帮助自己和他们去解决问题。

这并不意味着你不再关心技术，相反，我在看完一些技术管理的书后找到了共振频率——我要接触的更多是团队内的系统性的、团队外的延展性的技术内容，包括但不限于 Android iOS App 的整体架构，与之相关联的 UIUX 设计框架，还有为了增强业务理解带来的技术稳定性保障（例如 AI Workflow 的 Eval）、数据挖掘（找到真实痛点产出新的业务需求）等。有些地方会狭义表达为“技术评估”，“技术前瞻”等在技术管理角色中要求的技术能力，我则认为如果身处于创业公司、做着基层的技术管理工作，那么接触一些细节，上手做一些实现是有必要的，不用因为所谓 Vision 放弃了偶尔 venture 的机会。

是的，然后我带着很多想法来到了现在的角色，在垂类 AI 公司担任一位 TL/EM/PO。它并没有这么特别，反倒是事情多的让它显得不特别。多数时候，敢为人先就可以获得大胆试错的机会，做事情的时候仿佛一些大公司刚进去轮岗似的，今天我们需要一些数据就去采数据，明天做完数据分析就写 PRD，后天回归技术主线思考技术选型。这中间会包含很多人和人、团队和团队之间的联结，比在大企业内部更紧密，也让你对自己的角色有了明确的定位。你会从 Day 1 开始从一种顾问角色到后面慢慢感受到创业者乐趣，一步一步跟着公司成长，理解自己是半个乐团演奏者的同时更是指挥家的角色，换句话说是一个“支持型”、“共振性”，而“非指令型”和“完全放手型”的角色。

既然说到这这四个分类，不得不提我听过的两个极端案例：

• 在新加坡，一直声称自己是“支持型”但没有技术背景的职业经理人，只能给到从上往下分配的固定资源，没有任何创新尝试的努力，对个人的职业成长只有言语性的支持没有任何实质性的帮助，最后激励政策按照“年功序列”来。
• 在中国，一直表现出自己是“共振型”但每天半夜三点四点给所有团队成员群发消息的工程师出身经理人，过于想拉着大家一起干活（他也干），但是手活能做到的有限，不理解如何高效的培养团队成员来接手自己不擅长的内容，现实世界并非所有的事情都能一个人冲在最前面。

把力气用到对的地方而非嘴上说说，衍生出我最开始加入时就给自己写的一些座右铭（和角色本身无关）：

• 规范地做完，比完美重要。
• 我们是来一起构建一个赚钱的公司，顺便维护一个大家都体面工作的文化。
• 简单好维护效率高 比 极致性能极致代码优化 重要。
• 创业和守业哪个都不容易，该冲要勇敢冲，该稳要非常稳。

以及一些没有说出来但是一直坚持做的技术管理角色准则：

• 我一定有地方不成熟，但至少不要当个混蛋。
• 不要跟自己团队的人抢着做事情，尤其是技术方面的。
• 鼓励式合作，宣扬每个人所取得的成果，并告诉各个合作方。
• ...

除上面内容外，我自身对该角色定位的最鲜明一个特点，应是“看重团队协作”，我也尽力去表达出这个角色应领导的几种协作共赢：

• 我们在一个小团队也有较为完善的互相 backup 的机制，大家不会有请假的压力，所有人都要有陪伴家人和给自己放个假的权利，今天 iOS 缺人我就去写 iOS，明天我不在也有人可以分担节日活动的上线盯盘任务。
• 每个人有每个人的长处，尽可能让大家都有机会发挥长处，包括培养一些老人、新人能负责的代码之外的内容：运营沟通、产品设计、数据分析等等；从技术的视角、端侧的视角，去产出一些不同的价值，去带给其他人（不局限于小团队内部的）一些启发。一个村小说“教育是大最大的公益”，我这里要表达的异曲同工，“启发式合作是最能长期持续的合作”，三人行必有我师焉。
• 提高信息透明度，分享我对一些业务、技术的个人理解，更早准备未来会发生的事情预案，给到足够多的上下文，帮助大家做更多技术决策；反之亦然，听取更多人的想法，分析消化并转化到实际可以操作的 todo item，鼓励大家吐槽、找痛点、找需求。

管理规划

技术管理的规划，于我而言即思考公司产品战略和团队关系。若详细拆解，可引用书中给的四个关注点：职能、目标、团队、路径。

职能方面，可能对多数人来说觉得至少在创业公司里是简单明了的，比如我负责的是 Mobile App 相关的，那么就关注在这块业务，这个看法就只看到了“职能”的基础层。从前文的描述其实大家已经发现，从公司角度出发而不仅仅自身团队出发，是我思考的核心，特别在协同方面。因此，管理规划中关于职能的定义，在我这里更强调后半段：维护 Android/iOS App 的业务本身只是合格，怎么让这个团队职能产生更多的价值？举一些例子：

• 维护 App A 的同时，思考架构里有哪些可以复用到未来的 App B，提前规划。
• 适配 Android 16/17、iPad 的多尺寸屏幕/响应式时，思考哪些 UIUX 可以和 Web 共建。
• AI Coding 时代，团队积累了一年的经验如何扩展到更多的领域，交叉承担 AI 工具、前后端的一些需求，从新的视角发现增长点等等。

这些例子构建的是“职能”的增值层，除了在技术的绝对指标上去提升价值，还有许许多多能帮助公司、团队、用户的事情值得去做。我感觉过去几年自己有个重要的思想转变是：并非每一个新的延伸点团队都要做到最好，相反，能让大家有这个想法、共识，就已经能带动团队成员去看到更多的业务边界点，发现以前没有思考过的内容。有个不那么恰当的对照是：曾经我对很多大陆的大厂开源项目敬而远之，因为 KPI 导向的维护策略，使得它们没有长期的稳定性可言；但某天一位朋友说，其实开源出来本身就已经有很多价值，可能它们只是没有承诺这个东西可以投入长期生产。这里已经延伸出了”目标“的思考，只是把事情做对不难，找到对的事情去做才难。在多数创业公司里，找到一个合适的目标快速做到 80 分，比把一个 90 分的现有目标/职能做到 92 分来的效果好的多。不固化职能的定义，再不断寻找合适的目标、调整方位，就是我觉得最有收获的事情。

把团队的内容合并去下一节，我们先聊聊“路径”，即通过什么手段来实现目标。思考路径时，团队成员的背景、梯队建设是基础，另外一方面则是公司基因和产品基因。例如，同样是创业公司是，那它是量大抽奖型企业（一些出海做商店买量爆款的），还是专注一个垂类领域的深挖性企业（一些走长期会员付费型的），他们“基因”上要选择的技术路径就是不同的，营销的路径更是。这即是某种角度下的第一性原理，如果市面上什么技术火你就用什么，那显然是只看了招聘的做法，没有思考公司的业务长期适合什么技术路径，业务在什么路径下可以走的更远，拿到更多的留存并打败竞品。

而综合评估下，基因 + 团队合适的技术中有多个选项时，就来到了一些主观判断。这部分就和一些技术管理的“特色”有关系了，有的人用新不用旧，有的人少数服从多数（例如某个技术框架内会的人更多）。我担任当前角色的思路更偏向于：

1. 选择它，它出了问题我们能不能兜住底。例如某个跨端技术无法解决一个问题时，你能低成本降级到其他实现吗？或者某个编译工具、依赖工具，尽管它是开源的，你能在出问题的时候快速找到解法吗？这时候你认识这个领域的专家也好，团队里有某个这方面的爱好者也好，都是一些值得考虑的筹码。
2. 选择这个技术的公司是什么类型的公司，大陆以外地区的独角兽级别公司的选择整体上是我更喜欢的，这类公司往往带有生态建设的身份，使用该技术并发展该技术，大家群策群力到几个核心方向，并且尽可能是维护在一个核心项目而不是各玩各的。
3. 一些小点的依赖和工具，我们能不能把这多个选项的优势聚合来自己做，基于开源项目 fork 修改，适配我们团队的风格；或者增加一些中间适配层包装使其能被内部多个项目复用。

注意，当下即便是 Coding Agent 在面对上述个别问题时依旧有巨大的局限性，例如让 AI 阅读一个大型开源项目从而找到你的问题解法在现实中困难重重（比如 AOSP），对一些核心技术的路径选择要侧重“人”的维度。我想，这部分不仅仅是在 AI 公司、创业公司的思考方式，也是可以在大部分互联网公司所采用的策略。

团队建设

我讨厌书里对马匹和马夫的比喻，包括古代酷刑的一些类比。大家只是负责的职能不同，更应该像是一个乐团里的不同演奏者、首席演奏者、指挥家等，每个人都是演出里的一员。

创业公司的团队搭建是很有趣的一件事情，和大公司截然不同。

大公司的面试多是模版套路，就像高考很多科目是在考记忆力一样，多数大公司的团队面试美其名曰考智力看你聪不聪明，因此做题家是很适合去大公司的——从 HR 开始就全是刻板印象，每位候选人就是一个资源单位，你不来有的是人去面试，你的独特经历在部门老板以下的职位中并没有太多价值，最多是免去笔试的敲门砖。

而创业公司中，技术管理者考量的角度就可以多元起来：

• 学历和优秀的 Github 项目其实没有谁好谁坏，只有谁坚持长期学习和产出。
• 同样的技术背景，候选人如果对自家业务了解的多，对产业信息更敏感，其实更适合来创业。
• 有的人一样技术用十年，有的人每年都在换新的技术，但他们最后都不在面试前看看你家用什么技术，就都很减分——每个人都告诉你来了再学，学习能力很强，但是没有行动上或者至少口头上能说服你。

这并不是在说创业公司的面试普遍更高级，能在 1 小时内抓到更多候选人的匹配点等 —— 不，没有人可以在 1 小时快速了解电话对面那个人的全部。但是多元的 3-5 个 1 小时（3~5轮）带来了更多的覆盖面和可能性，是构建团队的基本输入元素。这就来到了这个小节的重点，以我的想法为例，构造一个 Mobile App 开发团队的构成不应该是 Android 工程师，iOS 工程师，或 Flutter 工程师，TA 可能是：

• 技术背景很厚实的 Android 工程师，同时学过一些 iOS，上架过一个 iOS 的个人小作品。
• 在中资和外企都待过的客户端小组长，业余兴趣是做设计。
• 英语老师转行程序员，从自己写过的一系列独立开发者作品到给开源项目贡献了大量 PR。

我以前在外企待过的一些经验，只给我开阔了下视野，知道这些可能；但在外企圈子也让你发现很多大型外企并未跳脱出假多元化的概念。HR 经常在意的是男女、肤色、语言、国籍等，因为有些东西就是他们隐形 KPI，要做的是符合政治正确的要求或者 CEO 的要求，还要保持公开的美好的形象表现，比如在 JD 里写我们是公平无歧视的。世界不是公平的，没有任何一件事情是公平的，团队成员面试和构成的本身也不是，但让团队构成本身更多样性的意义在于团队韧性以及创造管理规划层面的更多可能，这块在前面已经阐述过不再赘述。

尚未提到的一个考量因素是梯度，我觉得当下复杂度较高的问题。八年工作经验但比较抵触 AI 编程 versus 八年编程经验但刚毕业；同样是老师傅，有技术深度的和有技术广度的；同样是新人，对业务更了解的 versus 对当前技术栈更了解的。AI 能写很多代码，所以有人觉得想法更重要；但有专业老师傅就是能四两拨千斤，从一些不起眼的数字里，基于自己多年经验敏锐发现了下一个爆发点并快速实现。

我觉得多面手在这个时代是被强调的，而梯度的讨论要放到学习能力/自我教育方式的后面，未来团队搭建的重点是找到“发现自己不知道什么/应该知道什么，快速补齐到 60 分“的人，对创业公司来说还意味着找到“面对真实世界真实项目”的人。我很喜欢朋友的一个面试题叫做：讲一个你觉得做的很好的产品，说说为什么你觉得他做的很好。就像找设计参考时，我很喜欢浏览 Mobbin Design 这个网站，也推荐大家去看一本书叫做《设计，下一步》——我们讨论真实世界的真实项目，而真实世界是多样化的。从这个角度出发，结对工作一周的考察、给一个 Coding Agent 现场做个小工具的测试，可能都是更有价值的尝试。

回归做事

按照书里的分类，最后一个部分是任务管理，我认为是不需要多谈的内容。除了应届生外，大部分有工作经验的技术相关人员其实都已具备基础的任务管理素养。正如书中所言“我在各种规模的公司都做过调研，令人欣喜的是，所有的统计结果都显示：任务管理是技术管理者们最擅长的一项管理主题，而且不只是他们自己这么认为，他们的上级也是如此评价。”这本不该是个问题，只是各行各业工作中都存在的一个通用工作技巧，技术管理人员要做好，团队里的每个人也应该做好，是一种通过 SOP 和团队文化就可以优化好的技巧。

我有个偏见是任务管理 + 敏捷开发有关的内容被过于高估，互联网企业里管理方面最为抽象的事情就是任务管理的工作被独立化，对应一些大公司里的 TPM / Scrum Master 角色。我听过一些 TPM 的故事，例如负责一个部门 5 个团队的项目进度，还无法填满一天 5-6 小时的工作，研究的方法论多半是纸上谈兵，没有办法适应现实里五花八门的项目情况。或许有一天专门的研究院或者咨询公司，通过客观统计数据发现某些做法可以优化 SOP 里某部分的效率 5% 10%，但这又持续迭代持续多少次呢？多数情况下仍以项目实际情况来决定，包括 sprint 的时长、发版的周期，各个技术、业务可能都早已有成熟的方案。举个例子，App 发版很难见到每天一个版本，但是 Web 可以，这里不同团队有着大相径庭的任务管理策略。

真正在意这个项目、团队、公司的人，他不需要进度管理；任务的优先级制定和排期只是 Day 1 培训就所知的 SOP 一部分，成为了工作里的不成文规定。基本上要避免的无非是张小龙式的“今天早上开会后大家都知道要做什么了，晚上我想看到结果”；大家都不是圣人，从上往下的技术管理中避免这种事情的发生，规规矩矩的写规划定时间排期，就已经极大提高了团队的效率。更多的方法论包括 AI 时代很多人认为的 10x 的工程师可能页只是个别场景的昙花一现，不是一种直面现实能应用去千奇百怪的项目的方式。

从群众中来，到群众中去，回归到具体的项目里做事就是这个部分最好的答案。