Tech Lead
团队里最资深的工程师，对团队内部技术决策负责，但不负责更上层的工程组织。
Tech Lead 首先是独立贡献者，其次才是协调者。他写代码。他 Review 代码。两位工程师对实现意见不一致时，他拍板。他不是经理：不处理晋升、绩效评估，也不负责本团队之外的招聘流程。最后这条区分，正是把他和 Engineering Manager 分开的那条线，搞错了它代价很高。
在 Wavect，我们常把 Tech Lead 与一位 fractional CTO 一起部署。CTO 负责架构与跨团队协调。Tech Lead 负责本团队日常产出的质量：代码评审标准、团队如何实践 Agile、完成定义是真的还是走过场。把这两个角色混为一谈，是我们在 A 轮初创公司里最常见到的错误。
那个错误，举个实际例子：一家公司把它最好的工程师提拔为「Tech Lead」，然后悄悄堆上 1-on-1、招聘面试和编制规划。半年后代码库因为没有资深的人在评审而漂移，新晋的 Lead 则在把两份工作都做砸的过程中累垮。修法是把分工明确命名出来：技术权威留给 Tech Lead，人事权威移交给一位 EM，哪怕是 fractional 的。
诚实的取舍：一位强 Tech Lead 加上一位外部 CTO 思考伙伴，纸面上往往胜过一位初级全职 CTO，而且便宜得多。天花板是团队之外的决策权。Tech Lead 不负责跨产品的架构，也不负责董事会层面的技术风险，假装他负责，只会推迟你真正需要一位 CTO 的那一刻。
Tech Lead 到底该写多少代码？大多数时间，而这正是创始人悄悄把这个角色弄坏的地方。一旦有人成了「那个 Lead」，本能就是把他拉进会议、规划和协调，直到他每周只写百分之十的代码。一个停止发布的 Tech Lead 会失去团队的技术尊重，并从他本应最深了解的代码库里漂移出去。经验法则是至少一半时间动手，其余花在评审、设计和扫清阻碍上。当协调负荷真正超过这个比例的那一天，你拥有的不是一个超载的 Tech Lead，而是一个没人填的工程管理席位。